Why SDL_TextureID? (Potential performance loss on looking up

SDL Development
21

personallfy i prefer using a nice 32 bit integer than a pointer to some
memory reference of which i should know size, contents, values & co.
the performance hit of a lookup table is negligible and if i understand
correctly it cleans up the memory after itself so we even have free garbage
collection!

the only drawback i see is less debuggability but i believe that that could
be superseeded by a consistent api

VittorioOn Wed, Jan 20, 2010 at 1:38 PM, Adam Strzelecki wrote:

Regarding performance hit discussions, please remember that optimizations
without
sound reasons are very bad ideas.

Yup, I think we all know what Mr. Knuth said about premature optimization.
Personally I believe it is TRUE for 95% applications, however excluding
games/performance sensitive multimedia apps, where some initial choices can
have irreversible impact on performance.

I hate this C culture of the programmers wanting to know more than the
compiler does.
The time where compilers weren’t able to proper optimize code is long
gone.

Sure you’re right, still I highly doubt compiler will optimize THAT code so
the hash table lookup is as fast as straight pointer. Moreover SDL is
audio/video HW abstraction library aimed for game/multimedia apps, so the
performance IMHO shall be favored over safety.

On the other hand seems that SDL_TextureID based implementation won’t
suffer performance hit unless you got really many textures like few
hundreds, since texture hash table keeps 64 linked lists. My concern is that
I actually deal with hundreds of textures in my application.

Please first profile your applications with the right set of tools and
then complain with
facts.

Agreed.

Regards,

Adam

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

Jonathan Swifthttp://www.brainyquote.com/quotes/authors/j/jonathan_swift.html

  • “May you live every day of your life.”
22

Might I suggest a compromise of sorts? I don’t like opaque handles of any type, since you can’t see what’s going on and it makes debugging harder. For me the aggravation factor is ratcheted up another notch beyond what most of you have to put up with, since I don’t program in C or C++. That means that if I want to check out what’s actually going on under the hood while debugging, I have to fire up Visual Studio, load the SDL project and attach its debugger. And you can’t attach more than one debugger to a program at a time, which means extra hassle in getting it to work. Anything that can be done to mitigate the amount of switches I need to make between Delphi and Visual Studio is a net plus.

However, Sam and Bob have made some pretty good cases for why they’re used in SDL and the reasoning behind it. So maybe instead of replacing them altogether, we could keep the API as it is, and then add a little bit to it. Declare the structs for windows and textures in public headers, and create functions that take an ID and return a pointer to the actual structs. Mark them with whatever cautionary notes are deemed necessary in documentation and inline comments, so that coders understand that these aren’t necessarily stable or good for your health and irresponsible use of them may cause nasal demons. But at least make sure they’re there if they’re needed, because sometimes they really are needed.

Sound good?

23

Mason Wheeler wrote:

However, Sam and Bob have made some pretty good cases for why they’re used in SDL and the reasoning behind it. So maybe instead of replacing them altogether, we could keep the API as it is, and then add a little bit to it. Declare the structs for windows and textures in public headers, and create functions that take an ID and return a pointer to the actual structs. Mark them with whatever cautionary notes are deemed necessary in documentation and inline comments, so that coders understand that these aren’t necessarily stable or good for your health and irresponsible use of them may cause nasal demons. But at least make sure they’re there if they’re needed, because sometimes they really are needed.

Sound good?

I think you completely missed the point here. It is not about accessing the structure itself, in fact most of us proposed the way of hiding it inside private header. It is about actual argument passed to functions like SDL_GetTextureScaleMode of which you would expect only fetching a value of a struct field like so:

int SDL_GetTextureScaleMode(SDL_TextureID handle, int* mode)
{
SDL_Texture* tex = (SDL_TextureID) handle;

*mode = tex->scaleMode;
}

where SDL_TextureID is opaque void*, instead we have something like:

int SDL_GetTextureScaleMode(SDL_TextureID handle, int* mode)
{
SDL_Texture* tex = findTexture(handle); // handle is int here

*mode = tex->scaleMode;
}

now we may only hope that findTexture is really, really fast and it may even be ok to have bit of
overhead here, but when doing a game, and drawing hundreds of sprites using SDL_RenderCopy,
it is not that negligible.

Even worse, when using OpenGL or Direct3D one would normally sort by
texture id to reduce batch overhead, with ID based system drawing 100 sprites using same ID
means 100 lookups every single SDL_###Texture or SDL_Render### call using exact same
texture.

24

Another possibility is to convert over to structure pointers, but
allow you to query an ID and look up by ID for the cases where it may
be unsafe to hold onto a pointer.

I don’t want to expose the structure definitions publicly because they
are extremely likely to change and I don’t want to introduce binary
compatibility issues.On Wed, Jan 20, 2010 at 6:48 AM, Mason Wheeler wrote:

Might I suggest a compromise of sorts? ?I don’t like opaque handles of any type, since you can’t see what’s going on and it makes debugging harder. ?For me the aggravation factor is ratcheted up another notch beyond what most of you have to put up with, since I don’t program in C or C++. ?That means that if I want to check out what’s actually going on under the hood while debugging, I have to fire up Visual Studio, load the SDL project and attach its debugger. ?And you can’t attach more than one debugger to a program at a time, which means extra hassle in getting it to work. ?Anything that can be done to mitigate the amount of switches I need to make between Delphi and Visual Studio is a net plus.

However, Sam and Bob have made some pretty good cases for why they’re used in SDL and the reasoning behind it. ?So maybe instead of replacing them altogether, we could keep the API as it is, and then add a little bit to it. ?Declare the structs for windows and textures in public headers, and create functions that take an ID and return a pointer to the actual structs. ?Mark them with whatever cautionary notes are deemed necessary in documentation and inline comments, so that coders understand that these aren’t necessarily stable or good for your health and irresponsible use of them may cause nasal demons. ?But at least make sure they’re there if they’re needed, because sometimes they really are needed.

Sound good?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

25

personallfy i prefer using a nice 32 bit integer than a pointer to some
memory reference

Funny you should mention “32 bit” here… An integer is NOT necessarily 32
bits everywhere, which pretty much eliminates that advantage.

Of course, you can use something like Uint32, or a specific typedef - but what
if you accidentally use ‘int’ in application code? You can’t really make that
mistake with a pointer, but with integers, you won’t even get a compiler
warning most of the time…!

BTW, you can typedef a handle type as a pointer to a struct that is only
named, but not defined in the API headers. That works pretty much like a void

  • (compile error if you try to directly access anything through it), but it
    also prevents you from mixing it up with any other void * types.

of which i should know size, contents, values & co.

I don’t see why you “should” know anything like that just because the type of
your “handle” happens to be pointer rather than an integer. It’s just an
opaque handle, regardless of how it’s stored physically.

the performance hit of a lookup table is negligible

That depends on how many of them you do, in relation to actual work done…

Premature optimization is indeed the root of all evil - but “deoptimization by
design” might not be the greatest idea for performance critical APIs either.
:slight_smile:

and if i understand
correctly it cleans up the memory after itself so we even have free garbage
collection!

That is an orthogonal issue, really. You can have all objects freed
automatically when you close a “context”, or require the application to manage
them manually, regardless of how you reference objects.

Sure, with integers, you can check if objects are still valid - but there’s no
real need for that if the only way objects can disappear is as a direct result
of YOUR actions…! If you really can’t have your application be aware of when
it explicitly destroys it’s own contexts, you might want to check your design
before relying on side effects of the API to deal with it. :wink:

Objects disappearing for other reasons than direct actions of your application
code is another matter, but that can be handle just fine with pointers too.

One very simple way is to just leave the structs around, marked as “dead”, to
keep the pointers physically valid for safe error checking. In the case of
lost textures, one might extend this so that “dead” textures can be brought
back to life (as opposed to creating new ones), avoiding reinitialization of
texture handles in the game engine.

the only drawback i see is less debuggability but i believe that that could
be superseeded by a consistent api

Not sure what you have in mind here. Please expand…?On Wednesday 20 January 2010, at 15.28.10, “Vittorio G.” <vitto.giova at yahoo.it> wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

26

This changed my mind, certainly for windows handles. Textures I’m
still 50/50 on, there will be a lot more textures than windows in your
average program, and they will be accessed far more frequently.
Textures identifiers are far less likely to be used in the situation
described by Sam. But I’d lean toward them anyway. The IDs give a lot
of flexibility for Sam and the other SDL maintainers and perhaps we
are too quick to assume the performance will suffer negatively.

2010/1/20 Sam Lantinga :> I played with this a little tonight, and there are a few reasons why

this isn’t necessarily a good idea.

First, it’s easy to validate an ID, but you can’t necessarily validate
a pointer.

Second, you can potentially reuse a memory address, which means that
if you’re doing comparisons against a stored value, you can
potentially get a false positive.

Third, if we do it for textures, we should probably do it for windows
as well, and we currently pass window ID values through events, which
may be processed after the relevant window is destroyed.

I have this change roughed out, but I wanted to raise these
considerations for discussion before I check anything in.

27

Sam Lantinga wrote:

First, it’s easy to validate an ID, but you can’t necessarily validate
a pointer.

I think you can, in pretty much the same way as you would validate an
ID: check if it’s in your global table of valid pointers. (Of course
that has performance problems, so it might not be the best way.)

In fact, an ID can be a typedef for a pointer as easily as it can be
typedef for an integer. IDs and pointers are not mutually exclusive.

Second, you can potentially reuse a memory address, which means that
if you’re doing comparisons against a stored value, you can
potentially get a false positive.

You can also potentially reuse IDs. Or you could prevent pointers from
being reused by not deallocating them.

Third, if we do it for textures, we should probably do it for windows
as well, and we currently pass window ID values through events, which
may be processed after the relevant window is destroyed.

So, to distill your argument:

  • IDs have infinite lifetime.
  • The memory structures to which the IDs refer have finite lifetime.
  • Keeping the memory structures to which the IDs refer alive
    indefinitely would be a resource leak, and therefore bad.
  • Keeping the IDs alive indefinitely does not qualify as a resource
    leak, even though you could theoretically run out of IDs.

My approach to this problem would be to use reference counting. When a
window is destroyed, keep its memory structure alive as long as there
are pointers/IDs that refer to it.–
Rainer Deyke - rainerd at eldwood.com

28

Well, I also agree that having to look up an SDL_Texture for every function call is a pain.
I also see the value in hiding the pointer entirely and doing it as such, mainly the fact that SDL may free a texture without an application being aware of it - this is an issue that’s pretty simple to find when running a debugger - but if this occurs with say only one specific SDL 1.3 revision and the end-user is a typical computer consumer (ie, technologically impaired), who probably could not submit a decent bug report if his/her life depended on it, it may be impossible to help this person besides by forcing them to download the shared lib you use yourself.

I can propose two solutions for this:

  1. SDL doesn’t free textures ANYWHERE unless explicitly told to do so (SDL_FreeTexture or similar). SDL probably already does this anyway, but the only way this can fail is if the programmer fails within his own code, or if GL/DX free the texture ON THEIR own.
  2. SDL provides two versions of each function, one for TextureID and one for Texture*, and provide a means for getting a Texture* from a TextureID. This solution, however, completely nullifies the purpose.

And my two cents on the matter:
The application I recently began updating to SDL 1.3 (been strapped for time, made little progress) will usually render about 150-200 textures each frame. And it’s just a f/oss clone of a simple 2D mmorpg which has been operating the same way for like 10 years now. I’m not sure how badly a tree lookup for ever texture operation will affect the performance, but I’m sure I’d take a notable hit when profiling, but probably not too bad with regards to framerate.
I can’t say I like it, and I’m hardly the best or most experienced programmer in the world (5 years isn’t much in comparison to many of you, especially considering I haven’t even taken a higher educational class in computer science), but I assure you even when I began working on the project 4 years ago the protection offered by using an ID with a tree lookup wouldn’t have saved me any grief.
As far as I can see, the only thing it protects the programmers using SDL from is API inconsistencies between patches. And then, if they only use the functions already provided by SDL rather than trying to modify the structures directly, that is a minor problem as well (just provide their shared library when distributing and make no guarantees of other builds working correctly).
However, I don’t really care. I can’t see it having a major effect on any practical program using SDL. I do think I’d prefer pointers, though, just because some other programs might be hit harder by that “little bit” that I won’t miss.

29

In an open source project there is no such a thing as a private
header. Let me say that another way. The concept of a private header
is meaningless in an open source project. Nothing is private when all
the source code is just a download a way.

Rainer’s joke aside, the difference is some go into distro “development”
packages and are installed system-wide by a “make install” and some
aren’t, and if you bypass the formal API by reading the source code or
disassembling a binary, frankly, you get what you deserve.

It’s like driving the wrong direction on a one way street and
complaining that the “ONE WAY” sign didn’t physically prevent you from
doing it.

There are so many trivial ways to handle that problem that I don’t
even see it as a problem.

I doubt any method beats the simplicity of a pointer dereference. :slight_smile:

Ok, you lost me there. How do you have access to an index from an
earlier run of the program? Do you write it out to a file and then
read it back? That doesn’t work to well with pointers either. Or are
you talking about run the application in a loop inside say the main
program? In that case you have the same problem with a pointer.

Did you really assume I might have thought writing pointers to disk was
a good idea?

A “run” meant “between initializing the subsystem and deinitializing it,
perhaps multiple times in the same process” … this definition only
existed in my tired head, and not any formal text. I apologize for the
confusion.

The concern was tracking down the bug, when we’re already at the point
where an app misbehaved. A free’d pointer presumably crashes. A reused
index may not crash at all.

Please don’t reply with “but maybe the C runtime reused that page after
you called free()” because I just don’t really care all that much about
what SDL_TextureID is typedef’d to.

Typedef it to a bool for all I care.

–ryan.

30

My vote is for a prototyped struct.

struct SDL_TextureID;
typedef struct SDL_TextureID SDL_TextureID; // not needed in C++

You can have pointers to that all you want, but you can not instance it or dereference it (the compiler errors out because it has no definition), and it still debugs correctly (the debugger finds the
real SDL_TextureID definition in a .c file somewhere and displays its contents like any other public struct would).

I am very fond of NULL pointers as a failure mode, and dereferencing a pointer to an object that has been destroyed is no less safe than looking up an anonymous ID that has been destroyed and then
reused (!), I’d rather see a crash.On 01/19/2010 12:56 PM, Brian Barrett wrote:

If the structure definition wasn’t present in the public SDL API then
that is a strong indication to the programmer that they should not
dereference it. If they go to the trouble of including a private SDL
header or doing some ugly casting to access such members, well I have
no sympathy for them if they are forced to change their code when SDL
makes changes. =)

