if all one needs is a raw framebuffer to the PSP's vram,
instead of dealing with renderers and textures, that need to be
copied hence and forth, this method allows one to create a window,
set the pixel format using SDL_SetWindowDisplayMode() - preferably
BGR565 for optimal speed (the other possible natively supported
option is ABGR8888) - and then request SDL_GetWindowSurface(),
which provides one with a surface with direct framebuffer access.
note that the pixels pointer inside the surface will be switched
after each call because of double-buffering.
it's advisable to overwrite all pixels of the PSP visible area
(480x272) to not encounter old data.
after writing the pixels, a call to SDL_UpdateWindowSurface()
sends the changes to the graphics chip.
the result is a raw framerate of 250 fps with BGR565 mode, under
optimal circumstances - i.e. nothing else is done than drawing,
and the drawing loop is as simple as possible.
that leaves about 12 ms per frame for other tasks and still allow
a fluent 60 fps.
like SDL_triangle.c:305:30: runtime error: left shift of negative value -672
(even if the value was correctly computed)
(cherry picked from commit 4033a0a83b)
The previous code was working incorrectly on viewports not having the
top left corner on the origin: even in those cases we only need to look
at the width and height of the viewport, because the drawing coordinates
are translated.
Fixes#8828
Battle for Wesnoth apparently relies on being able to disable rendering
of UI elements by setting the clip rectangle to be empty.
Resolves: https://github.com/libsdl-org/SDL/issues/6896
Fixes: 00f05dcf "render: only enable clipping when the rectangle is valid"
Signed-off-by: Simon McVittie <smcv@collabora.com>
On some system like MacBook Pro Intel with AMD card, asking for the default device will always return the AMD GPU.
This is not an issue for 99% of the case when the renderer context is here to provide the maximum performance level like for game.
However, for video application using GPU for 1 quad and 1 texture, using the discrete GPU for that lead to an important power consumption (4 to 8W), heat increase, and fan noise.
With this patch, I successfully amend ffplay to only use the integrated GPU (i.e. the Intel one), instead of the discrete GPU (i.e. the AMD one).
Also, for some reason ID3D11DeviceContext_OMGetRenderTargets() was failing in the second read pixels call in the "testautomation --filter render_testViewport" test.
We already know the target view, so just use that.
(cherry picked from commit 619f65af0c)
Don't use the viewport offset when setting the clip rect in the D3D12 renderer.
This fixes "testautomation --filter render_testViewport" on Windows
(cherry picked from commit 304d425f99)
Fixes DPI awareness of testdrawchessboard (previously, the surface was
being created in points instead of pixels, resulting in the demo app
only drawing in a corner of the screen on High-DPI displays)
*_CreateWindowFramebuffer()/*_UpdateWindowFramebuffer(): are updated
to use SDL_GetWindowSizeInPixels instead of SDL_GetWindowSize() or
window->w/window->h.
Most of the _CreateWindowFramebuffer backends are untested except
for Windows.
Fixes#7047
(cherry picked from commit 67c91353e0)
This lets the user to correctly detect current vsync state by reading SDL_RendererInfo.
Also fixes SetVSync's return value check (it may be positive for error too).
Anonymous Maarten
rofl0r
Sam Lantinga
Ozkan Sezer
Francisco Javier Trujillo Mata
Ethan Lee
Sylvain
Alberto Mardegan
Ryan C. Gordon
Cameron Cawley
Anonymous Maarten
Simon McVittie
Jeremy Demeule
Eric Wasylishen
Ivan Mogilko
ds-sloth