OpenGL sprites?

Steve_Madsen · March 2, 2000, 2:01pm

Hi everyone,

In the testgl program distributed with SDL 1.1, the spinning cube is blitted
using SDL_GL_SwapBuffers( ). On my system running X Windows, this
function is invoked using X11_GL_SwapBuffers, which in
turn calls glXSwapBuffers, which seems to be part of Mesa3D.

What I would like to do, instead of treating the entire video surface
as an OpenGL buffer, is to have a small SDL surface (say 64x64 pixels).
On this surface, I could then place a textured, spinning OpenGL cube
against a black background; then by treating black as the key color
I could blit this spinning OpenGL cube onto my main SDL surface; the effect
would be a textured spinning cube moving around as any sprite would
do.

The example included in SDL 1.1 doesn’t address this. Does anyone
know of any sample code or tutorials that explain the proper method to
use to accomplish this?–
Steve Madsen
H2Eye Ltd.
24-28 Hatton Wall
London EC1N 8JH
United Kingdom (UK)
Tel: +44 (0) 207 404 9600
Fax: +44 (0) 207 404 9490
Email: @Steve_Madsen

Nicholas_Vining · March 2, 2000, 4:51pm

Hi everyone,

In the testgl program distributed with SDL 1.1, the spinning cube is
blitted
using SDL_GL_SwapBuffers( ). On my system running X Windows, this
function is invoked using X11_GL_SwapBuffers, which in
turn calls glXSwapBuffers, which seems to be part of Mesa3D.

What I would like to do, instead of treating the entire video surface
as an OpenGL buffer, is to have a small SDL surface (say 64x64 pixels).
On this surface, I could then place a textured, spinning OpenGL cube
against a black background; then by treating black as the key color
I could blit this spinning OpenGL cube onto my main SDL surface; the effect
would be a textured spinning cube moving around as any sprite would
do.

The example included in SDL 1.1 doesn’t address this. Does anyone
know of any sample code or tutorials that explain the proper method to
use to accomplish this?

What you would need to do is use Mesa 3D’s offscreen rendering context
generator. Basically, you’d end up bypassing all of SDL’s GL implementation
code. You’d set up an OSMesa context yourself, render to it, then dump data
from that into the SDL surface and then blit it. My advice to you is that
you should either pre-render the cube and then just blit it as a normal sort
of sprite, or to go 100% OpenGL. The two systems – SDL and OpenGL – do not
blend very well; if you try to make them blend, you will get into nasty
kludges and piles of smoking code. You could also just write your own
rotation and blitting engine.

OpenGL and 2D games don’t mix. This has been proven time and time again…
you might want to look at other solutions, like using a free software based
renderer with an SDL output target.

–
Steve Madsen

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: steve@h2eye.com (Steve Madsen)
To: sdl at lokigames.com
Date: Thursday, March 02, 2000 7:14 AM
Subject: [SDL] OpenGL sprites?

Daniel_Vogel · March 2, 2000, 6:16pm

hi`

Nicholas Vining wrote:

What you would need to do is use Mesa 3D’s offscreen rendering context
generator. Basically, you’d end up bypassing all of SDL’s GL implementation
code. You’d set up an OSMesa context yourself, render to it, then dump data
from that into the SDL surface and then blit it. My advice to you is that

Very ugly. a) it is slow and b) only works with Mesa. If you want to use
OpenGL and 2D blitting do it as I wrote in a mail before. Preblit stuff
to one surface and then blit the final image using OpenGL (using
glTexSubImage2D or glDrawImage (if you are on a SGI ;)))

you should either pre-render the cube and then just blit it as a normal sort
of sprite, or to go 100% OpenGL. The two systems – SDL and OpenGL – do not
blend very well; if you try to make them blend, you will get into nasty
kludges and piles of smoking code. You could also just write your own
rotation and blitting engine.

Nope. I guess I should write a little demo showing this stuff with SDL
and ClanLib. Well, I will do so once carneval is over.

OpenGL and 2D games don’t mix. This has been proven time and time again…

Wrong - all that is proven is that glDrawPixel seriously sucks on
consumer HW and drivers.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

Nicholas_Vining · March 2, 2000, 7:13pm

hi`