Personally, I think consistency is the most important thing. SDL has
always used pointers, so it should probably continue using them.

Another thing: pointers have an obvious “failure” state → NULL. With
integers, it could be 0 like OpenGL, or -1 (which SDL currently uses
for any function that returns an int IIRC). Consistent APIs are
easiest for the user.

–
Forest ‘LordHavoc’ Hale
Author of DarkPlaces Quake1 engine and mod
http://icculus.org/twilight/darkplaces

31

Okay, this is what I ended up doing. I’ll send a separate
announcement e-mail with the details.On Wed, Jan 20, 2010 at 7:44 AM, Sam Lantinga <@slouken> wrote:

Another possibility is to convert over to structure pointers, but
allow you to query an ID and look up by ID for the cases where it may
be unsafe to hold onto a pointer.

I don’t want to expose the structure definitions publicly because they
are extremely likely to change and I don’t want to introduce binary
compatibility issues.

On Wed, Jan 20, 2010 at 6:48 AM, Mason Wheeler wrote:

Might I suggest a compromise of sorts? ?I don’t like opaque handles of any type, since you can’t see what’s going on and it makes debugging harder. ?For me the aggravation factor is ratcheted up another notch beyond what most of you have to put up with, since I don’t program in C or C++. ?That means that if I want to check out what’s actually going on under the hood while debugging, I have to fire up Visual Studio, load the SDL project and attach its debugger. ?And you can’t attach more than one debugger to a program at a time, which means extra hassle in getting it to work. ?Anything that can be done to mitigate the amount of switches I need to make between Delphi and Visual Studio is a net plus.

