glSDL status

David_Olofson · February 9, 2003, 9:20am

Mentioned a fix for the next release in another post: That
SDL_surface::unused1 field is initialized to 0 in SDL 1.2.5, to avoid
trouble when you create surfaces with code not compiled with glSDL.
However, it turns out that I was stoopid and used 0xffffffff instead
of 0 to mean “no OpenGL texture for this surface”…

There’s new code for screen->surface and screen->screen bliting in the
new glSDL as well, but IIRC, it doesn’t work properly yet. Doesn’t
seem like anyone is missing it very much, since those operations are
dog slow on most h/w surface displays anyway, but I want 100% correct
emulation of the SDL API.

Actually, this stuff not working is the reason why Kobo Deluxe can’t
take screenshots in OpenGL mode. Screenshots are probably the main
reason to have it, no matter how slow it is. (As long as it doesn’t
impact normal rendering - and it doesn’t.)

Anyway, I still need a better texture space suballocator. The current
one doesn’t tile two ways, so you can’t surfaces that are both
wider and taller than the maximum texture size of your accelerator.
If you have a reasonably modern card, this isn’t much of an issue, as
these can generally handle 2048x2048, but if you have some old card
with a 256x256 limit, you’re in trouble…

Another limitation is that it can only tile a surface over one or more
textures; not the other way around. Surfaces own entire textures,
rather than lists of areas inside textures, which means there can
never be pixels form different surfaces in the same texture. This may
be inefficient in some cases, though I’m not sure it matters if
tiling is made more intelligent. (By splitting surfaces recursively
in a few levels, one could have near 100% texture space utilization
in every texture, I think. Currently, all tiles of one surface are of
the same size.)

Didn’t someone around here have some tiling code BTW…?

//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://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —

Calvin_Spealman · February 9, 2003, 12:02pm

David Olofson wrote:

Didn’t someone around here have some tiling code BTW…?

I don’t know what you need exactly but I’ve written some tiling code
recently, although I’d have to scrounge around for it because that
codebase was wipped when I restarted the project to clean up the design
a bit. It was a surface->surface tiled blit. I don’t know if it would
help, and I hope I don’t sound like an idiot if I’m wrong I’ll whip
it back together if it would be useful.

David_Olofson · February 9, 2003, 2:50pm

Well, I need surface->texture, but the interesting part is really the
"2D space allocation" algorithm. (Basically like your average
malloc()/free() memory manager, but 2D instead of 1D.) I don’t even
need code, really; if you have a nice algo, it might save me some
thinkin’ time.

//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://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Sunday 09 February 2003 20.59, Calvin Spealman wrote:

David Olofson wrote:

Didn’t someone around here have some tiling code BTW…?

I don’t know what you need exactly but I’ve written some tiling
code recently, although I’d have to scrounge around for it because
that codebase was wipped when I restarted the project to clean up
the design a bit. It was a surface->surface tiled blit. I don’t
know if it would help, and I hope I don’t sound like an idiot if
I’m wrong I’ll whip it back together if it would be useful.

Calvin_Spealman · February 9, 2003, 3:06pm

David Olofson wrote:

Well, I need surface->texture, but the interesting part is really the
"2D space allocation" algorithm. (Basically like your average
malloc()/free() memory manager, but 2D instead of 1D.) I don’t even
need code, really; if you have a nice algo, it might save me some
thinkin’ time.

Well, I’m trying to figure out just what you need so I can adapt my
algo. I dont know enough to know how this works exactly.

If I understand correctly, you need to take a surface and a tile it into
any texture, yes?

Surface:----

*

Texture:

|* * * * |

* * * *

Am I even close? I really hope I’m not wasting your time.

David_Olofson · February 9, 2003, 3:50pm

David Olofson wrote:

Well, I need surface->texture, but the interesting part is really
the “2D space allocation” algorithm. (Basically like your average
malloc()/free() memory manager, but 2D instead of 1D.) I don’t
even need code, really; if you have a nice algo, it might save me
some thinkin’ time.

Well, I’m trying to figure out just what you need so I can adapt my
algo. I dont know enough to know how this works exactly.

If I understand correctly, you need to take a surface and a tile it
into any texture, yes?

Surface:

*

Texture:

|* * * * |

* * * *

Am I even close?

Yeah, I think so… There are two problems glSDL has to deal with,
namely:

* OpenGL textures have to be square, and

* OpenGL textures have limited size.

That is, if a texture is very tall or very wide (like an SFont - a
font for a high resolution may not even fit in a 2048x2048 texture
w/o tiling!), it has to be chopped up in suitably sized pieces, so it
will fit in one or more OpenGL textures.

Currently, this is done by calculating the tile size that yields the
smallest possible square texture. All tiles in a surface (and thus,
in a texture) are the same size, and they’re either the full width of
the texture (wide surfaces), or the full height of the texture (tall
surfaces).

