SDL_RenderCopy android

Hello guys i have a problem on android

i have two textures for now lets call them textureA and textureB.I am doing
these operations

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer,texrureA,NULL,NULL);
SDL_RenderCopy(renderer,textureB,srcrect,dstrect);
SDL_RenderPresent(renderer);

I end up with the first texture not beeing drawn and only the second on a
black background.

It seems that somebody else had the same problem
http://forums.libsdl.org/viewtopic.php?t=7412&sid=664cf34c6d37a355564cf5c04bb0859a

Any idea?

Best Regards
Dimitris Zenios

No idea, unless texture A is broken it should work… What device is
it? It could be useful to know whether it’s OpenGL ES 1 or 2.

Also: did you try drawing more textures besides the second one? Maybe
it would help us to get more hindsight on the issue (to see if only
the first texture is skipped or all but the last).

2013/3/7, Dimitris Zenios <dimitris.zenios at gmail.com>:> Hello guys i have a problem on android

i have two textures for now lets call them textureA and textureB.I am doing
these operations

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer,texrureA,NULL,NULL);
SDL_RenderCopy(renderer,textureB,srcrect,dstrect);
SDL_RenderPresent(renderer);

I end up with the first texture not beeing drawn and only the second on a
black background.

It seems that somebody else had the same problem
http://forums.libsdl.org/viewtopic.php?t=7412&sid=664cf34c6d37a355564cf5c04bb0859a

Any idea?

Best Regards
Dimitris Zenios

Ok in order for everyone to be more clear.Attached you will find the simple
application.It doesn matter if i use two textures or just one which at
first i blit with NULL rects and then i pass a rect.

Below is the more important part.

SDL_Rect rect;

rect.x = 0;
rect.y = 0;
rect.w = 128;
rect.h = 128;

SDL_LockTexture(MooseTexture,NULL,&texture_surface->pixels,&texture_surface->pitch);
SDL_BlitSurface((SDL_Surface*)surface, NULL, texture_surface,NULL);
SDL_UnlockTexture(MooseTexture);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, MooseTexture, NULL, NULL);
SDL_RenderPresent(renderer);

/* Loop, waiting for QUIT or the escape key */
while (!done) {
    while (SDL_PollEvent(&event)) {
        switch (event.type) {
        case SDL_KEYDOWN:
            if (event.key.keysym.sym == SDLK_ESCAPE) {
                done = SDL_TRUE;
            }
            break;
        case SDL_QUIT:
            done = SDL_TRUE;
            break;
        }
    }


    SDL_RenderCopy(renderer, MooseTexture, &rect, &rect);
    SDL_RenderPresent(renderer);
}

I first draw the whole texture and present and then in a loop i only draw a
portion of a texture and present.I end up seeing only the portion.You can
see than i dont call anywhere in the loop RenderClear.Only copy and present.

I have also tried with a static texture instead of streaming with the same
results.

I am using GLES2.

Please tell me if you need anything else

P.S:I could not upload bg.jpeg cause of size limits.Its an empty white
background with some text in itOn Fri, Mar 8, 2013 at 10:57 AM, Dimitris Zenios <@Dimitris_Zenios>wrote:

Ok in order for everyone to be more clear.Attached you will find the
simple application.It doesn matter if i use two textures or just one which
at first i blit with NULL rects and then i pass a rect.

Below is the more important part.

SDL_Rect rect;

rect.x = 0;
rect.y = 0;
rect.w = 128;
rect.h = 128;

SDL_LockTexture(MooseTexture,NULL,&texture_surface->pixels,&texture_surface->pitch);
SDL_BlitSurface((SDL_Surface*)surface, NULL, texture_surface,NULL);
SDL_UnlockTexture(MooseTexture);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, MooseTexture, NULL, NULL);
SDL_RenderPresent(renderer);

/* Loop, waiting for QUIT or the escape key */
while (!done) {
    while (SDL_PollEvent(&event)) {
        switch (event.type) {
        case SDL_KEYDOWN:
            if (event.key.keysym.sym == SDLK_ESCAPE) {
                done = SDL_TRUE;
            }
            break;
        case SDL_QUIT:
            done = SDL_TRUE;
            break;
        }
    }


    SDL_RenderCopy(renderer, MooseTexture, &rect, &rect);
    SDL_RenderPresent(renderer);
}