However, Sam and Bob have made some pretty good cases for why they’re used in SDL and the reasoning behind it. ?So maybe instead of replacing them altogether, we could keep the API as it is, and then add a little bit to it. ?Declare the structs for windows and textures in public headers, and create functions that take an ID and return a pointer to the actual structs. ?Mark them with whatever cautionary notes are deemed necessary in documentation and inline comments, so that coders understand that these aren’t necessarily stable or good for your health and irresponsible use of them may cause nasal demons. ?But at least make sure they’re there if they’re needed, because sometimes they really are needed.

Sound good?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
? ? ? ?-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

32

I think everyone is in agreement that public structure headers for a volatile and platform-specific object would be a universally Bad Idea.

This discussion needs to stay on the topic of performance.

As for hash tables of linked lists - performance is highly dependent on the number of objects we’re talking about, for my .obj model loading for example I have to use huge hash tables (on the order of
11bit or larger) to avoid slow compares against lots of structs when adding a new vertex to a mesh, you really never want to be reviewing more than 5 things in a list (and even that is very
debatable), it’s not about mitigating “slow cases”, it’s about being FAST, because someone will care someday, and you don’t know why, when or where.

As I have not used SDL 1.3 I do not know precisely what these SDL_TextureID objects are used for, but anything that is accessed every frame should be as fast as possible, and hash lookups always sound
bad in that context.

