WinQuake without SciTech MGL (now with added DirectDraw)
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.
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.
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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 )
i should not be here
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.
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.
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.
Re: WinQuake without SciTech MGL (now with added DirectDraw)
Then don't archive them?
i should not be here
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.
Re: WinQuake without SciTech MGL (now with added DirectDraw)
Theres a solution to finding the OS in xreal and doom3 using the INFOEX struct. Its somewhere in the sys files
Productivity is a state of mind.
Re: WinQuake without SciTech MGL (now with added DirectDraw)
There's an issue regarding dark colors being overly brightened by gamma. In Check_Gamma, remove the "+ 1" becomes
Code: Select all
f = pow ((i + 1) / 256.0, gamm);
Code: Select all
f = pow (i / 256.0, gamm);
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.qbism wrote:There's an issue regarding dark colors being overly brightened by gamma.
In the original source, gamma is set by BuildGammaTable:
Code: Select all
void BuildGammaTable (float g)
{
int i, inf;
if (g == 1.0)
{
for (i=0 ; i<256 ; i++)
gammatable[i] = i;
return;
}
for (i=0 ; i<256 ; i++)
{
inf = 255 * pow ( (i+0.5)/255.5 , g ) + 0.5;
gammatable[i] = minmaxclamp (0, inf, 255); // mankrip - edited
}
}
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.
Defining a case of SC_SIZE prevents the window from being resized also.
i should not be here
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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
i should not be here
Re: WinQuake without SciTech MGL (now with added DirectDraw)
Is there any documentation for SciTech MGL somewhere? I'm interested in what the API looks like, just for fun!
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.
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.
i should not be here
Re: WinQuake without SciTech MGL (now with added DirectDraw)
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.
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.