Again rotozoom

ICH1994 wrote:

Is there a rotozoom function for SDL_Texture?
Hi,

I will assume your using SDL version 1.3 ?

I think you can use the native OpenGL commands for texture scaling/rotation:

  • “glScalef”
  • “glRotatef”

Just Google the above two OpenGL functions!------------------------
JeZ+Lee
JessePalser <AT> Gmail <DOT> com
16BitSoft®
Video Game Design Studio
www.16BitSoft.com

JeZ; you’re right if he’s using pure OpenGL; but wrong if he’s using SDL’s texture rendering API as his post would imply (DON’T ATTEMPT TO MODIFY AN OPENGL TEXTURE OR THE GL STATE MANUALLY IF YOU’RE RENDERING USING SDL_Textures!)

There’s been a debate about whether or not this should be included, and the resounding reason as to why not to is that it would be too slow to do in real time in the software renderer.

That said, I do believe I have an idea to resolve this.

Code:
SDL_Texture* SDL_TextureRotate(SDL_Texture* texture, float angle);

In the case of the software renderer; this creates a whole new SDL_Texture that is rotated.
In the case of the OpenGL and Direct3D renderer; this copies the struct and slightly modifies the state; so that the original SDL_Texture will still render non-rotated but the returned SDL_Texture will render rotated.

Then, any programmer can simply hold re-used rotations, and generate new ones only once on the fly. Simple caching routines can be used to optimize this (maybe SDL could even do this internally).

Note: This will also require SDL to maintain a reference count for each OpenGL/D3D texture. But a worthy sacrifice, IMO.

What do you guys think?------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

I would rather have something similar to SDL_RenderCopy() so that you can
choose whether or not to create a new texture. This would save a lot of
computation in the software renderer. It would be something like
SDL_RenderCopyRotate(SDL_Texture* texture, const SDL_Rect* srcrect, const
SDL_Rect* dstrect, SDL_float angle). Sprig does rotation and scaling in
software very quickly (though not perfectly) like this. If you could choose
a texture as a render target, then you could create a new texture as
desired. The issue with the function signature above is that the semantics
of the dstrect might be confusing. A couple of scaling parameters could
possibly be used instead of the dstrect members, but it’s not totally vital.

Jonny DOn Thu, Jan 20, 2011 at 11:49 AM, Nathaniel J Fries wrote:

JeZ; you’re right if he’s using pure OpenGL; but wrong if he’s using
SDL’s texture rendering API as his post would imply (DON’T ATTEMPT TO MODIFY
AN OPENGL TEXTURE OR THE GL STATE MANUALLY IF YOU’RE RENDERING USING
SDL_Textures!)

There’s been a debate about whether or not this should be included, and the
resounding reason as to why not to is that it would be too slow to do in
real time in the software renderer.

That said, I do believe I have an idea to resolve this.

Code:

SDL_Texture* SDL_TextureRotate(SDL_Texture* texture, float angle);

In the case of the software renderer; this creates a whole new SDL_Texture
that is rotated.
In the case of the OpenGL and Direct3D renderer; this copies the struct and
slightly modifies the state; so that the original SDL_Texture will still
render non-rotated but the returned SDL_Texture will render rotated.

Then, any programmer can simply hold re-used rotations, and generate new
ones only once on the fly. Simple caching routines can be used to optimize
this (maybe SDL could even do this internally).

Note: This will also require SDL to maintain a reference count for each
OpenGL/D3D texture. But a worthy sacrifice, IMO.

What do you guys think?


EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/


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

Nathaniel J Fries wrote:

JeZ; you’re right if he’s using pure OpenGL; but wrong if he’s using SDL’s texture rendering API as his post would imply (DON’T ATTEMPT TO MODIFY AN OPENGL TEXTURE OR THE GL STATE MANUALLY IF YOU’RE RENDERING USING SDL_Textures!) … What do you guys think?
Hi,