For example in my engine I do a hash lookup on shaders by mode and permutation and use a large enough hash table to almost never have more than one shader per list, thus avoiding the overhead, this
only matters because these objects are accessed hundreds of times per frame.

So what is the usage pattern of SDL_TextureID?On 01/20/2010 07:44 AM, Sam Lantinga wrote:

Another possibility is to convert over to structure pointers, but
allow you to query an ID and look up by ID for the cases where it may
be unsafe to hold onto a pointer.

I don’t want to expose the structure definitions publicly because they
are extremely likely to change and I don’t want to introduce binary
compatibility issues.

–
LordHavoc
Author of DarkPlaces Quake1 engine - LadyHavoc's DarkPlaces Quake Modification
Co-designer of Nexuiz - Nexuiz Classic – Alientrap
“War does not prove who is right, it proves who is left.” - Unknown
“Any sufficiently advanced technology is indistinguishable from a rigged demo.” - James Klass
“A game is a series of interesting choices.” - Sid Meier

33

Forest Hale wrote:> On 01/20/2010 07:44 AM, Sam Lantinga wrote:

Another possibility is to convert over to structure pointers, but
allow you to query an ID and look up by ID for the cases where it may
be unsafe to hold onto a pointer.

I don’t want to expose the structure definitions publicly because they
are extremely likely to change and I don’t want to introduce binary
compatibility issues.

