GSoC project idea

SDL Development
1

Sanya_M wrote:

Optimization. OpenGl and d3d renderers can be faster if they would use hardware vertex buffers/VBOs where possible. It will significantly increase performance when rendering huge count of small sprites. Also batching of draw calls instead of calling glBegin-glEnd/DrawUserPrimitive for every sprite would be a big performance improvement. These optimizations can even double rendering speed in some cases.

Can you do this without changing the API?

Sanya M wrote:

Rendering of arbitrary triangles/rotated sprites. I know, there was a discussion about it. But I can’t see why not add two functions, without removing or changing anything that exists now. Even if these functions wouldn’t be supported by software renderer or will work slow. In particular, lack of sprite rotation support stops me from using these renderers in my projects, and forces to reinvent the wheel by myself.

If you feel you can implement it effectively in software, then more power to you.

Render to texture. It isn’t used as frequently as rotated sprites, but it also is a very useful feature, which isn’t so hard to implement.

Already possible with streaming textures and use of SDL1.2 blitting APIs; but I assume you’re talking along the lines of FBOs here (texture->texture; not (surface->surface)->texture?

Anyway, I personally would like to see these in SDL1.3; but I’m sure there’s plenty of reasons why not to add them either.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

2

Batching draw calls shouldn’t be too difficult. You just need a queue. Each
call to SDL_Render* pushes an item on to the queue instead of drawing anything.
Then when you call SDL_RenderPresent it iterates over the queue and performs all
the drawing at once.________________________________
From: nfries88@yahoo.com (Nathaniel J Fries)
Subject: Re: [SDL] GSoC project idea

Sanya_M wrote:
Optimization. OpenGl and d3d renderers can be faster if they would use hardware
vertex buffers/VBOs where possible. It will significantly increase performance
when rendering huge count of small sprites. Also batching of draw calls instead
of calling glBegin-glEnd/DrawUserPrimitive for every sprite would be a big
performance improvement. These optimizations can even double rendering speed in
some cases.

Can you do this without changing the API?

3

You can pre-rotate surfaces in 1.3 using the current SDL_gfx. I am also
planning to update SDL_gfx at some point to provide the same API as the
current version (when it makes sense at least) but use 3D hardware
acceleration whenever possible … i.e. a line is simply a rect with a
single pixel texture. But since I am super busy finishing up some
studies, it will probably be a while until I get around to code this.On 3/22/11 4:06 PM, Nathaniel J Fries wrote:

Sanya M wrote:

Rendering of arbitrary triangles/rotated sprites. I know, there was a
discussion about it. But I can’t see why not add two functions,
without removing or changing anything that exists now. Even if these
functions wouldn’t be supported by software renderer or will work
slow. In particular, lack of sprite rotation support stops me from
using these renderers in my projects, and forces to reinvent the wheel
by myself.

If you feel you can implement it effectively in software, then more
power to you.

4

Andreas Schiffler wrote:> On 3/22/11 4:06 PM, Nathaniel J Fries wrote:

Sanya M wrote:

Rendering of arbitrary triangles/rotated sprites. I know, there was a discussion about it. But I can’t see why not add two functions, without removing or changing anything that exists now. Even if these functions wouldn’t be supported by software renderer or will work slow. In particular, lack of sprite rotation support stops me from using these renderers in my projects, and forces to reinvent the wheel by myself.

If you feel you can implement it effectively in software, then more power to you.

You can pre-rotate surfaces in 1.3 using the current SDL_gfx. I am also planning to update SDL_gfx at some point to provide the same API as the current version (when it makes sense at least) but use 3D hardware acceleration whenever possible … i.e. a line is simply a rect with a single pixel texture. But since I am super busy finishing up some studies, it will probably be a while until I get around to code this.

You’d probably make an excellent mentor for Sanya on this one.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

5

Nathaniel J Fries wrote:

Can you do this without changing the API?

Yes. This can be done with changing only internal code of the renderer.

Nathaniel J Fries wrote:

Already possible with streaming textures and use of SDL1.2 blitting APIs; but I assume you’re talking along the lines of FBOs here (texture->texture; not (surface->surface)->texture?

Yes. I think it will be faster and also easier to use than current implementation.

About rotating sprites in software:
I don’t know for which reasons people here love software renderer so much. And I don’t know if these people need rotated sprites.
But if all features of hardware-accellerated renderers must be supported in software renderer, I can implement it. But it wouldn’t work fast.

6

Andreas Schiffler wrote:

I am also planning to update SDL_gfx at some point to provide the same API as the current version (when it makes sense at least) but use 3D hardware acceleration whenever possible …

That would be so much appreciated!

7

deepak aggarwal wrote:

Hi Sam
I am working on game networking engine using sdl_net can I work on it as a Gsoc project.
Here’s the link of my initial work.
http://cid-6618ad5bacf34230.office.live.com/self.aspx/.Public/server.tar.gz (http://cid-6618ad5bacf34230.office.live.com/self.aspx/.Public/server.tar.gz)

Obviously I can’t speak for Sam, but generally the point of GSoC is for a CS student to hack a piece of open-source software to add desired features; not to create a piece of software using open-source software.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

8

Application submission period begins soon.

So I would like to know, should I submit this as a project proposal or should I forget about it. Or, maybe, i must just change something.

I will describe more details, hope, it will help decide.

  1. Rendering of arbitrary textured triangles, at least for hardware-accellerated renderers
    Rotated and non-rotated sprites (for hardware renderers) can be done through it. And can’t be done other way :slight_smile:
    Software renderer can just ignore this, and render only old good axis-aligned rectangles. There’s no reasons to remove support for them.
    I’ve seen that triangle rasterization in software can be done at acceptable speed (http://irrlicht.sourceforge.net/, “Burning’s video” renderer in Irrlicht), but I think no one will use it, because now every platform has opengl support.

  2. Vertex buffers and batching
    These optimizations significantly improve speed. Always. And they can be done without making any changes to current api.

  3. Render to textures/render targets
    It looks like streaming textures can’t be done without transferring data between video and system memory. If this is true, rendering to texture will be far faster. There can be some problems with implementing it in opengl (in direct3d it is simple and straightforward), but I think, summer is enough to solve them.

Why are these features needed?
Take a look at http://hge.relishgames.com/. This engine became a standard for 2d games for windows. At it’s core, it has exactly these features.
I frequently participate in game development contests. SDL has everything I need, except good graphics. So I must use another library or, practically, rewrite SDL’s renderer outside SDL just to add few functions.
With these features, SDL will become a complete library for 2d game development. Nothing else would be needed.

Why they must be in SDL’s core, not as a separate library?
Because SDL already contains renderers. Doing this in a separate library will require writing much more code, and this code will be a clone of current renderer’s code.

9

Application submission period begins soon.

So I would like to know, should I submit this as a project proposal or should I

forget about it. Or, maybe, i must just change something.

I will describe more details, hope, it will help decide.

  1. Rendering of arbitrary textured triangles, at least for hardware-accellerated

renderers
Rotated and non-rotated sprites (for hardware renderers) can be done through it.

And can’t be done other way

I think an actual rotation API would be more useful for rotated sprites than a
"arbitrary
triangles" API.

  1. Vertex buffers and batching
    These optimizations significantly improve speed. Always. And they can be done
    without making any changes to current api.

Yes, that would definitely be useful.

  1. Render to textures/render targets
    It looks like streaming textures can’t be done without transferring data between

video and system memory. If this is true, rendering to texture will be far
faster. There can be some problems with implementing it in opengl (in direct3d
it is simple and straightforward), but I think, summer is enough to solve them.

Really? I’ve already submitted an OpenGL version and it only took a few hours;
to write, including research. What seems to be holding things up is getting it
implemented in Direct3D. :stuck_out_tongue:

Why are these features needed?
Take a look at http://hge.relishgames.com/. This engine became a standard for 2d

games for windows. At it’s core, it has exactly these features.
I frequently participate in game development contests. SDL has everything I
need, except good graphics. So I must use another library or, practically,
rewrite SDL’s renderer outside SDL just to add few functions.
With these features, SDL will become a complete library for 2d game development.

Nothing else would be needed.

Agreed.

Why they must be in SDL’s core, not as a separate library?
Because SDL already contains renderers. Doing this in a separate library will
require writing much more code, and this code will be a clone of current
renderer’s code.

Also agreed.>From: Sanya_M <mezin.alexander at gmail.com>

Subject: Re: [SDL] GSoC project idea

10

Mason Wheeler wrote:

I think an actual rotation API would be more useful for rotated sprites than a
"arbitrary
triangles" API.

I think the best solution is “arbitrary triangles” with helper functions.
It gives you possibility to use some interesting effects like water and lens.
Box2D physics engine returns object’s rotation as 2x2 matrix. It is better to transform corners of the quad using Box2D’s math classes, rather than extracting rotation center and angle from the matrix and doing unnecessary math inside the drawing function again.
I think if something can be written in generic way, it must be written this way. With useful helper functions, if needed.

Really? I’ve already submitted an OpenGL version and it only took a few hours;
to write, including research. What seems to be holding things up is getting it
implemented in Direct3D. :stuck_out_tongue:

I wrote this just because I didn’t implement render to texture in OpenGl before.

11

Go ahead and submit this as a project proposal. Please include your
qualifications, availability, implementation plan, API thoughts, and
post-GSoC plans.

Thanks!On Sat, Mar 26, 2011 at 7:56 AM, Sanya_M <mezin.alexander at gmail.com> wrote:

Application submission period begins soon.

So I would like to know, should I submit this as a project proposal or
should I forget about it. Or, maybe, i must just change something.

I will describe more details, hope, it will help decide.

  1. Rendering of arbitrary textured triangles, at least for
    hardware-accellerated renderers
    Rotated and non-rotated sprites (for hardware renderers) can be done
    through it. And can’t be done other way [image: Smile]
    Software renderer can just ignore this, and render only old good
    axis-aligned rectangles. There’s no reasons to remove support for them.
    I’ve seen that triangle rasterization in software can be done at acceptable
    speed (http://irrlicht.sourceforge.net/, “Burning’s video” renderer in
    Irrlicht), but I think no one will use it, because now every platform has
    opengl support.

  2. Vertex buffers and batching
    These optimizations significantly improve speed. Always. And they can be
    done without making any changes to current api.

  3. Render to textures/render targets
    It looks like streaming textures can’t be done without transferring data
    between video and system memory. If this is true, rendering to texture will
    be far faster. There can be some problems with implementing it in opengl (in
    direct3d it is simple and straightforward), but I think, summer is enough to
    solve them.

Why are these features needed?
Take a look at http://hge.relishgames.com/. This engine became a standard
for 2d games for windows. At it’s core, it has exactly these features.
I frequently participate in game development contests. SDL has everything I
need, except good graphics. So I must use another library or, practically,
rewrite SDL’s renderer outside SDL just to add few functions.
With these features, SDL will become a complete library for 2d game
development. Nothing else would be needed.

Why they must be in SDL’s core, not as a separate library?
Because SDL already contains renderers. Doing this in a separate library
will require writing much more code, and this code will be a clone of
current renderer’s code.

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

12

Whether to do rotation or vertex-based rendering is a tricky subject.

What position will the image be rotated around? What about flipping (which can’t be accomplished with rotation)? We could add these sorts of options to function calls, but then we get huge function definitions like XNA’s SpriteBatch.Draw; which doesn’t seem desirable.

However, a vertex-based API requires the programmer to do all this crazy calculation himself, which many 2D programmers aren’t really willing to do (3D programmers consider it second nature, I’d bet).

My recommendation is to do everything: RenderCopy (keep the current API), RenderCopyRotateAround (add a float for angle and an SDL_Point or two ints for position), RenderCopyFlip (add an int for which axis to flip), and RenderCopyFull (combine RenderCopyRotateAround and RenderCopyFlip); and of course RenderCopyVertex which takes 4 SDL_Points instead of dstrect (maybe do this for srcrect too?).------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

13

How is scaling done? Often, a negative scaling factor represents a flip.

Jonny DOn Fri, Apr 1, 2011 at 7:44 PM, Nathaniel J Fries wrote:

Whether to do rotation or vertex-based rendering is a tricky subject.

What position will the image be rotated around? What about flipping (which
can’t be accomplished with rotation)? We could add these sorts of options to
function calls, but then we get huge function definitions like XNA’s
SpriteBatch.Draw; which doesn’t seem desirable.

However, a vertex-based API requires the programmer to do all this crazy
calculation himself, which many 2D programmers aren’t really willing to do
(3D programmers consider it second nature, I’d bet).

My recommendation is to do everything: RenderCopy (keep the current API),
RenderCopyRotateAround (add a float for angle and an SDL_Point or two ints
for position), RenderCopyFlip (add an int for which axis to flip), and
RenderCopyFull (combine RenderCopyRotateAround and RenderCopyFlip); and of
course RenderCopyVertex which takes 4 SDL_Points instead of dstrect (maybe
do this for srcrect too?).

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

14

Negative scaling = flipping is a fun topic, but honestly, in the rule of
"least surprises" that probably shouldn’t be how it is done. That’s because
it flips along the basis vectors of the image – wherever you define those
to be. If you said “bottom left pointing up and right” (which is how OpenGL
generally does it), then scaling by negative factor, say, { -1, 1 } would
flip along the Y axis, but the image wouldn’t be where you expected it to be
(would be IMAGE_SIZE pixels left of where you expect. That’s a natural
result of using 4 points to define the boundaries of the image, e.g. the
points (0,0), (x,0), (0,y), (x,y) would become (0,0), (-x,0), (0,y), (-x,
y).

I doubt we are going to reach a very good consensus on the API. There are a
lot of different ways to draw a sprite based on 3 factors: translation,
rotation, scaling. These are represented by 3x3 matrices in 2D, and you can
combine them in many ways which produce different results. The API would
need to clearly define the order in which they are applied, how to omit ones
if they aren’t necessary (e.g. “I just want to flip my image but not move
it”), and how to provide better control for those who might need it (e.g.
rototating around a point from an arbitrary distance represents a less than
standard use of rotate + translate).

How about instead of throwing out random function calls, we consider use
cases and design a single API that can be used easily by programmers of
varying levels of mathematics experience and implemented efficiently to
fulfill those cases?

PatrickOn Fri, Apr 1, 2011 at 7:41 PM, Jonathan Dearborn wrote:

How is scaling done? Often, a negative scaling factor represents a flip.

Jonny D

15

Well, the natural sprite pivot (image center) is good for both
rotation and scaling. Negative scaling factors are how you flip with
matrices too. I don’t really mind how the API turns out, as long as
scaling, rotation, and flipping are there and the pivot can be chosen
(or, equivalently, there’s translation). There are many examples of
popular 2D APIs out there that serve as good models.

Jonny DOn Sat, Apr 2, 2011 at 8:31 PM, Patrick Baggett <baggett.patrick at gmail.com> wrote:

Negative scaling = flipping is a fun topic, but honestly, in the rule of
"least surprises" that probably shouldn’t be how it is done. That’s because
it flips along the basis vectors of the image – wherever you define those
to be. If you said “bottom left pointing up and right” (which is how OpenGL
generally does it), then scaling by negative factor, say, { -1, 1 } would
flip along the Y axis, but the image wouldn’t be where you expected it to be
(would be IMAGE_SIZE pixels left of where you expect.?That’s a natural
result of using 4 points to define the boundaries of the image, e.g. the
points (0,0), (x,0), (0,y), (x,y) would become (0,0), (-x,0), (0,y), (-x,
y).
I doubt we are going to reach a very good consensus on the API. There are a
lot of different ways to draw a sprite based on 3 factors: translation,
rotation, scaling. These are represented by 3x3 matrices in 2D, and you can
combine them in many ways which produce different results. The API would
need to clearly define the order in which they are applied, how to omit ones
if they aren’t necessary (e.g. “I just want to flip my image but not move
it”), and how to provide better control for those who might need it (e.g.
rototating around a point from an arbitrary distance represents a less than
standard use of rotate + translate).
How about instead of throwing out random function calls, we consider use
cases and design a single API that can be used easily by programmers of
varying levels of mathematics experience and implemented efficiently to
fulfill those cases?
Patrick

On Fri, Apr 1, 2011 at 7:41 PM, Jonathan Dearborn <@Jonathan_Dearborn> wrote:

How is scaling done? ?Often, a negative scaling factor represents a flip.

Jonny D

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

16

Nathaniel J Fries wrote:

My recommendation is to do everything: RenderCopy (keep the current API), RenderCopyRotateAround (add a float for angle and an SDL_Point or two ints for position), RenderCopyFlip (add an int for which axis to flip), and RenderCopyFull (combine RenderCopyRotateAround and RenderCopyFlip); and of course RenderCopyVertex which takes 4 SDL_Points instead of dstrect (maybe do this for srcrect too?).

I thought exactly about such API, maybe I didn’t said it clearly enough.

But I think flip should be specified by additional parameter. Maybe it will be a bitfield with possible flags “flip horizontal”, “flip vertical”, “rotate 90 cw”. “rotate 180” can be done through combining “flip horizontal” and “flip vertical”. And “rotate 90 ccw” is combination of all these flags.
It can be added to all rendering functions as the last parameter. Passing additional zero shouldn’t be too hard, but this way we can get rid of functions like “RenderCopyFull (combine RenderCopyRotateAround and RenderCopyFlip)”.

Also, flip and 90 degree rotation can be done easily in software too.

17

Sanya_M wrote:

Nathaniel J Fries wrote:

My recommendation is to do everything: RenderCopy (keep the current API), RenderCopyRotateAround (add a float for angle and an SDL_Point or two ints for position), RenderCopyFlip (add an int for which axis to flip), and RenderCopyFull (combine RenderCopyRotateAround and RenderCopyFlip); and of course RenderCopyVertex which takes 4 SDL_Points instead of dstrect (maybe do this for srcrect too?).

It can be added to all rendering functions as the last parameter. Passing additional zero shouldn’t be too hard, but this way we can get rid of functions like “RenderCopyFull (combine RenderCopyRotateAround and RenderCopyFlip)”.

Also, flip and 90 degree rotation can be done easily in software too.

except, it is very rare that games requiring rotation to begin with only require rotation by multiples of 90 degrees. What if I’m making a top-down shooter with a medieval theme where you aim with your mouse? Rotation by 90 degrees doesn’t help me here.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

18

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.On 4/10/2011 18:36, Nathaniel J Fries wrote:

except, it is very rare that games requiring rotation to begin with
only require rotation by multiples of 90 degrees.

–
Rainer Deyke - rainerd at eldwood.com

19

Rainer Deyke wrote:> On 4/10/2011 18:36, Nathaniel J Fries wrote:

except, it is very rare that games requiring rotation to begin with
only require rotation by multiples of 90 degrees.

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.

–
Rainer Deyke - rainerd at eldwood.com

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

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). 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.

The fact that those cases will perform better and be pixel-perfect doesn’t mean to exclude other cases. Just catch these special cases and use the optimized method.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

20

Exactly. Pre-rotation is just not an option for serious needs. We need a
rotation API that can handle at least 1-degree precision, if not smaller.
Period.________________________________
From: nfries88@yahoo.com (Nathaniel J Fries)
Subject: Re: [SDL] GSoC project idea

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). 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.

The fact that those cases will perform better and be pixel-perfect doesn’t mean
to exclude other cases. Just catch these special cases and use the optimized
method.