[PATCH] SDL 1.3: Drawing from one texture to another

Here is a resubmission of a patch I sent last week and that went
unnoticed…

Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL one.
If there is interest to get this patch accepted in the SDL 1.3 tree, I can
work on implementing it for other backends.

What it does:
It adds a new function in SDL_video.h :

int SDL_SetTargetTexture(SDL_TextureID textureID)

where textureID is the ID of the texture to target, or 0 to revert the
target back to the window.

The texture has to be created with an access value of
SDL_TEXTUREACCESS_TARGET to be used this way. (this may be debattable, but
we need a way to tell the renderer that this texture may be used as a
target)

A corresponding function is added to the renderer functions table.

What do you think of it?

Florent
-------------- next part --------------
A non-text attachment was scrubbed…
Name: set_target_texture.diff
Type: text/x-patch
Size: 10020 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090701/742b7679/attachment.bin

I like the idea, though I think it would be simpler to do it without adding a new API
call. Just make SDL_SelectRenderer able to take a texture handle as well as a
window handle, and have fail and it return -1 if you pass in a handle to a texture
that doesn’t have SDL_TEXTUREACCESS_TARGET set.

Here is a resubmission of a patch I sent last week and that went unnoticed…

Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL one.
If there is interest to get this patch accepted in the SDL 1.3 tree, I can work on implementing it for other backends.

What it does:
It adds a new function in SDL_video.h :

int SDL_SetTargetTexture(SDL_TextureID textureID)

where textureID is the ID of the texture to target, or 0 to revert the target back to the window.

The texture has to be created with an access value of SDL_TEXTUREACCESS_TARGET to be used this way. (this may be debattable, but we need a way to tell the renderer that this texture may be used as a target)

A corresponding function is added to the renderer functions table.

What do you think of it?

FlorentFrom: flboudet@gmail.com (florent boudet)
Subject: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Patches often go unnoticed on the list. I’d suggest posting it on Bugzilla.
http://bugzilla.libsdl.org/

Pat>

From: florent boudet
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Tuesday, June 30, 2009 5:48:31 PM
Subject: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Here is a resubmission of a patch I sent last week and that went unnoticed…

Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL one.

If there is interest to get this patch accepted in the SDL 1.3 tree, I can work on implementing it for other backends.

What it does:

It adds a new function in SDL_video.h :

int SDL_SetTargetTexture(SDL_TextureID textureID)

where textureID is the ID of the texture to target, or 0 to revert the target back to the window.

The texture has to be created with an access value of SDL_TEXTUREACCESS_TARGET to be used this way. (this may be debattable, but we need a way to tell the renderer that this texture may be used as a target)

A corresponding function is added to the renderer functions table.

What do you think of it?

Florent

I don’t know if overloading SDL_SelectRenderer is a good idea. Do you
mean adding another argument? I think it would be much clearer as a
separate function.

Jonny DOn Tue, Jun 30, 2009 at 7:06 PM, Mason Wheeler wrote:

I like the idea, though I think it would be simpler to do it without adding
a new API
call.? Just make SDL_SelectRenderer able to take a texture handle as well as
a
window handle, and have fail and it return -1 if you pass in a handle to a
texture
that doesn’t have SDL_TEXTUREACCESS_TARGET set.
From: florent boudet
Subject: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Here is a resubmission of a patch I sent last week and that went
unnoticed…

Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL one.
If there is interest to get this patch accepted in the SDL 1.3 tree, I can
work on implementing it for other backends.

What it does:
It adds a new function in SDL_video.h :

int SDL_SetTargetTexture(SDL_TextureID textureID)

where textureID is the ID of the texture to target, or 0 to revert the
target back to the window.

The texture has to be created with an access value of
SDL_TEXTUREACCESS_TARGET to be used this way. (this may be debattable, but
we need a way to tell the renderer that this texture may be used as a
target)

A corresponding function is added to the renderer functions table.

What do you think of it?

