1  2  |   Order by default

May 11, 2005, 5:52pm

[View Quote] Those requirements seem a bit botched as well. There are games more
intensive and require less.

But I guess when you optimize for C++ _and_ MFC(!), hey.

May 11, 2005, 6:14pm

[View Quote] I recommend a unicorn as primary mode of transportation through a patch
of pies.

May 11, 2005, 7:13pm

[View Quote] I knew C++ before you finished your little VB escapades. So, if I
really wanted, I could. You want me to make a VB bot, VB.NET bot, C++
bot, C++.NET bot, C++ with GTK, C++ with MFC, the choice is yours.

But everyone and their mother has made a bot similar to yours, so there
really is no point.

May 11, 2005, 7:35pm

[View Quote] No real point now. Whenever you want to be the bigger man and admit
that not even you are perfect, then I can do it for ya. *shrug* pull an
Eep.

May 12, 2005, 1:43am

[View Quote] Nothing new. I don't rule everything, but I can do things better than him.

Jun 3, 2005, 12:58am

[View Quote] It's almost like Jacob evolved into some... thing.

May 11, 2005, 3:07am

[View Quote] How would adding another connection in-between, help at all? You may
want to look at your code, development system as the source rather than
the SDK. So if you're using, let's say , .NET, you're looking at some
overhead that you probably don't need.

You may want to actually pinpoint where the cause of the slow-down is.
I doubt very much that it's the SDK. But rather your connection (which
won't speed up by using a proxy), or your system itself.

--
--Big O

Jun 1, 2005, 1:04am

[View Quote] Timers are fine with a -1. Be careful with multi-threaded applications
with the SDK.

Jun 1, 2005, 1:06am

[View Quote] I need to ask you a small favor, please use decent grammar. I know it's
a pain but it really helps us to help you in the end.

Most programmers will be able to find errors in your code if they can
understand you. Also, link to a code file instead of copy and pasting.
(if you don't want to show the whole code just copy it to a new file and
show all related functions that are called -- use geocities to host it
or something)

Apr 20, 2005, 6:31pm

I guess that makes the code too advanced for someone like you. At least
get the spelling correct on the url.... geesh

[View Quote]

Apr 20, 2005, 6:39pm

[View Quote] I'm willing to bet that you didn't cry.

--
--Big O

Apr 21, 2005, 6:59pm

[View Quote] No, unless everyone has a problem with the word "village."

I'm sure all that cared fixed it for themselves. Just because I noticed
the mistake doesn't mean I want to go and fix it for you. You have to
learn how to use the spelling checker someday. Or at the very least,
test your links before you hit submit/send.

--
--Big O

Apr 22, 2005, 1:39am

[View Quote] It wasn't, until he found it bright to retort with an equally asnine
comment about how I'm just as stupid for not correcting. Such a pithy
argument.

Had he not commented on how Brant's coding style, his perfection
wouldn't have been so transparent.

--
--Big O

Apr 22, 2005, 3:58pm

[View Quote] I don't, I just don't like people who act like they're the best thing
since the wheel.

--
--Big O

May 11, 2005, 5:52pm

[View Quote] Those requirements seem a bit botched as well. There are games more
intensive and require less.

But I guess when you optimize for C++ _and_ MFC(!), hey.

May 11, 2005, 6:14pm

[View Quote] I recommend a unicorn as primary mode of transportation through a patch
of pies.

May 11, 2005, 7:13pm

[View Quote] I knew C++ before you finished your little VB escapades. So, if I
really wanted, I could. You want me to make a VB bot, VB.NET bot, C++
bot, C++.NET bot, C++ with GTK, C++ with MFC, the choice is yours.

But everyone and their mother has made a bot similar to yours, so there
really is no point.

May 11, 2005, 7:35pm

[View Quote] No real point now. Whenever you want to be the bigger man and admit
that not even you are perfect, then I can do it for ya. *shrug* pull an
Eep.

May 12, 2005, 1:43am

[View Quote] Nothing new. I don't rule everything, but I can do things better than him.

Jun 3, 2005, 12:58am

[View Quote] It's almost like Jacob evolved into some... thing.

May 23, 2005, 2:51pm

[View Quote] I think the 32bit one would perform just as fine in a 64 bit operating
system as it does in 32bit. There would probably be almost no noteable
difference.

I'd rather a *nix version. ;)

