[core] Splitting `rcore` by platform into submodules

[michaelfiber]

Issue description

As part of my experimenting in pr #3311 to divide rcore into submodules, one of the things I found was that the CoreData structure adds a lot of complexity to that endeavor and MAY benefit from being split up as well. I believe it may benefit because the current CoreData structure can be fairly difficult to understand with the large number of preprocessor directives within the struct itself. This is largely done to accommodate the many different target platforms. But if rcore is divided into different submodules based on platforms there is an opportunity to increase clarity.

Here are a couple of initial ideas for approaches:

1. Maintain a single instance of CoreData but have CoreData only contain data that all submodules use so that it is a simpler struct with no preprocessor directives. A single CORE instance would be defined extern in rcore.h, defined in rcore.c, and accessed from rcore.c and all the submodules. In addition to this each submodule would have a small CoreData like struct of its own, i.e. DesktopData, WebData, etc. The data that is currently in CoreData that is specific to an submodule would be moved to the data struct in that submodule. Each struct definition would become much more legible because it wouldn't be full of preprocessor directives but there would be more structs overall and they'd be more spread out instead of centralized in rcore.

2. Another option could be to have the CoreData struct defined entirely within a submodule specific header file so that each submodule has a complete CoreData struct and rcore.c can include a specific one based on the PLATFORM variable. There'd be more duplication but fewer structs and data would not be divided across multiple structs. Any changes to the data in CoreData that is used by all submodules would require applying the change to each submodule.

Personally I'm leaning towards the first option but am interested in what others think.

Environment

Experiments are being coded in Ubuntu 23.04 and leverage github actions to attempt to run build steps for all platforms.

Code Example

#3311

Under approach 1, what would happen to a member that is used, lets say, by PLATFORM_DESKTOP and PLATFORM_WEB but not PLATFORM_ANDROID nor PLATFORM_DRM.

Would it be under rcore?

Or not in rcore but duplicated on rcore_desktop and on rcore_web?

[raysan5]

I think both approaches have pros and cons.

• 1 keeps a common unified structure for all platforms with just "some" static additional variables per module (duplicated if required, @ubkp) but makes it more difficult to create multi-windows applications in case it was needed, because of those same custom variables, some pieces of data are spread around.
• 2 allows more customization per platform and makes the modules more self-contained per platform, but also increases the complexity dealing with multiple duplicated structs, if a change is needed, it should be maybe propagated to all platforms, for example, recently some new variables were added.

I think the best option could be 1, despite the cons. concerns. I think the number of custom variables is not that big and it should be easier to manage if well organized and documented in the code.

In an ideal scenario, the "extra" required variables could be, maybe, removed or integrated in some way into the main CoreData struct... Actually, that's another possibility, just keep everything in CoreData independently of the platform, beeing used or not. Probably the overload won't be that dramatic...

[raysan5]

EDIT: Copying the info from wishlist for reference:

• REDESIGN: Module subdivision. This module has grown a lot with every new supported platform (~7000 loc), at some point it could be divided into separate modules. Two possible approaches:
  • Divide by platform:
    • rcore_desktop.c - PLATFORM_DESKTOP (Windows, Linux, macOS)
    • rcore_android.c - PLATFORM_ANDROID
    • rcore_native.c - PLATFORM_DRM/PLATFORM_RPI
    • rcore_web.c - PLATFORM_WEB
  • Divide by technology
    • rcore_glfw.c - GLFW library based
    • rcore_sdl.c - SDL library based
    • rcore_native.c - Native implementation

This is not an easy task, still deciding the proper approach for it. There are 45 functions depending on ~100 GLFW functions, those 45 functions should be reproduced separately for the different platforms/technologies and exposed through the same common API.

Also related to this submodules project, some time ago I created a list of functions dependant on GLFW (PLATFORM_DESKTOP), that's probably the list of functions that should be duplicated between platform:

void CloseWindow(void)
    glfwDestroyWindow();
    glfwTerminate();
bool WindowShouldClose(void)
    glfwWaitEvents();
    glfwWindowShouldClose();
void ToggleFullscreen(void)
    glfwGetWindowPos()
    glfwGetMonitors();
    glfwSetWindowMonitor()
    glfwSwapInterval();
void MaximizeWindow(void)
    glfwGetWindowAttrib()
    glfwMaximizeWindow()
void MinimizeWindow(void)
    glfwIconifyWindow()
void RestoreWindow(void)
    glfwRestoreWindow()
