VOGONS

Search

Common searches

inaccuract / slight offset in colors tint in games

Topic actions

First post, by goldeng

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Hi everyone,

It's been a while since I last posted here. Hope everyone is doing well. 😀

I've found an inaccuracy in terms of the color tint of games running in DOSBox, which I believe that many don't pay too much attention to, as it's very hard to tell unless you sample the colors of the actual pixels with an eye-dropper tool in an image editing program.

I'm trying to re-produce an old adventure game in order to bring it to more audience, since the original didn't have subtitles in it which makes it less playable to some. I already have an extraction of the original game resources from the actual game files, but I capture some animations from the actual game running in DOSBox, in order to mixing them in the game engine I'm using to build the game from scratch. That is where I found some inaccuracy with the colors:

I took screenshots of the animation in DOSBox, and then went to the game creation engine to integrate them upon the original game background which was extracted from the actual game files. There I found that the color tint of the pixels has a slight offset. So I went to the DOSBOX.conf and tried changing the 'output' property to either of the options, and then run the game again to see if there's a difference.

I've found that when the game runs in "surface, opengl, openglnb and ddraw" modes, it has a certain offset value for the RGB. And when it runs in "overlay" mode, it has another offset value - none of these options give the exact color tint of the original game resources.

However, I built a virtual machine in the PCem emulator and tried to launch the game there. Surprisingly, I found that the colors in the PCem emulator are in the EXACT color tint values of the original game resources!

So my question is - is there a way to make DOSBox not tint the colors, and to preserve the original ones that the games designer used when drawing the graphics?

Attached a few screenshots that I took to better describe the problem:

Original image, extracted from the game file resources
Colors-Inaccurancy-Original-Image.png?rlkey=1wrlxzgv21zpe32exir5c862g&dl=1
PCem colors - the same as the extracted one
Colors-Inaccurancy-PCem.png?rlkey=qllheka05v6vg4j54dsiuykd0&dl=1
DOSBox in output values of surface, opengl, openglnb, ddraw
Colors-Inaccurancy-DOSBox-output-surface-opengl-openglnb-ddraw.png?rlkey=mqq8rngkrksevumkeydpo6vyg&dl=1
DOSBox in output value of overlay
Colors-Inaccurancy-DOSBox-output-overlay.png?rlkey=ljajuavydphz0s6zt4k91qin1&dl=1

Thanks for looking!

Reply 1 of 8, by jmarsh

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

The discrepancy with overlay is a result of using a different colorspace; DOSBox has to convert the image from RGB to YUV.
In the other cases, it's due to how DOSBox maps 6-bit VGA color palette values to 8-bit RGB; the 6-bit values are shifted left by 2 bits (multiplied by 4) and the 2 highest bits are copied into the lowest 2. This is the standard way to upconvert colors rather than simply shifting since otherwise it's impossible to reach maximum saturation.
For example this is how the value of green in your screenshot would be processed:
- right-shifted by 2 to fit into 6 bits of the VGA hardware palette (= 25)
- When rendering, DOSBox left-shifts by 2 (= 100) and adds the highest two bits (= 101)

Reply 2 of 8, by goldeng

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Thanks @jmarsh for the detailed explanation. That makes more sense to me now in terms of how DOSBox behaves. I just wonder if there's something that can be done to make it handle colors like how the PCem emulator does, for preserving the original color tint...

Reply 3 of 8, by jmarsh

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Technically PCem is doing the conversion wrong.
Think about how the value of 255 (the brightest possible value) would be handled:
- When put into the hardware's 6-bit palette, it would be 63
- PCem would then map it to 8-bits by multiplying by 4, giving 252 (three less than the brightest possible value)
- DOSBox would multiply it by 4 and add the two highest bits, giving 255.

Reply 4 of 8, by goldeng

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Thank for the info. Yet, I'm still confused. You claim that PCem is doing the conversion wrong. Though, I have the source graphic files from this game (not screenshots that were taken while running it in some emulator), so their color tint is the same as the designer used when creating the graphics. And PCem is the only emulator that I found which project the graphics to the screen in the same color tint as the source graphic files. So, if it were doing the conversion wrong as you claim, wouldn't the source color tint should have been shifted than the original?

Reply 6 of 8, by goldeng

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Basically, if I use DOSBox to run the game for capturing game animations which I wish to integrate with the game creating engine, when placing the cropped animations on-top of the original backgrounds from the source files, you could notice the slight difference in the color tint, since the background is also captured behind the animated content (it's not like having objects animation with transparancy). So you could clearly notice and see the animations playing in what appears like a "box" with color tint that is slighlty different from the background.

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window