741 Commits

Author SHA1 Message Date
Misa
66a08aa391 Add and use SDL_FALLTHROUGH for fallthroughs
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.

So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).

Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).

All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
2021-11-11 07:23:25 -08:00
Sam Lantinga
6c4b4ee7a6 Don't assert on API parameters
This causes lots of spam in test automation and it's not clear it's useful to developers. If we need this level of validation, we should add a log category for it.
2021-11-10 09:41:43 -08:00
Sam Lantinga
3a31a45028 End the scene before resetting the D3D device, since we'll start with BeginScene after that.
If we don't do this, we'll end up with unbalanced Begin/End scene pairs which causes D3DERR_INVALIDCALL in the present.

Fixes https://github.com/libsdl-org/SDL/issues/4933
2021-11-10 05:24:31 -08:00
Eric Wasylishen
0d98793693
testwm2: Fix video modes menu hit detection when highdpi or logical size used (#4936)
* SDLTest_CommonDrawWindowInfo: log SDL_RenderGetScale, SDL_RenderGetLogicalSize

* testwm2: fix video modes menu hit detection in High DPI cases

- also when logical size is specified, e.g.
  `--logical 640x480 --resizable --allow-highdpi`

* add function to determine logical coordinates of renderer point when given window point

* change since to the targeted milestone

* fix typo

* rename for consistency

* Change logical coordinate type to float, since we can render with floating point precision.

* add function to convert logical to window coordinates

* testwm2: use new SDL_RenderWindowToLogical

* SDL_render.c: alternate SDL_RenderWindowToLogical/SDL_RenderLogicalToWindow

Co-authored-by: John Blat <johnblat64@protonmail.com>
Co-authored-by: John Blat <47202511+johnblat64@users.noreply.github.com>
2021-11-09 21:03:42 -08:00
Ryan C. Gordon
04f42e0468 metal: Deal better with -[CAMetalLayer nextDrawable] returning nil.
Fixes #4863.
2021-11-09 12:03:12 -05:00
Sam Lantinga
637bcd0b72 Fixed build warnings 2021-11-07 11:19:07 -08:00
Ivan Epifanov
848d7b1254 Vita: Implement command batching 2021-11-02 13:43:22 -07:00
Ivan Epifanov
3f7a94fc94 Vita: Remove FillRects 2021-11-02 13:43:22 -07:00
Northfear
fba82ad1cb Remove sceGxmFinish from RenderPresent on Vita. Make sure that rendering is finished on render texture during locking 2021-10-31 09:17:13 -04:00
Sylvain
4960cc3dcb
Fixed a few warnings 2021-10-25 16:18:40 +02:00
Sylvain
b793394590
SDL_Renderer: make clear that we use render geometry for fillrect/copy/copyex when there is no specific back-end implementation (currently software, PSP, directfb) 2021-10-25 13:46:40 +02:00
Ozkan Sezer
b3f9d8f38d remove unused local vars after the latest commits. 2021-10-25 07:05:50 +03:00
Sylvain
502e9c3b45 SDL_Renderer simplifications:
- Factorize PrepQueueCmdDraw{,DrawTexture,Solid) into one single function
- Change SDL_Texture/Renderer r,g,b,a Uint8 into an SDL_Color, so that it can be passed directly to RenderGeometry
- Don't automatically queue a SET_DRAW_COLOR cmd for RenderGeometry (and update GLES2 renderer)
2021-10-24 22:27:56 -04:00
Sylvain
79732c9d1e Remove FillRects from back-end, where RenderGeometry can be used 2021-10-24 22:27:56 -04:00
Sylvain
f02ad2820f Remove FillRects from back-end, where RenderGeometry can be used 2021-10-24 22:27:56 -04:00
Sylvain
70b10c753d Use correct indices when using RenderGeometry / FillRects 2021-10-24 22:27:56 -04:00
Sylvain
16beed9aeb Less code since color is constant when done with triangles 2021-10-24 22:27:56 -04:00
Sylvain
99a346439c OpenGLES2: LINES and POINTS successive commands are combined into a single draw call
(using the same case for DRAW_GEOMETRY)
2021-10-24 22:27:56 -04:00
Sylvain
f0cdc1d0f6 OpenGLES2: remove FillRects, since it's can be done with RenderGeometry 2021-10-24 22:27:56 -04:00
Sylvain
37c39d5cb4 Use geometry to implement FillRects 2021-10-24 22:27:56 -04:00
Sylvain
b0eef52fe1 GLES2 batching: probably need to check for blendMode changes 2021-10-24 22:27:56 -04:00
Sylvain
c27e1249e1 Remove SDL_HAVE_RENDER_GEOMETRY define 2021-10-24 22:27:56 -04:00
Sylvain
77026f673b Metal: remove RenderCopy and RenderCopyEx from back-end 2021-10-24 22:27:56 -04:00
Sylvain
0e5160a056 VITA: remove RenderCopy and RenderCopyEx from back-end 2021-10-24 22:27:56 -04:00
Sylvain
73f4ab4c13 Direct3D11: remove RenderCopy and RenderCopyEx from back-end 2021-10-24 22:27:56 -04:00
Sylvain
ab758398af Direct3D: remove RenderCopy and RenderCopyEx from back-end 2021-10-24 22:27:56 -04:00
Sylvain
1fe7e3616b OpenGL: a few opengl functions become unused 2021-10-24 22:27:56 -04:00
Sylvain
88548070a5 OpenGLES: remove RenderCopy and RenderCopyEx from back-end 2021-10-24 22:27:56 -04:00
Sylvain
d192515428 OpenGL: remove RenderCopy and RenderCopyEx from back-end 2021-10-24 22:27:56 -04:00
Sylvain
b92056bbea OpenGLES2: remove RenderCopy and RenderCopyEx from back-end 2021-10-24 22:27:56 -04:00
Sylvain
76f9fb96d9 Use RenderGeometry to implement RenderCopy and RenderCopyEx at higher level 2021-10-24 22:27:56 -04:00
Ryan C. Gordon
08797adaef opengles2: Attempt to batch RenderCopy calls into a single glDrawArrays call. 2021-10-24 22:27:56 -04:00
Sam Lantinga
b360965d0d Added a hint for alternate OpenGL NV12 data format 2021-10-21 20:48:05 -07:00
Sam Lantinga
a34fe8161f Added the ability to bind NV12 textures in the OpenGL renderer 2021-10-21 12:28:35 -07:00
Sylvain
f080273acd
PSP: add implementation for RenderGeometry 2021-10-04 22:01:11 +02:00
Sylvain
dd9b2daf8d
PSP: fixed build 2021-10-04 21:56:42 +02:00
Sylvain
77acd44f28
DirectFB: fixed creation of palette textures 2021-10-01 22:30:51 +02:00
Ryan C. Gordon
114d1d46ac
direct3d: Remove unnecessary render target support check.
Direct3D 9 dictates that caps.NumSimultaneousRTs must always be at least 1,
which is to say that Direct3D 9 level hardware must always support render
targets.

(caps.NumSimultaneousRTs is meant to show if you can draw to multiple render
targets in a single draw call.)

We had already hardcoded SDL_RENDERER_TARGETTEXTURE as available earlier in
the function anyhow.

Fixes #4781.
2021-09-27 23:18:25 -04:00
Northfear
14f225198d Use SDL_calloc for allocation of gxm_texture 2021-09-26 14:16:35 -07:00
Northfear
5292156398 End Scene on RunCommandQueue on Vita 2021-09-22 11:54:26 -07:00
Sam Lantinga
eb3bf80f9c Fixed compiler warnings using Visual Studio 2019 2021-09-21 18:15:09 -07:00
Northfear
3b2fbb1cb7 End current scene before destroying the texture on Vita 2021-09-20 15:55:36 -07:00
Northfear
fc4296c114 Use aligned stride in sceGxmColorSurfaceInit 2021-09-20 13:23:42 -07:00
Northfear
7080bc2a91 Fallback to SCE_KERNEL_MEMBLOCK_TYPE_USER_RW_UNCACHE if CDRAM texture allocation fails 2021-09-20 13:23:42 -07:00
Ryan C. Gordon
ca9a321715
render: GL/GLES now draw lines almost perfectly matching software renderer.
One place known to differ in a significant way is a single line segment that
starts and ends on the same point; the GL renderers will light up a single
pixel here, whereas the software renderer will not. My current belief is this
is a bug in the software renderer, based on the wording of the docs:

"SDL_RenderDrawLine() draws the line to include both end points."

You can see an example program that triggers that difference in Bug #2006.

As it stands, the GL renderers might _also_ render diagonal lines differently,
as the the Bresenham step might vary between implementations (one does three
pixels and then two, the other does two and then three, etc). But this patch
causes those lines to start and end on the correct pixel, and that's the best
we can do, and all anyone really needs here.

Not closing any bugs with this patch (yet!), but here are several that it
appears to fix. If no other corner cases pop up, we'll call this done.

Reference Bug #2006.
Reference Bug #1626.
Reference Bug #4001.
...and probably others...
2021-09-19 15:47:24 -04:00
Ryan C. Gordon
857cc7c0c9
render: constified some local variables in SDL_AllocateRenderVertices. 2021-09-19 00:38:06 -04:00
Ryan C. Gordon
5faea84c63
render: Mark viewport/cliprect dirty when window is resized.
Fixes #4751.
2021-09-18 11:54:25 -04:00
Ivan Epifanov
79ec8986d3 Vita: refactor gxm texture render and add SDL_RenderGeometry support 2021-09-16 09:03:17 -07:00
Misa
4a9947336c SDL_RenderSetVSync(): Restrict vsync to 0 or 1
In the future, we might want to support special swap intervals. To
prevent applications from expecting nonzero values of vsync to be the
same as "on", fail with SDL_Unsupported() if the value passed is neither
0 nor 1.
2021-09-14 16:18:02 -07:00
Misa
4549769d7d Add SDL_RenderSetVSync()
Currently, if an application wants to toggle VSync, they'd have to tear
down the renderer and recreate it. This patch fixes that by letting
applications call SDL_RenderSetVSync().

This is the same as the patch in #3673, except it applies to all
renderers (including PSP, even thought it seems that the VSync flag is
disabled for that renderer). Furthermore, the renderer flags also change
as well, which #3673 didn't do. It is also an API instead of using hint
callbacks (which could be potentially dangerous).

Closes #3673.
2021-09-14 09:56:29 -07:00