Nicholas Vining wrote:

What you would need to do is use Mesa 3D’s offscreen rendering context
generator. Basically, you’d end up bypassing all of SDL’s GL implementation
code. You’d set up an OSMesa context yourself, render to it, then dump data
from that into the SDL surface and then blit it. My advice to you is that

Very ugly. a) it is slow and b) only works with Mesa. If you want to use
OpenGL and 2D blitting do it as I wrote in a mail before. Preblit stuff
to one surface and then blit the final image using OpenGL (using
glTexSubImage2D or glDrawImage (if you are on a SGI ;)))

He said he wanted to use SDL_Surfaces, not glTexSubImage2D. My understanding
was that he wanted to use a SDL video mode, but then render GL primitives into
a buffer that he could then use with SDL_Blitwhatever.

And I wish I was working on an SGI.

OpenGL and 2D games don’t mix. This has been proven time and time again…

Wrong - all that is proven is that glDrawPixel seriously sucks on
consumer HW and drivers.

Possibly that should be “2D surfaces”. Let’s face it, though – OpenGL is a 3D
API. Note the “3D”. Anytime I want to use 3D primitives in a 2D game, IMHO I
am better off (as far as speed and anti-kludginess are concerned) to simply
sit down for five hours in front of NASM and bash myself out some simple matrix
rotation/translation/perspective correction routines and triangle blitters.
Faster, better, nicer, less kludgey.

Apparantely Sam has a 3D graphics library for SDL that he built and never
released.

Daniel Vogel My opinions may have changed,

Nich

slouken · March 2, 2000, 8:58pm

Apparantely Sam has a 3D graphics library for SDL that he built and never
released.

What?
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Nicholas_Vining · March 2, 2000, 8:58pm

Apparantely Sam has a 3D graphics library for SDL that he built and never
released.

What?

It’s somewhere in my mail archives. You said that you had written a 3D
library for SDL with gouraud shaded polygons and Z buffering that you were
going to release sometime soon. That was about a month ago.

-Sam Lantinga (slouken at devolution.com)

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: slouken@devolution.com (Sam Lantinga)
To: sdl at lokigames.com
Date: Thursday, March 02, 2000 1:15 PM
Subject: Re: [SDL] OpenGL sprites?

slouken · March 2, 2000, 9:28pm

Apparantely Sam has a 3D graphics library for SDL that he built and never
released.

What?

It’s somewhere in my mail archives. You said that you had written a 3D
library for SDL with gouraud shaded polygons and Z buffering that you were
going to release sometime soon. That was about a month ago.

Nope, not me.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> -----Original Message-----

From: Sam Lantinga
To: sdl at lokigames.com
Date: Thursday, March 02, 2000 1:15 PM
Subject: Re: [SDL] OpenGL sprites?

–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Nicholas_Vining · March 2, 2000, 10:16pm

Apparantely Sam has a 3D graphics library for SDL that he built and
never

released.

What?

It’s somewhere in my mail archives. You said that you had written a 3D
library for SDL with gouraud shaded polygons and Z buffering that you
were

going to release sometime soon. That was about a month ago.

Nope, not me.

I apologize; it was Rafael.

Apparantely Rafael as a 3D graphics library for SDL that he built and never
released.

-Sam Lantinga (slouken at devolution.com)

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: slouken@devolution.com (Sam Lantinga)
To: sdl at lokigames.com
Date: Thursday, March 02, 2000 1:44 PM
Subject: Re: [SDL] OpenGL sprites?

-----Original Message-----
From: Sam Lantinga
To: sdl at lokigames.com
Date: Thursday, March 02, 2000 1:15 PM
Subject: Re: [SDL] OpenGL sprites?

Andreas_Umbach · March 3, 2000, 12:04am

vining at pacificcoast.net schrieb am 02 Mar 2000:

Possibly that should be “2D surfaces”. Let’s face it, though – OpenGL is a 3D
API. Note the “3D”. Anytime I want to use 3D primitives in a 2D game, IMHO I
am better off (as far as speed and anti-kludginess are concerned) to simply
sit down for five hours in front of NASM and bash myself out some simple matrix
rotation/translation/perspective correction routines and triangle blitters.
Faster, better, nicer, less kludgey.

