[SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Here you can discuss the development of patches.

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2006-11-21 @ 15:49

Thanks for the report. I have a faint idea how to fix 16-bit rendering. Could you try using GL_RGBA8 as internalformat for all textures? It should be used everywhere except in RenderFrame's TexSubImage2D call. I can't check since the Linux ATI driver doesn't support accelerated OpenGL at all for 16bit.

My code is tested against DosBox, QEmu and Scummvm. This is the absolute minimum I require, so I don't accept pure DosBox-bias ;) There must be a different way to achieve flipping, probably by changing DOSBox (since we already provide a patch, it could be added there).

The crash could be related to SDL_VideoQuit being called twice. That's intentional and inevitable. Be sure to re-patch your SDL tree, I have added one line in src/events/SDL_events.c to fix a crash due to this behaviour. Previous versions incorporated a similar modification, it seems to have been lost during your SDL-1.2 port.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-11-21 @ 17:30

Yes it does fix the crash...must have missed that line - twice :pppt:

16-bit mode also seems to work...nice work :)

As for the UpdateRects issue...I don't know, applications assume calling UpdateRects will change the screen, without any additional flips. Completely ignoring updates seems wrong. But with OHQ, updates are expensive so any application calling UpdateRect too often will suffer...
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2006-11-22 @ 12:49

Nope, calling UpdateRects is not terribly expensive, since my code simply skips updates if a frame is already being rendered. This is a kind of built-in frameskip, only that it doesn't really skip the update, it collects all UpdateRects until there is time to render another frame. The postponed updates are rendered at the next possibility. You disabled that code in your variant ;)

By the way, there is a new version up, including the latest suggestions discussed here and some significant simplification of the render code (without sacrificing the above mentioned functionality).
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-11-22 @ 13:11

But UpdateRects is skipped if doublebuffering is active!? When are the updates rendered then?
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-11-22 @ 13:53

Also...I was trying to differentiate the texture doublebuffering and opengl doublebuffering. I see no relation between the two, that's why I split the initialization (texture doublebuffering being activated by passing SDL_DOUBLEBUFFER flag and opengl by setting the env. variable - this way the application requesting doublebuffer surface will get one, but ogl doublebuffering can be enabled by the user independently). I'm not sure your patch completely honors that (setting flags &= ~(SDL_DOUBLEBUF) according to the environment variable and then returning this to the application as the surface flags).
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2006-11-22 @ 14:01

If double buffering is active, FlipHWSurface initiates rendering.

I agree that surface flags could be handled more intelligently. The current behaviour is probably a DOSBox-specific relic which should be replaced by a logical and generic behaviour. I'm not terribly concerned, however, as it works fine everywhere, as far as I can see.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-11-22 @ 14:13

I don't know, but it seems wrong to me. DOSBox will create a shadow surface if it gets SDL_DOUBLEBUF returned. This shouldn't be necessary as OGL doublebuffering isn't visible to the application. Moreover it requires a modification to dosbox, which shouldn't be required, if these flags would be carefully thought imho :happy:
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2006-11-22 @ 16:21

Well, there is the documented SDL API. I have read into it again, and it actually differs from our expectations. I think that making OHQ truly behave according to the documented API behaviour could almost fit your desire. I will poke at some bits to improve the API conformance, then I'll see what's possible.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2006-12-15 @ 04:20

Well, here it is. Or rather, see the usual download location.

This release may break things. I'd be happy to hear a "works here" from Windows and MacOS X users. And a windows DLL would be nice, too ;)

OSX support might be broken unless you recompile dosbox against the patched SDL. Or it might not. I'm not sure.

Noteworthy news:

- Better API comaptibility including the above suggestions
- MacOS X should work correctly now
- a full-screen mouse motion bug found and fixed

Note that the new API means that due to a DOSBox bug, fullscreen operation with fulldouble=true is not possible. fulldouble=false works fine, and check the README regarding double-buffering in general.

