VOGONS


First post, by KMO

User metadata
Rank Newbie
Rank
Newbie

I'm finally getting to the problem of corrupted colours in the FMV of Tomb Raider I on my XP system.

It looks like there's a fault in the VESA handling of my recently-acquired Gainward Bliss NVidia 7600GT card.

TR1 uses either VESA mode 110h (640x480 15bpp) or mode 111h (640x480 16bpp) to play its FMV clips. It uses 110h if available, else 111h. My 7600GT card natively offers only 111h.

It seems that TR1 is capable of painting correctly in either mode. I've observed that:

  • In DOSBox, which offers both 110h and 111h, so TR1 uses 110h, it looks okay.
  • Using dgVesa with dgVoodoo, which offers only 111h, it looks okay (although it seems sluggish and stuttery).

I then tried taking a screencapture of it running with the funny colours under the native VESA support, under dgVoodoo and VDMSound, using Video Thief, which captures the complete graphics card state.

When you view the capture with vtfview (which reprograms the graphics card as at the time of capture), you still see the same colour problems. But if you get vtfview to convert the screen memory to a BMP, the colours in the BMP are fine. This suggests that the data in the framebuffer is correct for a 16bpp mode, but the card's not displaying it correctly.

My next thought was that maybe there was something misprogrammed in the control registers to foul up the output, so I went to find something else that would test mode 111h.

I eventually located VGATEST (which I found in this thread). Its mode 111h test also looked wrong on screen and vtfview, but again the saved BMP was okay.

So if both VGATEST and TR1 are showing duff colours, it seems unlikely that TR1 is doing anything wrong, so that there's probably a fault with 16bpp display in my VGA BIOS.

Looking at the VGATEST colour ramps, it's clear that the red and green channels are incrementing at double-speed and wrapping, so you get two ramps in the space of one. The blue channel is fine. See the attachments below for actual appearance, and what the screen capture reckons it should look like. (Note that the test card actually has black areas between each ramp, which makes it less obvious that the green+red ramps are simply doubled.)

This behaviour would be consistent with this mode 111h actually being a 5:5:5 15bpp mode, rather than the claimed 5:6:5 16bpp. 😒

Has anyone else here seen this? Or, has anyone got a 7-series card where VGATEST and TR1 do work? Is the card BIOS simply misreporting 15bpp modes as 16bpp? Which are NVidia 7 cards supposed to provide?

Is it something specific to my system, or is this a general problem?

Reply 2 of 3, by KMO

User metadata
Rank Newbie
Rank
Newbie

Well, it looks like there's an easy workaround. Patch tomb.exe so that it always uses its 15bpp paint code, even if it's selected an (alleged) 16bpp mode.

Works a treat. 😁

This can be easily done in a hex editor - in the Glide DLL tomb.exe binary (873739 bytes), change byte 7AB32 from FF to 00.

Reply 3 of 3, by KMO

User metadata
Rank Newbie
Rank
Newbie
DosFreak wrote:

What about VDOS32? http://www.vdos32.com/

Done a few more tests, and as I suspected, anything that uses its own graphics rendering is fine, but if it uses the native VESA mode it isn't:

  • Glidos with its VESA emulation on works well - you just get that funny seam effect in the middle due to the texture join
  • Glidos without VESA emulation has shows the wrong colours
  • VDos32 in software mode (in a window) works correctly
  • Glidos+VDos32 seems to force on Glidos' VESA emulation, and that works as above.