I think everyone is in agreement that public structure headers for a volatile and platform-specific object would be a universally Bad Idea.

This discussion needs to stay on the topic of performance.

As for hash tables of linked lists - performance is highly dependent on the number of objects we’re talking about, for my .obj model loading for example I have to use huge hash tables (on the order of
11bit or larger) to avoid slow compares against lots of structs when adding a new vertex to a mesh, you really never want to be reviewing more than 5 things in a list (and even that is very
debatable), it’s not about mitigating “slow cases”, it’s about being FAST, because someone will care someday, and you don’t know why, when or where.

As I have not used SDL 1.3 I do not know precisely what these SDL_TextureID objects are used for, but anything that is accessed every frame should be as fast as possible, and hash lookups always sound
bad in that context.

For example in my engine I do a hash lookup on shaders by mode and permutation and use a large enough hash table to almost never have more than one shader per list, thus avoiding the overhead, this
only matters because these objects are accessed hundreds of times per frame.

So what is the usage pattern of SDL_TextureID?

–
LordHavoc
Author of DarkPlaces Quake1 engine - LadyHavoc's DarkPlaces Quake Modification
Co-designer of Nexuiz - Nexuiz Classic – Alientrap
“War does not prove who is right, it proves who is left.” - Unknown
“Any sufficiently advanced technology is indistinguishable from a rigged demo.” - James Klass
“A game is a series of interesting choices.” - Sid Meier

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

