Page 1 of 1
Let your Hardware do the Scaling: OpenGL-HQ
Posted: Tue Jul 05, 2005 12:14 pm
by `Moe`
Hi!
I usually do some patch-contributing for the DOSBox project, but this time I created something which is also useful for this project: high-quality scaling using your graphics hardware. Imagine hq2x, hq3x, hq4x, hq-any-x, executed by your 3D graphics card.
The best of it: There's no coding to be done. The latest version of OpenGL-HQ is a binary-compatible patch for SDL, which means any SDL app can use OpenGL-HQ instantly, without recompilation. You just swap your SDL.DLL (or whatever your OS uses) and get gorgeous scaling surpassing anything currently available (if you're a hq2x/3x/4x lover, that is).
For a full list of features and requirements, visit the OpenGL-HQ homepage at
http://garni.ch/dosbox/, it includes screenshots, documentation, a precompiled win32 SDL.DLL, and full source code.
Primary support location is the dosbox forum (find the direct link on the HP), but please be sure to read the full README, there are some inherent limitations, and the dosbox folks already did a good job finding out the most frequent questions.
Oh, and feel free to mention this to other SDL-based emulator projects as well. I don't know them all
Have Fun!
Joerg
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Tue Jul 05, 2005 5:56 pm
by BC
Since you work on DOSBox and are posting here, I have a question for you. How do you make Ultima 7 and Serpent Isle run in DOSBox?
I've edited the config file for no ems, but I still get a turn off ems message when I try to run the game. My OS is Windows XP.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Wed Jul 06, 2005 10:50 am
by `Moe`
Uhm, 3 answers:
a) I don't - there's exult
![Wink ;)](./images/smilies/icon_e_wink.gif)
b) search the forums, it has been discussed many times
c) maybe you're not editing the right dosbox.conf; check that the file you're editing is actually the file dosbox reads (see README)
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Wed Jul 06, 2005 11:26 am
by Dominus
I vote for c
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Wed Jul 06, 2005 2:04 pm
by BC
I added a @echo line to the cfg file and it prints out on startup, so it should be the right file. I also try specifying the conf file when starting the program.
I always get the message, "An error has occured loading a program".
If I try to start the game by dragging the icon over DOSbox it tells me to turn off the expanded memory manager.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Thu Jul 07, 2005 12:30 am
by dag
let me return back to the original topic: is it possible and/or hard work to implement the scalers via opengl in exult?
can it even be combined with a kind of bilinear filter like for example, let's see... original game resolution at 320x240, hardware-scaled (e.g. hq2x) to 640x480, hardware-bilinear-stretched to 1280x960?
i have already asked about opengl-filtering one or two times before in this forum, but never got "a real" answer.
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Thu Jul 07, 2005 1:24 am
by Dominus
BC: sounds like your Dosbox configuration is busted somehow. Make a new dosbox.conf according to the readme and then edit ems=false in the right section.
Then copy the dosbox.conf file to where you have U7 installed to and then the drag'n'drop should work (because when you drag'n'drop, dosbox starts from the U7 directory and not the dosbox directory - make sure you have no mounts in the dosbox.conf file in the u7 directory).
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Thu Jul 07, 2005 3:52 am
by `Moe`
dag, what I've announced is not just hq2x, it's something which looks like hq2x/3x/4x (even slightly better), but works with _any_ scaling factor. You can have it scaled to 1280x960 or to any other resolution you like, and all you need is to swap SDL.DLL, no coding at all. If your graphics card is capable of running OpenGL-HQ, it's also capable of doing it at such resolutions.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Thu Jul 07, 2005 6:37 am
by dag
@moe:
that's reallyreally cool (and that's the way i thought it to be.
![Smile :-)](./images/smilies/icon_e_smile.gif)
)
but can it be combined with bilinear filtering like the way i mentioned it?
hmm, maybe i just didn't get it: what if the physical resolution was, let's say 857x671? will it be bilinear filtered _after_ the scaling took place?
sorry, if i didn't get the point, but i havn't got any experience in opengl-coding at all.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Thu Jul 07, 2005 7:17 am
by drcode
This scaling looks much better than the usual that I've seen with OpenGL, which I'd guess is bilinear. Is this a new feature of OpenGL?
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Fri Jul 08, 2005 5:10 am
by `Moe`
dag, no, there's no need for combining it with bilinear filtering. This isn't some fixed "hq2x". It scales _directly_ to _any_ desired output size in highest quality. You tell what window size you'd like, and OpenGL-HQ will output at exactly that size. Look at the screenshots, there are quite some odd sizes there.
DrCode, it's not a new feature of OpenGL but application code: It uses OpenGL to be cross-platform and to exploit the graphics hardware, but the scaler itself is plain custom programming, a couple of fragment programs and some framebuffer update logic. In fact, it began as a patch for DosBox, only later I had the idea to build it into SDL.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Fri Jul 08, 2005 6:13 am
by Andy
Hmmm.... could this not help to provide dynamic lighting? Also, the Exult 3D project might find this useful...
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sun Jul 10, 2005 6:50 pm
by Andy
So, was this a stupid question? (I realize I ask a few ;0p ).
If it is the case that dynamic lighting can be used (since it's OpenGL) then it would have to be tied to U7's weather engine, or weather, and sun angle would have to be re-thought about all together. Also, there's the two moons at night....candles, explosions, light from magic weapons....
Uh, ya, I'll work on it when I get a brain transplant.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sun Jul 10, 2005 6:55 pm
by SB-X
Hmmm.... could this not help to provide dynamic lighting?
Exult already has an OpenGL scaler and it hasn't been used for dynamic lighting. In that respect, OpenGL-HQ scaler wouldn't be any different. In fact, it would be less likely to be used for that purpose because it doesn't involve changing Exult. (only adding a library)
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Fri Jul 15, 2005 3:25 pm
by BC
It wasn't the config file. I installed DOSBox on a different computer with the same config, and everything worked fine.
There was no sound though. So I ran si.bat by drag & drop (it had run in my previous attempts). After this I recieved the error message everytime I tried running Serpent in DOSBox. Also si.bat would no longer run either by drag & drop or from the command line. So I guess this is what caused my problem previously.
Strangely though, complete uninstallation of both DOSBox and U7 did not fix the problem. I'll try reinstalling in new directories next.
Any idea why this is? I used the unistallers in both cases, and deleted anything left.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sun Jul 17, 2005 1:26 am
by Arterion
The graphics from this are really nice! Great job. I do have a slight problem, though, which I don't know how to rectify. In Exult, I get an problem where my movement doesn't work correctly. e.g. if I want to move left, I will move left a moment, the left-down for a moment, then left again, all the while I'm holding the cursor directly left.
I can rectify the problem by going into the video menu and setting the scaling from 1x to 2x, but the visual quality suffers severly. I realize that both the software and hardware are trying to improve on the visuals when I do that, and the movement problems are likely related to the mouse position getting confused because of the scaling.
I think I probably need to disable the software visual improvements entirely, but I don't know how to accomplish that. "Disabled" isn't an option from the menu. I want the physical resolution to be 512x384, and the scaled resolution to be something like 1024x786.
I know to set the set SDL_OPENGLHQ_WINRES variable to 1024x786, but I don't know what to do from there.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sun Jul 17, 2005 8:12 am
by drg
I have troubles getting this to work. I swapped the sdl.dll in the exult directory, I created the .bat with set SDL_VIDEODRIVER=openglhq and
set SDL_OPENGLHQ_FULLRES=640x480, set the scale to x1 in the video options, but when starting the bat, it does not run. When I checked the stdout.txt in exult directory it says 'Couldn't set video mode (640, 480) at 8 bpp depth' . Note that when launching exult.exe directly (not through bat) it works, but there is no difference in aspect that way. My video card is an ATI rage 128, with the latest driver (the one supporting opengl).
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sun Jul 17, 2005 11:02 am
by drg
P.S. The line in stdout.txt 'Couldn't set video mode (X, Y) at 8 bpp depth' refers to the resolution X, Y set in the exult video options, not the one assigned to the SDL_OPENGLHQ_FULLRES variable.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Fri May 08, 2009 7:40 am
by Malignant Manor
Screenshots
Exult opening screen, windowed with aspect correction, scaling factor 3/3.6
Exult in-game, fullscreen without aspect correction, scaling factor 4
Since OpenGL is working nicely now and compiled by default this is a good thread to bump.
I've only quickly tried using a few of the compiled sdl.dll (different version) provided by the project but get the error message "the procedure entry point SDL_putenv could not be located in the dynamic link library SDL.dll". This could possibly be due to hardware on the testing system and/or differing dll versions.
I've manually merged the changes of
the 1.2.11 version of OpenGL HQ with
SDL 1.2.13. I haven't tried to compile it yet but you will need the last two links plus
my merged files (if you want to use them). Hopefully, this helps people who don't trust automatic merging.
*crosses fingers* There are no accidental pluses from pasting. *uncrosses fingers*
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Fri May 08, 2009 2:26 pm
by Dominus
Hmm, as far as I understood, the principle behind that SDL based OpenGL rendering does not require that Exult uses OpenGL on itself. It might even be counterproductive.
I've only quickly tried using a few of the compiled sdl.dll (different version) provided by the project but get the error message "the procedure entry point SDL_putenv could not be located in the dynamic link library SDL.dll". This could possibly be due to hardware on the testing system and/or differing dll versions.
This usually happens when you use an Exult build that was compiled with a higher SDL version, with a lower version SDL.dll. So if you run a current snapshot with that SDL.dll that was based on SDL 1.2.11 that error is to be expected.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Fri May 08, 2009 9:02 pm
by Malignant Manor
Thanks, Dominus. I figured it was a compatibility between the compiled versions but lacked the time to investigate much. The only ones available were compiled 1.3 sdl.dll's from 2005. Once this gets compiled, it should be able to be copied into the Exult folder without any problems.
Hmm, as far as I understood, the principle behind that SDL based OpenGL rendering does not require that Exult uses OpenGL on itself. It might even be counterproductive.
From the readme:
Disable all software scaling in your program. Many emulators default to some
kind of scaling, but OpenglHQ can only work with x1 (no) scaling. Moreover,
if the program's output is larger than the selected window size, the output
is scaled down using traditional bilinear filtering.
I haven't spent much time reading up on this but you may be right about not working properly under the OpenGL scaler which is sad because that is what made me find this thread in the first place. Point 1x might work fine but I could try adding a seperate scaler setting for OpenGL HQ.
Hopefully, I can compile it without problems since a background program will have the compiler running at a snail's pace for about a day and a half longer.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sat May 09, 2009 3:19 am
by Malignant Manor
I took a compiled sdl.dll from
gulikoza's DOSBox build.
Here is that dll with the readme and an added batch file to run Exult. Just add them to you Exult folder. This will work with the compiled snapshots Kirben makes and shouldn't cause any issues. Make a backup of sdl.dll just in case. Also remember to keep the modified sdl.dll backed up as well so that you can replace the one that automatically is installed when upgrading to a newer snapshot.
In Exult:
* Make sure that the scale_method in exult.cfg is Point and the scale is 1
* Switching between a window and fullscreen or changing the resolution will screw up rendering
* Because of the window size change between the Exult menu and the game menu/game, you need to use the --no menu command line to bypass it.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sat May 09, 2009 5:08 am
by Wizardry Dragon
I think the problem with it really is it doesnt have the same accomodations for varying resolutions that the software renderers (or some of them, at least), do - evidenced by the issues with the Exult menu. I suppose you could code around them, but I haven't touched the Exult rendering code in years and years, so I wouldn't know how easy or difficult that would be now.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sun May 10, 2009 12:26 am
by Malignant Manor
After testing on another computer, I guess the former video driver or card isn't fully compatible with this. The other computer worked perfectly so there is no need to bypass the Exult menu if yours works. My use of --nomenu in the batch file was out habit but shouldn't be needed even if the video card/drivers aren't fully compatible since there is no window resizing.
I suggest to make a copy of Exult.cfg and run the command line -c configfile to load it so you don't have to change the settings every time you switch between software and hardware scaling.
If you are building from source, "#undef SDL_VIDEO_DRIVER_OPENGLHQ" needs to be added to SDL_config.h.in. I read about it being missing at the DOSBox forums.
Code: Select all
--- SDL-org/include/SDL_config.h.in 2006-06-20 05:33:59.000000000 +0200
+++ SDL-1.2.11/include/SDL_config.h.in 2006-09-22 10:57:44.000000000 +0200
@@ -264,6 +264,7 @@
#undef SDL_VIDEO_DRIVER_GGI
#undef SDL_VIDEO_DRIVER_IPOD
#undef SDL_VIDEO_DRIVER_NANOX
+#undef SDL_VIDEO_DRIVER_OPENGLHQ
#undef SDL_VIDEO_DRIVER_OS2FS
#undef SDL_VIDEO_DRIVER_PHOTON
#undef SDL_VIDEO_DRIVER_PICOGUI
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Mon May 18, 2009 5:53 am
by Dominus
Hmm, while I'm writing on the documentation, I wondered if Exult could use the OpenGL HQ scaler "natively" since we now have working OpenGL scaling. The reason I'm asking is because our OpenGL scaler only does point scaling (?) and I'm used to the blurred look of the non OpenGL scalers
And while I appreciate Moe's way of doing it through SDL, from end-user point of view it is not very practical.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Mon May 18, 2009 6:29 am
by Malignant Manor
There are you can likely set it up to likely call it from within Exult with a little programing but not with OpenGL. (I can't even compile the dll myself.) The modified dll shouldn't cause issues if compiled from scratch (the stolen one has DOSBox specific edits) so Kirben could use it.
If the DLL was distributed and no further code or the patch to not have to install the dlls in a custom Windows install, then there is a little setup in the beginning and then no changes needed until possibly the next sdl comes out.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Sun Jul 01, 2012 7:36 pm
by Malignant Manor
Code: Select all
OpenGL-HQ for SDL
=================
This readme documents version 2006-12-15 of OpenGL-HQ, if you got
a later version there's a slim chance I forgot to update this :)
The current version and screenshots can be downloaded from
http://garni.ch/dosbox/
OpenGL-HQ is a video "driver" for SDL that uses your graphics hardware
to scale the output to any size you want. It was originally written for
2D games/emulators like dosbox, scummvm or exult.
WARNING: This is beta quality software. While it works nicely for me
and several other people, expect bugs to be present. If something
doesn't work, first check for a new version. Please mail me if you
encounter anything that's not yet listed in the README.
Features:
- uses your hardware to get fast scaling
- scales any 2D SDL program
- scales with any scaling factor, even fractional ones
- switches back to the native driver if an app tries to use OpenGL
- portable
- configurable like SDL
- see the screenshots at the URL above, really
Requirements:
- a Radeon 9600, GeForce 5700 or higher with current driver
(OpenGL extension ARB_fragment_program must be supported
and hardware-accelerated, EXT_framebuffer_object is also needed)
- OpenGL-support for your OS in SDL (which means Windows,
Linux/X11 or MacOS X)
Limitations:
- may show bad performance with programs that already provide
high-resolution output or with high-quality driver settings
(Radeon 9600-9800 class chips are driven at their limits)
- MacOS X untested (but should work)
- it has become very unlikely, but it is still possible that desktop
resolution is not autodetected correctly; use SDL_OPENGLHQ_FULLRES
in that case
Bugs unlikely to be fixed, or of unknown origin:
- ATI's Triple-Buffering feature interferes with some apps; if you see
lockups or similar, try setting SDL_OPENGLHQ_DOUBLEBUF as shown below
-- needs to be confirmed against current drivers
Bugs to be fixed:
none known
If you see any problems, CHECK THE TROUBLESHOOTING SECTION BELOW.
If your problem is not solved there, please write as detailed as you can:
Tell me what you did (exactly!), what you expected to happen, what
happened instead, and include screen shots of the problem. Include any
relevant config files as well (dosbox.conf for dosxbox, for example).
How to use (Quickstart)
=======================
This is a windows quickstart guide. Other systems adjust as needed.
1) Copy SDL.DLL into the application's directory, overwriting the shipped
version
2) Create a batch file (using Notepad) with these contents:
set SDL_VIDEODRIVER=openglhq
set SDL_OPENGLHQ_WINRES=800x600
.exe
3) Save the file as .bat in the same directory
as the EXE file is
4) Double-click this batch file to start the application; Create a shortcut
or adjust existing shortcuts to use this batch file
Configuration
=============
Configuration is done via environment variables (just like the rest of SDL). It
is recommended to set these options in a batch file (see previous section).
SDL_VIDEODRIVER - set it to openglhq to use OpenGL-HQ
SDL_OPENGLHQ_WINRES
SDL_OPENGLHQ_FULLRES - set to a resolution like "960x720" to set the windowed/
fullscreen size in all windowed/fullscreen modes; you may
add a bit depth as in "960x720-16"; alternatively, you can
specify a fixed scaling factor (like "2.5")
default: windowed: "1", fullscreen: your desktop resolution
SDL_OPENGLHQ_VIDEODRIVER - set to the name of your SDL video device (the one you'd
normally use for SDL_VIDEODRIVER)
SDL_OPENGLHQ_DOUBLEBUF - override application's choice of doublebuffering; if set
to 1, doublebuffering is always on, if set to 0, doublebuffering
is always off; if unset, the application's choice is respected
SDL_OPENGLHQ_STATIC
SDL_OPENGLHQ_DYNAMIC - two parameters which tweak the HQ calculation; the defaults
(static 10, dynamic 33) are fine in most cases; to optimize
rendering, play with these values (static 0-255, dynamic 0-100)
SDL_OPENGLHQ_DATA - a directory with data files for OpenGL-HQ - do not set this
You must set SDL_VIDEODRIVER to get any effect at all. If you want windowed
applications to be scaled, set SDL_OPENGLHQ_WINRES. Everything else is usually not
neccessary, the settings are autodetected.
If you want to set options for ALL SDL apps, you can do so:
Windows: Control Panel -> System Properties -> Advanced -> Environment Variables
Unix-like systems: add "export =" to ~/.profile
Performance
===========
To put it short: Absolutely great.
On hardware barely meeting the minimal requirements,
running a demanding protected-mode high-resolution SVGA program in DOSBox
with frameskip 0 and scaling by a factor of 2, performance drops by just 20%.
At frameskip 4, performance difference is at 5-10%.
At VGA resolution scaling by 4, the difference is reduced even more:
12% performance loss at frameskip 0. Software scaling is far worse: Normal2x
costs about 20%, advmame2x is at 25%, hq2x (not my optimized version, but the
slower HiEnd3D version) about 40%.
Troubleshooting
===============
Q: Something doesn't work or looks weird.
A: Check that you are running the latest official video drivers. It has not been
tested with hacked drivers, and old drivers are known to fail.
Q: DosBox crashes.
A: DosBox has bad error handling at video initialization. Until that's fixed,
a crash most probably means your hardware doesn't support OpenGL-HQ.
Q: DosBox locks up when trying to go fullscreen
A: ATI driver issue. Set "fulldouble=false" in your dosbox.conf, or set
SDL_OPENGLHQ_DOUBLEBUF
Q: Performance is terrible!
A: You've probably set forced vsync-waiting in Catalsyst Control Center and your
app wants double buffering (like "fulldouble=true" in DosBox). On a Radeon
9600-9800 class chip, that's simply too much at higher resolutions. These
first fully programmable chips are used to their limits, so that's barely
surprising.
Q: It works partly, but some video modes look exactly like before.
Q: Output looks much worse than in your screenshots, blurry and not sharp at all.
Q: WTF? I did everything as shown, and nothing changed?
A: Disable all software scaling in your program. Many emulators default to some
kind of scaling, but OpenglHQ can only work with x1 (no) scaling. Moreover,
if the program's output is larger than the selected window size, the output
is scaled down using traditional bilinear filtering.
Q: My mouse is slow! How can I speed it up?
A: This should mostly be fixed in the last release, but your backend video driver
might change acceleration setting when grabbing the mouse. At least the x11
driver does that, and you can configure it using environment variables.
For more help, search the "DosBox Patches" forum at http://vogons.zetafleet.com
for OpenGL-HQ. This code was first developed for DosBox only, and I regularly read
that forum.
Please DO NOT mail Sam Lantinga or the SDL team about this, they aren't involved in this
in any way at all.
Developer info
==============
If you are an application developer, you can use the "putenv" (POSIX) / "_putenv"
(MSVC) call to change these settings from within your program. For example, if you
want to enable openglhq, just use:
putenv("SDL_VIDEODRIVER=openglhq");
Of course, to be a fair player, you'd want to save the old value of SDL_VIDEODRIVER
first and set SDL_OPENGLHQ_VIDEODRIVER to that value, like this:
void EnableOpenglHQ()
{
static char entry[1024], *oldentry;
oldentry = getenv("SDL_VIDEODRIVER");
if (oldentry != NULL) {
strcpy(entry, "SDL_OPENGLHQ_VIDEODRIVER=");
strcat(entry,oldentry);
putenv(entry);
}
putenv("SDL_VIDEODRIVER=openglhq");
}
void DisableOpenglHQ()
{
static char entry[1024], *oldentry;
oldentry = getenv("SDL_OPENGLHQ_VIDEODRIVER");
if (oldentry != NULL) {
strcpy(entry, "SDL_VIDEODRIVER=");
strcat(entry,oldentry);
putenv(entry);
} else {
putenv("SDL_VIDEODRIVER");
}
}
Do the same for other configuration variables. One exception is SDL_OPENGLHQ_DOUBLEBUF,
this is intended for users only - developers should use the SDL_DOUBLEBUF flag as usual.
I've included a DosBox patch for those that want to enable openglhq in dosbox.conf.
How to compile
==============
This assumes you know how to compile C programs under a GNUish environment (Linux,
MingW, MacOS X with extra GNU tools). If you never used "cvs", "patch" or "make"
before, try to get a guide on these topics first. [some helpful soul please send
me a link]
First, get and extract a copy of the SDL-1.2.11 sources. Other versions have not been tested.
Then, move the directory "openglhq" (the one this README is in) below SDL-1.2.11/src/video
Then, patch SDL and create needed data files. cd into the SDL-1.2.11 directory and run
make -C src/video/openglhq
Watch closely for errors! If you see any, check that you have a recent autoconf and
automake installed, and that you are indeed using a clean source tree of SDL-1.2.11.
Now run configuration:
./configure
Check that it found your OpenGL libraries and headers. If it doesn't, this code is
automatically disabled. Check "./configure --help" to see how to tell SDL the
location of your GL libraries and headers.
Finally, compile and install:
make && make install
The resulting library should be a drop-in replacement for your existing
libSDL.so/SDL.DLL. It should be binary compatible, meaning that none of the apps
using it must be recompiled.
License
=======
SDL - Simple DirectMedia Layer OpenGL-HQ scaling
Copyright (C) 2005, 2006 Jörg Walter
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.
You should have received a copy of the GNU Library General Public
License along with this library; if not, write to the Free
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
The SDL patch uses code published on the SDL mailing list in January 2005 for
desktop resolution autodetect.
Credits
=======
Many thanks to all VOGONS users who assited in testing and providing windows
builds. Even more thanks to gulikoza from the VOGONS forums for porting the
code to EXT_framebuffer_object.
History
=======
2006-12-15 fix a subtle mouse movemement bug mainly observable in fullscreen
apps, improve API compatibility, reduce needless pixel copying,
working MacOS X support
2006-11-22 fix 16-bit video modes on ATI cards, improve compilation sequence,
improve rendering accuracy and speed by reducing complexity
2006-11-21 use EXT_framebuffer_object extension for rendering, fix threading
issues, improve performance, port to SDL-1.2, make 64-bit-clean
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Mon Jul 02, 2012 2:43 am
by Dominus
Hmm still wonder whether one can rip the openglhq scaling out of it and apply it to our opengl scaler
Unfortunazely Moe disappeared from the scene, seemingly from one day to the other ;(
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Mon Jul 02, 2012 3:25 am
by Malignant Manor
There's an updated patch for SDL 1.2.1.4 but I have no idea if it compiles easily.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Mon Jul 02, 2012 3:26 am
by Dominus
Not to mention that sdl is at 1.2.15 now which is essential to running SDL apps on os x these days...
And I still think that for an end user this way through SDL is not very friendly. I like the idea but it is a developer idea without regard to user friendliness.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Mon Jul 02, 2012 3:40 am
by Malignant Manor
The patch may work for 1.2.15 with minimal effort. I have no idea how easily the code code be separated from SDL. I need to finish other things before I even attempt compiling it for SDL. Plus, I have no way of testing it on this computer.
Re: Let your Hardware do the Scaling: OpenGL-HQ
Posted: Mon Jul 02, 2012 6:46 am
by Dominus
I might take a look at getting that into a scaler when I find some time and shelter from the heat. Yesterday my city was nominated hottest city in Europe (and not in a sexy way) and the heat will stay until the weekend...
Sorry I'm ranting...
Edit: he he, one look and I can say this is over my head...