SDL1.3 MacOS incremental draw 'flicker'

Hello everyone,

Currently the game I’m working on doesn’t redraw everything to the
screen everytime (it could, but doesn’t). On iOS this is fine, but on
Mac OS X (10.6.8 Snow Leopard) most of the time this is OK, but
sometimes it ‘flickers’ - it looks like some runs it has a single buffer
source and other runs it has a double buffer source - but i don’t
understand what has changed…

Anyone got any ideas why? It sort of feels like I’m using the API
wrongly by drawing incrementally per frame … is this ok or not? There
is a iPhoneOS example that does this in ‘rectangles.c’ (although that
does have a SDL_RenderClear() before the main loop … but since I draw
the whole screen … I can’t see that being a problem).

I’m currently building against SDL 1.3 build 5605 (although I have the
repo checked out here that I will test against the tip next).

My code looks like this (with some lines removed for clarity):

 if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_TIMER) < 0) 

{return 1;}

 window =  SDL_CreateWindow("Gulpman",
                      WINDOW_X_START, WINDOW_Y_START,
                      SCREEN_WIDTH, SCREEN_HEIGHT,
                      SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN
                      );
 if (!window) {return 1;}

 renderer = SDL_CreateRenderer(window, -1, 0);
 if (!renderer) {return 1;}

     SDL_Event event;
 while (!done) {
     while (SDL_PollEvent(&event))
     {
         // <<<<normal stuff here>>>
     }
     // <<<more uninteresting stuff here like moving player, 

monsters, etc >>>
render(renderer, graphics);
SDL_Delay(50); // for testing … frame rate control
not in yet
}
// <<>>

void render(SDL_Renderer renderer, MyGraphics graphics)
{
// <<>>>
// things like x, y, fg_colour, bg_colour and colour, vary per frame
if(!bg_transparent) {
SDL_Rect rect = { x, y, GLYPH_SIZE_SCREEN,
GLYPH_SIZE_SCREEN };
SDL_SetRenderDrawColor(renderer, colour.r, colour.g,
colour.b,colour.unused);
SDL_RenderFillRect(renderer, &rect);
}

     SDL_Texture* tex = texture[fg_colour];
     if(tex)
     {
         SDL_RenderCopy(renderer, tex, &srcRect, &dstRect);
     }

 // <<< more lines>>>
 /* update screen */
 SDL_RenderPresent(renderer);

}

Regards,
Rob

Anyone got any ideas why? It sort of feels like I’m using the API wrongly
by drawing incrementally per frame … is this ok or not? There is a
iPhoneOS example that does this in ‘rectangles.c’ (although that does have a
SDL_RenderClear() before the main loop … but since I draw the whole screen
… I can’t see that being a problem).

I do exactly this in my engine, I draw the scene incrementally if single
buffered (OpenGL in Linux IIRC) or the entire scene if double buffered (GL
ES under Android), and I haven’t noticed any flickering as you mentioned.
What I do wonder and I’ve never checked is that if the incremental rendering
is really worth the effort of doing dirty rects/intersections/etc, because
the accelerated rendering when using only textures is so fast that perhaps
it’s just not worth the effort.

Gabriel.

I think this depends a lot on whether we’re talking about OpenGL rendering or not.

If doing software rendering, incremental is a good idea.

If doing hardware rendering, incremental is usually a bad idea, especially on tiler GPUs such as in mobile devices, because these GPUs are designed to render the entire frame over again each time, not
incrementally update it (they walk the screen in tile order and render polygons in each tile inside the chip without writing to memory, then dump the tile image out to memory).On 10/16/2011 06:30 AM, Gabriel Jacobo wrote:

Anyone got any ideas why? It sort of feels like I’m using the API wrongly by drawing incrementally per frame … is this ok or not? There is a iPhoneOS example that does this in ‘rectangles.c’
(although that does have a SDL_RenderClear() before the main loop … but since I draw the whole screen … I can’t see that being a problem).

I do exactly this in my engine, I draw the scene incrementally if single buffered (OpenGL in Linux IIRC) or the entire scene if double buffered (GL ES under Android), and I haven’t noticed any
flickering as you mentioned.
What I do wonder and I’ve never checked is that if the incremental rendering is really worth the effort of doing dirty rects/intersections/etc, because the accelerated rendering when using only
textures is so fast that perhaps it’s just not worth the effort.

Gabriel.


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


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

I have seen this too, but I haven’t had the time to analyse it further.
It doesn’t always happen and so far I thought it was due to other
things I was working at.

BTW. In mercurial terms you’ll have to give us the full 12 hexdigit
changeset ID. The decimal number you gave is just valid in your
local repository.

For example I have:
$ hg heads
changeset: 5974:13e67468b846
tag: tip
user: Andreas Schiffler
date: Wed Oct 05 08:08:06 2011 -0700
summary: Refactored audio device enumeration/naming tests ana added
negative cases

changeset: 5960:eb025734b5a1
branch: SDL-1.2
parent: 5955:0ade820b8f5f
user: Ryan C. Gordon
date: Mon Sep 19 01:46:55 2011 -0400
summary: Cleaned up fatbuild.sh

– Kees

Op 2011-10-16 11:01 , Rob Probin schreef:> Hello everyone,