TextureID is used basically the same as an SDL_Surface in previous versions of SDL.
It’s your basic 2d image, sprite, etc. Anytime you want to draw a sprite, you use it in a function. Anytime you want to alter a sprite somehow, you use it in a function.

34

So after the updated api, i have run into this problem
using the new SDL_Window struct with SDL_CreateWindow and debug mode on
iphone everything is fine, then if i set to release the view is not
displayed anymore.
so i had to switch back to the old setvideomode, and the problem is gone,
works both in release and debug mode

is the problem known? is it possible to maintain the old SDL_CreateWindow
that returned that nice INTEGER value? my whole application is in pascal,
and having to bind to an integer value is much more preferrable than
rewriting the whole sdl_window structure!

bye
Vittorio

Samuel Goldwynhttp://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html

  • "I’m willing to admit that I may not always be right, but I am never
    wrong."On Thu, Jan 21, 2010 at 8:37 PM, nfries88 wrote:

Forest Hale wrote:

On 01/20/2010 07:44 AM, Sam Lantinga wrote:

Quote:

Another possibility is to convert over to structure pointers, but
allow you to query an ID and look up by ID for the cases where it may
be unsafe to hold onto a pointer.

I don’t want to expose the structure definitions publicly because they
are extremely likely to change and I don’t want to introduce binary
compatibility issues.

I think everyone is in agreement that public structure headers for a
volatile and platform-specific object would be a universally Bad Idea.

This discussion needs to stay on the topic of performance.

As for hash tables of linked lists - performance is highly dependent on the
number of objects we’re talking about, for my .obj model loading for example
I have to use huge hash tables (on the order of
11bit or larger) to avoid slow compares against lots of structs when adding
a new vertex to a mesh, you really never want to be reviewing more than 5
things in a list (and even that is very
debatable), it’s not about mitigating “slow cases”, it’s about being FAST,
because someone will care someday, and you don’t know why, when or where.

As I have not used SDL 1.3 I do not know precisely what these SDL_TextureID
objects are used for, but anything that is accessed every frame should be as
fast as possible, and hash lookups always sound
bad in that context.

For example in my engine I do a hash lookup on shaders by mode and
permutation and use a large enough hash table to almost never have more than
one shader per list, thus avoiding the overhead, this
only matters because these objects are accessed hundreds of times per
frame.

So what is the usage pattern of SDL_TextureID?

–
LordHavoc
Author of DarkPlaces Quake1 engine -
LadyHavoc's DarkPlaces Quake Modification
Co-designer of Nexuiz - Nexuiz Classic – Alientrap
“War does not prove who is right, it proves who is left.” - Unknown
“Any sufficiently advanced technology is indistinguishable from a rigged
demo.” - James Klass
“A game is a series of interesting choices.” - Sid Meier

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

TextureID is used basically the same as an SDL_Surface in previous versions
of SDL.
It’s your basic 2d image, sprite, etc. Anytime you want to draw a sprite,
you use it in a function. Anytime you want to alter a sprite somehow, you
use it in a function.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

35

You’re supposed to deal in pointers (which are not all that different from
integer “handles” in this context) rather than structs, no…?On Sunday 24 January 2010, at 21.52.02, “Vittorio G.” <vitto.giova at yahoo.it> wrote:

So after the updated api, i have run into this problem
using the new SDL_Window struct with SDL_CreateWindow and debug mode on
iphone everything is fine, then if i set to release the view is not
displayed anymore.
so i had to switch back to the old setvideomode, and the problem is gone,
works both in release and debug mode

is the problem known? is it possible to maintain the old SDL_CreateWindow
that returned that nice INTEGER value? my whole application is in pascal,
and having to bind to an integer value is much more preferrable than
rewriting the whole sdl_window structure!

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

36