void SetWindowState(unsigned int flags)
    glfwSwapInterval();
    glfwSetWindowAttrib()
    glfwHideWindow()
    glfwShowWindow()
void SetWindowIcon(Image image)
    glfwSetWindowIcon()
void SetWindowIcons(Image *images, int count)
    glfwSetWindowIcon()
void SetWindowTitle(const char *title)
    glfwSetWindowTitle()
void SetWindowPosition(int x, int y)
    glfwSetWindowPos()
void SetWindowMonitor(int monitor)
    glfwGetMonitors()
    glfwGetMonitorName()
    glfwGetVideoMode()
    glfwSetWindowMonitor()
void SetWindowMinSize(int width, int height)
    glfwGetVideoMode()
    glfwSetWindowSizeLimits()
void SetWindowSize(int width, int height)
    glfwSetWindowSize()
void SetWindowOpacity(float opacity)
    glfwSetWindowOpacity()
void *GetWindowHandle(void)
    glfwGetWin32Window()
    glfwGetX11Window()
    glfwGetCocoaWindow()
int GetMonitorCount(void)
    glfwGetMonitors();
int GetCurrentMonitor(void)
    glfwGetMonitors();
    glfwGetWindowMonitor()
    glfwGetWindowPos()
    glfwGetMonitorWorkarea()
Vector2 GetMonitorPosition(int monitor)
    glfwGetMonitors()
    glfwGetMonitorPos()
int GetMonitorWidth(int monitor)
    glfwGetMonitors()
    glfwGetVideoMode()
int GetMonitorHeight(int monitor)
    glfwGetMonitors()
    glfwGetVideoMode()
int GetMonitorPhysicalWidth(int monitor)
    glfwGetMonitors()
    glfwGetMonitorPhysicalSize()
int GetMonitorPhysicalHeight(int monitor)
    glfwGetMonitors()
    glfwGetMonitorPhysicalSize()
int GetMonitorRefreshRate(int monitor)
    glfwGetMonitors()
    glfwGetVideoMode()
Vector2 GetWindowPosition(void)
    glfwGetWindowPos()
Vector2 GetWindowScaleDPI(void)
    glfwGetMonitors()
    glfwGetMonitorContentScale()
    glfwGetMonitorWorkarea()
const char *GetMonitorName(int monitor)
    glfwGetMonitors()
    glfwGetMonitorName()
void SetClipboardText(const char *text)
    glfwSetClipboardString()
const char *GetClipboardText(void)
    glfwGetClipboardString()
void ShowCursor(void)
    glfwSetInputMode()
void HideCursor(void)
    glfwSetInputMode()
void EnableCursor(void)
    glfwSetInputMode()
void DisableCursor(void)
    glfwSetInputMode()
double GetTime(void)
    glfwGetTime()
const char *GetGamepadName(int gamepad)
    glfwGetJoystickName();
void SetMousePosition(int x, int y)
    glfwSetCursorPos()
void SetMouseCursor(int cursor)
    glfwSetCursor()
    glfwCreateStandardCursor()
static bool InitGraphicsDevice(int width, int height)
    glfwSetErrorCallback();
    glfwInitHint()
    glfwInit()
    glfwDefaultWindowHints();
    glfwWindowHint()
    glfwSetJoystickCallback();
    glfwGetPrimaryMonitor();
    glfwGetVideoMode(monitor);
    glfwGetVideoModes()
    glfwCreateWindow()
    glfwSetWindowMonitor()
    glfwTerminate();
    glfwSetWindowSizeCallback()
    glfwSetWindowMaximizeCallback()
    glfwSetWindowIconifyCallback()
    glfwSetWindowFocusCallback()
    glfwSetDropCallback()
    glfwSetKeyCallback()
    glfwSetCharCallback()
    glfwSetMouseButtonCallback()
    glfwSetCursorPosCallback()
    glfwSetScrollCallback()
    glfwSetCursorEnterCallback()
    glfwMakeContextCurrent();
    glfwSetInputMode()
    glfwSwapInterval()
    glfwGetFramebufferSize()
    glfwGetProcAddress()
static void SetupViewport(int width, int height)
    glfwGetWindowContentScale()
void SwapScreenBuffer(void)
    glfwSwapBuffers();
void PollInputEvents(void)
    glfwJoystickPresent()
    glfwGetGamepadState()
    glfwWaitEvents()
    glfwPollEvents()