Currently the game I’m working on doesn’t redraw everything to the
screen everytime (it could, but doesn’t). On iOS this is fine, but on
Mac OS X (10.6.8 Snow Leopard) most of the time this is OK, but
sometimes it ‘flickers’ - it looks like some runs it has a single
buffer source and other runs it has a double buffer source - but i
don’t understand what has changed…

Anyone got any ideas why? It sort of feels like I’m using the API
wrongly by drawing incrementally per frame … is this ok or not?
There is a iPhoneOS example that does this in ‘rectangles.c’ (although
that does have a SDL_RenderClear() before the main loop … but since
I draw the whole screen … I can’t see that being a problem).

I’m currently building against SDL 1.3 build 5605 (although I have the
repo checked out here that I will test against the tip next).

My code looks like this (with some lines removed for clarity):

if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_TIMER) < 
  1. {return 1;}

    window = SDL_CreateWindow(“Gulpman”,
    WINDOW_X_START, WINDOW_Y_START,
    SCREEN_WIDTH, SCREEN_HEIGHT,
    SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN
    );
    if (!window) {return 1;}

    renderer = SDL_CreateRenderer(window, -1, 0);
    if (!renderer) {return 1;}

     SDL_Event event;
    

    while (!done) {
    while (SDL_PollEvent(&event))
    {
    // <<<>>
    }
    // <<<more uninteresting stuff here like moving player,
    monsters, etc >>>
    render(renderer, graphics);
    SDL_Delay(50); // for testing … frame rate
    control not in yet
    }
    // <<>>

void render(SDL_Renderer renderer, MyGraphics graphics)
{
// <<>>>
// things like x, y, fg_colour, bg_colour and colour, vary per frame
if(!bg_transparent) {
SDL_Rect rect = { x, y, GLYPH_SIZE_SCREEN,
GLYPH_SIZE_SCREEN };
SDL_SetRenderDrawColor(renderer, colour.r, colour.g,
colour.b,colour.unused);
SDL_RenderFillRect(renderer, &rect);
}

    SDL_Texture* tex = texture[fg_colour];
    if(tex)
    {
        SDL_RenderCopy(renderer, tex, &srcRect, &dstRect);
    }

// <<< more lines>>>
/* update screen */
SDL_RenderPresent(renderer);

}

Regards,
Rob


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

Hi Gabriel,

I do exactly this in my engine, I draw the scene incrementally if single
buffered (OpenGL in Linux IIRC) or the entire scene if double buffered (GL
ES under Android), and I haven’t noticed any flickering as you mentioned.
What I do wonder and I’ve never checked is that if the incremental rendering
is really worth the effort of doing dirty rects/intersections/etc, because
the accelerated rendering when using only textures is so fast that perhaps
it’s just not worth the effort.

In my case, I know what’s been updated very specifically because of the
tiled nature of the background. You might be right, however, that if
it’s happening on the graphics chip that there might be no difference in
speed.

I must have been doing this too long - I still get the feeling that
those small phone batteries giving more power by ‘printing’ more stuff …

Regards,
Rob

Hi Kees,

I have seen this too, but I haven’t had the time to analyse it further.
It doesn’t always happen and so far I thought it was due to other
things I was working at.

BTW. In mercurial terms you’ll have to give us the full 12 hexdigit
changeset ID. The decimal number you gave is just valid in your
local repository.

Ah yes … I should have mentioned it’s the canned release off
http://www.libsdl.org/hg.php … so it’s not even my 5605 version (it
mentions that in the folder name when unzipped) :slight_smile:

Regards,
Rob

Hi Forest,

I think this depends a lot on whether we’re talking about OpenGL rendering or not.

If doing software rendering, incremental is a good idea.

If doing hardware rendering, incremental is usually a bad idea, especially on tiler GPUs such as in mobile devices, because these GPUs are designed to render the entire frame over again each time, not
incrementally update it (they walk the screen in tile order and render polygons in each tile inside the chip without writing to memory, then dump the tile image out to memory).

Interesting. My project also builds to iOS … but using incremental
rendering. So I perhaps will change that. Should be easy. Should it be
the same amount of main processing power on the mobile device? Will the
frame-rate be better?

I wonder on MacOSX, with the ‘SDL_WINDOW_OPENGL’ flag to the
SDL_CreateWindow call, I guessing the ‘Renderer’ calls I’m making are
actually OpenGL hardware rendering??? Since I haven’t looked under the
hood at any of the video stuff for SDL1.3, I have no clue. (This appears
to be a stupid question, requiring a ‘DUH!!!’ type reply :-D)

Assuming that the problem is that sometimes I have a double buffered
context sometimes and a single buffered one other times … I wonder if
I can check that.

Is SDL_GL_GetAttribute with the parameter of SDL_GL_DOUBLEBUFFER valid
for SDL1.3?

Ultimately, non-incremental rendering might be easier :slight_smile: But now I’m
curious to know what IS happening :slight_smile:

Regards,
Rob

P.S. This is ‘I don’t know’ number two on SDL1.3 for me (I didn’t have
any on 1.2) - the first being a weird colour Fill behaviour on one
specific surface type that’s still on my ‘to investigate’ list.