I first draw the whole texture and present and then in a loop i only draw
a portion of a texture and present.I end up seeing only the portion.You can
see than i dont call anywhere in the loop RenderClear.Only copy and present.

I have also tried with a static texture instead of streaming with the same
results.

I am using GLES2.

Please tell me if you need anything else

On Fri, Mar 8, 2013 at 6:55 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

No idea, unless texture A is broken it should work… What device is
it? It could be useful to know whether it’s OpenGL ES 1 or 2.

Also: did you try drawing more textures besides the second one? Maybe
it would help us to get more hindsight on the issue (to see if only
the first texture is skipped or all but the last).

2013/3/7, Dimitris Zenios <@Dimitris_Zenios>:

Hello guys i have a problem on android

i have two textures for now lets call them textureA and textureB.I am
doing
these operations

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer,texrureA,NULL,NULL);
SDL_RenderCopy(renderer,textureB,srcrect,dstrect);
SDL_RenderPresent(renderer);

I end up with the first texture not beeing drawn and only the second on
a
black background.

It seems that somebody else had the same problem

http://forums.libsdl.org/viewtopic.php?t=7412&sid=664cf34c6d37a355564cf5c04bb0859a

Any idea?

Best Regards
Dimitris Zenios


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

-------------- next part --------------
A non-text attachment was scrubbed…
Name: main.c
Type: text/x-csrc
Size: 2775 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130308/0c1cf7be/attachment-0001.c

2013/3/8 Dimitris Zenios <dimitris.zenios at gmail.com>

Ok in order for everyone to be more clear.Attached you will find the
simple application.It doesn matter if i use two textures or just one which
at first i blit with NULL rects and then i pass a rect.

Below is the more important part.

SDL_Rect rect;

rect.x = 0;
rect.y = 0;
rect.w = 128;
rect.h = 128;

SDL_LockTexture(MooseTexture,NULL,&texture_surface->pixels,&texture_surface->pitch);
SDL_BlitSurface((SDL_Surface*)surface, NULL, texture_surface,NULL);
SDL_UnlockTexture(MooseTexture);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, MooseTexture, NULL, NULL);
SDL_RenderPresent(renderer);

/* Loop, waiting for QUIT or the escape key */
while (!done) {
    while (SDL_PollEvent(&event)) {
        switch (event.type) {
        case SDL_KEYDOWN:
            if (event.key.keysym.sym == SDLK_ESCAPE) {
                done = SDL_TRUE;
            }
            break;
        case SDL_QUIT:
            done = SDL_TRUE;
            break;
        }
    }


    SDL_RenderCopy(renderer, MooseTexture, &rect, &rect);
    SDL_RenderPresent(renderer);
}

I first draw the whole texture and present and then in a loop i only draw
a portion of a texture and present.I end up seeing only the portion.You can
see than i dont call anywhere in the loop RenderClear.Only copy and present.

I have also tried with a static texture instead of streaming with the same
results.

I am using GLES2.

Please tell me if you need anything else

P.S:I could not upload bg.jpeg cause of size limits.Its an empty white
background with some text in it

It’s quite possible the system is using double buffering. If you run
SDL_RenderCopy(renderer,
MooseTexture, NULL, NULL); every frame, does it look like you want it to?–
Gabriel.

I’ve discussed this with Dimitris off list, and I’ve added a note on the
README.android file regarding the use of this rendering technique.

TL;DR: AFAICT, you can’t use it on Android :slight_smile:

Sorry for the top post!

2013/3/8 Dimitris Zenios <dimitris.zenios at gmail.com>> Ok in order for everyone to be more clear.Attached you will find the

simple application.It doesn matter if i use two textures or just one which
at first i blit with NULL rects and then i pass a rect.

Below is the more important part.

SDL_Rect rect;

rect.x = 0;
rect.y = 0;
rect.w = 128;
rect.h = 128;

SDL_LockTexture(MooseTexture,NULL,&texture_surface->pixels,&texture_surface->pitch);
SDL_BlitSurface((SDL_Surface*)surface, NULL, texture_surface,NULL);
SDL_UnlockTexture(MooseTexture);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, MooseTexture, NULL, NULL);
SDL_RenderPresent(renderer);

