VOGONS

Common searches


Reply 120 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Fixed that crash as well (it did affect dosbox sometimes). Unless anyone has any complaints, the current version is finished for now - I am satisfied, and there are no bugs I am aware of. Should someone build a DLL, I'll gladly distribute it 😉

Reply 121 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Here's a compiled dll. Not extensivly tested but should work 😉

Attachments

  • Filename
    SDL.zip
    File size
    153.85 KiB
    Downloads
    59 downloads
    File comment
    SDL OpenglHQ 10-11
    File license
    Fair use/fair dealing exception

Reply 122 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

I am experiencing some crashes with this version. Not sure what is going on (maybe ati driver updates or it was crashing before as well & I didn't notice it). My 16-09 build seems to work fine. Crash happens when dosbox switches modes...but not always, so it'll be harder to diagnose...

Reply 124 of 156, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

Not sure if it has been reported before, but Moe's latest SDL forces a full stretch in 640x350 games (Spellcasting, etc), even when aspect correction is disabled in the conf. It doesn't happen with Gulikoza's Direct3D renderer.

Reply 125 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

OpenGL-HQ indeed doesn't do any kind of aspect processing, i.e. it always scales the input image to the selected output resolution. It has no knowledge of DOSBox internal values. This is a known/intended limitation. An easy workaround is to use windowed mode, selecting a windowed resolution that matches whatever you want to see.

Reply 126 of 156, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Whoah. I just though of using OpenGLHQ SDL with Qemu....unfortunately Qemu doesn't like it. 🙁 Guess they don't use straight SDL. I've recently gotten alot of old Windows games working through Qemu (Switched alot of them from Vmware/VPC).

heh. Just think all those old Windows\DOS applications iusing openglhq.

How To Ask Questions The Smart Way
Make your games work offline

Reply 127 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Perhaps they do some undocumented stuff with frame updates. Many programs do, and they don't notice because the x11 and win32 drivers are quite forgiving. What happens?

Reply 128 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

I just read on the SDL mailing list that pbuffer support has been dropped from 1.3 in favor of the Framebuffer extension. Reading the description of this extension it seems it's better than render targets 😀. Any thoughts on this `Moe`?

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

Reply 129 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Yeah, I already saw that ATI supports the FB extension. Since it works for nnow, I will let it be, but there are a few things I'd like to improve, so when I lay my hands on OHQ next, I will probably switch to framebuffers. Maybe I don't even have to do anything, because it is all handled internally. Thanks for noticing me about SDL development.

Reply 130 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

I've taken the liberty to update the patch a little bit 😁

- switched to FBOs (and not using SDL for that)
- removed bunch of initialization stuff from RenderFrame() (unlike pBuffers, FBOs should preserve all OpenGL states when switching)
- make UpdateRects work
- make (texture) doublebuffering work with dosbox partial screen updates
- make opengl window always doublebuffered (any reason opengl should not be doublebuffered?)
- report hardware surface only when it is truly hardware (when pixel data range is in use)

This should make openglhq somewhat faster (especially with ati cards) and it should work with any SDL version...the old cvs version with pBuffer support is no longer needed. The UpdateRect assumes DOSBox order for changed rectangles (from top to bottom), this might have to be changed for other stuff.

Comments & bug reports are welcome 😀

Attachments

  • Filename
    sdl-openglhq.diff
    File size
    20.96 KiB
    Downloads
    75 downloads
    File license
    Fair use/fair dealing exception

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

Reply 131 of 156, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie

Would you upload your compiled SDL.DLL which includes your diff, also, gulikoza?
It seems that your patch can be used only after applying Moe's openglhq patch. The Moe's patch does not go with current sdl now because it has not been updated for a long time. I used to use nvidia card but now have ATI one installed in my laptop. just want to test with it to know how it gets more speed in my ati system...

Reply 132 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Well, I haven't tested my patch against newer SDL versions since I still use the old cvs. It's just the possibility that it might work, some parts of SDL-1.3.diff from Moe's patch probably have to be removed 😀

The problem is I don't know which version to use, 1.2 seems pretty much end of development. 1.3 however is probably less stable than it was before. There were a lot of changes, like replacing ddraw backend with direct3d, I don't know how well it works with dosbox.

Anyway, I'm attaching my current SDL.dll for testing.
I already figured out texture doublebuffering probably does not work 🙁
Does anybody know, when dosbox reports a changed line - does it update the whole line or just the pixels that have changed? If it's the latter, doublebuffering will never work or at least a lot slower.

Attachments

  • Filename
    SDL.ZIP
    File size
    140.31 KiB
    Downloads
    59 downloads
    File license
    Fair use/fair dealing exception

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

Reply 133 of 156, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

it updates the whole line, groups them together in groups of changed lines and lines it can skip, although with hardware surfaces this is slightly different since it uses a special scaler then that doesn't care for specific changed lines, just if the surface changed as a whole.

Reply 135 of 156, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

ah yeh it doesn't actually output an entire line, if you'd need something like that you'd probably have to keep some temporary buffer and do a blit from there to fill the buffer, i think dosbox uses that approach when doing double buffering with hardware surfaces.

Reply 136 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

OK, let's do it again 😀
This time I'm attaching full patch to SDL-1.2.11. It includes the previously mentioned changes with some differences:

- texture doublebuffering will obviously not work since dosbox does not update complete lines. Since supporting this would require having an extra surface and an extra blit, this would negate all the speed advantages of texture doublebuffering (if there are any at all). Texture doublebuffering can be selected by passing SDL_DOUBLEBUF in SDL_SetVideoMode() call if desired.

- opengl doublebuffering is not on by default, but requires setting SDL_OPENGLHQ_DOUBLEBUF environment variable. This has been tied to fulldouble option in dosbox patch. Opengl doublebuffering requires that pass 3 of the fragment shader runs at full res and that it updates the entire backbuffer (previously it only updated the changes). This is probably slower on some slower cards, but ogl doublebuffering might have other advantages...I don't know, left for the user to decide 😀

- pass SDL_ANYFORMAT flag in dosbox SDL_SetVideoMode call. This gets rid of ShadowSurface SDL creates in some cases. Possibly a speed advantage. SDL_HWPALETTE isn't needed (this will also force creation of shadow surface), 8-bit ogl output is supported on very few cards anyway.

The SDL patch has been updated to apply to SDL-1.2.11. One difference though is that since 1.2.11 uses a single Makefile for complete SDL, I haven't been able to hack it to create the required *.h files. After applying sdl patch, you need to run make in src/video/openglhq before running configure. You also need to run autogen before configure 😀

Attachments

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

Reply 137 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for your work. I have incorporated the essential parts into my code tree which already included some other improvements. I have, hovever, diverged from your code in many parts, so that it resembles more what I had before. Feel free to point me to any remaining improvements that can be done or that I missed.

You can find it on the usual web address.

Reply 139 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Hi moe,

let me address some notes you left in the code 😀

1. SDL_ohqthread.h:583 // |SDL_HWSURFACE left out -- why?

SDL docs state that SDL_HWSURFACE is invalid with SDL_OPENGL. Moreover, the flag is ignored if passed (SDL_Video.c:649).

2. ATi drivers still produce fuzzy picture when I'm in 16-bit mode. I have no idea why, I added a check in my version of DOSBox to print an error when bpp!=32. You have no idea how much time I spent figuring why my modifications to OHQ don't work before I noticed somebody set my desktop to 16-bit 😀

3. Using fulldouble=true doesn't work in your version. DOSBox only does UpdateRects on non-hardware surfaces, not a flip. This is ignored by OHQ when doublebuffering is active. Yes, I agree, my changes are probably somewhat dosbox biased 😀. Since dosbox does exactly one UpdateRects per frame I chose to go this way.

4. I get a crash when OHQ calls SDL_VideoQuit() (SDL_ohqthread.h:1010). This occurs with your version as well. I've debugged it a bit and it looks like some sort of threading issue. I didn't have these crashes before I had a dual-core cpu. I've disabled the call in my SDL build for the moment.

edit: I tried ykhwong's cvs and it doesn't crash. Even with the SDL.dll my build crashes...

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