RE: Improvements to the Speed of Calculations?

RE: Improvements to the Speed of Calculations? (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III

Message

larryfulkerson -> RE: Improvements to the Speed of Calculations? (6/27/2006 9:34:29 AM)
quote: ORIGINAL: ralphtrick As a short term fix, I also might look into moving things out of this 300x300x48 array, and into a 300x300 array. Then things like clearing the array, etc. might be faster If it's an array of chars, then if it's contiguous, then why not do a memove of '0' for 90000 chars. Would that be any faster?

Szilard -> RE: Improvements to the Speed of Calculations? (6/27/2006 10:05:38 AM)
quote: ORIGINAL: JAMiAM quote: ORIGINAL: Szilard The optimal-reentry-point issue should be easy to fix. Delete "optimal", and just do something like: on/adjacent to unit's formation HQ; or if none, on/adjacent to a cooperative HQ close to evaporation position; or if none, on/adjacent to a nearby supply point; or if none, don't reconstitute. I don't know about that being an "easy" fix, since it would require a major departure from the current model of a 1-4 week window, and fixed position, for the reconstituted units appearing. Now, if sufficient equipment is available, then it is pulled, committed to a unit, and the unit is stuck on the scheduled reinforcements track to appear at a specific position, at some point in time 1-4 weeks away. To have it dependent upon "finding" an HQ to reappear next to, when the time comes for it to show up on the map, and failing that either redump the equipment into inventory, or continually be reassigned a new reconstitution point based on HQ's that may or may not still exist on the map, seems to me to be inherently more problematic. Fair enough. I'd be OK with just reconstituting at a supply point.

a white rabbit -> RE: Improvements to the Speed of Calculations? (6/27/2006 12:44:36 PM)
quote: ORIGINAL: golden delicious quote: ORIGINAL: geozero BTW - I used a Commodore which only booted up from a 5.25" floppy. That's nothing. Before the ST we had a Commodore which loaded of cassette tapes. Those were the days. ..16K Spectrum then upgraded to a 48K, coal fired

golden delicious -> RE: Improvements to the Speed of Calculations? (6/27/2006 2:05:08 PM)
quote: ORIGINAL: JAMiAM I don't know about that being an "easy" fix, since it would require a major departure from the current model of a 1-4 week window, and fixed position, for the reconstituted units appearing. Now, if sufficient equipment is available, then it is pulled, committed to a unit, and the unit is stuck on the scheduled reinforcements track to appear at a specific position, at some point in time 1-4 weeks away. To have it dependent upon "finding" an HQ to reappear next to, when the time comes for it to show up on the map, and failing that either redump the equipment into inventory, or continually be reassigned a new reconstitution point based on HQ's that may or may not still exist on the map, seems to me to be inherently more problematic. A quick thought here: you could bar reconstitution of component units of a formation which has lost its HQ, with the exception of the HQ itself. This serves to make HQs more valuable and also means that if a formation really gets smashed up it'll take a good deal longer to recover.

ralphtricky -> RE: Improvements to the Speed of Calculations? (6/27/2006 7:44:27 PM)
quote: ORIGINAL: larryfulkerson quote: ORIGINAL: ralphtrick As a short term fix, I also might look into moving things out of this 300x300x48 array, and into a 300x300 array. Then things like clearing the array, etc. might be faster If it's an array of chars, then if it's contiguous, then why not do a memove of '0' for 90000 chars. Would that be any faster? [;)]

ralphtricky -> RE: Improvements to the Speed of Calculations? (6/27/2006 7:47:12 PM)
quote: ORIGINAL: a white rabbit quote: ORIGINAL: golden delicious quote: ORIGINAL: geozero BTW - I used a Commodore which only booted up from a 5.25" floppy. That's nothing. Before the ST we had a Commodore which loaded of cassette tapes. Those were the days. ..16K Spectrum then upgraded to a 48K, coal fired ..Altair 8800, built from a kit, fully loaded with 1024 Bytes of memory. Directly set the inputs using toggle switches, the only output is direct read of memory, or toggling the memory protect light (also played Mary had a Little Lamb on the AM radio.) Top that[:D]

