Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

WinQuake without SciTech MGL Goto page 1, 2 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Mon Apr 05, 2010 9:31 pm Post subject: WinQuake without SciTech MGL |

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Mon Apr 05, 2010 11:16 pm Post subject: |

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...)
_________________

Back to top |

qbism Joined: 04 Nov 2004 Posts: 82 |

Posted: Fri Apr 09, 2010 2:06 am Post subject: |

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.
_________________
http://qbism.com

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Aug 03, 2010 8:29 am Post subject: |

I missed this. Interesting .... That MGL stuff in vid_win.c looks hard to maintain and inflexible. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Tue Aug 03, 2010 11:05 am Post subject: |

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.
_________________
What's a signature?

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Aug 03, 2010 3:25 pm Post subject: |

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Aug 10, 2010 3:08 am Post subject: |

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Aug 10, 2010 8:22 am Post subject: |

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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010 MHQuake Blog (General) Direct3D 8 Quake Engines

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Aug 10, 2010 8:49 am Post subject: |

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

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Aug 10, 2010 9:35 am Post subject: |

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Aug 10, 2010 9:44 am Post subject: |

mh wrote:
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).
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Aug 10, 2010 9:46 am Post subject: |

mh wrote:
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
_________________

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Tue Aug 10, 2010 12:34 pm Post subject: |

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.

Actually, the intended standard resolution for DOS Quake was 320 x 240 (keeping the 4:3 aspect ratio).
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Aug 10, 2010 1:34 pm Post subject: |

frag.machine wrote:
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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Aug 10, 2010 7:53 pm Post subject: |

frag.machine wrote:
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.
_________________

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group