rpix86 version 0.14 released!

December 31st, 2013, 00:51 Posted By: wraggster

This version has only a couple of game-specific fixes, as I have not worked all that much on rpix86 during my Xmas vacation. The fixes are the following:

Fixed Flashback screen resolution problem. This was quite similar to the BC Racers screen resolution problem, except that Flashback goes to 256x224 resolution, and uses VGA Mode-X graphics mode instead of the MCGA mode used in BC Racers. Thus I needed to make a change that was very similar to the change I made for BC Racers, but this time to a different blitting routine.

Fixed Flashback Sound Blaster detection. The game did not set the Sound Blaster sample playing speed at all (which left the speed at zero), so the game never got an IRQ at the end of the playing buffer. Thus the game failed to detect the presence of the Sound Blaster card. I fixed my SB reset routine to set the default 22kHz sample playing speed, and this allowed Flashback to detect the Sound Blaster card properly.
Added game-specific hack for Lemmings AdLib detection. The game used a short delay loop waiting for the AdLib 80ms timer to tick, but this delay loop was so short that it took less than 80ms to run, and thus the game failed to detect the presence of an AdLib card. The fix was actually a pretty nasty hack, I simply check that if the running executable is called "VGALEMMI.EXE", I change the length of the AdLib tick to be practically zero instead of the default 80ms. This allows Lemmings to detect the AdLib card (as long as you select the VGA graphics mode when starting Lemmings).
I also spent some time debugging the horizontal scrolling problem in Commander Keen 1, but this is quite a difficult issue to solve. The problem is caused by synchronization issues between these five events:

The game setting the VGA Start Address register, which will take effect only after the next vertical retrace period.
The game setting the VGA pixel panning register, which will take effect immediately.
The game updating the screen contents between the vertical refresh periods.
rpix86 blitting the screen contents immediately after the actual hardware vertical sync has happened (gles_swap()).
rpix86 reporting the current vertical sync state to the game.
The biggest problem here is that the game needs to know the exact moment when the screen becomes active after the vertical sync period, but sadly that is the exact time when the game thread is not running! The Linux operating system runs the graphics blitting thread immediately after the hardware screen vertical refresh has happened and the gles_swap() call has updated the screen contents. So there is no way to run the game thread exactly when the game thread would need to run for the scrolling to be smooth. Faking the vertical sync end to happen at some other time works fine in many games, but not in games that need to do something exactly at this time.

Fixing this properly would need some completely different approach to the problem. DOSBox does all the timing internally with no regard to the actual physical screen refresh, but I don't want to go that route. I will continue looking into this problem in the future, but I don't know yet when or whether I will get it fixed.

http://rpix86.patrickaalto.com/rblog.html

There are 0 comments - Join In and Discuss Here