Windows 7 8-bit palette corruption

[Skutarth]

I'm sure this issue is commonly known by now. If you run Quake with a software renderer, most engines will have the problem. Even in previous versions of windows, surface palettes were not exclusive like they were supposed to be. Even if you're in fullscreen and set the palette, another program running in the background can attempt to change the palette and succeed, making the palette for the program intended to be viewed become garbled.

The big problem is that Windows 7 tries to do that palette change and corrupts it all by itself. Killing explorer and restarting it after exiting Quake works, but is a messy workaround/solution that is not cohesive to a user friendly client.

I've implemented an extremely ugly hack into my private build of the Quake engine, which works by forcing a palette update every frame instead of whenever it changes. This works well except for an occasional short, half second palette distortion when the game starts.

I've tried the same hack with Hexen 2, but it doesn't seem to work at all like it did for Quake.

Does anybody know of a real (not hacky) fix for this? I think all the software Quake-based engines out there would benefit from a fix.

DosBox had this problem up until recently. If they didn't just draw to a buffer, convert to a higher depth, then blit to the screen (a workaround, rather than a fix), the same solution would probably work for Quake and the like.

EDIT: On a side note to Baker, I noticed that Hexen 2 has nice looking software rendered transparent water. How hard would this be to backport over to ProQuake?

[MH]

The real cause of this problem is the use of the SciTech MGL library for WinQuake's renderer. I have a version of vid_win.c that doesn't use MGL and therefore doesn't suffer from this problem, and it's available for download from Inside3D (which is unfortunately down at the moment). I believe that Baker's been looking at it.

I also have a version 2.0 that uses fully native DirectDraw surfaces and runs quite a bit faster, but it's not suitable for human consumption (in other words it's f--ked).

[Baker]

I'm sure this issue is commonly known by now. If you run Quake with a software renderer, most engines will have the problem.

Try the MH-powered wqpro_api452.exe --- MH rewrote the software video code to not use Scitech MGL.

Warning: that exe will eventually crash. It's an experimental (for ProQuake, his code may work flawlessly with stock WinQuake) and I think I am writing pixels off the screen that makes it crash. As time progresses, I should be able to kill off that issue.

EDIT: On a side note to Baker, I noticed that Hexen 2 has nice looking software rendered transparent water. How hard would this be to backport over to ProQuake?

Well, ProQuake 4.52 has transparent water support in the software renderer courtesy of using some of Makaqu's code. Try r_wateralpha 0.5 and r_novis 1 on the start map, for example. Or on a map that actually supports transparent water, like q1edge or arenarg6 you don't need the r_novis 1. (r_novis is ghastly slow in software renderer).

However, post a screenshot of what the Hexen 2 software rendered transparent water looks like and I'll at least think about it.

The golden rule for ProQuake --- no external media requirements. So if this kind of thing requires an external color map for the alpha that is hard-coded to a specific palette (like the standard Quake palette), I would be unwilling to do it. The reason is, an assumption of the Quake palette is a false assumption ... a mod can use a different palette, such as what X-Men Ravages of Apocalypse uses. Hence a hardcoded palette is a hack in my book.

[metchsteekle]

try r_wateralpha .1 also, it looks shweet.

[Skutarth]

I should have figured MGL was the cause, since it relies on an antiquated DX API. I am pleased to hear that there's an up-and-coming alternative, though. Let me know when progress has been made with it!

Here are some examples of translucency in Hexen 2. Sorry about the window frames. I don't think it has screencapping built in or at least not bound to a key, and I'm too lazy to fix it in the code, trim off the borders, or figure out what the command to screencap is.





I think the colors are a bit off because I saved them from Paint, but you get the picture.

[WhiteMagicRaven]

So if you have problems with HeXen II use source port Hammer of Thyrion: Hexen II and HexenWorld for Linux, BSD, Unix, Mac OS X and Windows
Or install hexen2 and donot delete OpenGL32.dll in hexen2 folder (MiniGL) than install 3dfx emulator and you will run hexen2 GL original exes =)
nGlide - 3Dfx Glide wrapper | Zeus Software (wrapper uses Direct3D)
zeckensack's Glide wrapper (Wrapper uses OpenGL)

[Skutarth]

I don't have a problem with GL. I get no sound with Hammer of Thyrion, and one of the things I wanted was MP3 replacement of CD tracks either way (something I implemented but HoT doesn't support).

I almost always run software rendering because I like the nostalgia of playing it like I did in the days of DOS.

[WhiteMagicRaven]

P.S. mhquake is it true we will see DirectH2 whenever
as sayed here mhquake: Other updates for today (7th June 2010)

[MH]

I wouldn't say "will", but I'm definitely going to try it sometime and see how things go. I love me some Hexen II and think it's an obvious evolution to have the one engine handling both games.

[Skutarth]

I wouldn't say "will", but I'm definitely going to try it sometime and see how things go. I love me some Hexen II and think it's an obvious evolution to have the one engine handling both games.

From what I remember looking at the code, that's not as viable as you would think. There are a lot of changes from the stock Quake engine.