Jeremiah wrote:
The only question is. Who’s going to program it?
I realize it is the simplest but I could do OGL and D3D.
I don’t think the question is should we have rotation. Rotation is an
inevitability. The proof is empirical.1.The presence of multiple external libraries that handled rotation
for original SDL 1.2.x
2.The number of emails/requests for it.
3.And last but not least. Sam’s approvalThe only question is. Who’s going to program it?
Well, for OGL an D3D, it’s trivial. For non-accelerated backends,
like you said, there are multiple external libraries already available
for 1.2. The code for one of them could probably adapted and
integrated into SDL 1.3.>----- Original Message ----
From: Jeremiah
Subject: Re: [SDL] Rotation API
So far we have
SDL_RenderCopyRotated(SDL_texture *texture, const SDL_Rect *srcrect,
const SDL_Rect * dstrect, int angle);
as a unifying API suggestion
A texture. An angle(in degrees?) . With optional(?) SDL_rects for
rotating only a specific part of the texture. I like that. That covers
pretty much anything I’d want to do with rotation.
Although the Copy part makes me wonder. Does the copied texture have
the same id as original? What happens to old texture?
What do guys think?
Rotation in a function? Keeping the SDL_Texture structure the same.
or
add a new member to the SDL_Texture structure, and control rotation by
changing values .
With the latter method, you only have to create an object once
(atleast on some systems)
But with the previous method would make for better uniformity.On Thu, Feb 25, 2010 at 4:49 PM, Mason Wheeler wrote:
----- Original Message ----
From: Jeremiah <@Jeremiah>
Subject: Re: [SDL] Rotation APII don’t think the question is should we have rotation. Rotation is an
inevitability. The proof is empirical.1.The presence of multiple external libraries that handled rotation
for original SDL 1.2.x
2.The number of emails/requests for it.
3.And last but not least. Sam’s approvalThe only question is. Who’s going to program it?
Well, for OGL an D3D, it’s trivial. ?For non-accelerated backends,
like you said, there are multiple external libraries already available
for 1.2. ?The code for one of them could probably adapted and
integrated into SDL 1.3.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
So far we have
SDL_RenderCopyRotated(SDL_texture *texture, const SDL_Rect *srcrect,
const SDL_Rect * dstrect, int angle);as a unifying API suggestion
A texture. An angle(in degrees?) . With optional(?) SDL_rects for
rotating only a specific part of the texture. I like that. That covers
pretty much anything I’d want to do with rotation.Although the Copy part makes me wonder. Does the copied texture have
the same id as original? What happens to old texture?
The name is based on SDL_RenderCopy, which is basically the Texture
equivalent to SDL_BlitSurface. It copies/renders from the texture to the
render target (screen). It doesn’t copy it to a new texture.>----- Original Message ----
From: Jeremiah
Subject: Re: [SDL] Rotation API
Sam Lantinga wrote:
This has come up several times and each time the real pain is the
software rendering. If someone is willing to step up and provide a
software implementation, I’m open to adding it.My preference would be something like:
SDL_RenderCopyRotated(SDL_texture *texture, const SDL_Rect *srcrect,
const SDL_Rect * dstrect, int angle);
I think that, only because of the software implementation, this is a bad idea.
Rotation in the software implementation will be pretty slow. Even on modern hardware, rotation of a single texture in software would probably be noticable.
It isn’t uncommon for textures to be rotated, but it is uncommon for this angle of rotation to change for every frame (unless for some sort of “spinning” animation). I think it’d be better to rotate on demand, cache the rotated texture (in the case of the software backend), and then render the rotated texture when SDL_RenderCopy is called.
If it weren’t for the software implementation, I’d prefer what you’re suggesting. It really does make more sense for the accelerated renderers.
Cached rotations aren’t of much use for floating point angles. Integer
angles are not very useful (especially for large textures) unless the angle
is measured in a strange, small unit.
Jonny DOn Sun, Feb 28, 2010 at 12:25 PM, nfries88 wrote:
Sam Lantinga wrote:
This has come up several times and each time the real pain is the
software rendering. If someone is willing to step up and provide a
software implementation, I’m open to adding it.My preference would be something like:
SDL_RenderCopyRotated(SDL_texture *texture, const SDL_Rect *srcrect,
const SDL_Rect * dstrect, int angle);I think that, only because of the software implementation, this is a bad
idea.
Rotation in the software implementation will be pretty slow. Even on modern
hardware, rotation of a single texture in software would probably be
noticable.
It isn’t uncommon for textures to be rotated, but it is uncommon for this
angle of rotation to change for every frame (unless for some sort of
"spinning" animation). I think it’d be better to rotate on demand, cache the
rotated texture (in the case of the software backend), and then render the
rotated texture when SDL_RenderCopy is called.If it weren’t for the software implementation, I’d prefer what you’re
suggesting. It really does make more sense for the accelerated renderers.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Jonny D wrote:
Cached rotations aren’t of much use for floating point angles. ?Integer angles are not very useful (especially for large textures) unless the angle is measured in a strange, small unit.
Jonny D
Elaborate on why cached rotations arent of much use for floating point angles?
Because there are basically an infinite number of different rotations available, and you’re not likely to hit the same angle repeatedly.________________________________
From: nfries88
Subject: Re: [SDL] Rotation APIElaborate on why cached rotations arent of much use for floating point angles?
I second this notion, and I think if the SDL community is going to
continue to try and straddle the chasm between low-end hardware and
modern hardware, a new approach to a rendering API is needed.
I am not proposing that this rendering API be a part of SDL proper,
but it will need SDL’s support to be able to dynamically evaluate its
own rendering costs.
It could be, but it’s not necessary, as long as programs have a way of
ascertaining the cost of raster image transformations.
As Hardcoder noted: the presence of a cache between the source canvas
and the destination canvas should be dynamic, but I don’t think it
correlates so cleanly between whether or not the transformations are
fast. For instance if a sprite changes its transformation parameters
every time it is drawn, it is more costly to require an intervening
buffer and potentially an extra copy operation.
So basically what one would need is an API that allows one to express
composable graphics primitives starting with explicit raster images
(as opposed to automatic/dynamic cache raster images) through graphics
operations (like transformations or compositions; this is where
automatic/dynamic caches live) and finally to their destination
(another explicit raster image, like the framebuffer.) Then for any
application and platform, you would have to tweak some heuristics to
define an effective trade-off between cache overhead penalty and cache
reuse bonus.
Again, I’m not saying this needs to be a part of SDL, but I think the
discussion needs to be in this direction so that we can understand
exactly what SDL needs to make available for this sort of system to be
implemented on top of it.
For some graphics back-ends, it would probably be enough just to time
blitting and image manipulation operations, but many just won’t work
that way, so we’re probably better off with SDL exposing information
about acceleration to the application. I would add to that also though
that the user should be able to override this information.On Thu, Feb 25, 2010 at 7:36 AM, hardcoder wrote:
Sam Lantinga wrote:
This has come up several times and each time the real pain is the
software rendering. If someone is willing to step up and provide a
software implementation, I’m open to adding it.My preference would be something like:
SDL_RenderCopyRotated(SDL_texture *texture, const SDL_Rect *srcrect,
const SDL_Rect * dstrect, int angle);Whoever would implement the software side of this would probably have
to look at src/video/sdlgenblit.pl and add code to output rotating
versions of all those blitters.I don’t think this is the right way to go. When using hardware
backend like D3D or OGL rotation (or scaling) may be considered
a part of “blit” operation and is a no-cost thing.On the other hand for software rendering it is the complete opposite
and should not be encouraged on per-frame (or per-redraw / damaged
rect) basis. That said, scaling and rotation operations should be used
during the “blit” ONLY when using hw renderer. When using software
mode, we are back to surfaces and all costly operations like scaling
or rotation should be done at most once per many blits and ideally
only once at load time.Therefore I propose adding a field to SDL_RendererInfo structure to
query renderer scaling/rotation capabilities.
I second this notion, and I think if the SDL community is going to
continue to try and straddle the chasm between low-end hardware and
modern hardware, a new approach to a rendering API is needed.
Better question: what sort of hypothetical low-end hardware are we
even talking about anyway? How many years do we have to go back
in time until it was even possible to buy a new PC, (desktop or laptop)
that didn’t have hardware-accelerated 3D rendering with either D3D
or OpenGL or both?
The iPhone and the Palm Pre are probably the lowest-end general-
purpose computing platforms around these days, and both have OGL
support. Game consoles, including handhelds (NDS, PSP) have
hardware-accelerated 3D. Not sure if it’s OGL or something else,
but the capability’s there. What modern platform could anyone
possibly want to write an SDL game for that doesn’t have it?
If SDL 1.3 is supposed to be looking forward to the future and
dropping old, outdated stuff that nobody’s using anymore,
(CDROM audio, for example,) why not forget about bending over
backwards to support hypothetical platforms with no video
acceleration?
I’m not saying take out the software renderer entirely. It can be
useful for operations that don’t have to be done in realtime. But
we shouldn’t let performance worries with software rendering
hold SDL back for those of us who need more complicated things
for actual real-world scenarios.>----- Original Message ----
From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rotation API
You don’t need to go back in time at all, you just need to download the
latest version of qemu.On 3/1/2010 14:41, Mason Wheeler wrote:
Better question: what sort of hypothetical low-end hardware are we
even talking about anyway? How many years do we have to go back
in time until it was even possible to buy a new PC, (desktop or laptop)
that didn’t have hardware-accelerated 3D rendering with either D3D
or OpenGL or both?
–
Rainer Deyke - rainerd at eldwood.com
Better question: what sort of hypothetical low-end hardware are we
even talking about anyway? How many years do we have to go back
in time until it was even possible to buy a new PC, (desktop or laptop)
that didn’t have hardware-accelerated 3D rendering with either D3D
or OpenGL or both?You don’t need to go back in time at all, you just need to download the
latest version of qemu.
- That’s an emulator, not a real computer, and nobody writes software
with an emulator as their target platform. - According to Wikipedia: Graphics card (Cirrus CLGD 5446 PCI
VGA-card or standard-VGA-Graphics card with Bochs-VESA-BIOS-Extensions
- Hardware
level, including all non-standard modes, and with an experimental
patch
simple 3D via OpenGL)
So apparently even Qemu has some sort of OpenGL support.>----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] Rotation API
On 3/1/2010 14:41, Mason Wheeler wrote:
What about stripping out the software rendering to an addon library
like SDL-image?
Erik
** Sent from my iPhone so pls excuse any typos **On 2010-03-01, at 3:05 PM, Mason Wheeler wrote:
----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] Rotation APIOn 3/1/2010 14:41, Mason Wheeler wrote:
Better question: what sort of hypothetical low-end hardware are we
even talking about anyway? How many years do we have to go back
in time until it was even possible to buy a new PC, (desktop or
laptop)
that didn’t have hardware-accelerated 3D rendering with either D3D
or OpenGL or both?You don’t need to go back in time at all, you just need to download
the
latest version of qemu.
- That’s an emulator, not a real computer, and nobody writes
software
with an emulator as their target platform.- According to Wikipedia: Graphics card (Cirrus CLGD 5446 PCI
VGA-card or standard-VGA-Graphics card with Bochs-VESA-BIOS-Extensions
- Hardware
level, including all non-standard modes, and with an experimental
patch
simple 3D via OpenGL)So apparently even Qemu has some sort of OpenGL support.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
You don’t need to go back in time at all, you just need to download the
latest version of qemu.
- That’s an emulator, not a real computer, and nobody writes software
with an emulator as their target platform.
Maybe not, but I develop and test on an emulator, so running on an
emulator is important to me.
- According to Wikipedia: Graphics card (Cirrus CLGD 5446 PCI
VGA-card or standard-VGA-Graphics card with Bochs-VESA-BIOS-Extensions
- Hardware
level, including all non-standard modes, and with an experimental
patch
simple 3D via OpenGL)
I stand corrected, although “experimental patch” doesn’t exactly inspire
confidence.
Really, the problem isn’t computers without 3D hardware. The problem is
broken drivers, missing drivers, outdated drivers, graphics cards that
aren’t supported at all by a given OS, and graphics cards that don’t
support the right version of the right graphics API.
(That said, I don’t really care about the SDL 2D graphics API. Give me
OpenGL or give me a simple framebuffer.)On 3/1/2010 15:05, Mason Wheeler wrote:
From: Rainer Deyke
Subject: Re: [SDL] Rotation API
–
Rainer Deyke - rainerd at eldwood.com
I think the primary goal of software fallback software implementations
of graphics operations is compatibility between platforms – your
program should behave the same on platforms with or without hardware
accelerated rotozoom, for instance. I don’t think an optional DLL/DSO
does a lot to help that… although maybe using an software
implementation of OpenGL would solve all of our problems, and I
wouldn’t want that to be non-optional.On Mon, Mar 1, 2010 at 5:10 PM, Erik Yuzwa wrote:
What about stripping out the software rendering to an addon library like
SDL-image?
although maybe using an software implementation of
OpenGL would solve all of our problems, and I wouldn’t
want that to be non-optional.
I could not possibly fail to disagree with you less! ;-)>----- Original Message ----
From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rotation API
although maybe using an software implementation of
OpenGL would solve all of our problems, and I wouldn’t
want that to be non-optional.I could not possibly fail to disagree with you less!
Is that like a triple negative?On Mon, Mar 1, 2010 at 5:58 PM, Mason Wheeler wrote:
----- Original Message ----
From: Donny Viszneki <@Donny_Viszneki>
Subject: Re: [SDL] Rotation API
although maybe using an software implementation of
OpenGL would solve all of our problems, and I wouldn’t
want that to be non-optional.I could not possibly fail to disagree with you less!
Is that like a triple negative?
Quadruple, actually.>----- Original Message ----
From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rotation API
On Mon, Mar 1, 2010 at 5:58 PM, Mason Wheeler <@Mason_Wheeler> wrote:----- Original Message ----
From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rotation API
Rainer Deyke wrote:
You don’t need to go back in time at all, you just need to download the
latest version of qemu.
Lets be reasonable here… You would rather drop HW support on target platform in favor of emulator? Doesn’t really sound serious. And I don’t quite get your point: if you need consistent behavior on different renderers and one of them doesn’t support rotation (SW one) then simply don’t use it. For many coders like me - that develop for platforms that are actually used (PC / MAC / iPhone / iPad / Android) it is important to have a good tool that utilizes available resources and HW graphics (and we talk most basic usage here) is simply there for us all.
Rainer Deyke wrote:
Really, the problem isn’t computers without 3D hardware. The problem is
broken drivers, missing drivers, outdated drivers, graphics cards that
aren’t supported at all by a given OS, and graphics cards that don’t
support the right version of the right graphics API.(That said, I don’t really care about the SDL 2D graphics API. Give me
OpenGL or give me a simple framebuffer.)
No, it is not the problem. We do not discuss Direct3D 10, OpenGL 3.2 or Shader Model 5 here. We talk about rotation which is as basic as scaling or even doing a quad for rendering itself. Drivers are not a problem. It is OpenGL 1.0 feature which I believe my kitchen sink implements.