Investigate playability issues with Hostage Rescue Mission (1989)

[kcgen]

Context

Currently the eXoDOS project runs this game using the DOSBox Daum fork, which is understood to have specific emulation fixes not currently in upstream DOSBox (0.74.x and SVN) or active forks such as X, Pure, and Staging.

DOSBox Daum had 51 releases that included DOSBox SVN's commits ~r3600 through ~r3900, spanning 2010 through 2015.

The goal of this ticket is to answer the following

Is Daum still needed for this game?

• [ ] Does DOSBox SVN (download latest) play it OK?
• [ ] Does DOSBox X (download latest) play it OK?
• [ ] Does DOSBox Staging (download latest) play it OK?

If Daum plays it better:

• [ ] What aspect is better?
• [ ] Which Daum release was the first to fix it? Use these builds here to narrow it down.

How you can help

1. Download the above lastest DOSBox SVN, X, and Staging builds.
2. Ensure you have eXoDOS v5 (or eventually v6)
3. Find this game inside the eXoDOS installed folders (look for: HostageR/)
4. Run the game using the DOSBox SVN, X, and Staging builds. If it plays fine (everything looks, sounds, and handles OK) then simply indicate as such. Your task is done!

If SVN, X, and Staging all have problems, then try it with Daum:

1. Download the first and last Daum releases. Note: Daum had the most releases for Microsoft Windows, so having a Windows system (or VM) will help the most to answer the last question above.
2. Does the latest Daum release play it correctly? If so: summarize/describe how it's better than DOSBox SVN, X, and Staging (screenshots, video, audio records all help too).
3. Find the earliest (or oldest) Daum release that fixed it.
   1. Run the Daum release half way between the known good release (where the game playing correctly) and bad release (where the game doesn't playing correctly) until you've narrowed it down to adjacent releases.
   2. It will take at-most seven runs of different Daum versions to narrow this down (using this middle-selecting technique); so it's not as daunting as it seems! :-)

---

Follow up by code contributors

If Daum plays it better, your answers (especially the last one that narrows down the fix to a specific release) are critical to helping isolate the chunk of code fixed the given bug.

Pull requests should credit:

• @ykhwong as the original code author,
• the test team member who confirmed and isolated the Daum release,
• yourself (PR author) as integrating the fix

The PR should include the imported-from: URL pointing to DOSBox Daum. For an example, see commit a35c7c889.

[Burrito78]

Results (macOS Ventura 13.5.2/Apple M2):

DOSBox Staging 0.81.0-alpha-1689 Yellow graphical corruption on the vehicles, otherwise OK.

DOSBox SVN snapshot 12.09.23 Yellow graphical corruption on the vehicles, otherwise OK.

DOSBox-X v2023.09.01 Yellow graphical corruption on the vehicles, otherwise OK.

I don't run Windows so i can't test with Daum.

[kcgen]

Confirmed Daum runs smoother and without flicker. Likely a timing adjustment.

[dosbox]
machine = ega

Staging main (SVN is similar):

https://github.com/dosbox-staging/dosbox-staging/assets/1557255/367c19d4-53b0-4d24-8336-56063506b998

circa-2015 Daum:

https://github.com/dosbox-staging/dosbox-staging/assets/1557255/d4c42461-0135-45f3-96ea-d9ddbb8a0b86

Given SVN also has the video flash/corruption, the fix is now isolated to just the Daum additions.

Thanks for these tests, @Burrito78!

[MasterO2]

Does this game use PC Speaker? The audio sounds very different between those two video clips.

[kcgen]

Good ear, @MasterO2. Will do a second run with the impulse PC Speaker model.

[kcgen]

Thanks for the suggestion, @MasterO2. Here's Staging main with pcspeaker = impulse:

https://github.com/dosbox-staging/dosbox-staging/assets/1557255/b6ace5f6-ba54-477a-901e-03853bfe55d2

Daum's timing is definitely running faster. I'm not sure which is more accurate.

We know the sprite flashing is broken - so Daum is 100% better there.

But what about the PC Speaker intro music? - is faster or slower more accurate on real hardware? Might have to add this to the HW queue, @Grounded0.

[rderooy]

DOSBox 0.74-3

• Running the game in EGA mode, I don't have any yellow corruption. Just a lot of sprite flashing during the intro.
• CGA seems to run fine
• Seems to run quite sluggish

DOSBox Daum

• Flickering in EGA mode is almost gone, when run with machine=svga_s3, but not with machine=ega.
• CGA seems to run fine

DOSBox Staging 0.80.1

Like DOSBox 0.74-3 graphically, but runs faster

DOSBox Staging Git

Like 0.80.1

DOSBox-X 2023.09.01

Very little flickering with VGA or EGA adaptor setting

eXoDOS dosbox.conf

# Config file for Dosbox-ECE r4230
[sdl]
fullscreen=false
fulldouble=false
fullresolution=0x0
windowresolution=1280x960
output=direct3d
mapperfile=mapper.map
[dosbox]
machine=svga_s3
memsize=16
[render]
aspect=true
scaler=normal2x
[cpu]
core=auto
cputype=auto
cycles=800
[pci]
[mixer]
rate=49716
[midi]
fluid.soundfont=.\mt32\SoundCanvas.sf2
fluid.gain=.2
mt32.romdir=.\mt32
[sblaster]
oplmode=opl3
oplemu=nuked
oplrate=49716
[gus]
[speaker]
[joystick]
[serial]
[dos]
[ipx]
[autoexec]
mount c .\eXoDOS\
c:
cd HostageR
cls
@hostage
exit

[johnnovak]

This is a classic Amiga game by Infogrames, I too had a copy. There was a big hype about it back in the day, but it's not such a great game, after all. I guess people liked it for the graphics. The EGA conversion looks like shit, though 😄

https://amiga.abime.net/games/view/hostage-rescue-mission

[kcgen]

Recent discussion on vogons; Neville also notices the flicker:

https://www.vogons.org/viewtopic.php?t=96671

Hopefully we can isolate this video/timer change in Daum.

[MX9000]

@kcgen I did some testing and found that the change that solved the yellow flickering issue occurred between the last of the older SVN Daum builds for Windows (20150103) and the last one released and also used in eXoDOS (20150125).

[kcgen]

@MX9000 - very interesting.

• So "the last of the older SVN Daum builds for Windows (20150103)" is still affected by the flickering.

• While "the last one released and also used in eXoDOS (20150125)" fixed it.

Can you find sources for these two binaries?

• Daum 20150103
• Daum 20150125

That's ~22 days of changes.. so would be a huge help in isolating this change.

[Burrito78]

https://github.com/ykhwong/dosbox-svn-daum/releases

[MX9000]

@kcgen yes, the release 20150103 is still affected by the flickering while the one dated 20150125 is the first one to work. @Burrito78 thank you for finding the source code.

[kcgen]

I'm not seeing content in the source .zip or .tar.gz files (only a single LICENSE file is provided:

[MX9000]

Thanks to the Wayback Machine I was able to find the sources of the January 25, 2015 and January 27, 2014 versions, but unfortunately not the intermediate version of January 3, 2015.

Jan. 25. 2015

1. UPDATE: SVN r3894 base
2. UPDATE: xBRZ version 1.2 (ZenJu)
3. UPDATE: DOSBox-X branch patch (TheGreatCodeholio, 5ec6c54341d148d5e2fda49944f9ed6793538ff8 Jan/22/2015)
4. ADD: -disable_share parameter (Rainer): Some games such as Mad News do not start with SHARE
5. FIX: Minor bugs

Jan. 3. 2015

1. UPDATE: SVN r3876 base
2. UPDATE: DOSBox-X branch patch (TheGreatCodeholio, dosbox-x-9e21731799a8bb59da924e7b01eccb994acf75ca)
3. UPDATE: 3dfx Internal Voodoo Emulation (kekko)
4. ADD: -vgmlog parameter (ValleyBell, http://vgm.mdscene.net/forum/viewtopic.php?t=410)
5. FIX: Quick Launch did not allow some filename extensions.

Jan. 27. 2014

1. UPDATE: DOSBox-X branch patch (TheGreatCodeholio, dosbox-x-20140125-201539)
2. FIX: Crash on dynamic core
3. FIX: Minor bugs

source (Jan. 25. 2015).zip source (Jan. 27. 2014).zip

[kcgen]

We have those two in the repo: https://github.com/dosbox-staging/dosbox-staging/pull/2957

@junkrunner put in notable effort to try to disentangle Daum's changes from the SVN and X changes, as that level of separation was not retained in the Daum sources.

@ykhwong: do you have the red highlighted sources for the binaries shown in the above screenshot?

[kcgen]

ripsaw8080 has found better settings:

In SVN with machine=ega, reducing cycles to 500-600 range reduces flicker in the intro substantially.

Thanks, ripsaw8080 :+1: ; looks a lot better:

https://github.com/dosbox-staging/dosbox-staging/assets/1557255/f07a0dc7-47f6-4f76-be6e-2d3d64f2b821

[dosbox]
machine = ega

[cpu]
cycles = 500

[dos]
xms = false
ems = false
umb = false

[speaker]
pcspeaker = impluse
tandy = on

[autoexec]
mixer pcspeaker 50
mount c .
c:
autotype -w 1 f2 enter
hostage

[johnnovak]

@Python-Exoproject @kcgen

Okay, I've tested this on my real hardware Pentium MMX 200 PC (downclocked to 125 MHz, then slowed down further to moderate 386 speeds by disabling all caches in the BIOS and via SETMUL to rule out weird speed sensitivity issues as much as I can).

The bad news is I'm getting the same flickering and janky behaviour with the on my S3 video card which is one of the most compatible ones. The conclusion is that DOSBox Staging and all other DOSBox variants emulate the hardware behaviour accurately. Maybe the game would only look perfect on a real EGA card and the EGA emulation of VGA cards break it.

Saying that the Daum guys did some "magic" to fix this is a bit of wishful thinking in my view. What I suspect they just made some probably unrelated changes that "fixed" these games by fluke. In any case, it would be an interesting research project to find out what that is, and maybe introduce it as a config option as it could probably break the VGA/EGA emulation in other ways.

Here's the video proof; the game flickers like no tomorrow on my S3 card even with my Pentium slowed down to 386 speeds 😎

https://drive.google.com/file/d/1k4rEEPinhRYwpc0in4KLt0xL-Kv-MzIR/view?usp=sharing

Related issue: https://github.com/dosbox-staging/dosbox-staging/issues/3244

[kcgen]

Awesome stuff, @johnnovak!

So nice to see this repro'd in hardware and to have this concluded.

I suppose the game probably worked fine on the developer's machine and video card, and these inflexible assumptions and timings were hard-coded into the game's logic.

[Python-Exoproject]

Similar to #3244, #2950, and #2949 dos_rate=140 with cycles this time of 1000 seem to help a lot with this game. Its not quite as good as the other three games as there is still a bit of a flicker for the men in the intro and the scrolling writing but I can seem to find a setting that dials it in any better.

As with the other three games Im wondering if these values work for anyone else?

[MX9000]

Hi @Python-Exoproject! I'm experiencing a flickering issue that I can't solve in the game The Gold of the Aztecs (VGA mode) in eXoDOS 6.0, DOSBox 0.74-3, DOSBox-X 2024.03.01 and DOSBox Staging 0.81.0 as well. Try watching the initial animation when the main character jumps out of the plane and also the map scrolling in the game menu. Thank you!

[Python-Exoproject]

@MX9000 I had a look at Gold of the Aztecs to see if a similar solution will help. Unlike the other games with this issue, Daum does not fix the problem so its possibly something else and I will create a separate ticket for the game.

In the meantime, using dos_rate=140 did improve the situation, however it didnt fix it. Going up to dos_rate 280 did fix it but it also led to weird hiccups in the displaying of the graphics so I wouldnt recommend it

[Grounded0]

Closing this since this problem can be reproduced on real hardware too.

[Torinde]

Maybe the game would only look perfect on a real EGA card and the EGA emulation of VGA cards break it. In any case, it would be an interesting research project to find out what that is, and maybe introduce it as a config option as it could probably break the VGA/EGA emulation in other ways.

@Grounded0, due to the above the ticket seems to be "not planned" rather than "completed"?

[Grounded0]

Its vague what the correct close signal is but it probably is "not planned".

[MX9000]

After more experiments, it turns out that this game is sensitive to video memory timings. In DOSBox-X, on my machine, the flickering disappears by setting the vmemdelay = 1500 option under the [video] section and the cycles to 800 as in eXoDOS.

[johnnovak]

After more experiments, it turns out that this game is sensitive to video memory timings. In DOSBox-X, on my machine, the flickering disappears by setting the vmemdelay = 1500 option under the [video] section and the cycles to 800 as in eXoDOS.

That's some good info, and it explains why it flickers on my late 90s S3 card in my real MMX PC. The S3 cards were among the fastest, yeah.

Looks like we should implement vmemdelay then.

[johnnovak]

@Python-Exoproject It is possible to completely get rid of the flicker with the new vmem_delay option.

See the details and the config to fix the game here: https://github.com/dosbox-staging/dosbox-staging/pull/3597