If native OpenGL commands like:

  • “glScalef”
  • "glRotatef"
    CAN’T be used in SDL 1.3
    then some type of scaling/rotation functions
    SHOULD be added to SDL 1.3!
    (how else can a developer scale or rotate an SDL texture???)------------------------
    JeZ+Lee
    JessePalser <AT> Gmail <DOT> com
    16BitSoft®
    Video Game Design Studio
    www.16BitSoft.com

Jonny D wrote:

I would rather have something similar to SDL_RenderCopy() so that you can choose whether or not to create a new texture. ?This would save a lot of computation in the software renderer. ?It would be something like SDL_RenderCopyRotate(SDL_Texture* texture, const SDL_Rect* srcrect, const SDL_Rect* dstrect, SDL_float angle). ?

I agree that the interface would be more ideal (or even more ideal than that would be to make the entire renderer coordinate/vertex-based rather than rectangle based), but not functional.
What you’re suggesting to do is exactly the reason why I suggested that the software renderer should make a copy of the texture - doing this is SLOW in software.
Sprig might have been onto something with their method; but that doesn’t mean SDL will do it right. I personally think that if it were to be done like this, it should return on error for the software renderer since otherwise we (or game producers) will get floods of reports of “slow frames” if they make heavy use of rotation.

PS: I forgot to mention earlier, but scaling already exists. Just modify destrect to be the actual region you want it rendered to.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

Again, I have to ask, why not just throw out the software renderer? Why not
throw out all the non-accelerated renderers? They’re an ancient artifact.
Every platform that SDL supports has OpenGL or GLES available (plus D3D for
Windows) and has since the late 90s. It’s kind of archaic to be what-ifing
about software rendering for multimedia apps in the 2010s, but I see it all the
time on this list, and it’s usually an excuse to hold back the implementation of
features that would be simple to implement on an accelerated backend but too
difficult (or non-performant) to do in a software renderer. Well, that’s
precisely why no one uses software renderers anymore!

If we decided to forget about software renderers, we could trivially add:

Rotation
Zooming
Render targets
Logical sizing for SDL_Window, separate from the physical size
Shader support
Vertex manipulation (display your texture as a trapezoid, a parallelogram or
other skewed shapes instead of a rectangle)
…and probably plenty of other simple but incredibly useful features.

This seems like a complete no-brainer to me. Why is anyone still even
considering using a software renderer in this decade?!?________________________________
From: nfries88@yahoo.com (Nathaniel J Fries)
Subject: Re: [SDL] Again rotozoom

Jonny D wrote:

I would rather have something similar to SDL_RenderCopy() so that you can choose
whether or not to create a new texture. This would save a lot of computation in
the software renderer. It would be something like
SDL_RenderCopyRotate(SDL_Texture* texture, const SDL_Rect* srcrect, const
SDL_Rect* dstrect, SDL_float angle).

I agree that the interface would be more ideal (or even more ideal than that
would be to make the entire renderer coordinate/vertex-based rather than
rectangle based), but not functional.
What you’re suggesting to do is exactly the reason why I suggested that the
software renderer should make a copy of the texture - doing this is SLOW in
software.
Sprig might have been onto something with their method; but that doesn’t mean
SDL will do it right. I personally think that if it were to be done like this,
it should return on error for the software renderer since otherwise we (or game
producers) will get floods of reports of “slow frames” if they make heavy use of
rotation.

PS: I forgot to mention earlier, but scaling already exists. Just modify
destrect to be the actual region you want it rendered to.


EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

Not that I’d necessarily be opposed to dropping the software renderer,
casual games often fail back to a software renderer (dropping most
effects in the process) so they can be played by even the most ancient
and frail system, or can deal with cases where there are no drivers
installed with 3D hardware support (or with very broken drivers).On Thu, Jan 20, 2011 at 15:25, Mason Wheeler wrote:

This seems like a complete no-brainer to me.? Why is anyone still even considering
using a software renderer in this decade?!?


Do what you can, where you are, with what you have. - T. Roosevelt

