Matrix Games Forums

"thousands of calculations" is indeed a trivially small number for modern computers.


"C++, integer arithmetic"

Well, that explains it. C++ is primarily a business language and while it is far better than Fortran, Visual Basic and similar, it is still a pretty slow, high level language. If more of TOAW's calculation intensive operations can be done using machine language calls (or another faster language) that might greatly speed things up.

I like where this thread is going, with brainstorming on ways to speed things up. I like the idea of simplifying the supply calculations as a potentially easy fix to the slowness observed.

Hey that's the answer, just re-write the entire game in assembler! Better yet, blow the code onto a chip and get somebody to manufacture it on a PCI card. No digital download that way though ... [8|]

Sorry [;)]

Seriously, I don't think it's an issue of language. C/C++ are fast enough, indeed they are generally regarded as the fastest compiled languages in common use.

It's more a matter of algorithms and methodologies, like Ralph said.

ORIGINAL: CommC
C++ is primarily a business language....

Hmmmm....that's strange I'm a retired computer programmer, worked with computers for over twenty years and I've never heard it described that way. I've never thought of it that way. I have seen it used to build operating systems. I have seen it used to build some of the fastest games on the planet. CommC, my man, you've probably never met Cobol.

ORIGINAL: Captain Cruft
Seriously, I don't think it's an issue of language. C/C++ are fast enough, indeed they are generally regarded as the fastest compiled languages in common use.

It's more a matter of algorithms and methodologies, like Ralph said.

Given that it's C++ in name only, and is still essentially C code, I don't think that it gets any faster than that. Even C++ with the modern compilers and a bit of attention to the design is going to be fast enough.

I can do a lot with the algorithms. The original code was written to be understandable and take up little memory. There also weren't a lot of published works on game programming when it was written.

Don't worry, there are a lot of concepts that I can borrow from the RTS and other communities. I've got all the game programming gems books to reference, plus some others.

My first advice as someone who just spend the day figuring out why his own C++ code was running slow:

1) Don't trust yourself to guess why the code is going slow. Ignore your gut. Time your code.
2) See rule 1.

If you're not using Visual Studio 6.0 (the last version that had a profiler without going for the $$$ Edition), you can cobble together some timing classes that should work well. Start timer on construction, output tim on destruction when they fall out of scope. Helped me find my problems.

Sounds like Norm did a good job though with his original code, and the main thing making the huge scenarios run slow is, well, because they're huge.

Have fun.

..as far as speed goes, i'd say toaw3 is faster than toaw-acow

..based on the Imphal scen

ORIGINAL: XPav
If you're not using Visual Studio 6.0 (the last version that had a profiler without going for the $$$ Edition), you can cobble together some timing classes that should work well. Start timer on construction, output tim on destruction when they fall out of scope. Helped me find my problems.

Visual Studio 2005. The same tools still work, BTW. I've been doing more the Break and see where I am style of timing at the moment<g>. It is C code, so there are no objects. I plan to fix that for my own sanity over the next coupld of years.<g>

Sounds like Norm did a good job though with his original code, and the main thing making the huge scenarios run slow is, well, because they're huge.

That's a large part of it. He also has some algorithems that scale geometrically. 300x300 is 10 times bigger than 100x100. If you multpliy by the extra units, it gets even worse.

Have fun.

Oh, I definitely am. Picture scenario design on a HUGE scale<g>

..is there any way to slow Elmer down ? esp when he's moving units, blink and he's attacking, how he got there remaining a mystery..

ORIGINAL: ralphtrick
That's a large part of it. He also has some algorithems that scale geometrically. 300x300 is 10 times bigger than 100x100. If you multpliy by the extra units, it gets even worse.

Ahhh.... O(N^2)

Yay!

ORIGINAL: XPav

ORIGINAL: ralphtrick
That's a large part of it. He also has some algorithems that scale geometrically. 300x300 is 10 times bigger than 100x100. If you multpliy by the extra units, it gets even worse.

Ahhh.... O(N^2)

Yay!

Yep. I'm thinking I can find some algorithms that are O(n log n) at worst, or teach it about land masses, and cut down on how big the search space is.

I can also do a lot to trade storage space for time, and avoid the calculation altogether.