Captain Cruft -> RE: Improvements to the Speed of Calculations? (6/27/2006 11:50:44 PM)
Here's an off the wall idea. I have no clue as to whether it's feasible or not. Have a background thread which maintains a separate copy of the map array and unit data. Each action in the orders phase needs to update this copy, obviously. These updates would need to have a notion of the set of "affected hexes" and "affected units". Then, have the background thread continually doing the supply calcs and whatnot. So, come end of turn, it's probably about 95% of the way there already. This is something like the way virtual memory works. Or database caching. We need to get away from only doing one thing at once. Probably a nightmare to program mind you.

ralphtricky -> RE: Improvements to the Speed of Calculations? (6/28/2006 2:12:02 AM)
quote: ORIGINAL: Captain Cruft Here's an off the wall idea. I have no clue as to whether it's feasible or not. Have a background thread which maintains a separate copy of the map array and unit data. Each action in the orders phase needs to update this copy, obviously. These updates would need to have a notion of the set of "affected hexes" and "affected units". Then, have the background thread continually doing the supply calcs and whatnot. So, come end of turn, it's probably about 95% of the way there already. This is something like the way virtual memory works. Or database caching. We need to get away from only doing one thing at once. Probably a nightmare to program mind you. There are a bunch of things I can do. I need to find the bottlenecks first. I hope to cut down the speed using some simple things first. A thread is probably overkill unless I decide to use monte carlo simulation for the AI.

Szilard -> RE: Improvements to the Speed of Calculations? (6/28/2006 3:32:48 AM)
quote: ORIGINAL: ralphtrick There are a lot of things I can do. Probably the biggest help for the supply lookups is to look into rewriting it using the newer A* pathfinding algorithms. I'll have to write all that first, of course.[;)] Would that make such a big difference? I'd have thought it'd be the normal kind of thing where pruning the number of paths would give much bigger wins than optimizing individual path finding. Fun to play around with, anyway :)

ralphtricky -> RE: Improvements to the Speed of Calculations? (6/28/2006 3:55:54 AM)
quote: ORIGINAL: Szilard quote: ORIGINAL: ralphtrick There are a lot of things I can do. Probably the biggest help for the supply lookups is to look into rewriting it using the newer A* pathfinding algorithms. I'll have to write all that first, of course.[;)] Would that make such a big difference? I'd have thought it'd be the normal kind of thing where pruning the number of paths would give much bigger wins than optimizing individual path finding. Fun to play around with, anyway :) Maybe not, but it's a lot more fun to play around with. [;)]

CommC -> RE: Improvements to the Speed of Calculations? (6/28/2006 4:21:39 AM)
"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.

Captain Cruft -> RE: Improvements to the Speed of Calculations? (6/28/2006 4:49:08 AM)
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.

larryfulkerson -> RE: Improvements to the Speed of Calculations? (6/28/2006 5:01:30 AM)
quote: 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.

ralphtricky -> RE: Improvements to the Speed of Calculations? (6/28/2006 5:40:00 AM)
quote: 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.

XPav -> RE: Improvements to the Speed of Calculations? (6/28/2006 10:28:33 AM)
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.

a white rabbit -> RE: Improvements to the Speed of Calculations? (6/28/2006 1:47:53 PM)
..as far as speed goes, i'd say toaw3 is faster than toaw-acow ..based on the Imphal scen

ralphtricky -> RE: Improvements to the Speed of Calculations? (6/28/2006 4:43:57 PM)
quote: 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> quote: 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. quote: Have fun. Oh, I definitely am. Picture scenario design on a HUGE scale<g>

a white rabbit -> RE: Improvements to the Speed of Calculations? (6/28/2006 6:05:26 PM)
..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..

XPav -> RE: Improvements to the Speed of Calculations? (6/29/2006 6:30:26 AM)
quote: 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!

ralphtricky -> RE: Improvements to the Speed of Calculations? (6/29/2006 6:55:23 AM)
quote: ORIGINAL: XPav quote: 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.

Page: << < prev 1 [2]

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

1.75