s/renderer, casual/renderer, but casual/On Thu, Jan 20, 2011 at 15:33, Greg Jandl <@Greg_Jandl> wrote:

On Thu, Jan 20, 2011 at 15:25, Mason Wheeler wrote:

This seems like a complete no-brainer to me.? Why is anyone still even considering
using a software renderer in this decade?!?

Not that I’d necessarily be opposed to dropping the software renderer,
casual games often fail back to a software renderer (dropping most
effects in the process) so they can be played by even the most ancient
and frail system, or can deal with cases where there are no drivers
installed with 3D hardware support (or with very broken drivers).


Do what you can, where you are, with what you have. - T. Roosevelt


Do what you can, where you are, with what you have. - T. Roosevelt

This seems like a complete no-brainer to me. Why is anyone still even
considering
using a software renderer in this decade?!?

Not that I’d necessarily be opposed to dropping the software renderer,
casual games often fail back to a software renderer (dropping most
effects in the process) so they can be played by even the most ancient
and frail system, or can deal with cases where there are no drivers
installed with 3D hardware support (or with very broken drivers).

Then they’re free to use SDL 1.2, which hails from the era of ancient and
frail systems and is designed for them. But we’re not talking about 1.2;
we’re talking about 1.3. SDL 1.3 is supposed to modernize the library,
but it’s becoming increasingly clear that we can’t really do that with all
these software renderer anchors around our necks.>----- Original Message ----

From: Greg Jandl <greg.jandl at gmail.com>
Subject: Re: [SDL] Again rotozoom
On Thu, Jan 20, 2011 at 15:25, Mason Wheeler <@Mason_Wheeler> wrote:

Mason Wheeler wrote:

If we decided to forget about software renderers, we could trivially add:

Rotation
Zooming
Render targets
Logical sizing for SDL_Window, separate from the physical size
Shader support
Vertex manipulation (display your texture as a trapezoid, a parallelogram or other skewed shapes instead of a rectangle)
…and probably plenty of other simple but incredibly useful features.

I want to point out that render targets is actually simplest in the software renderer. It is older versions of OpenGL (before 3.0) that makes it an issue; not the software renderer.

I agree with you though, software rendering should be excluded from the texture rendering APIs. SDL no longer supports the archaic and/or unusual systems that required it.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

I was quite happy that SDL had a effecient generic software renderer when I
started to port SDL the PS3.

At the time we only had a frame buffer access. And a guy made a very
impressive demostration using that SDL software powered.

Now we have access to the RSX, so we can use vertex & fragments, but we
don’t have a OpenGL driver yet, so I guess the quick and dirty software
renderer port will be the only myoption for a couple of months.

If we dropped the software renderer, I would have to port… the SDL 1.2, it
doesn’t seems not very exiting to me ;)On Thu, Jan 20, 2011 at 10:40 PM, Mason Wheeler wrote:

----- Original Message ----

From: Greg Jandl <greg.jandl at gmail.com>
Subject: Re: [SDL] Again rotozoom

On Thu, Jan 20, 2011 at 15:25, Mason Wheeler wrote:

This seems like a complete no-brainer to me. Why is anyone still even
considering
using a software renderer in this decade?!?

Not that I’d necessarily be opposed to dropping the software renderer,
casual games often fail back to a software renderer (dropping most
effects in the process) so they can be played by even the most ancient
and frail system, or can deal with cases where there are no drivers
installed with 3D hardware support (or with very broken drivers).

Then they’re free to use SDL 1.2, which hails from the era of ancient and
frail systems and is designed for them. But we’re not talking about 1.2;
we’re talking about 1.3. SDL 1.3 is supposed to modernize the library,
but it’s becoming increasingly clear that we can’t really do that with all
these software renderer anchors around our necks.


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

Couldn’t agree more.

In a time where 2D accelerated graphics cards are gone, where 2D is
implemented with Z=0,
software rendering is a relic from the past.

For those that still require it, SDL 1.2 is not going away any time soon.–
Paulo

On Thu, Jan 20, 2011 at 10:40 PM, Mason Wheeler wrote:

----- Original Message ----

From: Greg Jandl <greg.jandl at gmail.com>
Subject: Re: [SDL] Again rotozoom

On Thu, Jan 20, 2011 at 15:25, Mason Wheeler wrote:

This seems like a complete no-brainer to me. Why is anyone still even
considering
using a software renderer in this decade?!?

Not that I’d necessarily be opposed to dropping the software renderer,
casual games often fail back to a software renderer (dropping most
effects in the process) so they can be played by even the most ancient
and frail system, or can deal with cases where there are no drivers
installed with 3D hardware support (or with very broken drivers).

Then they’re free to use SDL 1.2, which hails from the era of ancient and
frail systems and is designed for them. But we’re not talking about 1.2;
we’re talking about 1.3. SDL 1.3 is supposed to modernize the library,
but it’s becoming increasingly clear that we can’t really do that with all
these software renderer anchors around our necks.


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

Really? According to Wikipedia there’s an OpenGL implementation currently
available for PS3…________________________________
From: seb.darocha@gmail.com (Seb DA ROCHA)
Subject: Re: [SDL] Again rotozoom

I was quite happy that SDL had a effecient generic software renderer when I
started to port SDL the PS3.

At the time we only had a frame buffer access. And a guy made a very impressive
demostration using that SDL software powered.

Now we have access to the RSX, so we can use vertex & fragments, but we don’t
have a OpenGL driver yet, so I guess the quick and dirty software renderer port
will be the only myoption for a couple of months.

If we dropped the software renderer, I would have to port… the SDL 1.2, it
doesn’t seems not very exiting to me :wink:

This is exactly backward, IMO. If you have OpenGL available, there’s no
point in using the SDL video API. Just use OpenGL directly - it’s much
more powerful and flexible than anything SDL can offer, and also faster
than channeling all OpenGL calls through the SDL API.

I /only/ use the SDL video API for software rendering - for virtual
machines with flaky 3D acceleration, machines with crappy OpenGL
drivers, and machines with no OpenGL drivers installed at all. All of
which I encounter on a regular basis.On 1/20/2011 14:25, Mason Wheeler wrote:

Again, I have to ask, why not just throw out the software renderer? Why not
throw out all the non-accelerated renderers? They’re an ancient artifact.
Every platform that SDL supports has OpenGL or GLES available (plus D3D for
Windows) and has since the late 90s.


Rainer Deyke - rainerd at eldwood.com

Whatever work for you.

I personally prefer to use the SDL API. It gets me D3D on Windows and
OGL on the others, without having to roll my own twin rendering
pipelines.

Plus, though there are, of course, things I’m looking forward to
seeing in SDL, I just plain like working with it.On Thu, Jan 20, 2011 at 19:16, Rainer Deyke wrote:

I /only/ use the SDL video API for software rendering - for virtual
machines with flaky 3D acceleration, machines with crappy OpenGL
drivers, and machines with no OpenGL drivers installed at all. ?All of
which I encounter on a regular basis.


Do what you can, where you are, with what you have. - T. Roosevelt

Rainer Deyke wrote:

This is exactly backward, IMO. If you have OpenGL available, there’s no
point in using the SDL video API. Just use OpenGL directly - it’s much
more powerful and flexible than anything SDL can offer, and also faster
than channeling all OpenGL calls through the SDL API.

Is it better to do this? Probably.
Is it easier? No. It requires you to know something extra. If you didn’t know it, that means you’re spending valuable development time learning it. If you do, you’re probably still spending a little time implementing things in a way similar to how SDL already does it for you.

Every game product has to decide on the whole productivity vs efficiency thing. As an extreme example, it would usually be more efficient to write a program in assembly with only system dependencies. Would this be more efficient than C/C++ with SDL? Yes. Would this require extra time and effort? Definitely. Would this then require even more time and effort to port from, say, Windows to Linux or Linux to Mac? Undeniably. What about from Mac/x86 to iOS/ARM? You might never finish!------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/