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 ?
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?
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.
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 at yahoo.com> 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?
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.
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.>From: Kenneth Bull
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.
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.
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 DOn Wed, Nov 4, 2009 at 5:37 PM, Mason Wheeler wrote:
From: Kenneth Bull
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.
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 at yahoo.com> 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 ?
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.