Well that depends how SDL gets exposed to Pascal clients.On Sun, Jan 24, 2010 at 10:32 PM, David Olofson wrote:

On Sunday 24 January 2010, at 21.52.02, “Vittorio G.” < vitto.giova at yahoo.it> wrote:

So after the updated api, i have run into this problem
using the new SDL_Window struct with SDL_CreateWindow and debug mode on
iphone everything is fine, then if i set to release the view is not
displayed anymore.
so i had to switch back to the old setvideomode, and the problem is gone,
works both in release and debug mode

is the problem known? is it possible to maintain the old SDL_CreateWindow
that returned that nice INTEGER value? my whole application is in pascal,
and having to bind to an integer value is much more preferrable than
rewriting the whole sdl_window structure!

You’re supposed to deal in pointers (which are not all that different
from
integer “handles” in this context) rather than structs, no…?

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

37

I’m using SDL 1.3 with FreePascal with my own bindings as well.

You can either use pointers (since their size is same everywhere), or
you can use following type, that is an unsigned integer with a size of
pointer.

type SDL_TextureID=ptruint;

or

type SDL_TextureID=pointer;

or

type SDL_Texture=record somestruct…
end;
SDL_TextureID=^SDL_Texture;

All of them will just work fine.

Pavel Kanzelsberger
www.mediaware.skOn 25.1.2010, at 9:15, Paulo Pinto wrote:

Well that depends how SDL gets exposed to Pascal clients.

On Sun, Jan 24, 2010 at 10:32 PM, David Olofson wrote:
On Sunday 24 January 2010, at 21.52.02, “Vittorio G.” <vitto.giova at yahoo.it wrote:

So after the updated api, i have run into this problem
using the new SDL_Window struct with SDL_CreateWindow and debug
mode on
iphone everything is fine, then if i set to release the view is not
displayed anymore.
so i had to switch back to the old setvideomode, and the problem
is gone,
works both in release and debug mode

is the problem known? is it possible to maintain the old
SDL_CreateWindow
that returned that nice INTEGER value? my whole application is in
pascal,
and having to bind to an integer value is much more preferrable than
rewriting the whole sdl_window structure!

You’re supposed to deal in pointers (which are not all that
different from
integer “handles” in this context) rather than structs, no…?

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics
—.
| http://olofson.net http://kobodeluxe.com http://
audiality.org |
| http://eel.olofson.net http://zeespace.net http://
reologica.se |
‘---------------------------------------------------------------------’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Pavel Kanzelsberger

E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633

38

Well that depends how SDL gets exposed to Pascal clients.

Why, yes - but what I’m saying is, you need to deal in pointers (cast to
whatever type you like - they’re really just opaque handles anyway), as
opposed to copying the structure around by value.

(The quote below is what triggered my initial response.)

On Sunday 24 January 2010, at 21.52.02, “Vittorio G.” <
vitto.giova at yahoo.it>
[…]

my whole
application is in pascal, and having to bind to an integer value is
much more preferrable than rewriting the whole sdl_window structure!
[…]On Monday 25 January 2010, at 09.15.06, Paulo Pinto wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

39

that works for me, didn’t think i had to use pointers but then looking at
the code it is true that sdl_window is obscure
thanks David and Pavel
Vittorio

Pablo Picassohttp://www.brainyquote.com/quotes/authors/p/pablo_picasso.html

  • "Computers are useless. They can only give you answers."On Mon, Jan 25, 2010 at 2:32 PM, David Olofson wrote:

On Monday 25 January 2010, at 09.15.06, Paulo Pinto wrote:

Well that depends how SDL gets exposed to Pascal clients.

Why, yes - but what I’m saying is, you need to deal in pointers (cast to
whatever type you like - they’re really just opaque handles anyway), as
opposed to copying the structure around by value.

(The quote below is what triggered my initial response.)

On Sunday 24 January 2010, at 21.52.02, “Vittorio G.” <
vitto.giova at yahoo.it>
[…]

my whole
application is in pascal, and having to bind to an integer value is
much more preferrable than rewriting the whole sdl_window structure!
[…]

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org