Florent


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

No, I mean keeping the same function and allowing it to work on both types,
since it’s doing the same thing either way No new arguments are needed,
since they’re both just aliases for UInt32.

I don’t know if overloading SDL_SelectRenderer is a good idea. Do you
mean adding another argument? I think it would be much clearer as a
separate function.

Jonny DFrom: grimfang4@gmail.com (Jonathan Dearborn)
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

On Tue, Jun 30, 2009 at 7:06 PM, Mason Wheeler<@Mason_Wheeler> wrote:

I like the idea, though I think it would be simpler to do it without adding
a new API
call. Just make SDL_SelectRenderer able to take a texture handle as well as
a
window handle, and have fail and it return -1 if you pass in a handle to a
texture
that doesn’t have SDL_TEXTUREACCESS_TARGET set.
From: florent boudet
Subject: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Here is a resubmission of a patch I sent last week and that went
unnoticed…

Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL one.
If there is interest to get this patch accepted in the SDL 1.3 tree, I can
work on implementing it for other backends.

What it does:
It adds a new function in SDL_video.h :

int SDL_SetTargetTexture(SDL_TextureID textureID)

where textureID is the ID of the texture to target, or 0 to revert the
target back to the window.

The texture has to be created with an access value of
SDL_TEXTUREACCESS_TARGET to be used this way. (this may be debattable, but
we need a way to tell the renderer that this texture may be used as a
target)

A corresponding function is added to the renderer functions table.

What do you think of it?

Florent


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

I made a separate function to make it more clear to the API user.
SDL_TextureID and SDL_WindowID appear to be of different type to the
user, although both are uint32 and come from the same pool.

Both approach have their advantages (mine is more clear to the user
imo, yours adds less bloat to the API).
What would you prefer, maintainers of the API?

I am more bothered with the SDL_TEXTUREACCESS_TARGET access parameter:
this has not much to do with the way we access the texture data, and
this would have been much better on a ‘flags’ parameter for
SDL_CreateTexture (as we had on the SDL_CreateRGBSurface function in
SDL 1.2).
But I didn’t risked to modify the SDL_CreateTexture prototype…

FlorentOn Wed, Jul 1, 2009 at 8:02 PM, Mason Wheeler wrote:

No, I mean keeping the same function and allowing it to work on both types,
since it’s doing the same thing either way? No new arguments are needed,
since they’re both just aliases for UInt32.

From: Jonathan Dearborn
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

I don’t know if overloading SDL_SelectRenderer is a good idea.? Do you
mean adding another argument?? I think it would be much clearer as a
separate function.

Jonny D

On Tue, Jun 30, 2009 at 7:06 PM, Mason Wheeler wrote:

I like the idea, though I think it would be simpler to do it without adding
a new API
call.? Just make SDL_SelectRenderer able to take a texture handle as well as
a
window handle, and have fail and it return -1 if you pass in a handle to a
texture
that doesn’t have SDL_TEXTUREACCESS_TARGET set.
From: florent boudet <@florent_boudet>
Subject: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Here is a resubmission of a patch I sent last week and that went
unnoticed…

Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL one.
If there is interest to get this patch accepted in the SDL 1.3 tree, I can
work on implementing it for other backends.

What it does:
It adds a new function in SDL_video.h :

int SDL_SetTargetTexture(SDL_TextureID textureID)

where textureID is the ID of the texture to target, or 0 to revert the
target back to the window.

The texture has to be created with an access value of
SDL_TEXTUREACCESS_TARGET to be used this way. (this may be debattable, but
we need a way to tell the renderer that this texture may be used as a
target)

A corresponding function is added to the renderer functions table.

What do you think of it?

Florent


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


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

Den Wed, 1 Jul 2009 22:10:34 +0200
skrev florent boudet :

I made a separate function to make it more clear to the API user.
SDL_TextureID and SDL_WindowID appear to be of different type to the
user, although both are uint32 and come from the same pool.

