WinQuake without SciTech MGL (now with added DirectDraw)

[frag.machine]

[mh]

[mh]

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



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]

[mh]

[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]

[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]

[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]

[mankrip]

[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.