8- bit game: Wrong colours in full-screen mode.

[FernandoJS]

Hola!

I'm new to the forum, and I hope I'm posting in the correct place. Also, sorry if my English is not perfect.

I'm working on a project with an 8-bit colour depth and a 320 * 200 graphics resolution, and I've encountered a problem that I can't seem to solve... in a way that really satisfies me.

The problem is that, when I run the game in a full-screen mode, some of the colours of every background and every sprite are wrong. For example, the floor of a room is drawn with various tones of grey. When the game is run in a window, it looks perfect, but if it is played in full-screen, one of those tones becomes blue, other green, or yellow, and others don't change.

I believe that the problem has something to do with some of the colours of the palette "switching" place. But I don't know how, or why.

I've would show screenshots but, for some reason, I can't take them when I'm on full screen.

Anyway, I can partially fix this problem if I change the colour depth to 16, but maybe that's kind of a lazy solution.

Thanks in advance for the help! I appreciate it!

[Snarky]

I'm pretty sure this is a problem with Windows and your graphics card/driver. Modern computers aren't very good at supporting 8-bit color, since it's a totally outdated mode. There are probably ways to fix it, but even if you get it running OK on your computer, a lot of your players are going to have the same problem.

If you don't have a very good reason for using 8-bit mode, you should switch to 16 or 32 bit. I would recommend 32 bit, since (a) the color fidelity is better, and (b) it means you can use transparency effects.

[Scavenger]

Yeah, this is way beyond the scope of anything you can personally do in the AGS engine, since this is a bug that is the fault of Windows rather than AGS itself. AGS is just the latest in a long line of games that have wacky colours because of dodgy DirectDraw stuff. There's a lot of cool stuff you can do in 8-bit, but if you aren't doing any of that, it's way better to go with 32bit. Even though I love 8-bit so very much, I wouldn't wish it's problems on anyone.

There are a couple of solutions to this problem, as far as I can tell, but they're both pretty techy. The first is a registry entry, the second is patching allegro itself.

Code: ags

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectDraw\Compatibility\GameName]
"Name"="GameName.exe"
"Flags"=hex:00,08,00,00
"ID"=dword:33c6e80c //This needs to be the ID DirectDraw kicks out into MostRecentApplication. I think this is dependent only on the exe file itself, so shouldn't change from computer to computer - so you only need one .reg file to fix every player's instance of the game. Two if they're running 64bit, since this would need to be copied into the 64bit registry area too.

I believe the problem is that while running full screen, Windows tries to take control of the palette and this messes up all the colours, but when running Windowed mode DirectDraw never actually changes the display mode (and so Windows never tries to change the palette). The allegro patch (which works on 4.2 & 4.4, AGS uses 4.2.4) is:

Code: ags

#include "wddraw.h"
//Include the above at the top.

//Below should go into the allegro/src/win32/wwnd.c file as part of the windows callback code.
      case WM_QUERYNEWPALETTE:
      case WM_PALETTECHANGED:
         if ((HWND)wparam != wnd && gfx_directx_primary_surface) {
            IDirectDrawSurface2_SetPalette(gfx_directx_primary_surface->id, ddpalette);
            InvalidateRect(wnd, NULL, 1);
         }
         return 0;

Looking at it, guessing that it resets the palette to what DirectDraw is using every time Windows tries to change it. I've seen this kicking around a few places where this exact palette bug shows up, and it might be a permanent solution. I'm afraid I'm not nearly as confident at compiling as I should be, so I can't test it.

[FernandoJS]

Thanks a lot for the help!

I think i will switch to the 16-bit mode. After all, its true, I don't really have a good reason to continue working in the 8-bit mode. I'm not using any of the cool palette effects or anything like that.

Anyway, it would be interesting to try your solutions, Scavenger. I can't really test the Allegro patch myself either, but I would consider making the registry entry. The only problem I see with this solution is that it would require, if I understand correctly, creating a new registry file outside of the folder with the compiled game, and that would mean that everybody that downloads the game has to copy that .reg file into their registry area. Maybe this would be easy with an installation program that does everything automatically, but I've never tried to work with something like that before.

But again, thanks a lot for the help. You've been really helpful!

[Khris]

Like Snarky, I really recommend switching to 32bit, while you're at it.
Running a 16bit game always slaps my Win7-Desktop over the head, forcing it to switch to classic mode or whatever it's called.
There's no good reason to use 16bit over 32bit, afaik.

[Monsieur OUXX]

How about trying compatibility modes in the game's .exe file? Maybe Windows won't try to take over the palette as much as in regular, modern Windows 7/8/10 modes

Apart from that: Yeah, just fake 8-bit colors using 32 bits. the only solid reason to use 8-bits would be to save a few megabytes of space (nowadays it's meaningless) or to use palette shifting. Do you intend on using palette shifting? Nah bro. Also don't use 16-bits because even though it's less old than 8-bits, it's still super old (the golden age of that tech was at least 15 years ago).