Both approach have their advantages (mine is more clear to the user
imo, yours adds less bloat to the API).

I disagree. With Mason Wheeler’s approach, SelectRenderer always
sets the target for your renders, whatever that may be. When you
look at it that way, ie what you actually want to accomplish by using
the function (“i want to render things to there!”), it’s easy to use
and easy to understand. SelectRenderer can be described simply as “set
target for rendering”. (The user has to know that both windows and
textures can be targets, but they’d have to know that anyway to want to
render to textures in the first place, or to go looking for a
SetTargetTexture function for that matter.)

With two functions, the SelectRenderer description changes to something
like “set target window for rendering, unless rendering to a texture”.
SetTargetTexture could then be “set target texture for rendering, or 0
to revert target to the previously selected window”. Not a huge change,
but it’s more to keep in mind for new users, and leads to questions
like this:

SDL_SetTargetTexture(texture);
SDL_SelectRenderer(window);

Assuming the texture is nonzero, if these two functions are called in
this order, what is the result? Does SelectRenderer implicitly
call SetTargetTexture(0), or does it merely set the window to render to
once SetTargetTexture(0) is explicitly called some time in the future?
This is not clear.

SDL_SelectRenderer(texture);
SDL_SelectRenderer(window);

Probably no need to look things up in the documentation here. It’s just
changing the one state.

Having just one function for both windows and texture targets also makes
things easier if you want to change code that currently renders to a
window to render to a texture in stead (let’s say the shiny new version
of your engine wants to support fancy post-processing). No need to
change any calls if they’re the same in either case!

  • Gerry> What would you prefer, maintainers of the API?

I am more bothered with the SDL_TEXTUREACCESS_TARGET access parameter:
this has not much to do with the way we access the texture data, and
this would have been much better on a ‘flags’ parameter for
SDL_CreateTexture (as we had on the SDL_CreateRGBSurface function in
SDL 1.2).
But I didn’t risked to modify the SDL_CreateTexture prototype…

Florent

On Wed, Jul 1, 2009 at 8:02 PM, Mason Wheeler wrote:

No, I mean keeping the same function and allowing it to work on
both types, since it’s doing the same thing either way? No new
arguments are needed, since they’re both just aliases for UInt32.

From: Jonathan Dearborn
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to
another

I don’t know if overloading SDL_SelectRenderer is a good idea.? Do
you mean adding another argument?? I think it would be much clearer
as a separate function.

Jonny D

On Tue, Jun 30, 2009 at 7:06 PM, Mason Wheeler wrote:

I like the idea, though I think it would be simpler to do it
without adding a new API
call.? Just make SDL_SelectRenderer able to take a texture handle
as well as a
window handle, and have fail and it return -1 if you pass in a
handle to a texture
that doesn’t have SDL_TEXTUREACCESS_TARGET set.
From: florent boudet
Subject: [SDL] [PATCH] SDL 1.3: Drawing from one texture to
another

Here is a resubmission of a patch I sent last week and that went
unnoticed…

Here is a patch proposal to provide rendering to a texture.
It can be applied to the current trunk of SDL 1.3.
Currently, the only renderer on which I implemented it is the GL
one. If there is interest to get this patch accepted in the SDL
1.3 tree, I can work on implementing it for other backends.

What it does:
It adds a new function in SDL_video.h :

int SDL_SetTargetTexture(SDL_TextureID textureID)

where textureID is the ID of the texture to target, or 0 to
revert the target back to the window.

The texture has to be created with an access value of
SDL_TEXTUREACCESS_TARGET to be used this way. (this may be
debattable, but we need a way to tell the renderer that this
texture may be used as a target)

A corresponding function is added to the renderer functions table.

What do you think of it?

Florent


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


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

Thanks! That’s pretty much exactly my line of reasoning for wanting a
single function, expressed a lot better than I was able to.

Den Wed, 1 Jul 2009 22:10:34 +0200
skrev florent boudet :

