VOGONS

Common searches


Reply 140 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 141 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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

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

http://www.si-gamer.net/gulikoza

Reply 142 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 144 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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

http://www.si-gamer.net/gulikoza

Reply 145 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 146 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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 😀

http://www.si-gamer.net/gulikoza

Reply 147 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 148 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 149 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

This version does not work for me. Compiled with SDL-1.2.11 (freshly patched):

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

http://www.si-gamer.net/gulikoza

Reply 150 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Found the problem. SDL patch should also patch SDL_config.h.in or SDL_VIDEO_DRIVER_OPENGLHQ does not get defined.

--- 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 😁

http://www.si-gamer.net/gulikoza

Reply 151 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 152 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

which is a small, but significant dosbox bug

I'm sorry, but I still have to disagree with you on that 😀
Dosbox fulldouble is easily fixable (in RenderFrame()):

	// 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 😀. 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 😀)

http://www.si-gamer.net/gulikoza

Reply 153 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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.

http://www.si-gamer.net/gulikoza

Reply 154 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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.