static void KeyCallback(GLFWwindow *window, int key, int scancode, int action, int mods)
    glfwSetWindowShouldClose()

Here the functions list clean:

void CloseWindow(void)
bool WindowShouldClose(void)
void ToggleFullscreen(void)
void MaximizeWindow(void
void MinimizeWindow(void)
void RestoreWindow(void)
void SetWindowState(unsigned int flags)
void SetWindowIcon(Image image)
void SetWindowIcons(Image *images, int count)
void SetWindowTitle(const char *title)
void SetWindowPosition(int x, int y)
void SetWindowMonitor(int monitor)
void SetWindowMinSize(int width, int height)
void SetWindowSize(int width, int height)
void SetWindowOpacity(float opacity)
void *GetWindowHandle(void)
int GetMonitorCount(void)
int GetCurrentMonitor(void)
Vector2 GetMonitorPosition(int monitor)
int GetMonitorWidth(int monitor)
int GetMonitorHeight(int monitor)
int GetMonitorPhysicalWidth(int monitor)
int GetMonitorPhysicalHeight(int monitor)
int GetMonitorRefreshRate(int monitor)
Vector2 GetWindowPosition(void)
Vector2 GetWindowScaleDPI(void)
const char *GetMonitorName(int monitor)
void SetClipboardText(const char *text)
const char *GetClipboardText(void)
void ShowCursor(void)
void HideCursor(void)
void EnableCursor(void)
void DisableCursor(void)
double GetTime(void)
const char *GetGamepadName(int gamepad)
void SetMousePosition(int x, int y)
void SetMouseCursor(int cursor)
static bool InitGraphicsDevice(int width, int height)
static void SetupViewport(int width, int height)
void SwapScreenBuffer(void)
void PollInputEvents(void)

Most of those functions could be not required on target platform and just fallback to some default value.

Actually, that's another possibility, just keep everything in CoreData independently of the platform, beeing used or not. Probably the overload won't be that dramatic...

This would be excellent. Would make a lot simpler for anyone that want/need to extend it. I'd vote for this one.

[michaelfiber]

Actually, that's another possibility, just keep everything in CoreData independently of the platform, beeing used or not. Probably the overload won't be that dramatic...

I like that. It would be super clear. And a shared data structure would probably guide platform specific development to re-use rather than reinvent since every platform would have access to all the data structure anyway.

I hadn't considered multiple windows when I was thinking through it so the approach I was leaning towards before would probably need a lot of work to handle that sanely. And it would lose a lot of clarity.

[raysan5]

@michaelfiber @ubkp I've been thinking about the best approach for code organization and I got to the conclusion that avoiding breaking all raylib current build systems (and potentially many bindings or user codebases) is the best option, my idea is to just keep the rcore.c as the base module, containing all common functions BUT also the inclusion of the required submodules:

// rcore.c

// Required data types and variables

#if defined(PLATFORM_DESKTOP)
    #include "rcore_desktop.c"
#elif defined(PLATFORM_WEB)
    #include "rcore_web.c"
#elif defined(PLATFOM_DRM)
    #include "rcore_drm.c"
#elif defined(PLATFOM_ANDROID)
    #include "rcore_android.c"
#else
    // Software rendering backend, user needs to provide buffer ;)
#endif

// Common functions to all platforms

From an academic point of view it could be ugly but in practice it works very well.

[raysan5]

@michaelfiber @ubkp I'd also like to accelerate the development of this improvement, considering the latest events on the gamedev industry I think it could be beneficial for raylib in multiple ways, for example to allow other contributors to hook additional platforms in an easy way; at this moment I know is quite scary to look at rcore.

Please, let me know if you could help me with this big redesign!

my idea is to just keep the rcore.c as the base module, containing all common functions BUT also the inclusion of the required submodules

1. In that scenario, for example, IsWindowMinimized()(L1154-L1160), would it be under rcore.c with its #ifdefs? Or not in rcore.c but duplicated on rcore_desktop.c and rcore_web.c?
   
   I ask this because, if it's under rcore.c, then I don't think much would change. rcore.c would still have a considerable amount of #ifdefs, thus harder to track. I guess most functions would fall under that case.

#if defined(PLATFORM_DESKTOP)
#include "rcore_desktop.c"
#elif

2. Please correct me if I'm wrong (and I'm probably wrong), but I was under the impression that this way of including would be a bad idea (refs: 1, 2, 3).

