Add initial port of SDL3 #23630
Add initial port of SDL3 #23630
Conversation
sbc100
force-pushed
the
sdl3_port
branch
2 times, most recently
from
86d9a5f to
0a999bd
Compare
| 'video/offscreen/*.c', | ||
| 'audio/disk/*.c', | ||
| 'loadso/dlopen/*.c', | ||
| # Dummy backends, do we need to support these? |
There was a problem hiding this comment.
@slouken, sorry for another dumb question, but do you think its worth including the dummy backends? I guess it will increase code size, but maybe allow SDL3 to be used in more cases/places?
There was a problem hiding this comment.
I'm not sure how useful they are for emscripten, maybe if someone needs to disable audio or something like that? @icculus, thoughts?
| # symbols in the library (because LINKABLE includes the entire library). | ||
| self.emcc_args.append('-Wno-experimental') | ||
| self.emcc(test_file('browser/test_sdl3_misc.c'), ['-sLINKABLE', '-sUSE_SDL=3'], output_filename='a.out.js') | ||
| self.emcc(test_file('browser/test_sdl3_misc.c'), ['-sLINKABLE', '--use-port=sdl3'], output_filename='a.out.js') |
There was a problem hiding this comment.
Why test both ways of including SDL3 here? isn't that just a linker UI feature (not related to linkable/undefined symbols)?
There was a problem hiding this comment.
Yes, its just two ways to link the same library. Testing that both work. This a direct copy of the SDL2 test right above.
|
lgtm otherwise. |
So far I haven't got any browser tests working. Fixes: emscripten-core#23608
|
@sbc100 I guess I am late, but I wonder why did you choose to do |
|
@sbc100 I was also in the process of doing the sdl3 port... so here is my version The way I did is "scientific": I ran the emcmake / cmake build. I took the output of the run which generated the exact list of files that are compiled ( Hope this helps |
Both syntax's are supported. Since the |
This port also uses the The one modification I made to it was to allow a single |
|
@sbc100 I guess you can do whatever you want but I personally don't like the addition of the So far all ports have been self-contained and I feel it is better that way. I also demonstrated in the sdl3.py file I just posted in my previous message that you can simply include the .h inside the port file (and BTW other ports do it as well) |
Indeed, it could be argued that self-contained headers are better. However I've always found a it rather odd to have large amounts of C/C++ header code inside of python strings. I've always been hoping to find a way to avoid that, and this is my first attempt. I was thinking of following up with the extraction of such headers into their own files for other ports. I get that for external ports its kind of nice to represent them as a single file, so there are arguments both ways. |
|
I created a PR to inline the header for now: #23660 I may try to un-inline all of these headers in the future, but I agree that being consistent is good for now. |
I just got a couple of test working, but everything seems good so far.
Fixes: #23608