GSoC project idea

SDL Development
21

Rainer Deyke wrote:

I disagree that it’s rare. There are tons of applications for
rotation in 90 degree increments. For example: - Symmetric window
borders. - Tile maps with rotated tiles. - Pac-man-style games.
It’s obviously not a substitute for rotation by smaller increments,
but it doesn’t have to be. And unlike rotation by smaller
increments, it’s pixel perfect, so it can be safely used even in
games that try to avoid ugly rendering artifacts.

Except all of those games could do it in whatever image editing
program they use with only a 4:1 overhead (likely less with
compressed image formats).

Using four times as much memory as necessary is not, generally speaking,
acceptable. Wasting time in the image editor creating rotated images
each time you edit an image is even less acceptable.

For the type of game I recommended, doing
variants of every 1 degree and taking advantage of 90-degree rotation
would be a 89:1 overhead, or an 18:1 overhead if it’s every 5
degrees, 9:1 overhead for every 10 degrees, etc. Even then, for a 2D
PC game that’d be fine nowadays… but what about Android, iOS,
WebOS, Maemo, etc? That’d be crazy.

Like I said before, rotation in 90 degree increments is not a substitute
for rotation in smaller increments. Games that need smaller increments
would need to use OpenGL directly, just like before.

If you want to argue that SDL should have a generalized rotation API,
then make that argument, but don’t phrase it as an argument against
rotation in 90 degree increments. Rotation in 90 degree increments is
still an improvement over the status quo, even if it doesn’t solve your
particular problem.On 4/11/2011 13:41, Nathaniel J Fries wrote:

–
Rainer Deyke - rainerd at eldwood.com

22

Rainer Deyke wrote:

Except all of those games could do it in whatever image editing
program they use with only a 4:1 overhead (likely less with
compressed image formats).

Using four times as much memory as necessary is not, generally speaking,
acceptable. Wasting time in the image editor creating rotated images
each time you edit an image is even less acceptable.

Unfavorable, sure. Unacceptable? If you used SDL_gfx before, you were already doing it.

For the type of game I recommended, doing
variants of every 1 degree and taking advantage of 90-degree rotation
would be a 89:1 overhead, or an 18:1 overhead if it’s every 5
degrees, 9:1 overhead for every 10 degrees, etc. Even then, for a 2D
PC game that’d be fine nowadays… but what about Android, iOS,
WebOS, Maemo, etc? That’d be crazy.

Like I said before, rotation in 90 degree increments is not a substitute
for rotation in smaller increments. Games that need smaller increments
would need to use OpenGL directly, just like before.

If you want to argue that SDL should have a generalized rotation API,
then make that argument, but don’t phrase it as an argument against
rotation in 90 degree increments. Rotation in 90 degree increments is
still an improvement over the status quo, even if it doesn’t solve your
particular problem.

I’m not arguing that it wouldn’t be an improvement, only that it is not the ideal solution.

The ideal solution would be to let the programmer using SDL make the decisions. Sure, many people using SDL are novices. At the same time, when they suddenly drop to half the framerate that they normally get after adding rotation, one would hope they’d check the documentation. So merely document that it may have a notable performance impact when used on the software backend.

On systems supporting any hardware-accelerated rendering, SDL supports it. The default backend chosen will be a hardware accelerated one if any are available.
This means that if the programmer chooses to use the software backend, he does so purposefully and presumably with knowledge that it should not be expected to perform comparably to the hardware-accelerated ones. If the programmer delegates this choice to the user (I did this in a project using SDL 1.2 and an optional OpenGL render engine), the programmer should note that the user should not expect adequate performance ("(slow)" is not terribly difficult to add to a user interface).

Then there’s the quick’n’simple fact that the people who are arguing against addition of the feature:

  1. Are apparently not using it.
  2. Can simply continue doing so.
    However, the people who do want it (Wheeler and myself):
  3. Have already been using the third-party SDL_gfx to do it in advance, presumably.
  4. Want to have it available as part of the API for notable performance gains over SDL_gfx on hardware-accelerated backends
  5. and for notable simplification of our overall codebase (which is what SDL is all about, right?).
  6. and don’t care about performance on the software backend, because it’ll be the same as with SDL_gfx anyway.

As for your recommendation to do it myself in OpenGL; if I didn’t want a solid 2D rendering API already crafted for me, I would have an enormous number of options (SFML, GLUT, GLFW, ClanLib, Irrlicht, Ogre, etc). SDL’s simplicity of use by comparison to either Direct3D or OpenGL (and many of those alternatives) are why I use it, not for the portability (well, that IS a plus, but a plus that all of those alternatives have to some degree) or the ease of grabbing an OpenGL context.> On 4/11/2011 13:41, Nathaniel J Fries wrote:

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

23

I’m not arguing that it wouldn’t be an improvement, only that it is not the
ideal solution.

The ideal solution would be to let the programmer using SDL make the
decisions. Sure, many people using SDL are novices. At the same time, when
they suddenly drop to half the framerate that they normally get after adding
rotation, one would hope they’d check the documentation. So merely document
that it may have a notable performance impact when used on the software
backend.