I would like to use basically the same algorithm, but instead of
directly messing with textures, I’d like to just allocate space for
one tile at a time, through a “space manager” that tries the
suggested texture, then another texture of the same pixel format, and
if that fails, allocates a new texture. It should probably create
rather big textures, to keep the number down in the general case, but
I’m not totally sure about that. This will need some thinking and
tuning.

I really hope I’m not wasting your time.

Don’t worry! I’ll live, regardless.

//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://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Monday 10 February 2003 00.03, Calvin Spealman wrote:

Glenn_Maynard · February 9, 2003, 4:06pm

Yeah, I think so… There are two problems glSDL has to deal with,
namely:

OpenGL textures have to be square, and

The dimensions of OpenGL textures don’t have to be equal, they just have
to be powers of two. (Which is a significant restriction itself, of
course.) It’s perfectly legitimate to create a 256x2 texture.

(If the dimensions had to be square, glTexImage2D would only take a
"size" parameter instead of separate “height” and “width” parameters.)

Currently, this is done by calculating the tile size that yields the
smallest possible square texture. All tiles in a surface (and thus,
in a texture) are the same size, and they’re either the full width of
the texture (wide surfaces), or the full height of the texture (tall
surfaces).

Bear in mind that you can’t split up a texture into two separate
textures and render them onscreen in anything but GL_NEAREST without
getting a seam along the edge. There’s no easy, generic way to fix
that.On Mon, Feb 10, 2003 at 12:49:35AM +0100, David Olofson wrote:

–
Glenn Maynard

James_Tittle_II · February 9, 2003, 4:24pm

…Actually, there’s the new-ish extension GL_TEXTURE_RECTANGLE_EXT
which allows non-power of two textures…

l8r,
jamie>On Mon, Feb 10, 2003 at 12:49:35AM +0100, David Olofson wrote:

Yeah, I think so… There are two problems glSDL has to deal with,
namely:

OpenGL textures have to be square, and

The dimensions of OpenGL textures don’t have to be equal, they just have
to be powers of two. (Which is a significant restriction itself, of
course.) It’s perfectly legitimate to create a 256x2 texture.

(If the dimensions had to be square, glTexImage2D would only take a
"size" parameter instead of separate “height” and “width” parameters.)

David_Olofson · February 9, 2003, 5:13pm

Yeah, I think so… There are two problems glSDL has to deal
with, namely:
* OpenGL textures have to be square, and
The dimensions of OpenGL textures don’t have to be equal, they just
have to be powers of two. (Which is a significant restriction
itself, of course.) It’s perfectly legitimate to create a 256x2
texture.

(If the dimensions had to be square, glTexImage2D would only take a
"size" parameter instead of separate “height” and "width"
parameters.)

Yeah, you’re right, of course. Dunno where I got that from. Bugs in
old drivers, maybe?

I could get glSDL to handle some cases slightly more efficiently (no
tiling) by removing this “artificial” restriction, but it won’t
improve texture space utilization; only reduce the number of textures
used. Might make rendering ever so slightly faster on some cards and
drivers, but if there’s any problem with it whatsoever, I don’t think
it’s worth it.

BTW, ‘./testsprite -gl -flip 5800’ (ie 5800 32x32 sprites in
640x480x32, double buffered), runs at full frame rate (which means 80
FPS) on my P-III 933 w/ ATI FireGL 8800. Fast enough?

Removing the -gl argument gives me some 2.2 fps with this CPU. 5.9
million pixels per frame, of which about 2 million are actually
rendered. (The rest are transparent.)

Should disable retrace sync and do some more serious testing, perhaps.
No idea what Kobo Deluxe can do on this card. I’ve only concluded
that 1280x1024, 32 bits won’t drop below full frame rate. (80 Hz.)

Currently, this is done by calculating the tile size that yields
the smallest possible square texture. All tiles in a surface (and
thus, in a texture) are the same size, and they’re either the
full width of the texture (wide surfaces), or the full height of
the texture (tall surfaces).

Bear in mind that you can’t split up a texture into two separate
textures and render them onscreen in anything but GL_NEAREST
without getting a seam along the edge. There’s no easy, generic
way to fix that.