/* Loop, waiting for QUIT or the escape key */
while (!done) {
    while (SDL_PollEvent(&event)) {
        switch (event.type) {
        case SDL_KEYDOWN:
            if (event.key.keysym.sym == SDLK_ESCAPE) {
                done = SDL_TRUE;
            }
            break;
        case SDL_QUIT:
            done = SDL_TRUE;
            break;
        }
    }


    SDL_RenderCopy(renderer, MooseTexture, &rect, &rect);
    SDL_RenderPresent(renderer);
}

I first draw the whole texture and present and then in a loop i only draw
a portion of a texture and present.I end up seeing only the portion.You can
see than i dont call anywhere in the loop RenderClear.Only copy and present.

I have also tried with a static texture instead of streaming with the same
results.

I am using GLES2.

Please tell me if you need anything else

P.S:I could not upload bg.jpeg cause of size limits.Its an empty white
background with some text in it

On Fri, Mar 8, 2013 at 10:57 AM, Dimitris Zenios < dimitris.zenios at gmail.com> wrote:

Ok in order for everyone to be more clear.Attached you will find the
simple application.It doesn matter if i use two textures or just one which
at first i blit with NULL rects and then i pass a rect.

Below is the more important part.

SDL_Rect rect;

rect.x = 0;
rect.y = 0;
rect.w = 128;
rect.h = 128;

SDL_LockTexture(MooseTexture,NULL,&texture_surface->pixels,&texture_surface->pitch);
SDL_BlitSurface((SDL_Surface*)surface, NULL, texture_surface,NULL);
SDL_UnlockTexture(MooseTexture);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, MooseTexture, NULL, NULL);
SDL_RenderPresent(renderer);

/* Loop, waiting for QUIT or the escape key */
while (!done) {
    while (SDL_PollEvent(&event)) {
        switch (event.type) {
        case SDL_KEYDOWN:
            if (event.key.keysym.sym == SDLK_ESCAPE) {
                done = SDL_TRUE;
            }
            break;
        case SDL_QUIT:
            done = SDL_TRUE;
            break;
        }
    }


    SDL_RenderCopy(renderer, MooseTexture, &rect, &rect);
    SDL_RenderPresent(renderer);
}

I first draw the whole texture and present and then in a loop i only draw
a portion of a texture and present.I end up seeing only the portion.You can
see than i dont call anywhere in the loop RenderClear.Only copy and present.

I have also tried with a static texture instead of streaming with the
same results.

I am using GLES2.

Please tell me if you need anything else

On Fri, Mar 8, 2013 at 6:55 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

No idea, unless texture A is broken it should work… What device is
it? It could be useful to know whether it’s OpenGL ES 1 or 2.

Also: did you try drawing more textures besides the second one? Maybe
it would help us to get more hindsight on the issue (to see if only
the first texture is skipped or all but the last).

2013/3/7, Dimitris Zenios <dimitris.zenios at gmail.com>:

Hello guys i have a problem on android

i have two textures for now lets call them textureA and textureB.I am
doing
these operations

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer,texrureA,NULL,NULL);
SDL_RenderCopy(renderer,textureB,srcrect,dstrect);
SDL_RenderPresent(renderer);

I end up with the first texture not beeing drawn and only the second
on a
black background.

It seems that somebody else had the same problem

http://forums.libsdl.org/viewtopic.php?t=7412&sid=664cf34c6d37a355564cf5c04bb0859a

Any idea?

Best Regards
Dimitris Zenios


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


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


Gabriel.

You also can’t use it on other platforms reliably. The general
recommendation on all platforms is to draw the entire scene each frame.
Hardware textures make this generally cheap.On Fri, Mar 8, 2013 at 6:32 AM, Gabriel Jacobo wrote:

I’ve discussed this with Dimitris off list, and I’ve added a note on the
README.android file regarding the use of this rendering technique.

TL;DR: AFAICT, you can’t use it on Android :slight_smile:

Sorry for the top post!

2013/3/8 Dimitris Zenios <dimitris.zenios at gmail.com>

Ok in order for everyone to be more clear.Attached you will find the
simple application.It doesn matter if i use two textures or just one which
at first i blit with NULL rects and then i pass a rect.

Below is the more important part.

SDL_Rect rect;

rect.x = 0;
rect.y = 0;
rect.w = 128;
rect.h = 128;