I made a separate function to make it more clear to the API user.
SDL_TextureID and SDL_WindowID appear to be of different type to the
user, although both are uint32 and come from the same pool.

Both approach have their advantages (mine is more clear to the user
imo, yours adds less bloat to the API).

I disagree. With Mason Wheeler’s approach, SelectRenderer always
sets the target for your renders, whatever that may be. When you
look at it that way, ie what you actually want to accomplish by using
the function (“i want to render things to there!”), it’s easy to use
and easy to understand. SelectRenderer can be described simply as “set
target for rendering”. (The user has to know that both windows and
textures can be targets, but they’d have to know that anyway to want to
render to textures in the first place, or to go looking for a
SetTargetTexture function for that matter.)

With two functions, the SelectRenderer description changes to something
like “set target window for rendering, unless rendering to a texture”.
SetTargetTexture could then be “set target texture for rendering, or 0
to revert target to the previously selected window”. Not a huge change,
but it’s more to keep in mind for new users, and leads to questions
like this:

SDL_SetTargetTexture(texture);
SDL_SelectRenderer(window);

Assuming the texture is nonzero, if these two functions are called in
this order, what is the result? Does SelectRenderer implicitly
call SetTargetTexture(0), or does it merely set the window to render to
once SetTargetTexture(0) is explicitly called some time in the future?
This is not clear.

SDL_SelectRenderer(texture);
SDL_SelectRenderer(window);

Probably no need to look things up in the documentation here. It’s just
changing the one state.

Having just one function for both windows and texture targets also makes
things easier if you want to change code that currently renders to a
window to render to a texture in stead (let’s say the shiny new version
of your engine wants to support fancy post-processing). No need to
change any calls if they’re the same in either case!

  • GerryFrom: trick@icculus.org (Gerry Jo Jellestad)
    Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Oh, I see. I like it.

Jonny DOn 7/1/09, Mason Wheeler wrote:

Thanks! That’s pretty much exactly my line of reasoning for wanting a
single function, expressed a lot better than I was able to.

From: Gerry JJ
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Den Wed, 1 Jul 2009 22:10:34 +0200
skrev florent boudet :

I made a separate function to make it more clear to the API user.
SDL_TextureID and SDL_WindowID appear to be of different type to the
user, although both are uint32 and come from the same pool.

Both approach have their advantages (mine is more clear to the user
imo, yours adds less bloat to the API).

I disagree. With Mason Wheeler’s approach, SelectRenderer always
sets the target for your renders, whatever that may be. When you
look at it that way, ie what you actually want to accomplish by using
the function (“i want to render things to there!”), it’s easy to use
and easy to understand. SelectRenderer can be described simply as “set
target for rendering”. (The user has to know that both windows and
textures can be targets, but they’d have to know that anyway to want to
render to textures in the first place, or to go looking for a
SetTargetTexture function for that matter.)

With two functions, the SelectRenderer description changes to something
like “set target window for rendering, unless rendering to a texture”.
SetTargetTexture could then be “set target texture for rendering, or 0
to revert target to the previously selected window”. Not a huge change,
but it’s more to keep in mind for new users, and leads to questions
like this:

SDL_SetTargetTexture(texture);
SDL_SelectRenderer(window);

Assuming the texture is nonzero, if these two functions are called in
this order, what is the result? Does SelectRenderer implicitly
call SetTargetTexture(0), or does it merely set the window to render to
once SetTargetTexture(0) is explicitly called some time in the future?
This is not clear.

SDL_SelectRenderer(texture);
SDL_SelectRenderer(window);

Probably no need to look things up in the documentation here. It’s just
changing the one state.

Having just one function for both windows and texture targets also makes
things easier if you want to change code that currently renders to a
window to render to a texture in stead (let’s say the shiny new version
of your engine wants to support fancy post-processing). No need to
change any calls if they’re the same in either case!

  • Gerry

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