for example to allow other contributors to hook additional platforms in an easy way;

3. I'd say the only (actual) missing platform would be iOS. IMHO, I don't think we'd be seeing aditional (e.g.: consoles) platforms even if the conditions were right because of the SDKs and NDAs. Just as a reference, quoting the Godot documentation on a similar subject:

The reason other consoles are not officially supported are:

• To develop for consoles, one must be licensed as a company. As an open source project, Godot has no legal structure to provide console ports.

• Console SDKs are secret and covered by non-disclosure agreements. Even if we could get access to them, we could not publish the platform-specific code under an open source license.

4. I admit I'm having a hard time visualizing it all (separation, building, etc). Would it be a good idea to test it first in a sort of very minimal skeleton/prototype with just one or two structs/functions inside just to see what works or not?

Edit:

I'd also like to accelerate the development of this improvement

5. When the new structure is set in stone, to speed up its implementation, I'd suggest setting a temporary freeze in new PRs (like Linux distros do) to avoid having to play catch-up given the structural nature of the change.

[michaelfiber]

@michaelfiber @ubkp I've been thinking about the best approach for code organization and I got to the conclusion that avoiding breaking all raylib current build systems (and potentially many bindings or user codebases) is the best option, my idea is to just keep the rcore.c as the base module, containing all common functions BUT also the inclusion of the required submodules:

// rcore.c

// Required data types and variables

#if defined(PLATFORM_DESKTOP)
    #include "rcore_desktop.c"
#elif defined(PLATFORM_WEB)
    #include "rcore_web.c"
#elif defined(PLATFOM_DRM)
    #include "rcore_drm.c"
#elif defined(PLATFOM_ANDROID)
    #include "rcore_android.c"
#else
    // Software rendering backend, user needs to provide buffer ;)
#endif

// Common functions to all platforms

From an academic point of view it could be ugly but in practice it works very well.

Doing it this way feels wrong but I completely understand not wanting to break builds. Updating the Makefile was easy but I don't know about updating the others. Right now for testing I'm going to leave the Makefile change and then as I progress through this maybe I'll spot another way that doesn't feel so wrong? With the position of raylib as a great tool for education I'd hate to include something that would have a comment like // You shouldn't do this

Also for the CoreData I realized that if all the data is always there without preprocessor directives then it either needs all dependencies included no matter that target platform OR a lot of void pointers that will have to be cast each time in the platform specific rcore files.

Right now I am leaving the #if defined(PLATFORM_*) directives in the struct as I split out the rest of the functions. The CoreData structure doesn't get any more difficult to read than it did before but it maintains its very difficult to read directives. Another less disruptive approach may be a simple refactor to move platform specific stuff so there's just one directive per platform in CoreData. CORE->handle would become CORE->desktop->handle for instance. It does mean some repeated data structures between platforms but I think the readability would increase dramatically.

TL;DR:

• For now I'm leaving the preprocessor directives in the CoreData struct and will test out a refactor, possibly in a separate PR
• For now I'm leaving the Makefile change to include platform specific core c files as I look for other paths besides #include "rcore_*.c" because I would like to not break the build files so thoroughly and I would also like to avoid including a C file if at all possible.

[raysan5]

@ubkp here the answers for your questions:

1. In those cases the function would be duplicated for all platforms requiring it.

2. It's not recommended and probably bad practice from an academic point of view, still, it can be used and it's really handy. Actually raylib uses that approach for all its external libraries, #define XXXX_IMPLEMENTATION does exactly that.

3. Yes, most noticeable missing platform is PLATFORM_IOS, maybe PLATFORM_SOFTWARE could also be an option... BUT this structure opens the door to the addition of console platforms (by licensed users) in an easier way with minimal raylib modifications. Console homebrew platforms could also follow this same pattern.

4. Yes, it's a very big change in structure. I don't fully visualize it at the moment but I think it could work.

5. Completely agree. Still considering if moving the platform-specific parts from CoreData structure is a better approach, actually CoreData was created quite recently for organization (as a struct of structs), not long ago it was just a bunch of global variables.

Doing it this way feels wrong but I completely understand not wanting to break builds.

@michaelfiber I know, it feels wrong... but it actually works like a charm for this kind of situations.

[michaelfiber]

@raysan5 Ok, I can try that out.

[michaelfiber]

EDIT: Copying the info from wishlist for reference:

* [ ]  **REDESIGN: Module  subdivision**. This module has grown a lot with every new supported platform (~7000 loc), at some point it could be divided into separate modules. Two possible approaches:
  
  * Divide by platform:
    
    * `rcore_desktop.c`  - `PLATFORM_DESKTOP` (Windows, Linux, macOS)
    * `rcore_android.c` - `PLATFORM_ANDROID`
    * `rcore_native.c` - `PLATFORM_DRM`/`PLATFORM_RPI`
    * `rcore_web.c` - `PLATFORM_WEB`
  * Divide by technology
    
    * `rcore_glfw.c` - GLFW library based
    * `rcore_sdl.c` -  SDL library based
    * `rcore_native.c` - Native implementation

This is not an easy task, still deciding the proper approach for it. There are 45 functions depending on ~100 GLFW functions, those 45 functions should be reproduced separately for the different platforms/technologies and exposed through the same common API.

Also related to this submodules project, some time ago I created a list of functions dependant on GLFW (PLATFORM_DESKTOP), that's probably the list of functions that should be duplicated between platform:

void CloseWindow(void)
    glfwDestroyWindow();
    glfwTerminate();
bool WindowShouldClose(void)
    glfwWaitEvents();
    glfwWindowShouldClose();
void ToggleFullscreen(void)
    glfwGetWindowPos()
    glfwGetMonitors();
    glfwSetWindowMonitor()
    glfwSwapInterval();
void MaximizeWindow(void)
    glfwGetWindowAttrib()
    glfwMaximizeWindow()
void MinimizeWindow(void)
    glfwIconifyWindow()
void RestoreWindow(void)
    glfwRestoreWindow()
void SetWindowState(unsigned int flags)
    glfwSwapInterval();
    glfwSetWindowAttrib()
    glfwHideWindow()
    glfwShowWindow()
void SetWindowIcon(Image image)
    glfwSetWindowIcon()
void SetWindowIcons(Image *images, int count)
    glfwSetWindowIcon()
void SetWindowTitle(const char *title)
    glfwSetWindowTitle()
void SetWindowPosition(int x, int y)
    glfwSetWindowPos()
void SetWindowMonitor(int monitor)
    glfwGetMonitors()
    glfwGetMonitorName()
    glfwGetVideoMode()
    glfwSetWindowMonitor()
void SetWindowMinSize(int width, int height)
    glfwGetVideoMode()
    glfwSetWindowSizeLimits()
void SetWindowSize(int width, int height)
    glfwSetWindowSize()
void SetWindowOpacity(float opacity)
    glfwSetWindowOpacity()
void *GetWindowHandle(void)
    glfwGetWin32Window()
    glfwGetX11Window()
    glfwGetCocoaWindow()
int GetMonitorCount(void)
    glfwGetMonitors();
int GetCurrentMonitor(void)
    glfwGetMonitors();
    glfwGetWindowMonitor()
    glfwGetWindowPos()
    glfwGetMonitorWorkarea()
Vector2 GetMonitorPosition(int monitor)
    glfwGetMonitors()
    glfwGetMonitorPos()
int GetMonitorWidth(int monitor)
    glfwGetMonitors()
    glfwGetVideoMode()
int GetMonitorHeight(int monitor)
    glfwGetMonitors()
    glfwGetVideoMode()
int GetMonitorPhysicalWidth(int monitor)
    glfwGetMonitors()
    glfwGetMonitorPhysicalSize()
int GetMonitorPhysicalHeight(int monitor)
    glfwGetMonitors()
    glfwGetMonitorPhysicalSize()
int GetMonitorRefreshRate(int monitor)
    glfwGetMonitors()
    glfwGetVideoMode()
Vector2 GetWindowPosition(void)
    glfwGetWindowPos()
Vector2 GetWindowScaleDPI(void)
    glfwGetMonitors()
    glfwGetMonitorContentScale()
    glfwGetMonitorWorkarea()
const char *GetMonitorName(int monitor)
    glfwGetMonitors()
    glfwGetMonitorName()
void SetClipboardText(const char *text)
    glfwSetClipboardString()
const char *GetClipboardText(void)
    glfwGetClipboardString()
void ShowCursor(void)
    glfwSetInputMode()
void HideCursor(void)
    glfwSetInputMode()
void EnableCursor(void)
    glfwSetInputMode()
void DisableCursor(void)
    glfwSetInputMode()
double GetTime(void)
    glfwGetTime()
const char *GetGamepadName(int gamepad)
    glfwGetJoystickName();