SDL_LockTexture(MooseTexture,NULL,&texture_surface->pixels,&texture_surface->pitch);
SDL_BlitSurface((SDL_Surface*)surface, NULL, texture_surface,NULL);
SDL_UnlockTexture(MooseTexture);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, MooseTexture, NULL, NULL);
SDL_RenderPresent(renderer);

/* Loop, waiting for QUIT or the escape key */
while (!done) {
    while (SDL_PollEvent(&event)) {
        switch (event.type) {
        case SDL_KEYDOWN:
            if (event.key.keysym.sym == SDLK_ESCAPE) {
                done = SDL_TRUE;
            }
            break;
        case SDL_QUIT:
            done = SDL_TRUE;
            break;
        }
    }


    SDL_RenderCopy(renderer, MooseTexture, &rect, &rect);
    SDL_RenderPresent(renderer);
}

I first draw the whole texture and present and then in a loop i only draw
a portion of a texture and present.I end up seeing only the portion.You can
see than i dont call anywhere in the loop RenderClear.Only copy and present.

I have also tried with a static texture instead of streaming with the
same results.

I am using GLES2.

Please tell me if you need anything else

P.S:I could not upload bg.jpeg cause of size limits.Its an empty white
background with some text in it

On Fri, Mar 8, 2013 at 10:57 AM, Dimitris Zenios < dimitris.zenios at gmail.com> wrote:

Ok in order for everyone to be more clear.Attached you will find the
simple application.It doesn matter if i use two textures or just one which
at first i blit with NULL rects and then i pass a rect.

Below is the more important part.

SDL_Rect rect;

rect.x = 0;
rect.y = 0;
rect.w = 128;
rect.h = 128;

SDL_LockTexture(MooseTexture,NULL,&texture_surface->pixels,&texture_surface->pitch);
SDL_BlitSurface((SDL_Surface*)surface, NULL, texture_surface,NULL);
SDL_UnlockTexture(MooseTexture);

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, MooseTexture, NULL, NULL);
SDL_RenderPresent(renderer);

/* Loop, waiting for QUIT or the escape key */
while (!done) {
    while (SDL_PollEvent(&event)) {
        switch (event.type) {
        case SDL_KEYDOWN:
            if (event.key.keysym.sym == SDLK_ESCAPE) {
                done = SDL_TRUE;
            }
            break;
        case SDL_QUIT:
            done = SDL_TRUE;
            break;
        }
    }


    SDL_RenderCopy(renderer, MooseTexture, &rect, &rect);
    SDL_RenderPresent(renderer);
}

I first draw the whole texture and present and then in a loop i only
draw a portion of a texture and present.I end up seeing only the
portion.You can see than i dont call anywhere in the loop RenderClear.Only
copy and present.

I have also tried with a static texture instead of streaming with the
same results.

I am using GLES2.

Please tell me if you need anything else

On Fri, Mar 8, 2013 at 6:55 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

No idea, unless texture A is broken it should work… What device is
it? It could be useful to know whether it’s OpenGL ES 1 or 2.

Also: did you try drawing more textures besides the second one? Maybe
it would help us to get more hindsight on the issue (to see if only
the first texture is skipped or all but the last).

2013/3/7, Dimitris Zenios <dimitris.zenios at gmail.com>:

Hello guys i have a problem on android

i have two textures for now lets call them textureA and textureB.I am
doing
these operations

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer,texrureA,NULL,NULL);
SDL_RenderCopy(renderer,textureB,srcrect,dstrect);
SDL_RenderPresent(renderer);

I end up with the first texture not beeing drawn and only the second
on a
black background.

It seems that somebody else had the same problem

http://forums.libsdl.org/viewtopic.php?t=7412&sid=664cf34c6d37a355564cf5c04bb0859a

Any idea?

Best Regards
Dimitris Zenios


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


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


Gabriel.


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

Sam Lantinga wrote:

You also can’t use it on other platforms reliably. The general recommendation on all platforms is to draw the entire scene each frame. Hardware textures make this generally cheap.

Please don’t forget that SDL is not used only for games, where it is quite normal to redraw the entire scene at every frame. ‘Normal’ applications however, e.g. musical instruments, consist of many small widgets that are modified now and then and only partially. Following your recommendation the developer would be forced to recalculate and redraw the whole screen even if only one small widget needs to be modified. Maybe the application has better things to do, e.g. calculate complex waveforms or animations.

