SDL 1.2 to 1.3 major slowdown

[dragos-9]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi everyone!

I am working on a project, using SDL 1.2 and image, ttf and mixer libraries. The project is under Visual C++ and there are a lot of blits involved, including per-pixel and per-surface alpha. I decided to give 1.3 a try, as I read the code retains compatibility with 1.2 headers. The compilation went ok, but I had to disable cursor changing functions, as they appear not to be supported by 1.3. Eventually the program started, but the frame rate drops from 40 FPS to 10-20, and some fonts which should be white have a strange tint around them. Is this normal or I am doing something wrong? I'm using the latest add-on libraries although I have not recompiled them with 1.3. Shouldn't legacy blitting functions be at least as performant in 1.3 as in 1.2 even when using software rendering ?

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

[Kenneth Bull]

2009/11/3 dragos <d_pusca@...>:
> Shouldn't legacy blitting functions be at least as performant in 1.3 as in
> 1.2 even when using software rendering ?

SDL 1.3 works quite different from SDL 1.2.  1.2 compatibility is
implemented through a layer on top of the 1.3 API.
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[dragos-9]

Some parts of this message have been removed. Learn more about Nabble's security policy.

So is there no way to make use of both the old and the 1.3 specific functions in a practical manner? This means that porting a complex application from 1.2 to 1.3 is very difficult, and I am better off continuing in 1.2. The application is pure 2D, tile-based map, but the lack of hardware acceleration for such cheap 2D graphics is annoying. I understand the equivalent of SDL_BlitSurface in 1.3 is SDL_RenderCopy, but is there a function to copy part of a texture to another texture, to simulate bliting 2D graphics from one surface to another?

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

[Kenneth Bull]

2009/11/4 dragos <d_pusca@...>:
> So is there no way to make use of both the old and the 1.3 specific
> functions in a practical manner? This means that porting a complex
> application from 1.2 to 1.3 is very difficult, and I am better off
> continuing in 1.2. The application is pure 2D, tile-based map, but the lack
> of hardware acceleration for such cheap 2D graphics is annoying. I
> understand the equivalent of SDL_BlitSurface in 1.3 is SDL_RenderCopy, but
> is there a function to copy part of a texture to another texture, to
> simulate bliting 2D graphics from one surface to another?

You would need a renderer that renders to a texture instead of a
window, which you can't do yet, or use OpenGL instead of the renderer
API (via SDL_GL_CreateContext).

Other than that, you can still use surfaces, then convert to textures
as necessary, but that probably wouldn't be very efficient.

Why would you need to blit between surfaces/textures anyway?  Double
buffering is handled by the renderer...

To be honest, I'm not really sure why Sam chose to create a separate
texture API instead of using hardware surfaces with locks (where
locking loads pixel data into user space and unlocking copies it back
to video memory).  The only real difference I can see is that textures
are accessed via a handle instead of a pointer to a data structure.
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Simon Roby]

Wild guess (I do not know the internals of 1.3 and have not started
using it extensively), but have you tried using software surfaces
only?

I know a common mistake people sometimes do with the 1.2 API is
thinking that hardware surfaces are automatically better than software
surfaces and use them everywhere, including places where it doesn't
make sense (ie. pixel manipulation, hardware-to-software blitting),
and can usually get away with it because the underlying 1.2 driver
used on their dev machine doesn't support hardware surfaces so they
were using software surfaces all along (because SDL automatically
fallbacks to it).

