The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 wrote:

2013/3/8 Dimitris Zenios




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 :)


Sorry for the top post!


2013/3/8 Dimitris Zenios




--
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:

Sam Lantinga wrote:

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:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 D



On Sat, Mar 9, 2013 at 4:16 AM, Sik the hedgehog wrote:

sic:

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

Jonny D:

That's not realistic, there may be dozens of 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

On Sat, Mar 9, 2013 at 4:06 PM, wboe wrote:
[...]

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.


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

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.net http://olofsonarcade.com |
'---------------------------------------------------------------------'
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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?

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



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/3/9 David Olofson


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.