WinQuake without SciTech MGL (now with added DirectDraw)

[frag.machine]

Actually, the intended standard resolution for DOS Quake was 320 x 240 (keeping the 4:3 aspect ratio).

Explain why DOSQuake defaults to 320x200 then? 320x200 is intended to be 4:3 also.

320x240 was obtained via mode X, which wasn't 100% standard among all VGA cards back in 1996 (it worked OK in like 90% of the hardware, but there were a few chipsets that failed), so 320x200 was a safe fallback. And no, 320x200 != exact 4:3 aspect ratio.

[mh]

320x200x256 is standard VGA mode 13h. In other words if you were releasing a graphics program back in those days, and you wanted it to run on as wide a range of hardware as possible, you bloody better support this as your default. Anyone who remembers the old 80x25 character displays can do some interesting calculations around this.

I'm of the opinion that there is no such thing as a "canonical" video mode that you are "meant" to run software Quake at, or that software Quake is "designed" for. If you go back to the old techinfo.txt that came with DOS Quake you'll see it's pretty clear that 320x200 is just "the mode that works" and nothing more, and that there's plenty of talk about running Quake at higher resolutions.

[mh]

It took a while but here it is: the version with DirectDraw as well.

vid_win_ddraw.zip

This is 32-bit DirectDraw because I didn't want to go messing around with exclusive mode, losing the surface, different modes for fullscreen vs windowed, and crap like that. I'll leave it as an exercise for anyone who wants to do an 8-bit version.

It still runs faster than the GDI version (which it's 100% compatible with, drop-'n'-go replace) despite this (might be slower on Windows 7 though). Just popped it into a test build and even a year after I wrote it, it still works just fine.

You can switch between the DirectDraw and the GDI drivers by using the "vid_ddraw" cvar.

I had another version that also supported GDI+ and Direct3D drivers, but both performed poorly. It should be possible to do an OpenGL driver for this too, by the way...

[leileilol]

How would doing an MMX overlay work out for performance? On a P2/P3 that is (PMMX , K6 and 6x86MX wouldn't do so well)

ok, im annoying. i'll try this out

[mh]

No idea. The DirectDraw portion of the code is pretty close to optimal as-is (at least for 32-bit), so I doubt if there's much more to be squeezed out of that (aside from going 8-bit, of course, and I could be wrong).

I've compiled both Win and GL Quake using MSVC 2008 with support for SSE and SSE2 instructions, trusting the compiler to work out what's best (which it's pretty damn good at), and got no performance improvements at all. In the case of WinQuake that's obviously the asm at work preventing it, in the case of GLQuake it suggests any bottlenecks that exist are elsewhere.

It would be interesting to compare an SSE2 WinQuake with an asm WinQuake though. Be nice to be able to get rid of the asm. You could write directly to the DirectDraw surface then instead of having to go through an intermediate system memory buffer. And start updating the software renderer for full proper 32-bit support too.

[Spike]

firstly, why does the asm stop you from writing to vid.buffer?
your vid.rowbytes or whatever it is can be negative, and it'll work just fine (just make sure vid.buffer points to the start of the last line).

secondly, I agree that sse instructions are not really faster than x87 instructions. my personal experience was that x87 was actually faster. a large part of that is because sse is somewhat terrible for dotproducts, which quake has a lot of. later sse versions supposedly have better support for it.
sse is good for batch processing numbers big arrays, but for complex calculations its less good.
Also automatic optimisations won't use the more efficient aligned stores/loads.

MMX is hard to optimise automatically. And prevents you from using x87 instructions in the same blocks of code. So you'd need to write that stuff by hand. It'll perform best when you can churn out lots of pixels at a time, but really anything like that will have extra setup costs, so its not a guarenteed speedup in highly complex scenes. Its probably worthwhile for mixing the texture with its lightmap, but for actual rendering I'm less sure. Might be usable for the world, but models I wouldn't bother with. MMX is awesome for sound code though. :)

[mh]

secondly, I agree that sse instructions are not really faster than x87 instructions. my personal experience was that x87 was actually faster. a large part of that is because sse is somewhat terrible for dotproducts, which quake has a lot of. later sse versions supposedly have better support for it.
sse is good for batch processing numbers big arrays, but for complex calculations its less good.
Also automatic optimisations won't use the more efficient aligned stores/loads.

Yup, just did some test builds and both SSE and SSE2 compared quite poorly (about one third the speed).

That's useful info to have upfront as it may help prevent someone from going all the way with ripping out the asm only to realise at the very end that it was a bad idea.

[Spike]

I don't know what you're testing, but its not framerates/frametimes in quake. :)

Try rewriting your test loop using the msvc intrinsics, do four elements at a time, then see if its still slower.

[leileilol]

What about Quake2's video context code?

[szo]

Have been using the dib sections code in my hexen2 project, uhexen2: first tested as is with the bottom-up dib setup, it worked, by magical means, in 32 bits only, whereas in 64 bits it failed miserably. Tried to understand the reason, got bored, and switched to using a top-down setup by feeding -DIBWidth to VID_CreateDIB() as the lazy solution albeit the result being somehow slower.

Noticed today that one big difference between q1 and q2 code is that the width, height, and most importantly the rowbytes member of the viddef_t structure is unsigned int in q1 but signed int in q2: the bottom-up dib section code might as well be the reason for the change. For the bottom-up setup, we are assigning -width to vid.rowbytes, which is unsigned in q1, and it works in 32 bits because the address space is 4 gb and you get a wraparound in pointer atrithmetics. However in win64 that doesn't happen with 64 bit pointers and you simply get a segfault.

In short, the dib code here is really meant for signed int vid.rowbytes. In case anyone ever runs into such failures...

Just applying patches to uhexen2 now, changing the width, height, conwidth, conheight and rowbytes members to signed int. The conrowbytes member is already signed so that's ok already. Shame that I nailed the issue this late, but better late than never.

[qbism]

Shame that I nailed the issue this late, but better late than never.

Someday, someone with the same issue will find this in a web search.

[Vic]

Too bad I've never actually ported tochris to using DDraw init code :/ Along with proper renderer separation a-la Quake2. Good job anyway!

Off-topic: Although I don't get this obsession with asm code removal, it still performs a ton better than the C version.

[qbism]

Off-topic: Although I don't get this obsession with asm code removal, it still performs a ton better than the C version.

ASM video can be removed for ddraw while keeping ASM spans. DirectX SDK 2010 dropped ddraw.lib so we're obsolete either way.

[mankrip]

Is this really necessary?

Code: Select all

void VID_SetPalette (unsigned char *palette)
{

[...]

			colors[0].rgbRed = 0;
			colors[0].rgbGreen = 0;
			colors[0].rgbBlue = 0;
			colors[255].rgbRed = 0xff;
			colors[255].rgbGreen = 0xff;
			colors[255].rgbBlue = 0xff;

[...]

}

Removing those lines fixed the "color 0 can't be changed" for me. I've tested it in Windows Vista, and changing the color 0 works perfectly.

Also, I've got no clue why the color 255 is also being forced to 0xFF in this code. The original code didn't do that.

[mh]

It was needed on XP because the old driver model reserved those palette indexes for it's own use (long-standing NT issue). Can't exactly remember the thinking behind setting them to 0/0xff though. Either using an 8-bit buffer that's expanded to 32-bit at Flip time, or a WDDM driver, should remove the requirement for it.