glSDL cannot and will not use anything but GL_NEAREST. Getting
filtered scaling to work properly is way beyond the scope of glSDL,
and wouldn’t even be correct, since glSDL is supposed to render
exactly like SDL 2D. (Only faster, hopefully.

If you want 2D with scaling, transformation, blending modes not
supported by SDL, or even surface alpha and alpha channel at the same
time, use OpenGL directly. glSDL will only do that in SDL 1.3, if SDL
1.3 will do it in software as well. There’s just no point in
supporting stuff that you can’t do at all without glSDL, and it’s
much better done directly with OpenGL anyway.

Now, if someone ports glSDL to Direct3D, there might be some
motivation to support extra stuff, but IMHO, a 3D card that doesn’t
support OpenGL is either obsolete or severely broken anyway…
“D3DSDL” would basically just be a hack to make life easier for Win32
users and developers, since MS seems to be unwilling to support
OpenGL properly.

//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://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Monday 10 February 2003 01.05, Glenn Maynard wrote:

On Mon, Feb 10, 2003 at 12:49:35AM +0100, David Olofson wrote:

David_Olofson · February 9, 2003, 5:15pm

[…OpenGL texture sizes…]

…Actually, there’s the new-ish extension GL_TEXTURE_RECTANGLE_EXT
which allows non-power of two textures…

Problem is I probably won’t make myself very popular if I rely on
that…

//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://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Monday 10 February 2003 01.22, tigital wrote:

Ivan_Montes · February 9, 2003, 5:16pm

David Olofson wrote:

Yeah, I think so… There are two problems glSDL has to deal with,
namely:

OpenGL textures have to be square, and
OpenGL textures have limited size.

That is, if a texture is very tall or very wide (like an SFont - a
font for a high resolution may not even fit in a 2048x2048 texture
w/o tiling!), it has to be chopped up in suitably sized pieces, so it
will fit in one or more OpenGL textures.

Currently, this is done by calculating the tile size that yields the
smallest possible square texture. All tiles in a surface (and thus,
in a texture) are the same size, and they’re either the full width of
the texture (wide surfaces), or the full height of the texture (tall
surfaces).

I would like to use basically the same algorithm, but instead of
directly messing with textures, I’d like to just allocate space for
one tile at a time, through a “space manager” that tries the
suggested texture, then another texture of the same pixel format, and
if that fails, allocates a new texture. It should probably create
rather big textures, to keep the number down in the general case, but
I’m not totally sure about that. This will need some thinking and
tuning.-------------

If I’m not wrong about what you want to do I might have some code to do
this.
To be able to create the less amount of GL textures possible for a tiling
game, I
was making, I had to make a texture manager that will make possible to add
as
many tiles/sprites into a single texture as possible.

To make this I set up a minimum texture size for the tiles (64x64). When we
need
a bigger texture we set up the next biggest than tile texture with a power
of 2
dimensions (tile=70x40 -> text=128x64).

Then each texture created have associated a “bit” grid of for example 16x16
cells,
that’ll take 32bytes of memory. Each cell can be 0 or 1. 0 means empty and 1
means full

All the textures created are stored in a linked list, so when we add a new
tile we check in
that list for a texture which has enough free “cells”.

The textures should be sorted by its format in the list so we can optimize
the searching time
a bit.

hope this helps, Ivan

Calvin_Spealman · February 9, 2003, 5:24pm

Glenn Maynard wrote:

The dimensions of OpenGL textures don’t have to be equal, they just have
to be powers of two. (Which is a significant restriction itself, of
course.) It’s perfectly legitimate to create a 256x2 texture.

(If the dimensions had to be square, glTexImage2D would only take a
"size" parameter instead of separate “height” and “width” parameters.)

Bear in mind that you can’t split up a texture into two separate
textures and render them onscreen in anything but GL_NEAREST without
getting a seam along the edge. There’s no easy, generic way to fix
that.

In light of that, what do you have to say about the whole thing, David?

David_Olofson · February 9, 2003, 5:44pm

Glenn Maynard wrote:
[…texture dimensions and filtering…]
In light of that, what do you have to say about the whole thing,
David?

Nothing much more than what I’ve said in my reply to this post.

To rephrase; I could make use of non-square textures to reduce the
number of textures used, but it wouldn’t improve texture space
utilization, since that’s a problem with the power-of-2 restriction,
rather than with texture aspect ratio.

As to texture filtering, it’s virtually impossible to get it right
within the limits of the SDL 2D API. Getting glSDL’s internal tiling
to work with filtering would be quite simple, but it’s no point since
it doesn’t solve the real problem: tiled backgrounds in games, and
other situations where independent SDL blits are supposed to fit
edge-to-edge.

So, glSDL doesn’t, and probably never will do filtered scaling, unless
someone figures out a way to do it correctly without requiring
additional information from applications.

IMHO, this stuff is better left to a higher level 2D engine with
native OpenGL support. That would also gives you ultra smooth
scrolling throug sub pixel accurate scaling, and other nice things
that glSDL will never be able to provide.

glSDL is an accelerated implementation of the SDL 2D API; nothing
more, nothing less.

//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://olofson.net/audiality -’
— http://olofson.net — http://www.reologica.se —On Monday 10 February 2003 02.21, Calvin Spealman wrote: