-
-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate playability issues with Hostage Rescue Mission (1989) #2905
Comments
Results (macOS Ventura 13.5.2/Apple M2): DOSBox Staging 0.81.0-alpha-1689 DOSBox SVN snapshot 12.09.23 DOSBox-X v2023.09.01 I don't run Windows so i can't test with Daum. |
Confirmed Daum runs smoother and without flicker. Likely a timing adjustment. [dosbox]
machine = ega Staging staging-hostages.mp4circa-2015 Daum: daum-hostages.mp4Given SVN also has the video flash/corruption, the fix is now isolated to just the Daum additions. Thanks for these tests, @Burrito78! |
Does this game use PC Speaker? The audio sounds very different between those two video clips. |
Good ear, @MasterO2. Will do a second run with the |
Thanks for the suggestion, @MasterO2. Here's Staging staging-hostages-impulse.mp4Daum'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. |
DOSBox 0.74-3
DOSBox Daum
DOSBox Staging 0.80.1Like DOSBox 0.74-3 graphically, but runs faster DOSBox Staging GitLike 0.80.1 DOSBox-X 2023.09.01Very 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 |
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 😄 |
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. |
@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). |
@MX9000 - very interesting.
Can you find sources for these two binaries?
That's ~22 days of changes.. so would be a huge help in isolating this change. |
@kcgen yes, the release 20150103 is still affected by the flickering while the one dated 20150125 is the first one to work. |
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
Jan. 3. 2015
Jan. 27. 2014
|
ripsaw8080 has found better settings:
Thanks, ripsaw8080 👍 ; looks a lot better: video0027.mp4[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 |
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: |
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. |
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? |
Hi @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 |
Closing this since this problem can be reproduced on real hardware too. |
@Grounded0, due to the above the ticket seems to be "not planned" rather than "completed"? |
Its vague what the correct close signal is but it probably is "not planned". |
After more experiments, it turns out that this game is sensitive to video memory timings. |
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 |
@Python-Exoproject See the details and the config to fix the game here: #3597 |
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?
If Daum plays it better:
Use these builds here to narrow it down.
How you can help
HostageR/
)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:
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.
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:
The PR should include the
imported-from:
URL pointing to DOSBox Daum. For an example, see commit a35c7c8.The text was updated successfully, but these errors were encountered: