InsideQC Forums

So, WDDM was introduced in Windows Vista... Good to know.

I'll test my current build in Windows XP later; if there's any errors besides the color 0 being always black under it, I'll add a cvar to make those lines optional.

You could always attempt to detect the windows version and choose smart defaults for that cvar too. I'm already doing that in Engoo, detecting WinNT to avoid generating lookups that involve the colors 0 and 255 (one reason why I take screenshots in the DOS version )

Changing the color 0 is working fine in my XP SP3 machine, so I'll leave those lines out.

Anyway, I already had implemented color 0 replacement for everything except the 2D graphics, so if anything goes wrong, it will be just the status bar and a few menu plaques.

auto-defaulting cvars depending on operating system means that a config cannot easily be copied from one system to the next, though for single player I don't think that's very common.

Then don't archive them?

I don't like the idea of different cvar defaults depending on anything; if it can't be given a sensible default then it probably shouldn't be a cvar, and if it's in any way system-dependent then it almost definitely shouldn't be a cvar (there are honourable exceptions).

The reason why I thought about creating a cvar is because I don't know how to make the engine detect the OS version, and also because I don't have all versions of Windows installed here to test on them. By using a cvar, players would be able to test it themselves. It was not meant to be a foolproof solution.

Theres a solution to finding the OS in xreal and doom3 using the INFOEX struct. Its somewhere in the sys files

There's an issue regarding dark colors being overly brightened by gamma. In Check_Gamma, remove the "+ 1" becomes

qbism wrote:There's an issue regarding dark colors being overly brightened by gamma.

The vanilla code doesn't have this bug, and the MGL-less code I'm using is the one without DirectDraw, and doesn't have it either. I only found it in code derived from SDLQuake.

In the original source, gamma is set by BuildGammaTable: The algorithm is a bit different here. It seems like the author of that bug rounded the 0.5 up to make the compiler not warn about possible loss of data in the implicit typecasts.

I'm having trouble trying to make the window stretchable (doing away with the "go fullscreen" maximize as well) with the video also being stretched by StretchBlt (no want for reinitalization crap right now).

Defining a case of SC_SIZE prevents the window from being resized also.

I've finally made the window 'stretchable' by having two nummodes, cycling one to another in between WM_SIZE calls while setting the width/height of both of those nummodes to the actual window size. Dirty hack, but kinda works. Now I just have to get those two dummy modes to not display in the modes list it resizes similar to how Unreal does it

Is there any documentation for SciTech MGL somewhere? I'm interested in what the API looks like, just for fun!

Considering Scitech MGL is what delayed GTA's release by 10 months I wouldn't think it sounds fun. The only real advantage of MGL is the support for VBE/AF and the Scitech Display Doctor/Univbe drivers, allowing linear accelerated video modes on the crappier video cards (such as Trident, Cirrus, Chips & Technologies, Neomagic, etc.. anything that isn't S3, Matrox, 3dfx, ATI or Nvidia).

I don't recommend learning MGL as, well, Nvidia hardware can't get along with MGL, plus it only really works in Win9x - it has lots of problems with NT/XP/Vista/7/8.
Honestly, the only audience you'll benefit with MGL support are the vintage computing audience....which I am a part of, but i'd rather maintain a DOS version than a Windows MGL version.

make your own vesa driver. that's more fun. all modern hardware should be fine with a linear-mapped framebuffer (with about just 3 interupts into the video bios), though hardware mouse cursors and vsync are more tricky.
devices that require windowing to access the entire framebuffer are more sanely handled by copying from system memory anyway, which would be faster on linear-mapped framebuffers too if you ever read it back.
if you're on windows, just use ddraw for fullscreen and dibs for windowed mode. special libraries with special hacks for each piece of hardware are more trouble than they're worth.