VOGONS

Common searches


Reply 20 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

New version is online.

Changes:
- incorporated compiler fixes for Windows
- automatically reverts back to your native video driver if an app tries to use OpenGL (which means you can set openglhq as your default driver and your SDL-3D-games still work)
- fixed a small rendering error with partial updates and non-integral scaling factors
- added fixed scaling factors, see README
- fixed 8/16bpp surfaces
- improved docs

This seems to be quite final. What's left:

- video mode selection problems as seen above
- opengl library access
- ATI linux driver fix/workaround for exult/scummvm

Reply 21 of 156, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Moe, are your changes against the main 1.2.x CVS line, or the 1.3.x branch? I'm not even sure what's different between the two, but I was told by one of the devs that the 1.3.x branch isn't very active right now so I usually just compile the 1.2.x CVS.

Reply 23 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie

Thanks Moe! Now I can compile successfully with your new patch, but there are other problems...

1.) Fullscreen still doesn't work. It seems to just freeze after changing to the new video mode in my Win2k. Has to be killed.
2.) Graphical errors in ScummVM. Bits of the screen are missing, and only appear if screen changes in that area. Also, colours are wrong in samnmax since the last version of the patch.
3.) Setting windowres to scaling factor like 2 instead of resolution causes a crash.

4.) This is probably unrelated to openglhq, but does anyone know why my SDL build lags behind in all the sound by about a second? Also, why is it so big, weighing in at 400k?

Reply 24 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

HunterZ, I'd love to use the 1.2 branch as well, but Render Targets are a must, so I have no choice.

bkman wrote:

1.) Fullscreen still doesn't work. It seems to just freeze after changing to the new video mode in my Win2k. Has to be killed.

Did you try specifying SDL_OPENGLHQ_FULLRES, possibly with different bit depths?

bkman wrote:

2.) Graphical errors in ScummVM. Bits of the screen are missing, and only appear if screen changes in that area. Also, colours are wrong in samnmax since the last version of the patch.

Funny thing, ScummVM works very fine for me. About wrong colors, I might have messed up 16-bit modes, now that you mention it. Will investigate.

bkman wrote:

3.) Setting windowres to scaling factor like 2 instead of resolution causes a crash.

Uh, sorry, stupid "this last change can't possibly break anything" bug. Will fix 😉

bkman wrote:

4.) This is probably unrelated to openglhq, but does anyone know why my SDL build lags behind in all the sound by about a second? Also, why is it so big, weighing in at 400k?

You could try to copy over the audio subdir from SDL-1.2, perhaps it is a bug that has been fixed. It's so big because it probably still has debugging symbol information in it. Remove them with the "strip" command (for mingw only)

EDIT: Can someone provide a patched, working SDL.DLL here? I'm not sure if my cross-compilations would be binary compatible.

Reply 25 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Next update is available.

Changes:
- Fix 15/16-bit modes
- Fix partial update bug on windows (the scummvm issue)
- Fix scaling factors
- included a ready-to-use SDL.DLL
- ATI triple buffering problem won't occur anymore in most cases (setting fulldouble=true is the only way to trigger it now)

New problems:
- something with the mouse on windows seems to be amiss, can anyone confirm?
- linux/ATI display corruption got worse

Please help:
- tell me if / how well it works for nVidia hardware, I can only test ATI
- I haven't seen any fullscreen issues, neither windows nor linux; please show screenshots, detailed reports, something so I can find out what's wrong

Have Fun!

Reply 26 of 156, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie
`Moe` wrote:

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"?

Heh...I know what happens...I have monitor connected via BNC cable (no DDC support) and have a maximum 1280x1024 resolution set in the drivers. The funny thing about ati drivers is that they limit the resolution by themselves...the call to switch to higher res will succeed, but the drivers will actually switch to maximum allowed res. That's why the picture is so much bigger - sdlohq thinks it got 1600x1200 or whatever the maximum res reported by the drivers is...setting OPENGLHQ_FULLRES works.

I don't know what the best approach would be, but dosbox uses a call to GetSystemMetrics to determine desktop resolution - ofcourse this is win32 only...
I haven't done extensive testing but your dll seems to work for me.

Reply 27 of 156, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Stupid ATI drivers. They try to pull that crap with refresh rate too. I have to use ATI Tray Tools to override the ATI drivers to get higher and per-resolution refresh rates.

Reply 28 of 156, by CobZo

User metadata
Rank Newbie
Rank
Newbie

This SDL patch doesn't work for me. Dosbox crashes at startup if I set SDL_VIDEODRIVER to openglhq.

OpenGL information:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce FX 5900/AGP/SSE/3DNOW!
OpenGL version string: 2.0.0 NVIDIA 76.64

Backtrace:

cobzo@toosa ~ $ SDL_VIDEODRIVER=openglhq gdb dosbox
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/local/bin/dosbox
[Thread debugging using libthread_db enabled]
[New Thread -1489017136 (LWP 2294)]
[New Thread -1489392720 (LWP 2297)]
[New Thread -1497883728 (LWP 2300)]
CONFIG: Using default settings. Create a configfile to change them

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1489392720 (LWP 2297)]
0xa7f47682 in glIsList () from /usr/lib/opengl/nvidia/lib/libGL.so.1
(gdb) where
#0 0xa7f47682 in glIsList () from /usr/lib/opengl/nvidia/lib/libGL.so.1
#1 0xa7da5a7f in DeinitOpenGL () from /home/cobzo/SDL13/lib/libSDL-1.3.so.0
#2 0xa7da5e70 in RenderThread () from /home/cobzo/SDL13/lib/libSDL-1.3.so.0
#3 0xa7db040b in SDL_RunThread () from /home/cobzo/SDL13/lib/libSDL-1.3.so.0
#4 0xa7db070d in RunThread () from /home/cobzo/SDL13/lib/libSDL-1.3.so.0
#5 0x464783b0 in start_thread () from /lib/libpthread.so.0
#6 0x46211dfe in clone () from /lib/libc.so.6
(gdb)

Reply 30 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie

Thanks Moe, that last update fixed most of the bugs, but I still can't use fullscreen mode properly. It sometimes works in SCUMMVM (like when I set a sclaing factor of 2, or don't set the fullres) but it just locks dosbox. Also, sets a resolution that is way higher than my desktop res by default, and with a scaling factor in dosbox's case (which it shouldn't).

As for windows mouse problems... the cursor in scummvm seems slow, but maybe its just my PC.

Reply 31 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Well then, here's the next version. (the usual location)

Changes:
- added a patch that was proposed on the SDL mailing list to detect desktop resolution correctly (fix one fullscreen issue)
- check what video mode we actually got in case we're getting less than we ask for (fix another fullscreen issue)
- change cleanup code for nvidias linux driver
- add GLX_ATI_render_texture support - I finally found out how to use it, yay! Big performance boost for linux.
- modified SDL's X11 render target code so linux users no longer see graphical corruptions
- made the whole thing opengl-symbol-free, which means compiling against SDL should once again work without explicitly linking opengl
- fixed a bug with partial updates

I hope this is nearing a final version now... I'd love to just use it 😀

Reply 33 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie
`Moe` wrote:

I hope this is nearing a final version now... I'd love to just use it 😀

Its not there yet, unfortunately 😜

Both your SDL.dll and my own compiles segfault SDL when openglhq mode is enabled. 🙁

Reply 34 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

HunterZ, I use it on Linux/ATI, and test it every once in a while on Windows/ATI. I don't have access to capable enough nVidia hardware. A volunteer with both systems and a little C/gdb experience would be greatly appreciated.

bkman, shame on your PC 😉 Can you debug a little?
Are you using MinGW/Msys? Then please do these steps:

1) In the shell: gdb dosbox.exe
2) Inside gdb: r
3) After the crash, inside gdb: bt
copy the output of that last command, it should look similar to what CobZo posted.

Oh, and what hardware are you using?

Reply 35 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie

It segfaults within SDL which then deploys its parachute, so I don't know if it would tell you much in GDB. Dosbox doesn't really crash.

Btw, I'm running a Pentium 4 (Celeron) and a Radeon 9550 with new Catalyst drivers. In Windows 2000 SP4, I should add!

Last edited by bkman on 2005-06-19, 22:45. Edited 1 time in total.

Reply 36 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Oh, that parachute thing is perfectly OK. gdb still gives a meaningful stack trace, because it catches the segfault before SDL catches it. Since you're using roughly similar hardware to mine, I'll reboot and see if there's something amiss in real windows (in vmware, the dll worked just fine)

Reply 37 of 156, by bkman

User metadata
Rank Newbie
Rank
Newbie

Sorry it took so long, but I was using mostly precompiled stuff without debug symbols and had to recompile everything.

Starting program: c:\dev\test/dosbox.exe 

Program received signal SIGSEGV, Segmentation fault.
GUI_StartUp(Section*) (sec=0x2a674c8) at sdlmain.cpp:885
885 sdl.desktop.bpp=sdl.surface->format->BitsPerPixel;
Current language: auto; currently c++
(gdb) bt
#0 GUI_StartUp(Section*) (sec=0x2a674c8) at sdlmain.cpp:885
#1 0x00000280 in ?? ()
#2 0x004a6832 in Section::ExecuteInit(bool) (this=0x2a674c8, initall=true)
at c:/dev/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_list.h:130
#3 0x004a6884 in Config::Init() (this=0x22fde0)
at c:/dev/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_list.h:130
#4 0x00491e98 in SDL_main (argc=1, argv=0x22fe80) at sdlmain.cpp:1119
#5 0x004b6858 in console_main ()
#6 0x004b6c37 in WinMain@16 ()
#7 0x004b64aa in main ()

Reply 38 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Fine, thanks. I also went and used a sleepless night for some debugging... that's exactly what I saw, too. I already know what's wrong, I don't understand why, however - I moved some initialization stuff around, and the same code suddenly fails... well, watch this space for news.

UPDATE: I fixed the bug, but all of a sudden I see the fullscreen problem as well. Plus some crashes. Very weird, I don't get why glClear should segfault...

UPDATE 2: ...because some opengl drivers seem to work asynchronously. A few well-placed glFinish seem to have fixed everything. Let's hope your drivers agree. New release coming up.

Reply 39 of 156, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Here it is. Changes:
- fixes crash on windows/ATI
- fixes yet another fullscreen bug (hopefully the last one...)

Please tell me if it works. I'm quite confident by now 😉