If I’m trying to get the size of a texture, or just one of the two dimensions, it’s a real pain to have to set up dummy variables for a four-argument function call. Could this be refactored out into four separate functions please? Or, better still, get rid of the awkward “opaque handle” method of dealing with textures and windows and just give us direct access to the SDL_Texture and SDL_Window structs, like we have for SDL_Surface? Information hiding is nice, to a point, but any abstraction that the consumer has no way to get underneath is evil.
If I’m trying to get the size of a texture, or just one of the two dimensions, it’s a real pain to have to set up dummy variables for a four-argument function call. ?Could this be refactored out into four separate functions please? ?Or, better still, get rid of the awkward “opaque handle” method of dealing with textures and windows and just give us direct access to the SDL_Texture and SDL_Window structs, like we have for SDL_Surface? ?Information hiding is nice, to a point, but any abstraction that the consumer has no way to get underneath is evil.
You do know that you can pass NULL for the things you’re not
interested in, right? See the source for SDL_QueryTexture, pretty
straightforward…
http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/video/SDL_video.c?view=markupOn Tue, Jun 30, 2009 at 2:54 PM, Mason Wheeler wrote:
–
sigh You’re right, of course. I keep forgetting that C’s pointer parameters are not quite the same thing as passing by reference.
Even so, this ought to be four functions, not one, or better yet, no functions, just a struct we can dereference our way into.> ----- Original Message -----
From: pphaneuf@gmail.com (Pierre Phaneuf)
Subject: Re: [SDL] SDL_QueryTexture is awkward to useOn Tue, Jun 30, 2009 at 2:54 PM, Mason Wheeler<@Mason_Wheeler> wrote:
If I’m trying to get the size of a texture, or just one of the two dimensions, it’s a real pain to have to set up dummy variables for a four-argument function call. Could this be refactored out into four separate functions please? Or, better still, get rid of the awkward “opaque handle” method of dealing with textures and windows and just give us direct access to the SDL_Texture and SDL_Window structs, like we have for SDL_Surface? Information hiding is nice, to a point, but any abstraction that the consumer has no way to get underneath is evil.
You do know that you can pass NULL for the things you’re not
interested in, right? See the source for SDL_QueryTexture, pretty
straightforward…http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/video/SDL_video.c?view=markup
Even so, this ought to be four functions, not one, or better yet, no
functions, just a struct we can dereference our way into.
I can certainly see why it’s not just a struct that can be
dereferenced (much more robust ABI this way). Wasn’t there some ABI
breaking in the past, due to SDL_Surface being the way it is? I’d call
this learning from past mistakes…
I kind of like the symmetry of SDL_QueryTexture with
SDL_CreateTexture, myself, and it’s no more difficult to get just two
than all of them. I can certainly see the future-proofing advantage in
having them together, for example, if a mutex gets added to textures
for safety, the current API could guarantee consistency. This, of
course, makes no sense at the moment for textures, these
characteristics cannot be changed, but the key part is “at the
moment”, which is why people call this kind of thing
"future-proofing". Another more realistic idea could be to have SDL
use native structures for textures more directly (making it a
"thinner" wrapper), and it might be expensive to fetch these values on
some platforms, say (for example, roundtripping to the X server).
What I really don’t like is how “access” is an int rather than an
SDL_TextureAccess… Ow, my type safety, it hurts…On Tue, Jun 30, 2009 at 3:13 PM, Mason Wheeler wrote:
–