On systems supporting any hardware-accelerated rendering, SDL supports it.
The default backend chosen will be a hardware accelerated one if any are
available.
This means that if the programmer chooses to use the software backend, he
does so purposefully and presumably with knowledge that it should not be
expected to perform comparably to the hardware-accelerated ones. If the
programmer delegates this choice to the user (I did this in a project using
SDL 1.2 and an optional OpenGL render engine), the programmer should note
that the user should not expect adequate performance ("(slow)" is not
terribly difficult to add to a user interface).

Then there’s the quick’n’simple fact that the people who are arguing
against addition of the feature:

  1. Are apparently not using it.
  2. Can simply continue doing so.
    However, the people who do want it (Wheeler and myself):
  3. Have already been using the third-party SDL_gfx to do it in advance,
    presumably.
  4. Want to have it available as part of the API for notable performance
    gains over SDL_gfx on hardware-accelerated backends
  5. and for notable simplification of our overall codebase (which is what
    SDL is all about, right?).
  6. and don’t care about performance on the software backend, because it’ll
    be the same as with SDL_gfx anyway.

As for your recommendation to do it myself in OpenGL; if I didn’t want a
solid 2D rendering API already crafted for me, I would have an enormous
number of options (SFML, GLUT, GLFW, ClanLib, Irrlicht, Ogre, etc). SDL’s
simplicity of use by comparison to either Direct3D or OpenGL (and many of
those alternatives) are why I use it, not for the portability (well, that IS
a plus, but a plus that all of those alternatives have to some degree) or
the ease of grabbing an OpenGL context.

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

This is just silly now.

We all know that OpenGL is capable of arbitrary rotations and that they’re
as fast as fixed 90 degree ones +/- flipping. Having arbitrary rotations
implies that 90-degree increments are supported as well, so it isn’t that
they are conflicting or otherwise incompatible feature requests. Clearly, if
SDL was OpenGL-only, there wouldn’t be any question, it would just be “the
way” – rather, there is no reason to limit what doesn’t need to be
limited, especially if it doesn’t have any effect. Okay, so the only reason
not to support it is that it may not be fast for some people who aren’t
using OpenGL + hw acceleration, i.e. software rendering.

Are we seriously concerned that software implementations would be slow? Did
anyone expect something different? After reading this and the “HD Games [in
software]” thread, I just don’t get it. Why is everyone so concerned with
software rendering (via SDL)? The practice as a whole has been deprecated in
favor of hardware accelerated APIs for over a decade in the gaming
industry…that’s lifetimes ago, games, game engines, companies have risen
and fallen since then – did they missed the whole DirectX 1 to 11? Dumb
framebuffer to unified shaders?

Whatever – ignoring that, arbitrary rotations in software a doable as well,
anyone with any experience writing software rasterizers know how to texture
map a eye-planar quad with arbitrary UV coords. It isn’t as fast as a
memcpy() or blit, no, but it shouldn’t cause the system to grind to a
screeching halt when the screen isn’t flooded with them. Easiest example,
the game Quake can be run in software mode at 1280x1024 (!) on processors
as old as single core AMD64 processors. That’s a hell of a lot of pixels
from about 15-30K polygons/frame, and it even does multichannel positional
audio mixing and runs a VM. All. In. Software. Single threaded. I think
we’ll do OK on the software renderer performance for real world usage. I’d
venture a guess that many of the 2D games that use it are far less complex
than game made even in 1998+ in both code and assets. Clearly if you’re
hitting 100% CPU core utilization in software mode and lagging like hell,
you probably need to consider switching to hardware-accelerated rendering or
better algorithm(s). Or, I don’t know, buy a graphics card.

Seriously, stop wasting time with these back and forth emails and start
writing out what you need, not what you don’t or concerns about the
performance of features that a) don’t exist yet and b) may or may not even
be used by you.

Patrick

24

I had a friend who I trust with low-level optimization stuff look at the SDL_rotozoom routine, and he says that in general there should be a significant performance gain by drawing straight to the framebuffer rather than creating and drawing to another surface, then drawing to the framebuffer. It makes logical sense to me, it’s basically performing two blits instead of one how it is presently.

I’ll try to make a proof of concept later on.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

25

I made a game once that needed fast scaling. One of the optimizations
I made over sdl_gfx was the one you mention, it greatly increased
performance.
Another thing that increased the performance by a bunch was mip
mapping because of its cache friendliness. The true hog in these
routines is memory access and the best way I learned to optimize them
is to organize and access data in cache friendly ways.On Friday, April 15, 2011, Nathaniel J Fries wrote:

I had a friend who I trust with low-level optimization stuff look at the SDL_rotozoom routine, and he says that in general there should be a significant performance gain by drawing straight to the framebuffer rather than creating and drawing to another surface, then drawing to the framebuffer. It makes logical sense to me, it’s basically performing two blits instead of one how it is presently.

I’ll try to make a proof of concept later on.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/