But again I may be completely wrong and this could not be relevant
with how the 1.2 compatibility layer of 1.3 works. (Could someone
confirm if anything I'm saying makes sense?)

On Wed, Nov 4, 2009 at 15:41, dragos <d_pusca@...> wrote:

> So is there no way to make use of both the old and the 1.3 specific
> functions in a practical manner? This means that porting a complex
> application from 1.2 to 1.3 is very difficult, and I am better off
> continuing in 1.2. The application is pure 2D, tile-based map, but the lack
> of hardware acceleration for such cheap 2D graphics is annoying. I
> understand the equivalent of SDL_BlitSurface in 1.3 is SDL_RenderCopy, but
> is there a function to copy part of a texture to another texture, to
> simulate bliting 2D graphics from one surface to another?
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>

--
--
- SR
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[dragos-9]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Kenneth Bull wrote:

Why would you need to blit between surfaces/textures anyway? Double
buffering is handled by the renderer...

For example you have a surface that holds the map view port area, on which you render the tiles. It is more convenient to hold it as a separate surface, in case you need to apply filters such as convert to gray scale, you apply the filter to the whole surface instead to a rectangle on the main screen. Also in the case of graphic interface controls, such as buttons with text. To render text with SDL_ttf functions each time the button is displayed is quite inefficient, it is better to render the text to a "buffer" surface, and redraw it with SDL_ttf only if the text is changed.

Simon Roby wrote:

Wild guess (I do not know the internals of 1.3 and have not started
using it extensively), but have you tried using software surfaces
only?

I don't know what happens in other builds and environments, but in my case (Win32, SDL 1.2.14) it doesn't matter which flags I use, all surfaces become automatically software. Even if I call SetVideoMode with HWSURFACE, the surface returned will be software.

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

[masonwheeler]

Some parts of this message have been removed. Learn more about Nabble's security policy.

>From: Kenneth Bull <llubnek@...>

>Subject: Re: [SDL] SDL 1.2 to 1.3 major slowdown
>
>Why would you need to blit between surfaces/textures anyway?  Double
>buffering is handled by the renderer...

For render targets to do compositing and intermediate image work on.
We've been over this one a few times on here.  It was possible in SDL 1.2
where everything was a surface, and it's very noticeably missing from the
Texture API.  I remember someone submitted a hackish patch to add
render target support for the GL renderer a few months ago, but nobody
ever mentioned it again.

Looks like yet another user is looking for them, so I'll get the ball rolling
again: Render targets are essential for any non-trivial 2D game, and
without them the API is deficient and unsuitable for real-world
development.

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

[dragos-9]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I think two additional functions will suffice from a 2D engine perspective and an easier upgrade from 1.2 to 1.3: a hardware accelerated copy from one texture to another (with clipping and alpha blending at a minimum, scaling and other operations could be a plus) and a Texture to Surface conversion, the opposite of the SDL_CreateTextureFromSurface function.

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

[Kenneth Bull]

2009/11/4 dragos <d_pusca@...>:
> I think two additional functions will suffice from a 2D engine perspective
> and an easier upgrade from 1.2 to 1.3: a hardware accelerated copy from one
> texture to another (with clipping and alpha blending at a minimum, scaling
> and other operations could be a plus) and a Texture to Surface conversion,
> the opposite of the SDL_CreateTextureFromSurface function.

You can use SDL_QueryTexturePixels or SDL_LockTexture to get the pixel
data of a texture, which can then be converted to a surface using
SDL_CreateRGBSurfaceFrom.

Render to texture makes a bit more sense to me then a copy function.
It's closer to how you would have to do it in OpenGL anyway and it
would be a lot more versatile.  You'd need to change
SDL_CreateRenderer, SDL_SelectRenderer and SDL_DestroyRenderer to use
an SDL_RendererID (or something like that) and add a
SDL_CreateRendererForTexture function though.  It may actually be less
work to do it this way than create a versatile texture to texture
blit, since blend mode, etc would be handled by the existing API.
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Jonathan Dearborn-2]

I don't remember if I chimed in last time render targets came up, but
I'm all for it too.  Lowest common denominator APIs do not work and
are a pain when you could just check for functionality at runtime.

Jonny D


On Wed, Nov 4, 2009 at 5:37 PM, Mason Wheeler <masonwheeler@...> wrote:

>>From: Kenneth Bull <llubnek@...>
>>Subject: Re: [SDL] SDL 1.2 to 1.3 major slowdown
>>
>>Why would you need to blit between surfaces/textures anyway?  Double
>>buffering is handled by the renderer...
>
> For render targets to do compositing and intermediate image work on.
> We've been over this one a few times on here.  It was possible in SDL 1.2
> where everything was a surface, and it's very noticeably missing from the
> Texture API.  I remember someone submitted a hackish patch to add
> render target support for the GL renderer a few months ago, but nobody
> ever mentioned it again.
>
> Looks like yet another user is looking for them, so I'll get the ball
> rolling
> again: Render targets are essential for any non-trivial 2D game, and
> without them the API is deficient and unsuitable for real-world
> development.
>
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>

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

[Sam Lantinga-4]

Can you post a link to a test case?  I've tried hard to make sure that
the SDL 1.2 compatibility goes through a code path with comparable
speed to the original 1.2 code.

On Tue, Nov 3, 2009 at 2:10 PM, dragos <d_pusca@...> wrote:

> Hi everyone!
>
> I am working on a project, using SDL 1.2 and image, ttf and mixer libraries.
> The project is under Visual C++ and there are a lot of blits involved,
> including per-pixel and per-surface alpha. I decided to give 1.3 a try, as I
> read the code retains compatibility with 1.2 headers. The compilation went
> ok, but I had to disable cursor changing functions, as they appear not to be
> supported by 1.3. Eventually the program started, but the frame rate drops
> from 40 FPS to 10-20, and some fonts which should be white have a strange
> tint around them. Is this normal or I am doing something wrong? I'm using
> the latest add-on libraries although I have not recompiled them with 1.3.
> Shouldn't legacy blitting functions be at least as performant in 1.3 as in
> 1.2 even when using software rendering ?
> _______________________________________________
> SDL mailing list
> SDL@...
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>

--
        -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
SDL@...
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[dragos-9]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Sam Lantinga wrote:

Can you post a link to a test case? I've tried hard to make sure that
the SDL 1.2 compatibility goes through a code path with comparable
speed to the original 1.2 code.

The code can be found on SVN at the project's home page http://sourceforge.net/projects/treasurefleet/

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