I’ve just started a closed beta for my game based on SDL 2 (2.0.3) and one
of the testers reported a very weird behaviour when running the game on a
Samsung S3 (Android 4.3).
Basically every colour is turned into red as showed in the pics you can
find here:
That guy was experiencing this problem on a Galaxy Note 10.1 which has a
Mali-400MP4 as GPU, the same used by the S3. My game works fine on a Sony
Xperia U with a Mali-400 instead. So it seems to be very specific to that
particular GPU.
This is a known issue, take a look at Bugzilla for a few workarounds.
2015-09-04 12:42 GMT-03:00 Davide Coppola :> Hi everyone,
I’ve just started a closed beta for my game based on SDL 2 (2.0.3) and one
of the testers reported a very weird behaviour when running the game on a
Samsung S3 (Android 4.3).
Basically every colour is turned into red as showed in the pics you can
find here: http://imgur.com/a/dvris
The most weird thing is that if he takes a screenshot the images come up
with the right colours.
That guy was experiencing this problem on a Galaxy Note 10.1 which has a
Mali-400MP4 as GPU, the same used by the S3. My game works fine on a Sony
Xperia U with a Mali-400 instead. So it seems to be very specific to that
particular GPU.
i see that info.flags is set to 10, which is b00001010 so flags SDL_RENDERER_ACCELERATED and SDL_RENDERER_TARGETTEXTURE are set, SDL_RENDERER_SOFTWARE and SDL_RENDERER_PRESENTVSYNC are off
then when calling
long x = SDL_GetTicks();
SDL_RenderPresent(m_main_renderer); // swap();
long y = SDL_GetTicks();
if (y > x+1)
{
std::wstring s=L"present time ";
s += ltow(y-x,NULL);
ppw_debug_string(s);
}
I get times between 2msec and 15msec…
any suggestions ?
the time is never more than 15msec, which makes me think of a vsync issue? but that flag is off? could it be ?
The resolution of the timer might not be high enough to do the measurement.
Use a high precision timer.Am 05.09.2015 09:40 schrieb “jeroen clarysse” <jeroen.clarysse at telenet.be>:
in my app, i notice that calling SDL_RenderPresent() takes at least
4msecs, sometimes up to 15msec !
i wonder why this is so slow ? The actual drawing and bltting is always
done in less than a msec, but presenting takes longer ?
i see that info.flags is set to 10, which is b00001010 so flags
SDL_RENDERER_ACCELERATED and SDL_RENDERER_TARGETTEXTURE are set,
SDL_RENDERER_SOFTWARE and SDL_RENDERER_PRESENTVSYNC are off
then when calling
long x = SDL_GetTicks();
SDL_RenderPresent(m_main_renderer); // swap();
long y = SDL_GetTicks();
if (y > x+1)
{
std::wstring s=L"present time ";
s += ltow(y-x,NULL);
ppw_debug_string(s);
}
I get times between 2msec and 15msec…
any suggestions ?
the time is never more than 15msec, which makes me think of a vsync issue?
but that flag is off? could it be ?
i see that info.flags is set to 10, which is b00001010 so flags
SDL_RENDERER_ACCELERATED and SDL_RENDERER_TARGETTEXTURE are set,
SDL_RENDERER_SOFTWARE and SDL_RENDERER_PRESENTVSYNC are off
then when calling
long x = SDL_GetTicks();
SDL_RenderPresent(m_main_renderer); // swap();
long y = SDL_GetTicks();
if (y > x+1)
{
std::wstring s=L"present time ";
s += ltow(y-x,NULL);
ppw_debug_string(s);
}
I get times between 2msec and 15msec…
any suggestions ?
the time is never more than 15msec, which makes me think of a vsync issue?
but that flag is off? could it be ?
are you sure ? I?m on OSX and I figured SDL_GetTicks() was accurate enough up to a msec ?
if I look at my mainloop, the value of SDL_GetTicks increments nicely?> On 05 Sep 2015, at 10:19, M. Gerhardy <martin.gerhardy at gmail.com> wrote:
The resolution of the timer might not be high enough to do the measurement. Use a high precision timer.
Am 05.09.2015 09:40 schrieb “jeroen clarysse” <@Jeroen_Clarysse>:
in my app, i notice that calling SDL_RenderPresent() takes at least 4msecs, sometimes up to 15msec !
i wonder why this is so slow ? The actual drawing and bltting is always done in less than a msec, but presenting takes longer ?
i see that info.flags is set to 10, which is b00001010 so flags SDL_RENDERER_ACCELERATED and SDL_RENDERER_TARGETTEXTURE are set, SDL_RENDERER_SOFTWARE and SDL_RENDERER_PRESENTVSYNC are off
then when calling
long x = SDL_GetTicks();
SDL_RenderPresent(m_main_renderer); // swap();
long y = SDL_GetTicks();
if (y > x+1)
{
std::wstring s=L"present time ";
s += ltow(y-x,NULL);
ppw_debug_string(s);
}
I get times between 2msec and 15msec…
any suggestions ?
the time is never more than 15msec, which makes me think of a vsync issue? but that flag is off? could it be ?
On Sat, Sep 5, 2015 at 1:10 PM, jeroen clarysse <@Jeroen_Clarysse> wrote:
in my app, i notice that calling SDL_RenderPresent() takes at least 4msecs, sometimes up to 15msec !
i wonder why this is so slow ? The actual drawing and bltting is always done in less than a msec, but presenting takes longer ?
i see that info.flags is set to 10, which is b00001010 so flags SDL_RENDERER_ACCELERATED and SDL_RENDERER_TARGETTEXTURE are set, SDL_RENDERER_SOFTWARE and SDL_RENDERER_PRESENTVSYNC are off
then when calling
long x = SDL_GetTicks();
SDL_RenderPresent(m_main_renderer); // swap();
long y = SDL_GetTicks();
if (y > x+1)
{
std::wstring s=L"present time ";
s += ltow(y-x,NULL);
ppw_debug_string(s);
}
I get times between 2msec and 15msec…
any suggestions ?
the time is never more than 15msec, which makes me think of a vsync issue? but that flag is off? could it be ?
That seems to be a list of flags supported by the renderer.
Now that you’ve mentioned that, I think it is probably not the renderer,
but the graphics driver that is enforcing vsync.
You could try running other 3D programs and see if they are too bound by
vsync. This issue has come up more than once in this list, and I think that
was the reason.
Measuring the fps of you app without fps guard is the clear way to
verify you problem.On Sat, Sep 5, 2015 at 4:59 PM, Pallav Nawani wrote:
That seems to be a list of flags supported by the renderer.
Now that you’ve mentioned that, I think it is probably not the renderer, but
the graphics driver that is enforcing vsync.
You could try running other 3D programs and see if they are too bound by
vsync. This issue has come up more than once in this list, and I think that
was the reason.
Measuring the fps of you app without fps guard is the clear way to
verify you problem.
hm, i dont know : simply measuring the time before and after presenting (swap) should detect this too… I could also inspect the time difference between AFTER and BEFORE, and add that to the difference between BEFORE and AFTER. Together, if this becomes a constant, will be the VSYNC time if VSYNC is on. Unless there is some weird thing going on that also adds up wasting the same amount of time EVERY time
Most Likely, the renderer is ignoring SDL_RENDERER_PRESENTVSYNC and
enforcing Vsync anyway.
This reminds me, there are two ways to enable vsync (that flag and a
hint), but only one of them actually works… but I can’t remember
which one :O) I had stumbled upon this with Sol before and my solution
was just to set both things to be safe.
The hint is SDL_HINT_RENDER_VSYNC if I recall correctly.
I wonder why SDL requests a R3 G3 B2 (8-bit) system GL framebuffer by default in the first place. I?d expect SDL to default to at least 5,6,5 (16-bit) ? sane systems will probably just give back 16 or 24/32 bit when 8 bit is requested, in any case.
Ryan / Sam: would you object to changing the default RGB bit sizes that SDL requests for the system GL framebuffer from 3,3,2 to 5,6,5?> On Sep 5, 2015, at 1:52 PM, Owen Alanzo Hogarth wrote:
I had this issue on a samsung device. I was able to solve it by adding this code before my window create call.
I always thought that the default size of the rgb bitfields depended on
system capabilities.On Sat, Sep 5, 2015 at 12:27 PM, Alex Szpakowski wrote:
I wonder why SDL requests a R3 G3 B2 (8-bit) system GL framebuffer by
default in the first place. I?d expect SDL to default to at least 5,6,5
(16-bit) ? sane systems will probably just give back 16 or 24/32 bit when 8
bit is requested, in any case.
Ryan / Sam: would you object to changing the default RGB bit sizes that
SDL requests for the system GL framebuffer from 3,3,2 to 5,6,5?
On Sep 5, 2015, at 1:52 PM, Owen Alanzo Hogarth wrote:
I had this issue on a samsung device. I was able to solve it by adding
this code before my window create call.
But systems are allowed to actually use larger sizes than what was requested (and they definitely do in practice.) The 3-3-2 request just seems to screw up colors on some Android devices.> On Sep 5, 2015, at 4:31 PM, Raymond Jennings wrote:
I always thought that the default size of the rgb bitfields depended on system capabilities.
Your video driver probably comes with a way to force VSYNC off no
matter what the app asks for, so you can try that.
Calling a “Draw” function using Direct3D/OpenGL doesn’t draw
anything. It just places commands into a queue to be processed
asynchronously by the GPU. If you Present before rendering has finished,
Present will block.On 05/09/2015 3:40 AM, jeroen clarysse wrote:
in my app, i notice that calling SDL_RenderPresent() takes at least 4msecs, sometimes up to 15msec !
i wonder why this is so slow ? The actual drawing and bltting is always done in less than a msec, but presenting takes longer ?
i see that info.flags is set to 10, which is b00001010 so flags SDL_RENDERER_ACCELERATED and SDL_RENDERER_TARGETTEXTURE are set, SDL_RENDERER_SOFTWARE and SDL_RENDERER_PRESENTVSYNC are off
then when calling
long x = SDL_GetTicks();
SDL_RenderPresent(m_main_renderer); // swap();
long y = SDL_GetTicks();
if (y > x+1)
{
std::wstring s=L"present time ";
s += ltow(y-x,NULL);
ppw_debug_string(s);
}
I get times between 2msec and 15msec…
any suggestions ?
the time is never more than 15msec, which makes me think of a vsync issue? but that flag is off? could it be ?
I?ll have multiple graphs at the same time to be displayed on the 2nd monitor. Data from these graphs is accumulated in a separate thread and stored in arrays of doubles. What is the fastest/best way to draw these graphs (separately, on different sections of the screen) ?
a) directly to the renderer with SDL_RenderDrawPoints()
b) to a surface by getting a pointer to the pixels , setting the proper pixels and then blitting the surface to the renderer
c) idem as b, but to a texture ?
I?ll have multiple graphs at the same time to be displayed on the 2nd
monitor. Data from these graphs is accumulated in a separate thread and
stored in arrays of doubles. What is the fastest/best way to draw these
graphs (separately, on different sections of the screen) ?
a) directly to the renderer with SDL_RenderDrawPoints()
b) to a surface by getting a pointer to the pixels , setting the proper
pixels and then blitting the surface to the renderer
c) idem as b, but to a texture ?