Anyone interested in this should check out http://www.tutok.sk/fastgl/
No need to reinvent the wheel. Just help to integrate this baby into
SDL.

Andreas–
Probably one of the smallest 3D-Games in the world: http://www.gltron.org
More than 50’000 Downloads of the latest version (0.53)

Daniel_Vogel · March 3, 2000, 3:08am

vining at pacificcoast.net wrote:

He said he wanted to use SDL_Surfaces, not glTexSubImage2D. My understanding
was that he wanted to use a SDL video mode, but then render GL primitives into
a buffer that he could then use with SDL_Blitwhatever.

glReadPixels… it is as slow as that OSMesa stuff.

And I wish I was working on an SGI.

bzflag runs very nice on them ;—)

Wrong - all that is proven is that glDrawPixel seriously sucks on
consumer HW and drivers.

Possibly that should be “2D surfaces”. Let’s face it, though – OpenGL is a 3D
API. Note the “3D”. Anytime I want to use 3D primitives in a 2D game, IMHO I

Did you ever have a look at how much 2D is in the OpenGL API?

am better off (as far as speed and anti-kludginess are concerned) to simply
sit down for five hours in front of NASM and bash myself out some simple matrix
rotation/translation/perspective correction routines and triangle blitters.

I doubt that.

Faster, better, nicer, less kludgey.

Okay, I should simply sit down and write some code which I will do next
week to demonstrate what I think (oh, oh, another promise/ deadline ;)).
Should work as a nice tutorial/ demonstration for both SDL and ClanLib.
2D done right can be quite cool with OpenGL.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

(sorry it is carnevel season and I am rather drunk)

slouken · March 3, 2000, 3:51am

Okay, I should simply sit down and write some code which I will do next
week to demonstrate what I think (oh, oh, another promise/ deadline ;)).
Should work as a nice tutorial/ demonstration for both SDL and ClanLib.
2D done right can be quite cool with OpenGL.

Sounds great!

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Nicholas_Vining · March 3, 2000, 3:44am

vining at pacificcoast.net wrote:

He said he wanted to use SDL_Surfaces, not glTexSubImage2D. My
understanding

was that he wanted to use a SDL video mode, but then render GL primitives
into

a buffer that he could then use with SDL_Blitwhatever.

glReadPixels… it is as slow as that OSMesa stuff.

I know. I AM SIMPLY QUOTING WHAT HE SAID HE WANTED! (Sorry if I’m losing my
patience)

My opinions remain:

OpenGL for anything 2D ends up being a kludge. It can WORK, but that
doesn’t mean it’s a good idea. I can store my map information as a series of
natural logarithms if I wanted to, but why would I when there are better,
nicer, simpler methods of doing it?

I would LIKE To run a SGI server.

I’m sure you can do it, but that isn’t really what it was designed for.
There ARE assorted pieces of code in OpenGL that when used together will
serve as a 2D API. It still ends up going through a variety of unoptimized
rendering pipelines and assorted pieces of hardware which it wasn’t supposed
to, unless you’re a very clever coder. (Nate Miller’s glTexFont library can
spike my framerate down enough that under Mesa with a 3Dfx driver it’ll drop
from 60 to 30 FPS. Note that this isn’t that the library is THAT slow, but
simply that I can’t hit that display target… Mesa’s flipping architecture
is interesting)

It may even LOOK better if you pre-render your 3D objects in
POVray/3DSmax and preserve the alpha values… for one thing, you can have
nice free anti-aliasing with a bit of work, a .PNG file, and a kludge… or
you can just render twice, once against a white background, once against a
black background, and solve a bit of linear algebra to generate data for an
alpha channel that the program might not even save. I’m just grepping for
the formula: Ah.

given Pw is pixel value on white, Pb is pixel value on black, then
Pw = 1*(1-a) + PaPb = 0(1-a) + P*a
where a is alpha (0=transparent to 1=opaque), P is true pixel value, so
a = 1 - ( Pw - Pb )P = Pb / a
Note that you must correct for a<=0; in that case you assign whatever
value is convenient for P, instead of dividing by zero or dicking around
with negative numbers. Also note that if a isn’t in 0…1, clip it before
storing it.