Pure Android, without JNI, works perfectly also with partial screen updates. It is notable that after screen initialisation, the first time that one widget is modified, the entire screen is redrawn. Later on, only the widgets that are modified are recalculated and redrawn. The widgets are not double buffered, their shape is recalculated when needed. It would be very favourable if SDL for Android could mimic this behaviour.

I have the feeling that the problems as reported by the OP are similar to my experiences with SDL for Android tablets that I described two or three times in this forum. Next week I will get a very recent tablet that probably will show this bad behaviour clearly. I am hoping that my hacking skills will be sufficient to find a general solution!

Regards,
Wouter

Sam is right though, neither OpenGL nor Direct3D guarantee that the
back buffer contents will be defined after a swap, i.e. you have to
assume they’re garbage and you have to redraw the entire screen. I
believe OpenGL ES is the same in regards to this.

Widgets go through a completely different rendering pipeline as far as
I know, so they aren’t affected by this limitation.

2013/3/9, wboe <w.boeke at upcmail.nl>:> Sam Lantinga wrote:

You also can’t use it on other platforms reliably. The general
recommendation on all platforms is to draw the entire scene each frame.
Hardware textures make this generally cheap.

Please don’t forget that SDL is not used only for games, where it is quite
normal to redraw the entire scene at every frame. ‘Normal’ applications
however, e.g. musical instruments, consist of many small widgets that are
modified now and then and only partially. Following your recommendation the
developer would be forced to recalculate and redraw the whole screen even if
only one small widget needs to be modified. Maybe the application has better
things to do, e.g. calculate complex waveforms or animations.

Pure Android, without JNI, works perfectly also with partial screen updates.
It is notable that after screen initialisation, the first time that one
widget is modified, the entire screen is redrawn. Later on, only the widgets
that are modified are recalculated and redrawn. The widgets are not double
buffered, their shape is recalculated when needed. It would be very
favourable if SDL for Android could mimic this behaviour.

I have the feeling that the problems as reported by the OP are similar to my
experiences with SDL for Android tablets that I described two or three times
in this forum. Next week I will get a very recent tablet that probably will
show this bad behaviour clearly. I am hoping that my hacking skills will be
sufficient to find a general solution!

Regards,
Wouter

You can always buffer them yourself (render to a texture). Then the only
substantial logic change is to copy that buffer to the screen each frame.

Jonny DOn Sat, Mar 9, 2013 at 4:16 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

Sam is right though, neither OpenGL nor Direct3D guarantee that the
back buffer contents will be defined after a swap, i.e. you have to
assume they’re garbage and you have to redraw the entire screen. I
believe OpenGL ES is the same in regards to this.

Widgets go through a completely different rendering pipeline as far as
I know, so they aren’t affected by this limitation.

2013/3/9, wboe <w.boeke at upcmail.nl>:

Sam Lantinga wrote:

You also can’t use it on other platforms reliably. The general
recommendation on all platforms is to draw the entire scene each frame.
Hardware textures make this generally cheap.

Please don’t forget that SDL is not used only for games, where it is
quite
normal to redraw the entire scene at every frame. ‘Normal’ applications
however, e.g. musical instruments, consist of many small widgets that are
modified now and then and only partially. Following your recommendation
the
developer would be forced to recalculate and redraw the whole screen
even if
only one small widget needs to be modified. Maybe the application has
better
things to do, e.g. calculate complex waveforms or animations.

Pure Android, without JNI, works perfectly also with partial screen
updates.
It is notable that after screen initialisation, the first time that one
widget is modified, the entire screen is redrawn. Later on, only the
widgets
that are modified are recalculated and redrawn. The widgets are not
double
buffered, their shape is recalculated when needed. It would be very
favourable if SDL for Android could mimic this behaviour.

I have the feeling that the problems as reported by the OP are similar
to my
experiences with SDL for Android tablets that I described two or three
times
in this forum. Next week I will get a very recent tablet that probably
will
show this bad behaviour clearly. I am hoping that my hacking skills will
be
sufficient to find a general solution!

Regards,
Wouter


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

sic:

Widgets go through a completely different rendering pipeline as far as
I know, so they aren’t affected by this limitation.

No, widgets (home-made) are exactly like other items. The only difference is that they usually can accept touches or mouse clicks.

Jonny D:

You can always buffer them yourself (render to a texture). Then the only substantial logic change is to copy that buffer to the screen each frame.

