VOGONS

Common searches


First post, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Well, it's difficult to tell the GPU that nothing has changed, even more so because DOS programs usually access the framebuffer directly, and dosbox doesn't have a way to detect changes automatically. Manually checking would be quite time-consuming. There is a patch somewhere which adds a simple version of this check for all scalers, but I think it had other issues. Doublebuffering adds more issues. All that means it's more complex to do that than you'd think at first.
I'm right now working on an even more improved version of OpenGL-HQ, and I will keep your idea in mind.

Reply 1 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

So, here is the latest installment of OpenGL-HQ. But it's different than all releases before: it's a patch for SDL!

Yes, this means ALL SDL apps can be scaled. I've tested it with exult and scummvm, and it works fine.

Get the patch (sorry, no binary yet) at the usual place: http://garni.ch/Software/dosbox/

Follow the instructions in the README, and in dosbox.conf, disable ALL scaling and set output=surface. Performance seems to be way better (don't ask me why), the look didn't change.

Hint: There are some places in the README where some volunteers could help me 😉

Reply 2 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

An interesting idea certenly, but I don't think I like it yet 😀 There's no easy way of changing environment variables in windows (most users are just used to clicking icons). Supporting existing apps can be both good and bad thing. Passing something like SDL_OPENGLHQ flag to SDL_SetVideoMode might be a better idea, but ofcourse, existing apps could not use it then...

Reply 3 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Indeed, plus it would mean a bigger, more intrusive patch to SDL. The patch, as it is, is practically no patch at all, but a subdir that's added, plus a few lines to adjust Makefiles. Way cleaner than what I did to DosBox. A long way cleaner. I hope the dosbox sources forgive me 😉

As for the practical side: SDL is configured using environment vars. This need not just be in your system configuration. A batch file does it's purpose as well, and you can just do a 'setenv("SDL_VIDEODRIVER","openglhq")' in your program to enable it (something SDL users usually forget...). IMHO SDL's conventions are uncommon, but useful.

Reply 4 of 156, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Moe: That's awesome! I hope you submit it to the SDL devs so it might get into the CVS.

gulikoza: I could go both ways on this. For starters, SDL already uses environment variables to control some of its behavior. On the other hand, it's not unreasonable to force developers to add specific support for Moe's stuff to make sure that it doesn't break their apps. Plus, there needs to be a way to turn it on in code and not just via an environment variable for apps developed in the future (to address your point of user-unfriendliness).

Reply 5 of 156, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Moe: Another issue I should mention is that putenv() is not ANSI C and doesn't work too well in some environments. For example, it seems that the environment gets reset after a program exits (inside of the same NTVDM or MSYS session).

Reply 6 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

putenv is supposed to be reset. It only has effect for the current process, and any child processes it might start (and not even those, depending on how you start them). Of all OSes only DOS allowed a program to modify the global environment, and that was compiler-dependent and probably a bug (but who cared? You'd reboot anyway for the next game, since it wanted other memory managers, other drivers, ... 😀 ).

The app is supposed to use putenv for it's own configuration only, which is reasonable and works very well. Look at the SDL docs, it is even documented (although, as I already mentioned, few people seem to notice that passage).

The only gotcha might be that switching SDL_VIDEODRIVER needs a SDL_QuitSubSystem/SDL_InitSubSystem(SDL_INIT_VIDEO) cycle, but that is manageable (and works - the DosBox version of OpenGL-HQ does that, too).

Patching DosBox to support the SDL variant of OpenGL-HQ would probably mean a 10-line patch. I didn't do it yet, since in the current state, it's far from getting into offical releases (remember that the 1.3 branch of SDL is not scheduled for any release yet), so it's something for insiders anyways. Of course, if someone compiled a nice SDL.DLL and shipped a dosbox.exe with a batch file for openglhq, he'd do me a favour *hint* 😀

Reply 7 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie

Does anyone have a build of SDL.dll with openghq that works? I have not had much success with building it using MinGW..

Edit: Perhaps I need to set the path of the windows opengl library...? Any clues how I might do that so that ./configure picks it up?

Reply 9 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie
`Moe` wrote:

set LDFLAGS to contain "-L/path/to/your/libGL.a"

Err, small problem with that; MinGW only comes with libopengl32.a. I've made a link to it called libGL.a, and passed the dir as an LDFLAG, but configure still doen't seem to detect it, and compilation crashes out at:

SDL_wingl.c  -DDLL_EXPORT -DPIC -o .libs/SDL_wingl.o
SDL_wingl.c:232:2: #endif without #if
make[3]: *** [SDL_wingl.lo] Error 1
make[3]: Leaving directory `/c/dev/SDL12/src/video/wincommon'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/c/dev/SDL12/src/video'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/dev/SDL12/src'
make: *** [all-recursive] Error 1

Edit: Actually, it seems to be one speciic line causing this. Maybe its just a coding error? If I remove it it compiles successfully, but SDL segfaults when trying openglhq mode.

Any more specific advice?

Last edited by bkman on 2005-06-15, 15:42. Edited 1 time in total.

Reply 11 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie
ykhwong wrote:

bkman, you need to install sdl 1.3.x branch.
http://www.libsdl.org/cvs/SDL-1.3.tar.gz
or, cvs -d :pserver:guest@libsdl.org:/home/sdlweb/libsdl.org/cvs co -r branch_1_3_x SDL12

I followed the instruction in the readme and already checked it out from the CVS, so I don't know what the problem is. Have you been able to compile successfully in windows with Mingw?

Reply 12 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Ok...this is weird.

@bkman: yes, that is a bug in sdl cvs. There's one #endif too many, just comment it out 😀

Ok first...SDL will crash if you put an invalid SDL_VIDEODRIVER. Kinda weird, I thought you'd want somekind of fallback. Second, openglhq does not get compiled in, that's why the crash. Third, configure does not check for OpenGL in target mingw so -DENABLE_OPENGLHQ is never defined. Forcing OpenGL check obviously fails since it's tailored to linux includes. And fourth...is #include <termios.h> needed? Mingw does not have it 😀
I'll try manually editing the Makefiles...but I have little hope it'll work...

Reply 14 of 156, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

That explains why the stupid WHAT.EXE utility that Sierra used in all of it's anthology/collection releases doesn't work in XP or DOSBox, although DOSBox really ought to support it.

Aaaaanyways, I'm going to have to play with this 😀

Reply 15 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Ok...things don't look so grim anymore 😁

Seems Opengl is just assumed in windows: src/video/SDL_sysvideo.h

/* OpenGL is pretty much available on all Windows systems */

So I guess OpenGLhq can be assumed as well. I modified configure.in...

--- configure.in.old    2005-06-15 18:50:18.000000000 +0200
+++ configure.in 2005-06-15 17:01:14.000000000 +0200
@@ -1557,11 +1557,6 @@
CFLAGS="$CFLAGS -DENABLE_WINDIB"
VIDEO_SUBDIRS="$VIDEO_SUBDIRS windib"
VIDEO_DRIVERS="$VIDEO_DRIVERS windib/libvideo_windib.la"
+ # Enable OpenglHQ
+ CFLAGS="$CFLAGS -DENABLE_OPENGLHQ"
+ SYSTEM_LIBS="$SYSTEM_LIBS -lopengl32"
+ VIDEO_SUBDIRS="$VIDEO_SUBDIRS openglhq"
+ VIDEO_DRIVERS="$VIDEO_DRIVERS openglhq/libvideo_openglhq.la"
# See if we should enable the DirectX driver
if test x$use_directx = xyes; then
CFLAGS="$CFLAGS -DENABLE_DIRECTX"

Also...glColorTable() has to be treated as an extension since it is not present in opengl32.dll...after a while, the following dll seems to work 😀

Attachments

  • Filename
    SDL.zip
    File size
    132.95 KiB
    Downloads
    74 downloads
    File comment
    SDL 1.3.0 with OpenGLhq patch
    File license
    Fair use/fair dealing exception

Reply 17 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

I'm currently working on the next release, fixing a few bugs and such. The glColorTable problem will disappear and thanks for the configure update.

In what way does fullscreen not work? If you don't set SDL_OPENGLHQ_FULLRES, it will autodetect your desktop size and use that. Perhaps that's too much, or it has problems with multiple desktops (if applicable)?

Reply 18 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Well...it somewhat weird...my monitor will switch to 1280x1024 (I have 1280x960 as desktop resolution) but the console image is stretched even more (I can only see about 3/4 of the blue area). In prince however, top left corner of the game is centred on the screen and lower right corner is off the screen...

Reply 19 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Funny thing. My code qasks your true video driver for the maximum resolution, probably that's why it switches up. I have no other idea how to find the desktop resolution automatically. But why it would stretch and scale the actual game image wrong, I don't know. What happens if you set SDL_OPENGLHQ_FULLRES to some sensible value like "1280x960"?