I was in a contest with four other coders to come up with that formula. It
took me 4 minutes. The winner: 45 seconds. Aie! Anyways, to recap after all
that, if you just use rendered 2D sprites you get WAY better quality –
smoother, softer, silkier. You can EVEN do some work with lighting the
sprites real time. (I may produce a demo of that too, since that’s a VERY
cool trick, and the math is hard core so I like it. Let’s just say “2D bump
rules”)

Okay, I should simply sit down and write some code which I will do next
week to demonstrate what I think (oh, oh, another promise/ deadline ;)).
Should work as a nice tutorial/ demonstration for both SDL and ClanLib.
2D done right can be quite cool with OpenGL.

And I can produce in a fraction of that time a 30 frame spinning cube
animation which anti-aliases nicely and fulfills all the requirements with a
fraction of the kludginess.

Sorry for turning this into a flamewar, but I strongly feel that, with a few
exceptions (there are some interesting ramifications if you want to do
something like Final Fantasy Tactics), OpenGL should be used for 100% 3D
gaming only, and SDL for 2D applications, and that what’s more, “neer the
twain shall meet”.

Daniel Vogel My opinions may have changed,

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: 666@grafzahl.de (Daniel Vogel)
To: sdl at lokigames.com
Date: Thursday, March 02, 2000 7:28 PM
Subject: Re: [SDL] OpenGL sprites?

Amedeo_Storni · March 3, 2000, 11:27am

“Andreas Umbach” wrote in message
news:20000303010434.A3297 at tulpe.ards.dataway.ch…

vining at pacificcoast.net schrieb am 02 Mar 2000:

Possibly that should be “2D surfaces”. Let’s face it, though – OpenGL
is a _3D

API_. Note the “3D”. Anytime I want to use 3D primitives in a 2D game,
IMHO I

am better off (as far as speed and anti-kludginess are concerned) to
simply

sit down for five hours in front of NASM and bash myself out some simple
matrix

rotation/translation/perspective correction routines and triangle
blitters.

Faster, better, nicer, less kludgey.

Anyone interested in this should check out http://www.tutok.sk/fastgl/
No need to reinvent the wheel. Just help to integrate this baby into
SDL.

No. That is strict GPL, so it cannot be integrated with SDL.

Regards
Amedeo

Nicholas_Vining · March 3, 2000, 4:32pm

Newsgroups: loki.open-source.sdl

IMHO I

am better off (as far as speed and anti-kludginess are concerned) to
simply

sit down for five hours in front of NASM and bash myself out some
simple
matrix

rotation/translation/perspective correction routines and triangle
blitters.

Faster, better, nicer, less kludgey.

Anyone interested in this should check out http://www.tutok.sk/fastgl/
No need to reinvent the wheel. Just help to integrate this baby into
SDL.

No. That is strict GPL, so it cannot be integrated with SDL.

Depends where you merge them. You wouldn’t want to link it into SDL, as SDL
is designed to be a low level system. You COULD probably with a bit of
stylish hacking get FastGL to output natively to some sort of “pixel
buffer”… in other words, we just have to hack it to dump right into
the default video surface’s pixel buffer.

I’d prefer to write my own. Less of a kludge, and besides, from what I can
tell, fastgl seems to be all about GUI design… still cool, though.

Regards
Amedeo

Cheers,

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: astorni@softhome.net (Amedeo Storni)
To: sdl at lokigames.com
Date: Friday, March 03, 2000 3:58 AM
Subject: [SDL] Re: Re: OpenGL sprites?

Marian_Krivos · March 5, 2000, 2:09pm

Anyone interested in this should check out http://www.tutok.sk/fastgl/
No need to reinvent the wheel. Just help to integrate this baby into
SDL.

No. That is strict GPL, so it cannot be integrated with SDL.

Regards
Amedeo

NO! IT IS LGPL!!! (see license.txt in the OpenGUI root directory)