ANNC: glSDL 0.5

David_Olofson · July 4, 2003, 12:44pm

Changes in glSDL-0.5:
* glSDL uses inline from SDL’s begin_code.h.
* Fixed void pointer arithmetics.
* SDL_SetClipRect(…, NULL) now works again.
* Added Microsoft Visual C++ project files by
Florian Hufsky.

glSDL 0.5 is best used with SDL 1.2.5 or later.

Download:
http://olofson.net/mixed.html

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

Santi_Ontanon · July 4, 2003, 6:15pm

Hi David,

I’m very interested in glSDL I’ve downloaded it one hour ago, compiled
the examples, and noticed the REALLY SMOOTH scroll!!
Then, I followed the instructions for VisualC and tried to compile one
of my games using glSDL, result: all what I get is a BLACK screen.
After creating a 512x384 window, ALL the computer screen turns to black
(the computer doesn’t freeze, the app is running, but just not
displaying anything!). The same happens if I start the app in fullscreen.

I’m using VC++6.0 under Windows ME, in a Laptop with an ATI RADEON
MOBILITY 32MB (witch fully supports HW accelerated OpenGL)

any clues?

thanks in advance!

David_Olofson · July 4, 2003, 7:09pm

[…black screen…]

any clues?

Not really, but this is not unheard of… It seems that something goes
wrong when using glSDL 0.5 in fullscreen mode on Win32. No idea what
happens.

Try windowed mode for now. I don’t know what’s wrong with fullscreen
mode, and as I don’t have a Win32 devsystem at hand, I can’t
investigate it much further right now.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 05 July 2003 03.14, Santi Onta??n wrote:

Florian_Hufsky · July 5, 2003, 2:08am

did you take a look at stderr.txt and stdout.txt?
maybe it’s the resolution. try something more common, like 640x480 or
320x240.> ----- Original Message -----

From: santi.ontanon@terra.es (Santi Ontanon)
To:
Sent: Saturday, July 05, 2003 3:14 AM
Subject: Re: [SDL] ANNC: glSDL 0.5

Hi David,

I’m very interested in glSDL I’ve downloaded it one hour ago, compiled
the examples, and noticed the REALLY SMOOTH scroll!!
Then, I followed the instructions for VisualC and tried to compile one
of my games using glSDL, result: all what I get is a BLACK screen.
After creating a 512x384 window, ALL the computer screen turns to black
(the computer doesn’t freeze, the app is running, but just not
displaying anything!). The same happens if I start the app in fullscreen.

I’m using VC++6.0 under Windows ME, in a Laptop with an ATI RADEON
MOBILITY 32MB (witch fully supports HW accelerated OpenGL)

any clues?

thanks in advance!

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Dinand_Vanvelzen · July 5, 2003, 5:21am

" (witch fully supports HW accelerated OpenGL)"
The mobility series don’t always support HW accel for everything.

"the computer screen turns to black"
This is most likely because OpenGL has encountered an error for which it
silently sets
an error flag. Use glGetError() between function calls so you can see where
the error happens.
i suggest reading this page:
http://www.3dlabs.com/support/developer/GLmanpages/glgeterror.htm--------------------------------
| Dinand Vanvelzen, |
| Programmer, |

Software Engineering student

David_Olofson · July 5, 2003, 7:44am

SDL should just pick the next higher resolution and center the display
on the resulting screen.

Besides, if the application doesn’t terminate, that means someone
somewhere is ignoring error returns, or nothing anywhere detects that
there is a problem.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 05 July 2003 11.10, Florian Hufsky wrote:

did you take a look at stderr.txt and stdout.txt?
maybe it’s the resolution. try something more common, like 640x480
or 320x240.

David_Olofson · July 5, 2003, 7:56am

" (witch fully supports HW accelerated OpenGL)"
The mobility series don’t always support HW accel for everything.

Well, glSDL does rely on h/w accelerated OpenGL to provide any form
of h/w acceleration, of course. However, it only uses “plain” blits
and alpha blending, so I don’t think there should be a problem on any
remotely usable OpenGL implementation. Even a full s/w implementation
should work, although performance would be, at best, laughable.

"the computer screen turns to black"
This is most likely because OpenGL has encountered an error for
which it silently sets
an error flag. Use glGetError() between function calls so you can
see where the error happens.
i suggest reading this page:
http://www.3dlabs.com/support/developer/GLmanpages/glgeterror.htm

There are some DBGx defines in glSDL.c that causes GL errors to be
printed in some places, but other than that, GL error checking is
virtuall nonexistent.

It would probably be a good idea to be rather paranoid when setting
the video mode and when uploading textures and maybe some other
things. TODO for 0.6.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 05 July 2003 14.20, Dinand Vanvelzen wrote:

Santi_Ontanon · July 7, 2003, 12:54am

Thanks for all you suggestions.
However, my problem is not that glSDL doesn’t work in my computer. It
DOES work (at least with the examples provided), it only doesn’t work
wih one of my games.
I’ve some questions:

When running the examples, a “stderr.txt” file is generated with all
the messages send to stderr, but this file is not generated when running
my game. Is there any #define that I should turn on for getting the
stderr file? or it’s just that the examples output strings to stderr and
not glSDL?
Which are the valid operations with surfaces when using glSDL? I think
that my problem is that I perform pixel-level access to the screen surface.

I think that glSDL is a great project, and will avoid us from having to
implement the typical OpenGL based 2D tile engines using surfaces as
textures, and use standard SDL calls!!

cheers

santi

Florian_Hufsky · July 7, 2003, 4:11am

i think you cannot pixel acess the screen memory with standard sdl calls.
there should be opengl specific calls, but for performance reasons i
wouldn’t use them!> ----- Original Message -----

From: santi.ontanon@terra.es (Santi Ontanon)
To:
Sent: Monday, July 07, 2003 9:53 AM
Subject: Re: [SDL] ANNC: glSDL 0.5

Thanks for all you suggestions.
However, my problem is not that glSDL doesn’t work in my computer. It
DOES work (at least with the examples provided), it only doesn’t work
wih one of my games.
I’ve some questions:

When running the examples, a “stderr.txt” file is generated with all
the messages send to stderr, but this file is not generated when running
my game. Is there any #define that I should turn on for getting the
stderr file? or it’s just that the examples output strings to stderr and
not glSDL?

Which are the valid operations with surfaces when using glSDL? I think
that my problem is that I perform pixel-level access to the screen
surface.

I think that glSDL is a great project, and will avoid us from having to
implement the typical OpenGL based 2D tile engines using surfaces as
textures, and use standard SDL calls!!

cheers

santi

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

David_Olofson · July 7, 2003, 5:47am

Thanks for all you suggestions.
However, my problem is not that glSDL doesn’t work in my computer.
It DOES work (at least with the examples provided), it only doesn’t
work wih one of my games.
I’ve some questions:

When running the examples, a “stderr.txt” file is generated with
all the messages send to stderr, but this file is not generated
when running my game. Is there any #define that I should turn on
for getting the stderr file? or it’s just that the examples output
strings to stderr and not glSDL?

It’s just SDL’s normal stderr handling. glSDL outputs some debug stuff
when it gets to work - which means that it doesn’t get very far at
all with your game…

Which are the valid operations with surfaces when using glSDL?

Anything basicall - although if you don’t SDL_DisplayFormat*() them,
glSDL will have to convert and upload every time the surface has been
changed.

Actually, I think the wrapper version is a bit broken in that regard.
It doesn’t care much about SDL_HWSURFACE, which means it can’t always
tell when surfaces have to be converted and uploaded before every
blit - which is the case with software surfaces! (They don’t require
locking, and without locking, there’s no way glSDL can tell when a
surface has been manipulated.)

I
think that my problem is that I perform pixel-level access to the
screen surface.

Not 100% sure it works with the wrapper versions, but tre correct
approach is to lock and unlock the surfaces as if they were hardware
surfaces. (They should actually be hardware surfaces but that doesn’t
work with the wrapper, as the 2D stuff is s/w only when running
OpenGL.)

I think that glSDL is a great project, and will avoid us from
having to implement the typical OpenGL based 2D tile engines using
surfaces as textures, and use standard SDL calls!!

That’s the idea. Actually, you don’t even have to recompile to use the
backend version; it’s just another video driver. There are some
remaining issues, but it’s more or less working now.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 07 July 2003 09.53, Santi Onta??n wrote:

David_Olofson · July 7, 2003, 5:53am

The screen!? Sorry, my caffeine/blood ratio is bad, so so I missed
that.

Right; accessing the screen doesn’t work at all with glSDL/wrapper.
There is some stuff in place, but most of it is broken. It’s enough
to get screenshots to work, but that’s about it.

Anyway, it does work in the (unreleased) backend version, but as
expected, it’s insanely ineffective. The only way to do it
"correctly" with the current SDL API is to copy the whole screen into
a shadow surface when the screen is locked, and blit that back to the
screen when it’s unlocked. Even if you only tweak one pixel… heh

Don’t do that with glSDL. Render into other surfaces (with alpha if
you need), and blit those to the screen instead. Procedural textures,
that is.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 07 July 2003 13.13, Florian Hufsky wrote:

i think you cannot pixel acess the screen memory with standard sdl
calls. there should be opengl specific calls, but for performance
reasons i wouldn’t use them!