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.
Posted: Mon Nov 03, 2014 4:12 pm
Subject: Re: Blake Stone - help!
[ IP : Logged ]
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?)
Topics: 165
Posts: 8330
Location: Neo-traditions, Inc.
Posted: Mon Nov 03, 2014 5:21 pm
Subject: Re: Blake Stone - help!
[ IP : Logged ]
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
DieHard Officer
Joined: 07 Aug 2014
Last Visit: 15 Apr 2018
Topics: 34
Posts: 512
Location: Newport, Oregon
Posted: Mon Nov 03, 2014 11:15 pm
Subject: Re: Blake Stone - help!
[ IP : Logged ]
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
DieHard Officer
Joined: 11 Apr 2007
Last Visit: 18 Feb 2019
Topics: 17
Posts: 517
Location: Odrowaz
Posted: Wed Nov 05, 2014 12:36 am
Subject: Re: Blake Stone - help!
[ IP : Logged ]
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.
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?
Posted: Wed Nov 05, 2014 5:46 pm
Subject: Re: Blake Stone - help!
[ IP : Logged ]
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).
- 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
DieHard Officer
Joined: 11 Apr 2007
Last Visit: 18 Feb 2019
Topics: 17
Posts: 517
Location: Odrowaz
Posted: Wed Nov 05, 2014 6:18 pm
Subject: Re: Blake Stone - help!
[ IP : Logged ]
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).
- 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.