Giel wrote: If you are using Windows and experience bad performance, please try the fixed exe instead, which has a workaround for ATI drivers switching into software mode!
I don't think a 3dfx card would be able to handle the game.Mr. Impact wrote: Hi, DevUrandom
Thank You for the fast reply.
Next weekend I will test the new exe with the first listed Computer.
I will write my experience in this forum.
The PII with the Voodoo-Card was tested with the new File, but it won´t work. :'(
much greez
Mr. Impact
Code: Select all
Module Name Total % Timer samples
atioglxx.dll 35.81 14351
processr.sys 34.31 13748
ntkrnlpa.exe 6.05 2426
warzone2100.exe 4.50 1802
4 modules, Total: 32327 samples, 80.68% of total session samplesCode: Select all
CS:EIP Symbol + Offset Total % Timer samples
0x805b19f6 NtFreeVirtualMemory 0.80 322
0x8050080c ZwYieldExecution 0.55 219
0x8053fcf8 KeReleaseInStackQueuedSpinLockFromDpcLevel 0.42 170
0x80518a28 MmTrimAllSystemPagableMemory 0.34 136
0x80616e64 LsaDeregisterLogonProcess 0.26 105
0x80544c00 KiDispatchInterrupt 0.26 103
6 functions, 424 instructions, Total: 1055 samples, 43.49% of samples in the module, 2.63% of total session samplesCode: Select all
CS:EIP Symbol + Offset 64-bit Total % Timer samples
0x585a20 SDLNet_Read32 3.58 1434
0x5cd6e7 SDLNet_Read32+294087 0.17 69
0x5cd6ee SDLNet_Read32+294094 0.16 66
0x5cd2e2 SDLNet_Read32+293058 0.04 17
0x5df333 SDLNet_Read32+366867 0.03 11
0x5de298 SDLNet_Read32+362616 0.03 13
0x5d87eb SDLNet_Read32+339403 0.03 11
0x5ccd32 SDLNet_Read32+291602 0.03 14
0x5ccd30 SDLNet_Read32+291600 0.03 14
0x5ccd2a SDLNet_Read32+291594 0.03 14
0x5ccd20 SDLNet_Read32+291584 0.03 12
0x5a2571 SDLNet_Read32+117585 0.03 13
0x5a2561 SDLNet_Read32+117569 0.03 11
0x5a253f SDLNet_Read32+117535 0.03 11
1 function, 13 instructions, Total: 276 samples, 15.32% of samples in the module, 0.69% of total session samples
Hi, thanks for the input.OvermindDL1 wrote: That is the profile of it and its usage in order of time taken, the top 13 are displayed as they were the most, they are all pretty well like that however. What is interesting here is a couple reasons, first, not enough time is taken up to account for a slowdown, so this is not really an issue, definitely something with the OpenGL code no doubt is the reason for the slowdown. Second, for just being a network function to read an int32 it seems to take up a rather tremendous amount of time, even extracting an int32 from a bitstream is faster, and that should be slower. Third, why is this function being called at all in single player (tutorial of all things)?
Overall, it seems the code has an odd slowdown in relation to some SDL functionality. The SDLNet_Read32 is seemingly being called needlessly, and even for being called it seems to slow, however this does not account for the main issue as to why there is a frame being rendered once every 3 to 10 seconds. That is obviously due to the way OpenGL is handled, which I could probably take a look into as all my 3d programming takes place on this very computer, in this operating system install, and all in OpenGL, and I have never ran into a speed issue on my Radeon x1950xt (it consistently outperforms all the other brands I have installed in other computers here for my OpenGL code), so there is obviously something being done in the code to cause this software mode switch (which I could try to debug into the code if I get time to download it and watch the gpu profiler to see what instruction is causing the switch to take place).
I do have to ask though, what possessed whom-so-ever to choose SDL? All my encounters with it have been that it tries to make things look easier to use, but ends up being so freakishly harder then if you just do it yourself with other libraries, not to mention it does have quite a few bugs that have bit me in the rear...
Not surprising, as it renders in software.OvermindDL1 wrote:Now obviously post of the time is being spent in the OpenGL part of the ATI drivers
Whatever that may be, probably also something to do with the software rendering.with the next most being spent inside processr.sys
Which isn't that much, especially considering that it's running roughly a hundred times slower than it's supposed to. Run at the usual speed, the profile might look completely different.In the warzone2100 executable, a tremendous amount of time (3.56%, the next highest being only 0.04%) being taken up by SDLNet_Read32
I think the netcode always runs, to have less different codepaths between single and multi player.Third, why is this function being called at all in single player (tutorial of all things)?
It is simple, tested, available on all platforms (and was three years ago when work on the source began) and there are way more important things to do than exchange the backend again.I do have to ask though, what possessed whom-so-ever to choose SDL? All my encounters with it have been that it tries to make things look easier to use, but ends up being so freakishly harder then if you just do it yourself with other libraries, not to mention it does have quite a few bugs that have bit me in the rear...
Why? Evidently ATI regards GL_TEXTURE_MAX_LOD as not important enough to support it in their driver (which I can understand, as the difference to GL_TEXTURE_MAX_LEVEL is a) not very obvious, and b) quite useless, imo). And I set it to 3 for a reason, even if 1000 worked, we could just omit the complete line.OvermindDL1 wrote:Just as a test, have you tried glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LOD, 1000); just to see if it causes a slow-down on systems where people experience it?
A good profile might be interesting, though currently the graphics engine is the main problem - no change to any other code will make much difference.EDIT1: I used to use a few different profiler's, but anymore I pretty much just use CodeAnalyst. It is far more useful then what I showed earlier when the symbols and source code of the app you are profiling are on the computer though.
You need libphysfs, flex and yacc for that.EDIT3: Also unable to find physfs.h, script_lexer.lex.c, script_parser.tab.c, probably a few others...
As far as I remember SDL was the least of our problems, I see no reason to use anything else.EDIT4: And no SDL is not the only thing that supports Win/Mac/*Nix, there are other, vastly better things, not an all-in-one like SDL is, but easier to use and made well.
On the GNA site, you can get most of the stuff you need: http://download.gna.org/warzone/development/OvermindDL1 wrote: I get an alert when a new driver comes out, so I always stay updated (kind of a necessity for what I program, I like to see if things break with new drivers...).
Just as a test, have you tried glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LOD, 1000); just to see if it causes a slow-down on systems where people experience it?
Are there any dependencies I should download to compile the trunk, or is it all self-contained?
EDIT1: I used to use a few different profiler's, but anymore I pretty much just use CodeAnalyst. It is far more useful then what I showed earlier when the symbols and source code of the app you are profiling are on the computer though.
EDIT2: I downloaded the trunk, got sdl 1.2.12 (latest stable). And my compiler appear incapable of full C99 support (varidic macros to be exact...), may need to change those before I can do anything...
EDIT3: Also unable to find physfs.h, script_lexer.lex.c, script_parser.tab.c, probably a few others...
EDIT4: And no SDL is not the only thing that supports Win/Mac/*Nix, there are other, vastly better things, not an all-in-one like SDL is, but easier to use and made well.
Code: Select all
Module Name 64-bit Total % Timer samples
processr.sys 54.96 22359
warzone2100-clamp_maxlevel.exe 8.19 3331
ntkrnlpa.exe 7.98 3246
3 modules, Total: 28936 samples, 71.13% of total session samplesCode: Select all
CS:EIP Symbol + Offset Thread ID Total % Timer samples
0x5124cf NO SYMBOL 0.17 101
0x5124f5 NO SYMBOL 0.16 96
0x42d2d2 NO SYMBOL 0.13 79
0x5124e2 NO SYMBOL 0.12 73
0x5124d5 NO SYMBOL 0.12 75
0x42a283 NO SYMBOL 0.10 58
0x5124f0 NO SYMBOL 0.09 53
0x5124dd NO SYMBOL 0.09 54
0x58fc70 SDLNet_TCP_Open 0.05 28
9 functions, 16 instructions, Total: 617 samples, 19.91% of samples in the module, 1.03% of total session samplesCode: Select all
CS:EIP Symbol + Offset Thread ID Total % Timer samples
0x805b19f6 NtFreeVirtualMemory 1.07 645
0x8050080c ZwYieldExecution 0.58 350
0x8053fcf8 KeReleaseInStackQueuedSpinLockFromDpcLevel 0.45 270
0x80544c00 KiDispatchInterrupt 0.29 177
0x80518a28 MmTrimAllSystemPagableMemory 0.27 165
0x80545d0c InterlockedDecrement 0.23 138
0x8051625c MmIsNonPagedSystemAddressValid 0.19 113
0x80616e64 LsaDeregisterLogonProcess 0.18 109
0x8053fcc0 KeAcquireInStackQueuedSpinLockAtDpcLevel 0.17 100
9 functions, 828 instructions, Total: 2067 samples, 54.83% of samples in the module, 3.44% of total session samplesCode: Select all
CS:EIP Symbol + Offset Thread ID Total % Timer samples
0x690d6250 atiPPHSN 4.49 2704
1 function, 1326 instructions, Total: 2704 samples, 82.84% of samples in the module, 4.49% of total session samples
I doubt I will have any more time to work on it for a few days though.Yup, warzone currently only uses a single thread.OvermindDL1 wrote: And yes, apparently processr.sys is just the Idle loop, and I have two cores so it tends to remain about 50%. I am not used to it showing up in my profiles since most things I profile are heavy multi-threaded executables. Always learning something...
I think that if you'd disable one of your cores you'd get a similar load on that one to your 14.46%. I.e. Warzone itself would _not_ use any more CPU time, your OS & drivers might though.OvermindDL1 wrote: Although the app is plenty fast enough as it is (makes sense considering the age), it is only taking up 14.46% of the cpu time over both my cores (double that to about 29% for a single core).
Currently cleaning up code and fixing bugs are our top priority. Adding new features is also done from time to time. That doesn't mean though that if we see a good way of speeding up WZ (without it going at the cost of clean code) we won't implement it.OvermindDL1 wrote: On slower computers (more along the lines of when this game was released), it would still fare well, but it is spending most of its time in the OpenGL API, which would hurt it on those older systems.
Considering it is more then fast enough for modern systems, I do not think any real time should be spent on making it faster, just fixing bugs and adding features (and fixing bugs those features will invariably introduce of course). Although you can probably guess what bug I am wanting fixed.
So vs2k3 doesn't support __VA_ARGS__ in macros then ? I wish you luck with compiling then, since some of the most used macros we use depend on it (e.g. debug() and ASSERT()). I could otherwise suggest you to use MinGW instead of MSVC, you can use this in combination with the Code::Blocks IDE if you wish, or otherwise the Makefile.raw buildsystem could be used. The Makefile.raw system requires you to use a terminal to compile though... (You'll only need to hit "mingw32-make -f Makefile.raw" in the root of the source tree)OvermindDL1 wrote: I am using Visual Studio 2k3. I own a license to 2k5 standard, however dealing with the 2k5 CRT is not fun the few times I have used it, so I am sticking with 2k3 until I am forced to otherwise. I made my own project by down-grading the 2k5 project so that is all fine, and changed the varidic macro's to something more useful for that compiler. Only build errors/warnings I have right now is that missing header and couple of missing files.
Well you do know that Boost is entirely C++ right ? And we're currently only using C, and until all of us agree to using C++ we'll stick with C. Otherwise I must agree boost::program_options is really nice...OvermindDL1 wrote: And use the popt method of command-line parsing is by far the best, although I usually use boost::program_options, same command-lin syntax, just a different way of working with it, few more options, less dependencies, and so forth.
. I downloaded the game and the fix for it but it says it is an unkown file type. Please help I'm desperate to start! Sorry for my ignorance.