May 23, 2005, 3:45pm

[View Quote] I'd agree with you if it were a mission critical application like a
server. Something like AW would probably have little to no difference.
But the only way to tell is to have a 64 bit version.

All you need is the graphics driver now for the 64 bit system now. :)

May 23, 2005, 4:14pm

[View Quote] They need to probably start all those systems from scratch (basically
the whole browser) with those things in mind. Or at least a module
system that they can build into. Each time they add something they have
to work around something they've done previously.

Maybe allow each seperate world to load modules they want to use.
Terrain, Water, whatever. Basically the server scripting they were
going to add a while back, but with more pizaz.

May 24, 2005, 5:46pm

[View Quote] Not so likely here, AWI uses an older version of renderware. Meaning,
not the current version, and hasn't been for a while.

> 64 Bit is not just for servers and mission critical processing its also
> geared to home entertainment for high quality video and audio such as
> cinematography and 3d rendering.

3D rendering is not really what we see when you think and generally want
to talk about 3D rendering. Building meshes with 3DS max and animations
is more along the lines of what you're infering here. Simply drawing
polygons on a screen is not really 3D rendering.

I won't deny that it will give boosts in performance, but nothing much
more than what you could do using 32bit legacy applications running
under the 64 bit processor. In AW's case, anyways.

> It also would be easier to do a 64 bit binary then to rewrite the whole of
> the client to have linux support for which I tell people over and over runs
> fine using WINE anyway, stop bitching about a linux specific client if you
> ever want to see a new version in the next 5 years cause AW would have to
> start over and rewrite half the client.

I never denied that it couldn't. The client needs to be rewritten. The
features have become convoluted because of previous features. Terrain
and water working together, for instance. (Not being able to have
different heights for water, water under terrain, et. al.)

> Thing is you could do much more advanced terrain details you could actually
> make each cell curve to the next rather than having terrain such large
> squares because the processing power to calculate these things would be
> there.

Or just precompile some sort of terrain information if the terrain is
now static. The power is there in non 64bit processors as well. The
problem is people usually run quite a bit more software when running AW
than they would, with say, Half-life 2. It's a different type of
software, it's not really a game, that's why users treat it differently.
This is not necessarily a bad thing, but it tends to slice down the
CPU time AW uses and can use.

May 24, 2005, 5:57pm

[View Quote] Well, if you understand what I'm saying, it's that the 64bit processor
is developed for applications like that. Not to say it won't give
benefits to AW, but AW most likely uses direct calls to the graphic card
and it's interface (DX/OGL), as opposed to mathematical formulae to
actually build the model's binary form, and so on.

From what I understand the 64bit processors have their memory
controller directly in them, which is probably where the real boost
comes in.

The only real problem I see with a 64bit version is that it needs more
time that they don't have. Building on top of a 32 bit piece of software.

May 25, 2005, 12:32am

[View Quote] Please tell me you aren't using a "I can only go up to 4 GB of memory
with 32bit" as the argument as why it should be upgraded. ;) I can see
the rest, but that was just a stupid useless fact. Home users will be
fine with 4 gigs for probably 5-10 years now. Hell, 512 is more than
enough for normal users and most gamers.

May 25, 2005, 2:14pm

[View Quote] There is absolutely no reason for an operating system to use so much
memory. At all, there is no excuse for it. The operating system gives
the interface to devices. And yes, 16 MB is enough for certain things.
Hell my friend is running a webserver on that much.

I really see no ungodly reason for the gigantic memory limit. It may be
needed in certain instances, but last I recall windows wasn't the only
operating system. I think Redhat used to support well beyond 4 gigs on
a 32bit system.

Things will use it in the future, yes, but distant future and for things
home users have no use for. The arguement is flawed that that much ram
would be necessary for a home user at this point in time, or even in the
near future.

The reason Longhorn uses so much memory is probably for the reason most
of the software is server-ed (so I hear), so it needs to download it and
load it into memory. Bad design, but I suppose good against piracy.

Apr 20, 2005, 6:29pm

hey there

[View Quote]

May 11, 2005, 5:52pm

[View Quote] Those requirements seem a bit botched as well. There are games more
intensive and require less.

But I guess when you optimize for C++ _and_ MFC(!), hey.

May 11, 2005, 6:14pm

[View Quote] I recommend a unicorn as primary mode of transportation through a patch
of pies.

1  2  |   Order by default