That’s not realistic, there may be dozens off them. At that, in ‘normal’ applications there is no such thing as a ‘frame’. The screen has to be updated only when something visible has been modified. Meanwhile the application is doing useful other things, e.g. calculate complicated audio waveforms.

It would be nice if you could create apps that look like normal Android apps, the user should see no difference. So if native Android has no problems with partial screen updates, this should be possible with SDL-for-Android too.

Wouter

[…]

It would be nice if you could create apps that look like normal Android apps, the user
should see no difference. So if native Android has no problems with partial screen
updates, this should be possible with SDL-for-Android too.

If you want to implement “smart refresh” on a true page flipping
display (which is what you typically have on Android devices, in my
experience), you need to figure out how many pages you actually have
(usually two, but it’s possible to force three or four via the driver
in some environments), and keep one set of dirty rectangles or similar
for each page. That is, every partial screen update will eventually be
performed once for each page.

The simple, brute force variant is to simply loop { repaint_area();
swapbuffers(); } once for each page whenever you render something.

The clever, efficient variant would be to have the GPU copy repainted
areas into the other pages as needed. I’m not sure if you can
generally do this via public APIs (FBOs?), but I suspect most
environments that implement a desktop or similar over 3D accelerators
are doing this one way or another.

All that said, I believe the nice, safe, “simple,” portable approach
is still to set up VBOs or similar for your windows, GUI components
and whatnot, so you can just repaint the screen without re-rendering
all the details. This has the bonus of making translucent objects,
move/scale/zoom effects and the like easy and efficient to implement,
as each object, regardless of what it contains, is just a texture.On Sat, Mar 9, 2013 at 4:06 PM, wboe <w.boeke at upcmail.nl> wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Now we’re coming somewhere! I’m hoping that one of the SDL guru’s is willing to give his opinion. Sam, how are you doing?

Sam Lantinga wrote:

You also can’t use it on other platforms reliably. The general recommendation on all platforms is to draw the entire scene each frame. Hardware textures make this generally cheap.

Wouter said:

Pure Android, without JNI, works perfectly also with partial screen updates. It is notable that after screen initialisation, the first time that one widget is modified, the entire screen is redrawn. Later on, only the widgets that are modified are recalculated and redrawn. The widgets are not double buffered, their shape is recalculated when needed. It would be very favourable if SDL for Android could mimic this behaviour.

It’s not just Android; these don’t always work on Mac OS X with SDL 2,
and after discussion on this list (16th Oct 2011), it was clear that
sometimes it was double buffering and other-times not (and, IIRC, even
running in a window this was true).

Mostly my game was very trivial to switch to entire screen updates - and
in fact it simplified code in the normal game (no thinking about what
had changed, no dirty areas, etc.). IIRC, the frame rate didn’t change.

However, for scene transitions it was a big pain. I’m cloning an old
Sinclair ZX Spectrum game. That computer (in the original version) has a
single video buffer - so obviously the scene transitions were
incremental. I ended up with a fake graphics engine that just recorded
all draw commands, and then could replay these through the proper
graphics engine. (I considered other strategies, and this looked like
the fastest option based on how my game code was structured).

However, I don’t see how easily you can do this with a double buffering
/ page flipping display … I’d like an incremental rendering option
with SDL, but I think it would be better to find a strategy for these
types of cases.

Regards,
Rob

2013/3/9 David Olofson > On Sat, Mar 9, 2013 at 4:06 PM, wboe <w.boeke at upcmail.nl> wrote:

[…]

It would be nice if you could create apps that look like normal Android
apps, the user
should see no difference. So if native Android has no problems with
partial screen
updates, this should be possible with SDL-for-Android too.

If you want to implement “smart refresh” on a true page flipping
display (which is what you typically have on Android devices, in my
experience), you need to figure out how many pages you actually have
(usually two, but it’s possible to force three or four via the driver
in some environments), and keep one set of dirty rectangles or similar
for each page. That is, every partial screen update will eventually be
performed once for each page.

That’s probably the case in the majority of devices, however, according to
this technical note [1], the buffers may or may not be preserved.

As it’s been mentioned previously, if you really want to do it this way,
render to a texture as if you were rendering to the screen, then render
that texture to the actual screen buffer.

[1] http://www.khronos.org/registry/egl/specs/EGLTechNote0001.html


Gabriel.