You know, the more I think about this, the more I find myself questioning the
basic design. Why do we have a concept of a “current renderer”? In the 1.2
API, you specified the target you’re blitting to for blits, and the screen you’re
flipping for flips. (Even though it didn’t support multiple screens yet!)

Getting rid of that, moving to the “current renderer” system, takes what ought
to be a function parameter and moves it to a piece of global state, and global
state that’s hidden behind an impenetrable abstraction at that. Two evils for
the price of one! What’s the rationale behind this?> ----- Original Message -----

From: grimfang4@gmail.com (Jonathan Dearborn)
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Oh, I see. I like it.

Jonny D

On 7/1/09, Mason Wheeler <@Mason_Wheeler> wrote:

Thanks! That’s pretty much exactly my line of reasoning for wanting a
single function, expressed a lot better than I was able to.

From: Gerry JJ
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Den Wed, 1 Jul 2009 22:10:34 +0200
skrev florent boudet :

I made a separate function to make it more clear to the API user.
SDL_TextureID and SDL_WindowID appear to be of different type to the
user, although both are uint32 and come from the same pool.

Both approach have their advantages (mine is more clear to the user
imo, yours adds less bloat to the API).

I disagree. With Mason Wheeler’s approach, SelectRenderer always
sets the target for your renders, whatever that may be. When you
look at it that way, ie what you actually want to accomplish by using
the function (“i want to render things to there!”), it’s easy to use
and easy to understand. SelectRenderer can be described simply as “set
target for rendering”. (The user has to know that both windows and
textures can be targets, but they’d have to know that anyway to want to
render to textures in the first place, or to go looking for a
SetTargetTexture function for that matter.)

With two functions, the SelectRenderer description changes to something
like “set target window for rendering, unless rendering to a texture”.
SetTargetTexture could then be “set target texture for rendering, or 0
to revert target to the previously selected window”. Not a huge change,
but it’s more to keep in mind for new users, and leads to questions
like this:

SDL_SetTargetTexture(texture);
SDL_SelectRenderer(window);

Assuming the texture is nonzero, if these two functions are called in
this order, what is the result? Does SelectRenderer implicitly
call SetTargetTexture(0), or does it merely set the window to render to
once SetTargetTexture(0) is explicitly called some time in the future?
This is not clear.

SDL_SelectRenderer(texture);
SDL_SelectRenderer(window);

Probably no need to look things up in the documentation here. It’s just
changing the one state.

Having just one function for both windows and texture targets also makes
things easier if you want to change code that currently renders to a
window to render to a texture in stead (let’s say the shiny new version
of your engine wants to support fancy post-processing). No need to
change any calls if they’re the same in either case!

  • Gerry

Getting rid of that, moving to the “current renderer” system, takes what
ought
to be a function parameter and moves it to a piece of global state, and
global
state that’s hidden behind an impenetrable abstraction at that.? Two evils
for
the price of one!? What’s the rationale behind this?

I was thinking about this, how it forced the API to be single-threaded
(having shared state), but I figured that since every other backend
forces you to be single-threaded anyway, the lowest common denominator
kind of dictated it (if the API is clearly single-threaded, your code
will more likely work everywhere, or it will screw up everywhere, but
you have that nice, consistent “everywhere” in both cases).

Especially as things are moving toward OpenGL as the preferred
backend, which is itself sharing that characteristic…

There’s some stuff that is quite doable in a multi-threaded context,
like render to different off-screen target, it’s a bit of a shame that
it forces you to do it in software. I suppose that in the nice
hardware accelerated situations, everything gets funnelled through a
single command queue anyway, so there’s absolutely no advantage to
multi-threading in that case anyway.On Thu, Jul 2, 2009 at 3:45 PM, Mason Wheeler wrote:


It’s not the threading that bugs me, really. I don’t have any good reason in my
project to try to draw to the screen from two different threads. The problem is
keeping track of the identity of the current renderer across different subsystems.
I’m trying to build something that has two different SDL_Window objects
embedded in the same Delphi form. I’m going to need some sort of global in
my project to mirror the internal SDL global variable that keeps track of the
current renderer, and that concept just bugs me.

Getting rid of that, moving to the “current renderer” system, takes what
ought
to be a function parameter and moves it to a piece of global state, and
global
state that’s hidden behind an impenetrable abstraction at that. Two evils
for
the price of one! What’s the rationale behind this?

I was thinking about this, how it forced the API to be single-threaded
(having shared state), but I figured that since every other backend
forces you to be single-threaded anyway, the lowest common denominator
kind of dictated it (if the API is clearly single-threaded, your code
will more likely work everywhere, or it will screw up everywhere, but
you have that nice, consistent “everywhere” in both cases).

Especially as things are moving toward OpenGL as the preferred
backend, which is itself sharing that characteristic…

There’s some stuff that is quite doable in a multi-threaded context,
like render to different off-screen target, it’s a bit of a shame that
it forces you to do it in software. I suppose that in the nice
hardware accelerated situations, everything gets funnelled through a
single command queue anyway, so there’s absolutely no advantage to
multi-threading in that case anyway.From: pphaneuf@gmail.com (Pierre Phaneuf)
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another
On Thu, Jul 2, 2009 at 3:45 PM, Mason Wheeler<@Mason_Wheeler> wrote:

Well, the API could require you to pass the current context to each and
every video APi call. That seemed even more unwieldy.On Thu, Jul 2, 2009 at 1:56 PM, Mason Wheeler wrote:

It’s not the threading that bugs me, really. I don’t have any good reason
in my
project to try to draw to the screen from two different threads. The
problem is
keeping track of the identity of the current renderer across different
subsystems.
I’m trying to build something that has two different SDL_Window objects
embedded in the same Delphi form. I’m going to need some sort of global in
my project to mirror the internal SDL global variable that keeps track of
the
current renderer, and that concept just bugs me.

From: Pierre Phaneuf
**Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to
another

On Thu, Jul 2, 2009 at 3:45 PM, Mason Wheeler wrote:

Getting rid of that, moving to the “current renderer” system, takes what
ought
to be a function parameter and moves it to a piece of global state, and
global
state that’s hidden behind an impenetrable abstraction at that. Two
evils
for
the price of one! What’s the rationale behind this?

I was thinking about this, how it forced the API to be single-threaded
(having shared state), but I figured that since every other backend
forces you to be single-threaded anyway, the lowest common denominator
kind of dictated it (if the API is clearly single-threaded, your code
will more likely work everywhere, or it will screw up everywhere, but
you have that nice, consistent “everywhere” in both cases).

Especially as things are moving toward OpenGL as the preferred
backend, which is itself sharing that characteristic…

There’s some stuff that is quite doable in a multi-threaded context,
like render to different off-screen target, it’s a bit of a shame that
it forces you to do it in software. I suppose that in the nice
hardware accelerated situations, everything gets funnelled through a
single command queue anyway, so there’s absolutely no advantage to
multi-threading in that case anyway.


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

Have a default value? If one is not passed in, then act how it is.
Otherwise select it with every call.On Fri, Jul 3, 2009 at 2:22 PM, Sam Lantinga wrote:

Well, the API could require you to pass the current context to each and
every video APi call.? That seemed even more unwieldy.

I don’t see it as being “unwieldy.” It’s basically the same as object-oriented
programming, in which the current object gets passed as the Self parameter
to every method call. Only difference is that the syntax is a bit different.

Well, the API could require you to pass the current context to each and
every video APi call. That seemed even more unwieldy.

Have a default value? If one is not passed in, then act how it is.
Otherwise select it with every call.From: renesd@gmail.com (Rene Dudfield)
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another
On Fri, Jul 3, 2009 at 2:22 PM, Sam Lantinga wrote:

