ZOOMIE1980 -> RE: A6M2 cant upgrade to A6M3? (8/2/2004 7:58:03 PM)
|
quote:
ORIGINAL: Mr.Frag quote:
Stick to what you know, Fraggo, programming, application design, application performance are what I make my living at and I'm as good as any and better than most at it. Umm, golly gee little programmer dude, what exactly do you think I do for a living for Big Blue? You are just a tad full of yourself at times. Like you are the only person in the world who ever wrote a line of code? I grew up and became an Architect. More full telling your types what to do [;)] As far as your inability to read the posts here by others complaining about how slow the game runs on system blah blah blah, well, I'm not going to repeat all their posts, I'm sure they can slap you silly as far as your goal of making witp run slower then it already does by being pigged out with lots of useless libraries vs tight code routines that let the monster run on 4+ year old pc's [:D] Proof yet, you still haven't a singl;e clue as to what you are talking about. There are ALL KINDS of facilities in this day and age to things a LOT more flexible while still retaining small system footprints without losing speed. (Ever hear of dynamic arrays, hash-maps, etc...) Case in point. I have a "wargame-like" test applet I wrote about four years ago, that uses the wxWidgets class library that I was using to test some scrolling techniques. It has a hex grid of 300x300, somehat LARGER than the one in WitP. It has attached to the "map" over 300 "bases", 100 "airfields" 100 "cities", over 200 "LCU's, 30,000 individual generic "aircraft", 1500 "ships" in 200 "task-forces", all computer generated but still game-like data. Each entity is a fully fleshed out data entity, not an empty object (i.e. I was testing for clean scrolling of a busy, large memory footprint hex map). I did this about four years ago on a PIII 650Mhz machine with 128MB Ram. That is a test system with over 1.5 times the amount of data loaded into it that the ENTIRE WitP database. It uses STL maps, hash-maps, std::lists and few dynamic arrays to store it's data. And I can gain INSTANT access to any hex on the board via two std::maps (by LCU or by "base name", and a hashmap (x,y) coords) and acces to whatever is located there. Now there is no real logic behind the "game pieces" but they are full data elements. It's a standard WIN32 app and the WHOLE THING runs in 6MB RAM!!! By comparison today, I demo a financial settlement system that consists of over 2.5 MILLION lines of code in 31 different processes that go against and Oracle Server, personal edition, on a PIV 2.4 GZ notebook with 512MB RAM. That little test system cranks out 25 million settlement txns a day. COMBINED, the database and application, together, eat up about 350MB RAM. That little demo system is probly 10X or more the amount of code, linked in libraries, and data processing as this game is. What's the difference? These examples have NO candy. No sound, no embedded high-res graphics, no external visual or audio stuff at all. Want to know where your system resources are being eaten up? It damned sure as HELL is NOT in the data processing parts of the code, unless they are using some really dumb techniques. It's in all that background sound and pretty video-graphics stuff. If have a full copy of Visual Studio installed run their little DirectX sample that basically loads up a DirectX session and displays a litte 3D object bouncing around......look at the memory that thing eats up! Don't talk to me about high volume data processing, and that is what WitP is, a data processer with a psuedo real-time presentation layer. And that processing is NOT what is costing resources. The thing that forces the bottom end of computer resources up, even in wargames, is sound and video enhancements, NOT in how the programmers are dealing with the data and its processing. As I stated, there is NO reason to code turn based wargames the way GG and Co., do it anymore. Not one, other than the time to invest in learning a new way. And, of course, that may very well be reason enough...
|
|
|
|