void SetMousePosition(int x, int y)
    glfwSetCursorPos()
void SetMouseCursor(int cursor)
    glfwSetCursor()
    glfwCreateStandardCursor()
static bool InitGraphicsDevice(int width, int height)
    glfwSetErrorCallback();
    glfwInitHint()
    glfwInit()
    glfwDefaultWindowHints();
    glfwWindowHint()
    glfwSetJoystickCallback();
    glfwGetPrimaryMonitor();
    glfwGetVideoMode(monitor);
    glfwGetVideoModes()
    glfwCreateWindow()
    glfwSetWindowMonitor()
    glfwTerminate();
    glfwSetWindowSizeCallback()
    glfwSetWindowMaximizeCallback()
    glfwSetWindowIconifyCallback()
    glfwSetWindowFocusCallback()
    glfwSetDropCallback()
    glfwSetKeyCallback()
    glfwSetCharCallback()
    glfwSetMouseButtonCallback()
    glfwSetCursorPosCallback()
    glfwSetScrollCallback()
    glfwSetCursorEnterCallback()
    glfwMakeContextCurrent();
    glfwSetInputMode()
    glfwSwapInterval()
    glfwGetFramebufferSize()
    glfwGetProcAddress()
static void SetupViewport(int width, int height)
    glfwGetWindowContentScale()
void SwapScreenBuffer(void)
    glfwSwapBuffers();
void PollInputEvents(void)
    glfwJoystickPresent()
    glfwGetGamepadState()
    glfwWaitEvents()
    glfwPollEvents()
static void KeyCallback(GLFWwindow *window, int key, int scancode, int action, int mods)
    glfwSetWindowShouldClose()

Here the functions list clean:

void CloseWindow(void)
bool WindowShouldClose(void)
void ToggleFullscreen(void)
void MaximizeWindow(void
void MinimizeWindow(void)
void RestoreWindow(void)
void SetWindowState(unsigned int flags)
void SetWindowIcon(Image image)
void SetWindowIcons(Image *images, int count)
void SetWindowTitle(const char *title)
void SetWindowPosition(int x, int y)
void SetWindowMonitor(int monitor)
void SetWindowMinSize(int width, int height)
void SetWindowSize(int width, int height)
void SetWindowOpacity(float opacity)
void *GetWindowHandle(void)
int GetMonitorCount(void)
int GetCurrentMonitor(void)
Vector2 GetMonitorPosition(int monitor)
int GetMonitorWidth(int monitor)
int GetMonitorHeight(int monitor)
int GetMonitorPhysicalWidth(int monitor)
int GetMonitorPhysicalHeight(int monitor)
int GetMonitorRefreshRate(int monitor)
Vector2 GetWindowPosition(void)
Vector2 GetWindowScaleDPI(void)
const char *GetMonitorName(int monitor)
void SetClipboardText(const char *text)
const char *GetClipboardText(void)
void ShowCursor(void)
void HideCursor(void)
void EnableCursor(void)
void DisableCursor(void)
double GetTime(void)
const char *GetGamepadName(int gamepad)
void SetMousePosition(int x, int y)
void SetMouseCursor(int cursor)
static bool InitGraphicsDevice(int width, int height)
static void SetupViewport(int width, int height)
void SwapScreenBuffer(void)
void PollInputEvents(void)

Most of those functions could be not required on target platform and just fallback to some default value.

I'll probably just go function by function through rcore and move the functions that have platform_specific logic. That will probably align with the list of functions that reference glfw but I'm not sure. Also If you are keeping a list then SetWindowFocused should be on it too.

[michaelfiber]

Immediately as I make this transition I see the opportunity to add some simple javascript functions to the default HTML templates for emscripten that would help with things like reading the clipboard and disabling the cursor without having the ID of the canvas element hard coded into raylib. That makes me think this submodule approach might be a good one. It's much easier to check at a glance how complete each implementation is.

@michaelfiber If you need help with anything, please let me know.

[raysan5]

@michaelfiber thank you very much for this big effort! Undoubtely it opens the door to many per-platform improvements.

This is a lot of work, please, let me and @ubkp help with it.

I created a separate branch to start merging the changes: https://github.com/raysan5/raylib/tree/rcore_platform_split

We can divide the functions to port in chunks between us.

Also, I'm locking any change in rcore module for now, at least until we get a functional version and we can validate if it's a good line to follow for raylib (I'm pretty convinced of it!).