… or expose the SDL_Renderer structure and let the users dereference the
function pointers themselves…On Friday, 3 July 2009 00:31:03 Mason Wheeler wrote:

I don’t see it as being “unwieldy.” It’s basically the same as
object-oriented programming, in which the current object gets passed as the
Self parameter to every method call. Only difference is that the syntax is
a bit different.

C doesn’t have default function arguments.On Fri, Jul 3, 2009 at 12:25 AM, Ren? Dudfield wrote:

On Fri, Jul 3, 2009 at 2:22 PM, Sam Lantinga wrote:

Well, the API could require you to pass the current context to each and
every video APi call. That seemed even more unwieldy.

Have a default value? If one is not passed in, then act how it is.
Otherwise select it with every call.


http://codebad.com/

I believe he means pass NULL and let the function figure out how to deal with
it.

JeffOn Friday 03 July 2009 03:44, Donny Viszneki wrote:

On Fri, Jul 3, 2009 at 12:25 AM, Ren? Dudfield wrote:

On Fri, Jul 3, 2009 at 2:22 PM, Sam Lantinga wrote:

Well, the API could require you to pass the current context to each and
every video APi call. That seemed even more unwieldy.

Have a default value? If one is not passed in, then act how it is.
Otherwise select it with every call.

C doesn’t have default function arguments.

You know, the more I think about this, the more I find myself questioning
the
basic design.? Why do we have a concept of a “current renderer”?? In the 1.2
API, you specified the target you’re blitting to for blits, and the screen
you’re
flipping for flips. (Even though it didn’t support multiple screens yet!)

Getting rid of that, moving to the “current renderer” system, takes what
ought
to be a function parameter and moves it to a piece of global state, and
global
state that’s hidden behind an impenetrable abstraction at that.? Two evils
for
the price of one!? What’s the rationale behind this?

That is a real good question.

My experience is that you get the “current thingy” design in software
for many different reasons. One is that the hardware is built that
way. That is, if you have to do something to the hardware to make a
change, folks tend to reflect that up into the software. Another is
when the designer believes that switching from one “thingy” to another
is a heavy weight operation. I say “believes” because reality rarely
has a lot to do with it. If the designer believes that switching is
costly then the design will reflect the idea that you should pick a
"thingy" do all you need to it and then pick another thingy to work
on. You also see this approach when the designer is building a
portability layer over a bunch of different interfaces for working
with thingies. If most of the under layers use a "current thingy"
model then it is very likely that the portability layer will too. But,
by far the most common reason is that the designer thinks using that
model and as a result never thinks to do it any other way.

BTW, X and OpenGL both have contexts which are the equivalent of
renderers. Most graphics systems use them. These contexts were very
heavy weight back in the bad old days, and switching from one to
another took a lot of time. Because switching really was heavy weight
switching was avoided like the plague. As a result almost all graphics
systems use the idea of a context that has to be selected. This works
its way down into the driver design and the hardware design. The
graphics context for OpenGL is huge and if you go swapping them around
all over the place it can be a problem, or at least it was at some
time in the past. How many OpenGL contexts can the current generation
of graphics systems store? When switching from on to another can cause
program code to be deployed to several hundred cores on the GPU, what
does a context switch cost? I don’t know.

What I am saying is that back in the bad old days switching renderer
contexts was expensive and so it was to be avoided. As a result,
everything from the hardware on up was built to avoid context switches
and that was reflected all the way up into the highest levels of the
API. Yes, the reality of ancient hardware shaped the APIs which then
shaped modern hardware. People learned to do things that way, and so
that view of the world was passed down from generation to generation
and … That is most likely why it is that way now.

You might be tempted to say my explanation boils down to “because it
has always been done that way” which is th worst possible answer
(Admiral Grace would haunt me forever for saying that.) What I am
saying is that back in the bad old days there were real good reasons
for doing that way and as a result it might still be a good idea to do
it that way even though it might be possible to do it a complete
different way now.

