-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] Add PLATFORM_WEB_SDL
#3537
Conversation
@raysan5 If you agree with this platform addition and changes, I think this batch is ready for merge. 👍 |
@ubkp thanks for working on this improvement, I see that at this moment this is mostly a replica of Maybe the SDL web support can be addressed in some other way, in building side only with some extra flag (actually I keep this PR open for discussion as long as you are also testing it but for now, I'm not merging more big changes until |
@raysan5 It could share the same code as
Would you like me to proceed? |
It seems that there are changes to I think it is a good "example" of what is necessary to add a new platform as it clearly shows that there are multiple pieces to change (like One way that comes to mind would be to have a platform definition file (format tbd, but simple), that could define what it needs and that would be turned (via a small tool) into the proper defines that way the code could remain generic. Something like:
If a new platform gets added and it uses OPENGL_ES2 the generic code does not need to change... That is clearly beyond the scope of this PR but I find this PR interesting for that reason... |
|
True in this instance without any changes, but not "obviously, unavoidable" in the future. I can think of another way to do it: // PLATFORM_INCLUDE_IMPLEMENTATION is a define containing the c file implementation (replaces 16 lines of code in rcore.c...)
#include PLATFORM_INCLUDE_IMPLEMENTATION |
Actually, nevermind, I'm out. I'm spending more time having to argue against overengineering or suboptimal changes than actually fixing code. And what's the point of fixing something only to watch software regression later. It's much easier to just continue on my own. Good luck. P.S.: please don't reopen this. |
@ubkp For what it is worth, I wasn't arguing about your changes, on the contrary I was just pointing out that this was a very interesting example that demonstrates what was truly required to add a new platform in the current version of raylib. And I was merely suggesting that, if interested, there are options to do it better, way down the line in the future (raylib 6.0?). Not let's change the world before applying your PR... |
I don't mean it in a negative way, but this seems kind of pointless, compared to the maintainance cost it adds, it's not exposing the web APIs directly in a way that matters I think ideal would be a PLATFORM_WEB that doesn't use either of those, but emscripten APIs directly. Though, I don't know what kind of effort that would take, and whether it would be worth it either |
@ubkp I'm sorry to read your last message and I don't understand how the conversation derived to this point. You did an amazing work in those last months and if today the platform-split is a reality is thanks to your contributions. Hopefully you continue contributing to the project in a future. At the moment I'm quite overload with the preparation of the new In any case, this kind of board-style asynchronous conversation could be a bit difficult to follow and discuss important topics, feel free to write me to [email protected] or find me on Discord raylib community. |
@Peter0x44 I personally believe there are advantages over library_glfw.js . Looking at @ubkp implementation, I can see that a lot of calls are now implemented because they have an SDL equivalent where in the glfw implementation they are marked non implemented. Also from my experience looking at the emscripten code, SDL seems to be more supported than GLFW. For example if you look at the number of tests for SDL vs GLFW, there is a clear winner. Looking at the emscripten documentation:
which is a clear indication that the most supported platform is SDL. I think there is a very valid case for raylib to experiment with a different web platform implementation, like this one based on SDL. Especially since, with the platform split, it doesn't affect the other platforms. I also think that waiting after raylib 5.0 is definitely the way to go though. |
Changes
Adds the
PLATFORM_WEB_SDL
. Does that by:rcore_web_sdl.c
toplatforms
(R1);rcore.c
(R17-R18, R240, R492-R493, R562-R563, R3052);rlgl.c
(R813, R2276).Adds
PLATFORM_WEB_SDL
to theMakefile
(R18-R19, R119, R161, R169, R238-R241, R271, R314, R330, R349, R446-R448, R607).Adds
PLATFORM_WEB_SDL
to the examples Makefiles:Makefile
: R18-R19, R91, R142, R168, R187, R206, R210, R256, R300-R302, R303, R318-R323, R433, R619, R644.Makefile.Web
: R36-R37, R53-R56, R63, R114, R140, R159, R178, R182, R228-R230, R255-R257, R258, R274-R279, R348, R1134.Applies [core] Fix missing keys on
PLATFORM_DESKTOP_SDL
#3539 fix toPLATFORM_WEB_SDL
(R77, R178-R199).Notes
rcore_web_sdl.c
at this moment is almost the same asrcore_desktop_sdl.c
and have been working great on my preliminary tests. I'll now go function by function testing and inspecting what or if something needs to be changed.As with
PLATFORM_DESKTOP_SDL
, the user should provide theSDL2
library.Environment
Compiled on Linux (Ubuntu 22.04 64-bit) with SDL2 (2.28.5) and Emscripten (3.1.48).
Tested on Firefox (115.3.1esr 64-bit) and Chromium (117.0.5938.149 64-bit) running on Linux (Mint 21.1 64-bit).
Edits
Makefile
changes.