WinQuake without SciTech MGL (now with added DirectDraw)
WinQuake without SciTech MGL (now with added DirectDraw)
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.
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.
Last edited by mh on Mon Oct 25, 2010 1:26 am, edited 1 time in total.
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
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...)
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...)
i should not be here
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.
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.
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.
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.
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.
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
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.
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
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.
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.
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
*cough* FTEQW has that */cough*mh wrote:I'm sure that someone like Baker will undertake to do a resizable window at some point in time, though.
(And somehow Fruitz of Dojo on the Mac has that ... go figure).
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Actually, the intended standard resolution for DOS Quake was 320 x 240 (keeping the 4:3 aspect ratio).Baker wrote: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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Leileilol's computer considers 320x240 a "high resolution" mode.frag.machine wrote:Actually, the intended standard resolution for DOS Quake was 320 x 240 (keeping the 4:3 aspect ratio).
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..