First: Nice game!

Second: I have some proposals concerning Soldat. I noticed using a debugger and debug dlls several of the follwing exception at startup:

First-chance exception in Soldat.exe: 0xC0000005: Access Violation.

This should be no problem, though.

Further, the screen flickers (which is already laid out in the manual, yes, I saw that), but I suggest something to fix this. The screen is flickering in debug mode to show some programming faults, which is avoided in release mode:

Direct3D8: (ERROR) :*** Exception in d:\builds\nt32_chk\multimedia\directx\dxg\d3d8\fe\vshader.cpp Line: 655

Direct3D8: (ERROR) :Vertex buffer must be unlocked during DrawPrimitive call

Direct3D8: (ERROR) :DrawPrimitive failed.

It seems like a VertexBuffer is not unlocked before DrawPrimitive. This causes no problems with the release build, but I propose to fix it, because the DrawPrimitive will fail then in debug mode.
Additionally, locking of buffers consumes a lot of cpu cycles, especially leaving them locked is not good.
Moving objects with matrix transformation instead of vertex manipulation would be a lot faster.

And there seems to be a memory leak:
Direct3D8: (ERROR) :Memory still allocated! Alloc count = 165
Direct3D8: (ERROR) :Current Process (pid) = 00000098
Direct3D8: (ERROR) :Memory Address: 003d4284 lAllocID=1 dwSize=00003524, ReturnAddr=044d7346 (pid=00000098)
Direct3D8: (ERROR) :Memory Address: 003d9274 lAllocID=10 dwSize=00000f9c, ReturnAddr=044c73d4 (pid=00000098)
[...]
Direct3D8: (ERROR) :Total Memory Unfreed From Current Process = 1305503 bytes

Which should be fixed, too.
Hope the best for the next version,
J.


PS:

from faq:
[...] John Pascal (or whatever his name is) [...]

His name is Niklaus Wirth -
see http://de.wikipedia.org/wiki/Niklaus_Wirth :)

The access violations that appear while using debuggers probably are because of the cheat-protection (there were some mean trainers for 1.0.5b), but ever since there were only some harmless little bugs to cheat with :)

Janus, if you want to make sure that Michal reads this either PM or email him.

Additionally, locking of buffers consumes a lot of cpu cycles, especially leaving them locked is not good.
Moving objects with matrix transformation instead of vertex manipulation would be a lot faster.
are these operations that are executed very often or only load/start-up things? I mean.. what would you say how much this could increase the performance of Soldat? In frames per second?

I guess I'm talking gibberish or something :)

wow janus, youre the man (hope michal will react this)

..cont..
Since the game is moving objects all the time, the slow code ist executed every frame, not just startup. Though, I cannot tell how much the performance will improve. This depends on machine, graphics, ram etc.
I took some further investigations, leading to the cognizance that the level graphics (stones, walls) are already drawn in one cycle using a vertex buffer, but to move them, this buffer is locked and the verticê are altered. Using a matrix transformation and no locking at all, this part would surely improve much, especially on slow machines.
The other objects (players, font, menues) are drawn using a user buffer, which is not a good thing to do; every primitive (that is 4 points) is drawn in one call, this is VERY slow when drawing many player models, as can easy be seen with many players. These should be accumulated in a Vertex buffer as well, which should get flushed in one turn when it gets full. There are a lot of tutorials on this topic
around the Net.
And, finally, some proposals on memory management:
Soldat uses VERY much ram on my PC (some 60 mb, which is in fact the image size). Sometimes Windows even reports lack of virtual ram. This is due to the fact that global data arrays of uninitialized data are used in Soldat, which do not inflate the exe, but DO get inflated in ram!
So do not use static arrays, use some dynamic lib or do it by hand using GetMem (or what is it called in Pascal).

J.

hey,
i'm not sure how much control michal has over the D3D calls; soldat was written in delphi, and he's using a delphi->directX lib.. (i forget which one).

it's possible that the lib is what's causing the problems (not unlocking the VB, etc.). i have no idea how high-level the interface is, it's possible that, for instance in the case of the per-vertex tranformations, he's simply specifying a translation vector, and the lib is doing the rest.. in which case, he can't really change this without rewriting the lib.

raigan

Hi there. [8D]

Yeah, fixing those bugs would be great since when i play Soldat (or even just use mapmaker and interfacemaker) my CPU usage rises up to 100%, witch is a lot for a game like this (not even UT2004 is so hard on my CPU). Besides, that monitor flicking thing really annoyis (sp?) me... Is there any way i can fix that now?

Another thing, sometimes, when i play soldat, Win xp displays me this message warning me that my minium virtual memory is too low... Well thats fweird since i have 256MB so my page file shouldn't need to be that big, besides that my page file is configured to have its size between 400 MB and 1000 MB. Hell, i think thats enough... [xx(]

Anyway, this game rox and i won't stop playing it it because of this bugs but it would be nice to see this fixed in a future version...

I'm off, stay cool. [:D]

quote:Originally posted by Ragnarok
when i play Soldat (or even just use mapmaker and interfacemaker) my CPU usage rises up to 100%, witch is a lot for a game like this (not even UT2004 is so hard on my CPU).

Soldat tries to reach the highest frame rate possible.. so that's the reason why the CPU usage goes up to 100%

and UT2004 SHOULD do the same, but maybe you set something like vsync..

Actually, MOST games will use EVERY LITTLE BIT OF CPU they can. As far as mem usage goes... I think a lot of it has to do with how windows handles things... If you boot up your computer windows will already have around 50% of your memory allocated...

50% damn what the hell are you running ? 386 with XP ?

Athlon 2400 with 256 MB RAM, win98