WinQuake without SciTech MGL (now with added DirectDraw)

[mh]

This is a 100% drop-n-go replacement for vid_win.c that will enable you to build a version of WinQuake that doesn't need or use the SciTech MGL library.

vid_win_no_mgl.zip

I've taken it from a WinQuake build I'm currently experimenting with (interpolation, console alpha, some extended limits) and may release some day, but it can be used in any WinQuake engine. No other changes are needed, replace your vid_win.c with this one, compile and run.

No DirectDraw (it's nasty stuff), just pure unadulterated Windows GDI goodness. Performance is about on a par with the MGL version.

[leileilol]

Awesome! Modern card stabilities be damned.

Interestingly, this lead me towards a step for a Windows 3.1 Quake port using Win32s, but it left me hanging at a error unable to create a timing event. Oh well, I came close, anyway. Needed to dummy out all the display changing functions so no fullscreen support for Win31 (Unless WinG is used...)

[qbism]

WOW! My laptop can now go native resolution in software mode (1280 x 800).

caveat- vid.rowbytes can be negative, so some engine mod stuff may need to abs() it, like high-res waterwarp from makaqu-
warpbuffer = Q_malloc(abs(vid.rowbytes)*vid.height);

Here's a 480x600 slice


Full screenshot link:http://qbism.com/MGalleryItem.php?id=15

Featuring alpha water and particles, stainmaps, and oq+ items! Map is anti clan IV.

[Baker]

I missed this.

Interesting ....

That MGL stuff in vid_win.c looks hard to maintain and inflexible.

[Spike]

Yes. MGL sucks.

DAMN YOU AND YOUR BLUE START BUTTONS!!!

It wraps the APIs, and still requires you to know which API its using. Easier to use the API in question directly. Less overhead then, and less GPL concerns. Oh, and less blue start buttons. I really have no idea how it achieved it, but it makes me want to put that in an app and install it on people's computers just to see their face when their startbutton starts flashing random colours.

Q2 supports directdraw. I wonder what the performance difference would be now that windows emulates everything anyway.

[Baker]

I added this in to my engine as a test and reorganized some of the stuff just slightly to mirror changes I've made (rather mild stuff).

Some notes relating to this ...

First, it is a lot cleaner.

1) Doesn't seem to show the ultra low resolutions in the video mode setup screen. I'm sure I could make it do so. Since software renderers are CPU intensive with more pixels, having lower resolution modes available obviously is helpful.

2) I can get a crash. I'm sure I can determine the nature of it when I have some time to play around and prioritize this. Maybe something like trying to draw a pixel off the screen somewhere ... or something to that effect.

Again, it is a lot cleaner --- quite an understatement actually. No unsightly palette flashing, fast performance when switching video modes ... no silly taskbar icons rendering themselves through fullscreen mode.

I do notice that software renderers plus the mp3 playback based on MHQuake's don't play nice together especially when the screen resolutions get higher. They must fight each other for CPU time.

Something for sure to play around with more when time permits.

[Baker]

My test implemention of this, MH's rewritten vid_win.c actually beats the MGL version by 14 frames per second in a timedemo demo1.

timedemo demo1: vid_win.c = 251 frames per second.
timedemo demo1: vid_win_mh.c = 265 frames per second (!)

This is in 320x200 mode. Of course, MH's code doesn't allow that mode

But I consider that standard software Quake's native mode.

[mh]

I must dig out my native DirectDraw version and see if I can tidy it up and get it working again; that was even faster.

[leileilol]

Does that come with a resizable window for windowed mode?

I don't mean re-initing a new video mode per resize - i mean stretching using the hardware overlay or whatever that accellerated 2d plane is called.

Quake has been missing this kind of versatility for a long time.

[mh]

No, no resizable window. Doing that would mean (at the very least) having to destroy and recreate the back buffer every time the window size changes (and remember that it can change down as well as up). It also needs to recalculate the clip area for in_win.c and update the 25,000 global variables that Quake uses for storing the window size. Then we need an agreed mechanism for storing out the new window size, for restoring it when Quake starts up again, how it's going to behave if you move the config to a new PC, and all kinds of messy stuff like that.

In theory it's no more difficult than setting a new video mode, but in practice there are lots of fiddly little bits that need to be gotten right, and it's probably better for now to just focus on the core job of getting the f-ck rid of MGL. I'm sure that someone like Baker will undertake to do a resizable window at some point in time, though.

[Baker]

I'm sure that someone like Baker will undertake to do a resizable window at some point in time, though.

*cough* FTEQW has that */cough*

(And somehow Fruitz of Dojo on the Mac has that ... go figure).

[leileilol]

Then we need an agreed mechanism for storing out the new window size, for restoring it when Quake starts up again, how it's going to behave if you move the config to a new PC, and all kinds of messy stuff like that.

zdoom didn't need that

[frag.machine]

My test implemention of this, MH's rewritten vid_win.c actually beats the MGL version by 14 frames per second in a timedemo demo1.

timedemo demo1: vid_win.c = 251 frames per second.
timedemo demo1: vid_win_mh.c = 265 frames per second (!)

This is in 320x200 mode. Of course, MH's code doesn't allow that mode

But I consider that standard software Quake's native mode.

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

[Baker]

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

Leileilol's computer considers 320x240 a "high resolution" mode.

[leileilol]

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.