Hello,
This is for SDL 1.2 only.I’ve noticed an incredible difference of speed between fullscreen mode and windowed mode.Fullscreen mode is like 100 times faster than windowed mode for blits.
I’m running Mac OS 10.5
Any reason ?
Thanks
Hello !
This is for SDL 1.2 only.I’ve noticed an incredible
difference of speed between fullscreen mode and
windowed mode.Fullscreen mode is like 100 times
faster than windowed mode for blits.
I’m running Mac OS 10.5
As far as i know OSX is double buffering every
window on the desktop and also updating them only on VSYNC
to avoid tearing. But OSX does this only on the desktop,
not on fullscreen apps.
CU
Hello !
This is for SDL 1.2 only.I’ve noticed an incredible
difference of speed between fullscreen mode and
windowed mode.Fullscreen mode is like 100 times
faster than windowed mode for blits.
I’m running Mac OS 10.5As far as i know OSX is double buffering every
window on the desktop and also updating them only on VSYNC
to avoid tearing. But OSX does this only on the desktop,
not on fullscreen apps.
Try using OpenGL (with same bits per pixels than the desktop) with
SDL_OPENGLBLIT, that improved the speed a lot for our game (no
difference anymore between fullscreen and window).
- AlbertAm 01.05.2009 um 16:22 schrieb Torsten Giebl:
SDL_OPENGLBLIT simply doesn’t blit the information correctly. It is slow anddoesn’t refresh the screen properly.
— En date de?: Ven 1.5.09, Albert Zeyer <albert.zeyer at rwth-aachen.de> a ?crit?
Albert Zeyer <albert.zeyer at rwth-aachen.de>
Objet: Re: [SDL] Mac OS X speed
?: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Vendredi 1 Mai 2009, 16h28
Am 01.05.2009 um 16:22 schrieb Torsten Giebl:
Hello !
This is for SDL 1.2 only.I’ve noticed an incredible
difference of speed between fullscreen mode and
windowed mode.Fullscreen mode is like 100 times
faster than windowed mode for blits.
I’m running Mac OS 10.5As far as i know OSX is double buffering every
window on the desktop and also updating them only on VSYNC
to avoid tearing. But OSX does this only on the desktop,
not on fullscreen apps.
Try using OpenGL (with same bits per pixels than the desktop) with?
SDL_OPENGLBLIT, that improved the speed a lot for our game (no?
difference anymore between fullscreen and window).
- Albert
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_OPENGLBLIT simply doesn’t blit the information correctly. It is
slow and
doesn’t refresh the screen properly.
Well, with the restriction I said (same BPP than desktop; or better,
just 0), it worked really great for us, faster than all other possible
combination of video drivers, settings and BPP (in window mode). Also,
compared with the Linux performance (on the same computer),
SDL_OPENGLBLIT comes very close to that; without, I have more or less
half the FPS (probably because one further step of copying the data is
in between), so very bad performance.
We also had some problems in the beginning with refreshing and
blitting. It seems that some additional initialisation is needed for
that case. For example, we need to do a SDL_FillRect(black) & SDL_Flip
& SDL_FillRect(black) on the screen surface. Without that, it looked
very weird on all semi transparent sections.
We also didn’t had our code correct for double buffering in the
beginning. We had some assumption that we don’t need to refresh
sections on the screen surface which did not changed. This worked fine
with most of the default drivers but it’s of course wrong with OpenGL
and double buffering (or at least the situation is more complicated
there, you need to keep both buffers synchronised). We had some weird
flickering with these bugs.Am 01.05.2009 um 19:39 schrieb julien CLEMENT:
— En date de : Ven 1.5.09, Albert Zeyer <albert.zeyer at rwth-
aachen.de> a ?crit :De: Albert Zeyer <@Albert_Zeyer>
Objet: Re: [SDL] Mac OS X speed
?: “A list for developers using the SDL library. (includes SDL-
announce)”
Date: Vendredi 1 Mai 2009, 16h28Am 01.05.2009 um 16:22 schrieb Torsten Giebl:
Hello !
This is for SDL 1.2 only.I’ve noticed an incredible
difference of speed between fullscreen mode and
windowed mode.Fullscreen mode is like 100 times
faster than windowed mode for blits.
I’m running Mac OS 10.5As far as i know OSX is double buffering every
window on the desktop and also updating them only on VSYNC
to avoid tearing. But OSX does this only on the desktop,
not on fullscreen apps.Try using OpenGL (with same bits per pixels than the desktop) with
SDL_OPENGLBLIT, that improved the speed a lot for our game (no
difference anymore between fullscreen and window).
- Albert
Hello,
This is for SDL 1.2 only.I’ve noticed an incredible difference of speed between fullscreen mode and windowed mode.Fullscreen mode is like 100 times faster than windowed mode for blits.
Have you tried SDL 1.3? It’s specifically optimized for Mac OS X OpenGL.
See ya,
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Hello,
This is for SDL 1.2 only.I’ve noticed an incredible difference of speed between fullscreen mode and windowed mode.Fullscreen mode is like 100 times faster than windowed mode for blits.
I’m running Mac OS 10.5
Any reason ?
Oh, I forgot to answer the original question… Yes, by default the Carbon
APIs that SDL 1.2 use are limited to the screen refresh rate, typically 60
FPS. I think there’s a setting somewhere to change this, but I don’t remember
offhand where.
See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Thank you for the answer,
actually, I know SDL since early versions like 0.8 or something like this, and I fear I have to re-learn everything for SDL 1.3 … now that I’m quite skilled with 1.2 
Julien
— En date de?: Jeu 7.5.09, Sam Lantinga a ?crit? Sam Lantinga
Objet: Re: [SDL] Mac OS X speed
?: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Jeudi 7 Mai 2009, 14h16
Hello,
This is for SDL 1.2 only.I’ve noticed an incredible difference of speed between fullscreen mode and windowed mode.Fullscreen mode is like 100 times faster than windowed mode for blits.
I’m running Mac OS 10.5
Any reason ?
Oh, I forgot to answer the original question… Yes, by default the Carbon
APIs that SDL 1.2 use are limited to the screen refresh rate, typically 60
FPS.? I think there’s a setting somewhere to change this, but I don’t remember
offhand where.
See ya!
??? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Thank you for the answer,
actually, I know SDL since early versions like 0.8 or something like this, and I fear I have to re-learn everything for SDL 1.3 … now that I’m quite skilled with 1.2
Switching to 1.3 should be relatively painless, except for some changes in
the surface details and keyboard handling. Please let me know how it goes
for you, if you decide to try it.
See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Thank you for the answer,
actually, I know SDL since early versions like 0.8 or something like this, and I fear I have to re-learn everything for SDL 1.3 … now that I’m quite skilled with 1.2Switching to 1.3 should be relatively painless, except for some changes in
the surface details and keyboard handling. Please let me know how it goes
for you, if you decide to try it.
Replacing surfaces with windows and textures as the screen objects that get drawn to has been less than “relatively painless,” because windows are write-only. (This is a perfect opportunity to make a joke about the language that the library is written in, but I’ll forbear.) We’re left with two choices: run in “compat” mode, which does some funny stuff under the hood to map a hidden window onto an SDL_Surface, which may or may not massively degrade performance based on various factors, or create big workarounds where new textures are constantly being created from surfaces. (Which does massively degrade performance, period.) We need to add some sort of “render targets” concept. The new API is essentially worthless without it, unfortunately.>----- Original Message ----
From: Sam Lantinga
Subject: Re: [SDL] Mac OS X speed
We’re left with two choices: run in “compat” mode, which does some funny stuff under the hood to map a hidden window onto an SDL_Surface, which may or may not massively degrade performance based on various factors
It degrades performance, yes, but to the level of SDL 1.2. The new API
can have massively better performance, and the reason is in how the
API is laid out, some optimizations just couldn’t be made with the 1.2
API. The compatibility layer basically erases those improvements, but
it shouldn’t be any worse than it was with 1.2, you’re just not
getting the full benefit…
It’s also not a distinct “compatibility mode”, you can mix and match
between the SDL_compat.h stuff and the new API, to some degree.
What did you mean by “render targets” that are so critical? I get
large improvements in frames per seconds with the new API, I’d hardly
call it “worthless” myself, but if it could be even better, I’m sure
no one will complain…On Thu, May 7, 2009 at 9:07 AM, Mason Wheeler wrote:
What did you mean by “render targets” that are so critical? I get
large improvements in frames per seconds with the new API, I’d hardly
call it “worthless” myself, but if it could be even better, I’m sure
no one will complain…
It’s currently impossible to blit from one texture to another. ( see this thread: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-April/069671.html ) That means that all dynamic drawing has to be done in surfaces, then converted to a texture, then blitted to the screen. Every single frame. This wasn’t an issue in SDL 1.2, because all we had were surfaces, and you can use a surface as a render target. But now, with an intermediate step (textures), it’s huge step backwards if you’re working with a screen that changes a lot.
My idea for a render target is basically something that behaves exactly like a window, except that it doesn’t get displayed onscreen. An offscreen rendering buffer (like a surface) with the high-speed performance of textures, where you can compose your image, and then blit the whole thing to the screen. They’re very useful for any sort of compositing work, fades/tints, screen transitions, etc, and being suddenly unable to use them without taking a big performance hit is a major disappointment.
For example:
SDL_SelectRenderer(RenderTargetID);
for texture in tileList do
SDL_RenderCopy(texture.id, nil, texture.destrect);
RenderAllScreenEffects();
SDL_RenderCopy(HUD.id, nil, HUD.destrect);
SDL_SelectRenderer(WindowID);
SDL_RenderCopy(RenderTargetID, nil, nil);
SDL_RenderPresent();
See how that could be useful?>----- Original Message ----
From: Pierre Phaneuf
Subject: Re: [SDL] Mac OS X speed
It’s currently impossible to blit from one texture to another. ?( see this thread: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-April/069671.html ) ?That means that all dynamic drawing has to be done in surfaces, then converted to a texture, then blitted to the screen. ?Every single frame. ?This wasn’t an issue in SDL 1.2, because all we had were surfaces, and you can use a surface as a render target. ?But now, with an intermediate step (textures), it’s huge step backwards if you’re working with a screen that changes a lot.
Ah, yes, I see how that could be useful. They might not be possible on
some APIs, though, am I mistaken? I think OpenGL needs an extension
for that, which might or might not be present…
My current programs don’t seem to have much use for intermediate
stages, I usually have a bunch of surfaces/textures that I blast to
the screen, some of which are streamable, others static. This does
yield a little bit higher command traffic, it hasn’t caused me any
trouble.
Hmm, that reminds me… The documentation comment for
SDL_LockTexture/SDL_UnlockTexture should probably have a comment to
them being possibly fairly slow (locking might transfer the pixel data
from the video card back into the main memory, and unlocking going the
other way). A comment pointing to SDL_UpdateTexture being faster
(skips the download) if you’re going to overwrite the entire area
could be nice too.On Thu, May 7, 2009 at 5:26 PM, Mason Wheeler wrote:
Sorry to bring back this old thread, but I am interested in the
subject that was discussed here.
I think the game I’m working on could benefit greatly from an API in
SDL 1.3 allowing blitting from one texture to another.
I am facing with the following problems that can be resolved with such
a feature:
-
My game composes an image with a lot of tiles. All the tiles are
loaded as textures, and blitted individually for every frame on the
screen. In SDL 1.2, I used to compose my image in an intermediate
surface on which I only update the deltas between frames, and then
blit this intermediate surface on the screen. On SDL 1.3, using an
intermediate surface and transfering it to a texture to blit on the
screen is too slow, and I get better performances when blitting every
tile individually each frame. However, I notice a sensible frame drop
when the number of tiles tend to increase. I think having an
intermediate texture that can be used as the intermediate surface of
the SDL 1.2 version could help smooth the framerate, but this requires
the ability to blit from one texture to another. -
To manage transition effects, I sometimes have to render the whole
screen to an offscreen buffer. In SDL 1.2, it was a simple matter of
blitting to an offscreen SDL_Surface instead of blitting on the
display surface. On SDL 1.3, I have to keep a copy of my textures as
SDL_Surface to be able to blit them on an SDL_Surface that will be
copied to a texture in order to achieve the same effects. This would
be enhanced a bit in terms of speed and memory consumption if there
was a way to blit from one texture to another.
Is there something preventing the adoption of this kind of feature in
SDL 1.3? If no, I would be glad to work on it.
I think almost every implementation of OpenGL feature this ability
(but sometimes in nonstandard ways).
Florent
Le 7 mai 09 ? 23:26, Mason Wheeler a ?crit :>
----- Original Message ----
From: Pierre Phaneuf
Subject: Re: [SDL] Mac OS X speedWhat did you mean by “render targets” that are so critical? I get
large improvements in frames per seconds with the new API, I’d hardly
call it “worthless” myself, but if it could be even better, I’m sure
no one will complain…It’s currently impossible to blit from one texture to another.
( see this thread: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-April/069671.html
) That means that all dynamic drawing has to be done in surfaces,
then converted to a texture, then blitted to the screen. Every
single frame. This wasn’t an issue in SDL 1.2, because all we had
were surfaces, and you can use a surface as a render target. But
now, with an intermediate step (textures), it’s huge step backwards
if you’re working with a screen that changes a lot.My idea for a render target is basically something that behaves
exactly like a window, except that it doesn’t get displayed
onscreen. An offscreen rendering buffer (like a surface) with the
high-speed performance of textures, where you can compose your
image, and then blit the whole thing to the screen. They’re very
useful for any sort of compositing work, fades/tints, screen
transitions, etc, and being suddenly unable to use them without
taking a big performance hit is a major disappointment.For example:
SDL_SelectRenderer(RenderTargetID);
for texture in tileList do
SDL_RenderCopy(texture.id, nil, texture.destrect);
RenderAllScreenEffects();
SDL_RenderCopy(HUD.id, nil, HUD.destrect);
SDL_SelectRenderer(WindowID);
SDL_RenderCopy(RenderTargetID, nil, nil);
SDL_RenderPresent();See how that could be useful?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2009/6/17 Florent GMail (imap)
- My game composes an image with a lot of tiles. All the tiles are loaded
as textures, and blitted individually for every frame on the screen. In SDL
1.2, I used to compose my image in an intermediate surface on which I only
update the deltas between frames, and then blit this intermediate surface on
the screen. On SDL 1.3, using an intermediate surface and transfering it to
a texture to blit on the screen is too slow, and I get better performances
when blitting every tile individually each frame. However, I notice a
sensible frame drop when the number of tiles tend to increase. I think
having an intermediate texture that can be used as the intermediate surface
of the SDL 1.2 version could help smooth the framerate, but this requires
the ability to blit from one texture to another.
try this: http://ogltotd.blogspot.com/2006/12/render-to-texture.html
google “render to texture opengl” for more info.
2009/6/17 Florent GMail (imap)
- My game composes an image with a lot of tiles. All the tiles are loaded as textures, and blitted individually for every frame on the screen. In SDL 1.2, I used to compose my image in an intermediate surface on which I only update the deltas between frames, and then blit this intermediate surface on the screen. On SDL 1.3, using an intermediate surface and transfering it to a texture to blit on the screen is too slow, and I get better performances when blitting every tile individually each frame. However, I notice a sensible frame drop when the number of tiles tend to increase. I think having an intermediate texture that can be used as the intermediate surface of the SDL 1.2 version could help smooth the framerate, but this requires the ability to blit from one texture to another.
try this: http://ogltotd.blogspot.com/2006/12/render-to-texture.html
google “render to texture opengl” for more info.
Cool! Now, from what I’ve seen, it appears that SDL draws its texture ID numbers and window ID numbers from the same pool in serial. In other words, you’ll never have a texture with the same ID as a SDL_Window at the same time. If that’s true, it shouldn’t be too difficult to modify SDL_SelectRenderer to use this code, for the GL backend at least. Anyone know how to do it in other backends?From: llubnek@gmail.com (Kenneth Bull)
Subject: Re: [SDL] Blitting from one texture to another (was: Mac OS X speed)
2009/6/18 Mason Wheeler
Cool! Now, from what I’ve seen, it appears that SDL draws its texture ID
numbers and window ID numbers from the same pool in serial. In other words,
you’ll never have a texture with the same ID as a SDL_Window at the same
time. If that’s true, it shouldn’t be too difficult to modify
SDL_SelectRenderer to use this code, for the GL backend at least. Anyone
know how to do it in other backends?
DirectX: http://www.two-kings.de/tutorials/dxgraphics/dxgraphics16.html
To my knowledge it shouldn’t be much of an issue for any other backends.
FYI, this is what streaming textures and SDL_CreateRGBSurfaceFrom() are for.
Some functions you’ll need:
SDL_QueryTexture(), SDL_QueryTexturePixels(), SDL_PixelFormatEnumToMasks(),
SDL_CreateRGBSurfaceFrom(), etc.On Wed, Jun 17, 2009 at 6:07 PM, Florent GMail (imap) wrote:
Sorry to bring back this old thread, but I am interested in the subject
that was discussed here.
I think the game I’m working on could benefit greatly from an API in SDL
1.3 allowing blitting from one texture to another.I am facing with the following problems that can be resolved with such a
feature:
My game composes an image with a lot of tiles. All the tiles are loaded
as textures, and blitted individually for every frame on the screen. In SDL
1.2, I used to compose my image in an intermediate surface on which I only
update the deltas between frames, and then blit this intermediate surface on
the screen. On SDL 1.3, using an intermediate surface and transfering it to
a texture to blit on the screen is too slow, and I get better performances
when blitting every tile individually each frame. However, I notice a
sensible frame drop when the number of tiles tend to increase. I think
having an intermediate texture that can be used as the intermediate surface
of the SDL 1.2 version could help smooth the framerate, but this requires
the ability to blit from one texture to another.To manage transition effects, I sometimes have to render the whole screen
to an offscreen buffer. In SDL 1.2, it was a simple matter of blitting to an
offscreen SDL_Surface instead of blitting on the display surface. On SDL
1.3, I have to keep a copy of my textures as SDL_Surface to be able to blit
them on an SDL_Surface that will be copied to a texture in order to achieve
the same effects. This would be enhanced a bit in terms of speed and memory
consumption if there was a way to blit from one texture to another.Is there something preventing the adoption of this kind of feature in SDL
1.3? If no, I would be glad to work on it.
I think almost every implementation of OpenGL feature this ability (but
sometimes in nonstandard ways).Florent
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
OK, I’m lost. How does creating a new surface from an existing texture equate to copying from one texture to another? Once you create the new surface, it still needs to be converted to a texture to be usable, with the corresponding performance hit. What we’re looking for is to draw textures directly onto each other as render targets so as to keep the surface -> texture conversions to an absolute minimum.
FYI, this is what streaming textures and SDL_CreateRGBSurfaceFrom() are for.
Some functions you’ll need:
SDL_QueryTexture(), SDL_QueryTexturePixels(), SDL_PixelFormatEnumToMasks(), SDL_CreateRGBSurfaceFrom(), etc.From: slouken@libsdl.org (slouken)
Subject: Re: [SDL] Blitting from one texture to another (was: Mac OS X speed)
On Wed, Jun 17, 2009 at 6:07 PM, Florent GMail (imap) wrote:
Sorry to bring back this old thread, but I am interested in the subject that was discussed here.
I think the game I’m working on could benefit greatly from an API in SDL 1.3 allowing blitting from one texture to another.
I am facing with the following problems that can be resolved with such a feature:
- My game composes an image with a lot of tiles. All the tiles are loaded as textures, and blitted individually for every frame on the screen. In SDL 1.2, I used to compose my image in an intermediate surface on which I only update the deltas between frames, and then blit this intermediate surface on the screen. On SDL 1.3, using an intermediate surface and transfering it to a texture to blit on the screen is too slow, and I get better performances when blitting every tile individually each frame. However, I notice a sensible frame drop when the number of tiles tend to increase. I think having an intermediate texture that can be used as the intermediate surface of the SDL 1.2 version could help smooth the framerate, but this requires the ability to blit from one texture to another.
- To manage transition effects, I sometimes have to render the whole screen to an offscreen buffer. In SDL 1.2, it was a simple matter of blitting to an offscreen SDL_Surface instead of blitting on the display surface. On SDL 1.3, I have to keep a copy of my textures as SDL_Surface to be able to blit them on an SDL_Surface that will be copied to a texture in order to achieve the same effects. This would be enhanced a bit in terms of speed and memory consumption if there was a way to blit from one texture to another.
Is there something preventing the adoption of this kind of feature in SDL 1.3? If no, I would be glad to work on it.
I think almost every implementation of OpenGL feature this ability (but sometimes in nonstandard ways).Florent
Yes, AFAIU streaming textures is soft->hard blits, while Florent’s
question is about hard->hard blits.–
Sylvain
On Thu, Jun 18, 2009 at 08:47:56PM -0700, Mason Wheeler wrote:
OK, I’m lost. How does creating a new surface from an existing texture equate to copying from one texture to another? Once you create the new surface, it still needs to be converted to a texture to be usable, with the corresponding performance hit. What we’re looking for is to draw textures directly onto each other as render targets so as to keep the surface -> texture conversions to an absolute minimum.
From: Sam Lantinga
Subject: Re: [SDL] Blitting from one texture to another (was: Mac OS X speed)FYI, this is what streaming textures and SDL_CreateRGBSurfaceFrom() are for.
Some functions you’ll need:
SDL_QueryTexture(), SDL_QueryTexturePixels(), SDL_PixelFormatEnumToMasks(), SDL_CreateRGBSurfaceFrom(), etc.On Wed, Jun 17, 2009 at 6:07 PM, Florent GMail (imap) wrote:
Sorry to bring back this old thread, but I am interested in the subject that was discussed here.
I think the game I’m working on could benefit greatly from an API in SDL 1.3 allowing blitting from one texture to another.
I am facing with the following problems that can be resolved with such a feature:
- My game composes an image with a lot of tiles. All the tiles are loaded as textures, and blitted individually for every frame on the screen. In SDL 1.2, I used to compose my image in an intermediate surface on which I only update the deltas between frames, and then blit this intermediate surface on the screen. On SDL 1.3, using an intermediate surface and transfering it to a texture to blit on the screen is too slow, and I get better performances when blitting every tile individually each frame. However, I notice a sensible frame drop when the number of tiles tend to increase. I think having an intermediate texture that can be used as the intermediate surface of the SDL 1.2 version could help smooth the framerate, but this requires the ability to blit from one texture to another.
- To manage transition effects, I sometimes have to render the whole screen to an offscreen buffer. In SDL 1.2, it was a simple matter of blitting to an offscreen SDL_Surface instead of blitting on the display surface. On SDL 1.3, I have to keep a copy of my textures as SDL_Surface to be able to blit them on an SDL_Surface that will be copied to a texture in order to achieve the same effects. This would be enhanced a bit in terms of speed and memory consumption if there was a way to blit from one texture to another.
Is there something preventing the adoption of this kind of feature in SDL 1.3? If no, I would be glad to work on it.
I think almost every implementation of OpenGL feature this ability (but sometimes in nonstandard ways).Florent