Bob PendletonOn Thu, Jul 2, 2009 at 2:45 PM, Mason Wheeler wrote:

----- Original Message ----
From: Jonathan Dearborn
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

Oh, I see.? I like it.

Jonny D

On 7/1/09, Mason Wheeler wrote:

Thanks!? That’s pretty much exactly my line of reasoning for wanting a
single function, expressed a lot better than I was able to.

From: Gerry JJ
Subject: Re: [SDL] [PATCH] SDL 1.3: Drawing from one texture to another

? Den Wed, 1 Jul 2009 22:10:34 +0200
skrev florent boudet :

I made a separate function to make it more clear to the API user.
SDL_TextureID and SDL_WindowID appear to be of different type to the
user, although both are uint32 and come from the same pool.

Both approach have their advantages (mine is more clear to the user
imo, yours adds less bloat to the API).

I disagree.? With Mason Wheeler’s approach, SelectRenderer always
sets the target for your renders, whatever that may be.? When you
look at it that way, ie what you actually want to accomplish by using
the function (“i want to render things to there!”), it’s easy to use
and easy to understand. SelectRenderer can be described simply as “set
target for rendering”. (The user has to know that both windows and
textures can be targets, but they’d have to know that anyway to want to
render to textures in the first place, or to go looking for a
SetTargetTexture function for that matter.)

With two functions, the SelectRenderer description changes to something
like “set target window for rendering, unless rendering to a texture”.
SetTargetTexture could then be “set target texture for rendering, or 0
to revert target to the previously selected window”.? Not a huge change,
but it’s more to keep in mind for new users, and leads to questions
like this:

? ? SDL_SetTargetTexture(texture);
? ? SDL_SelectRenderer(window);

Assuming the texture is nonzero, if these two functions are called in
this order, what is the result?? Does SelectRenderer implicitly
call SetTargetTexture(0), or does it merely set the window to render to
once SetTargetTexture(0) is explicitly called some time in the future?
This is not clear.

? ? SDL_SelectRenderer(texture);
? ? SDL_SelectRenderer(window);

Probably no need to look things up in the documentation here.? It’s just
changing the one state.

Having just one function for both windows and texture targets also makes
things easier if you want to change code that currently renders to a
window to render to a texture in stead (let’s say the shiny new version
of your engine wants to support fancy post-processing).? No need to
change any calls if they’re the same in either case!

  • Gerry

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


±----------------------------------------------------------

BTW, X and OpenGL both have contexts which are the equivalent of
renderers. Most graphics systems use them. These contexts were very
heavy weight back in the bad old days, and switching from one to
another took a lot of time. Because switching really was heavy weight
switching was avoided like the plague. As a result almost all graphics
systems use the idea of a context that has to be selected. This works
its way down into the driver design and the hardware design. The
graphics context for OpenGL is huge and if you go swapping them around
all over the place it can be a problem, or at least it was at some
time in the past. How many OpenGL contexts can the current generation
of graphics systems store? When switching from on to another can cause
program code to be deployed to several hundred cores on the GPU, what
does a context switch cost? I don’t know.

I think the key here is that it looks like Mason’s Delphi unit would
like to change the context sometimes (when there’s more than one
SDL_Window objects embedded in the same Delphi form, he was saying),
so he’d like to set it back the way it was after, but there’s no
SDL_GetRenderer() to know which SDL_WindowID is currently active, so
he needs to fake it, by keeping the last value passed into his
SDL_SelectRenderer() wrapper in some global variable of his wrapper,
when this information is most certainly available inside of SDL (did I
get this correctly, Mason?).

There is a glXGetCurrentContext, he’d need the SDL equivalent.

Also, GCs in X11 were expensive, as in you didn’t want to create a ton
of them, but functions took them as parameters, if I recall correctly.On Fri, Jul 3, 2009 at 7:05 PM, Bob Pendleton wrote: