joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.78k stars 381 forks source link

Documentation: S3 Trio acceleration in Windows 95 OSR2 is dependent on video memory size #224

Closed ghost closed 8 years ago

ghost commented 8 years ago

Running European Air War (EAW) demo with the directdraw renderer shows no viewport to the game world, although the HUD appears. This occurs with S3 Trio driver and more than 1mb of video memory (vram), leading to logging about an unimplemented "color compare" register.

This behavior is described here: https://archive.org/stream/bitsavers_s3Trio64VIdeoAcceleratorJul95_15892560/Trio64V_Integrated_Graphics_Video_Accelerator_Jul95_djvu.txt

I believe this implementation would occur in vgaxga.cpp. In the case of EAW at 256 colors, 0xb2e8 would hold the color to compare while 0xbee8 (function XGA*_Multifun) decides on the color comparison (bit 8 of BEE8H, Index OEH = 1); and traced all XGA operations to "Rectangle fill" and "BitBLT". I assume the rectangle fill is drawing the HUD, then the BitBLT procedure is drawing the game world in the non-HUD areas by use of the color comparison. In the code, XGA_BlitRect could be modified to accommodate the color comparison.

However, I no longer think this implementation is necessary. If vram is set to 1mb, then this color comparison and BitBLT is not done; but setting the vram >1mb then leads to the unimplemented color comparison and the BitBLT - and thus no drawing of the game world. So, the solution to running EAW (and I recall another combat flight simulation) is to use vmemsize=1.

It believe the cause is the directx6 S3 Trio driver using the vram size to activate the BitBLTs. Although there is a very small possibility that the EAW team could or would directly perform this kind of detection. However, I don't know whether these BitBLTs perform better in dosbox-x emulation than without, although PCem may yield an answer if it has the same behavior.

ghost commented 8 years ago

Observed differences in directdraw acceleration in dxdiag where the vram size is higher. In this example, the XGA routines seemed faster than without, but was unable to test that the BitBLTs have an advantage in emulation.

Edit: perhaps directx is emulating the BitBLTs in software. If this is true, then the question is whether the emulation of Win95 BitBLT is slower than a future implementation in dosbox-x emulation. I did test EAW by its fps counter (control-g) and noted no difference between the Win95 BitBLTs and running a blank screen without the color comparison system in emulation. Any performance bottleneck must be somewhere else.