DieHard Wolfers

[Chris]

I added Darkone's FPS counter to a test exe for Planet Strike: http://chokfiles.webs.com/BS_FIRE2.ZIP

It's numbers definitely agree with you guys. In real DOS, when picking up items or getting damaged, it tells me that the game drops down to around 30-60fps for a second then goes back up again, but in every other circumstance it stays at a constant 70fps. If I run the exe as "bs_fire2 nobonus nodamage" (which removes the flash), it stays at a constant 70fps even when picking up items or getting damaged, so it definitely seems to be the flash that's causing the number to drop.

This makes me wonder if there's some sort of intentional "screen delay" in the flash routine. I think that makes the most sense because if my 800mhz CPU only gets 30-60fps, that would mean a 100mhz CPU would get 4-8fps otherwise.

edit: If I take out the VW_WaitVBL(1) calls in UpdatePaletteShifts() it seems to help: http://chokfiles.webs.com/BS_FIRE3.ZIP

[serpens]

Eh, so if the stutter/slowdown/delay/whatever was something intentionally introduced by the developers... Why did they do such a thing? What's the purpose? (And why does it not work in this particular release of DOSBox?)

[Tricob]

The VBL thing is probably added so "snow" wouldn't show up when the screen flashes. Odds are the VBL thing slows down some video cards but not others. You can see this "snow" in the DOS version of Wolf3D, if you have the right hardware. I remember seeing the "snow" in Wolf3D during my 80286 days, and it was always visible whenever I'd pick up an item.

[Cyanosis]

Tricob wrote:

The VBL thing is probably added so "snow" wouldn't show up when the screen flashes. Odds are the VBL thing slows down some video cards but not others.

Interesting, that explains things better. Honestly, the stutter isn't that game breaking, but I'll be glad when there's a BS4SDL (somehow, without the source code or adding to and improving the PS source code) or reverse engineering on ECWolf that eliminates the problem altogether. As well as WASD support. Those perma-binded hot keys are bullshit.

[serpens]

Chris wrote:

This makes me wonder if there's some sort of intentional "screen delay" in the flash routine. I think that makes the most sense because if my 800mhz CPU only gets 30-60fps, that would mean a 100mhz CPU would get 4-8fps otherwise.

edit: If I take out the VW_WaitVBL(1) calls in UpdatePaletteShifts() it seems to help: http://chokfiles.webs.com/BS_FIRE3.ZIP

So is there any possibility of removing that delay for Aliens of Gold as well? You're the hex editing master, so if anyone knows how to do that, it's you. Maybe by modifying the way that useless "add extra VBLs" BACKSPACE+V cheat works, or something?

[Chris]

Yes. The easiest way is to just compile a normal Planet Strike exe, then one with a change, and compare them (I just used cmp in Linux), then look for a similar area in Aliens of Gold, and test a similar change in the same place (I used uHex in DOS).

http://chokfiles.webs.com/BS_AOG2.ZIP - bs_aog2.exe gets rid of the bonus flash by using bonus = 0 (0x18DEF-> 12 to 0) - bs_aog3.exe gets rid of the damage flash by also substituting red with white (0x18E38-> 11 to 0F) - bs_aog4.exe replaces the first 2 VW_WaitVBLs, with DrawAmmo I think (0x18E7B and 0x18EAE-> 02 00 06 2D to C3 0A 58 1C)

[serpens]

Chris wrote:

Yes. The easiest way is to just compile a normal Planet Strike exe, then one with a change, and compare them (I just used cmp in Linux), then look for a similar area in Aliens of Gold, and test a similar change in the same place (I used uHex in DOS).

http://chokfiles.webs.com/BS_AOG2.ZIP - bs_aog2.exe gets rid of the bonus flash by using bonus = 0 (0x18DEF-> 12 to 0) - bs_aog3.exe gets rid of the damage flash by also substituting red with white (0x18E38-> 11 to 0F) - bs_aog4.exe replaces the first 2 VW_WaitVBLs with DrawAmmo, I think (0x18E7B and 0x18EAE-> 02 00 06 2D to C3 0A 58 1C)

My goodness, you wouldn't believe how happy this makes me! The problem's been bugging me for several days now, prompting me to look for elusive DOSBox builds all over the Net. I even tried modifying and compiling the DOSBox source myself, with predictable results (I don't know the first thing about that). With your modified executable the game runs perfectly smooth in every aspect under the latest DOSBox. Such a relief!

I'll try to learn something from your post, too, so that if I ever need anything similar done in the future, I can try myself and you won't need to answer my bugging for help. Thank you! It's good to have some peace of mind once again.