Several new screenshots have been added to show off compatibility with various emulators and games.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-12-26 @ 12:15

This version does not work for me. Compiled with SDL-1.2.11 (freshly patched):
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
0x681317a5 in SDL_WM_SetIcon (icon=0x258abf8, mask=0x0)
    at ./src/video/SDL_video.c:1797
1797            if ( icon && video->SetIcon ) {
(gdb) p video
$1 = (SDL_VideoDevice *) 0x0


Also, I don't really quite understand the logic behind OHQ_UpdateRects. I see OHQ now uses only one texture in all cases, I don't see the need to expose SDL_DOUBLEBUF to the application. Application surface is the texture, not the underlying OpenGL surface, and it is now single buffered in all cases....
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-12-26 @ 17:38

Found the problem. SDL patch should also patch SDL_config.h.in or SDL_VIDEO_DRIVER_OPENGLHQ does not get defined.
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


This was already patched in the previous version :happyhappy:
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2006-12-27 @ 03:02

On the contrary: due to the way UpdateRects is synchronized with the render thread, the surface is always double buffered, even with a single framebuffer. The SDL_DOUBLEBUF flag is only returned if the application requests it, just to be nice and to appear closer to the real thing. Actual output double buffering is controlled by the app and optionally overriden by environment variables, just like you suggested. There are some fine details in Flip and UpdateRects derived from checking the new version against a dozen SDL apps, although only DOSBox actually breaks under certain circumstances (which is a small, but significant dosbox bug as I already pointed out elsewhere).
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-12-27 @ 09:40

which is a small, but significant dosbox bug

I'm sorry, but I still have to disagree with you on that :happy:
Dosbox fulldouble is easily fixable (in RenderFrame()):
Code: Select all
   // When OpenGL is doublebuffed, update entire display
   if (this->hidden->flags&SDL_DOUBLEBUF) {
       this->hidden->real_video->glViewport(0,0,tw,th);
       this->hidden->real_video->glCallList(this->hidden->displaylist);
       this->hidden->real_video->GL_SwapBuffers(this->hidden->real_video);
   } else {
       this->hidden->real_video->glViewport(x,y,cw,ch);
       ...


Unless the application updates entire display every frame, I don't see how current code can work...unless of course it knows it has doublebuffered surface and updates entire display every frame :happy:. But it's faster this way, since texture uploads (the slowest part) and the shaders run only on the changed part, changing the viewport and drawing entire screen should have negligible slowdown (infact none, providing current code does not work :happy:)
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby gulikoza » 2006-12-27 @ 11:57

There's another problem I've noticed with fullscreen switch & doublebuffering (with or without my proposed patch, affects older versions as well). If a display change occurs while in fullscreen (loading dosbox, switching to fullscreen and starting a game), switching back to window mode does not work, the window will be empty or severely corrupted. I've debugged it a bit, I can't find anything strange. Ever weirder, without doublebuffering everything works fine...

edit: nevermind, driver problems...seems to be fixed by setting most basic setting AA & AF off, vsync off...
Last edited by gulikoza on 2006-12-27 @ 23:46, edited 1 time in total.
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2006-12-27 @ 12:24

Use an unmodified OHQ version, and a plain CVS dosbox version for a start. The dosbox bug is that with fulldouble=true, dosbox will render into a separate blit surface, but never blits it to the real surface later on. This doesn't even reach OHQ code (and is different from my personal opinion that DOSBox should call UpdateRects, which you refer to), it is simply an unhandled case in DOSBox's logic.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby wahoyaho » 2007-1-14 @ 19:53

moe, how come you don't build the sdl.dll anymore :x i dunno how to build the dll from the source
wahoyaho
Newbie
 
Posts: 1
Joined: 2007-1-14 @ 19:33

Re: [SDL patch version] Hq2x / Hardware OpenGL-HQ scaling

Postby `Moe` » 2007-1-15 @ 15:11

I don't build it either, they were contributed by others.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 3 guests