Skip to content
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

Introduce a way to add a 100% external custom platform #3594

Closed
wants to merge 2 commits into from
Closed

Introduce a way to add a 100% external custom platform #3594

wants to merge 2 commits into from

Conversation

ypujante
Copy link

@ypujante ypujante commented Dec 2, 2023

Let me start with a few things (in order to avoid misunderstanding):

  • this is based on this discussion/comment
  • this is a draft request to gather feedback and show what is possible
  • this is in no way ready to be merged and is just a proposal
  • everything, and I truly mean everything is up for debate, from the naming, to the structure, to the approach... this is what is project is for: a discussion
  • if you want to close and forget all about it I am perfectly fine with it
  • the external folder that I added at the root is purely for demonstration purposes and would NOT be included in a final/ready to merge version.
  • in its current state it is fully functional (if using CMake as a build tool) as demonstrated by the examples

With these details out of the way, let's get to the interesting part.

The purpose of this effort is to demonstrate what it could take for raylib to support platforms that are NOT embedded in raylib and as a result not maintained by @raysan5.

Goals (that I have tried to achieve with this PR)

  • developing a new (external) platform should require 0 changes to raylib (the raylib repo)
  • it should be fairly simple for a platform developer to write an external platform (the actual code in the platform itself might be complicated, but that is besides the point...)
  • it should be fairly simple for a user to use a platform that is not embedded in raylib
  • changing raylib to support external/custom platforms should not affect the build/runtime/compile time performance of the embedded platforms
  • there are no changes to current platforms

After looking at the source code, I believe there are 2 areas where there needs to be "hooks" for a platform to reside outside raylib:

  • the source code: actual implementation of the platform + various defines to tailor the build
  • the build files: which libraries to include, link options, compile options, etc... Note that for this PR I concentrated only on CMake but obviously the other build frameworks supported would have to be modified accordingly. That being said, it is not a 100% requirement if it is too hard to achieve with other build frameworks, as raylib could take the position that if you want to develop/use a custom platform, you must use CMake (this is my personal opinion, not knowing what is possible with Makefiles/zig, and would be totally open for other build platforms if at all possible)

The overall approach that I took is the following: use conventions as much as possible so that it is easy both from the user of the platform and the developer of the platform to integrate with raylib.

The "only" required pieces of information that raylib needs are:

  • the fact that is a custom platform (added a new enum options "Custom")
  • where the platform is located on the file system. In CMake this translates into providing a PLATFORM_CUSTOM_ROOT_DIR variable.

The custom platform looks like this (by convention):

root/cmake
       raylibPlatformCustomLibraryConfig.cmake [optional]
       raylibPlatformCustomTargetConfig.cmake  [optional]
       raylibPlatformCustomProjectConfig.cmake [optional]
root/src
       raylib_platform_custom.c [required]
       raylib_platform_custom.h [required]
  • cmake/raylibPlatformCustomProjectConfig.cmake: optional and contain cmake definitions that needs to happen before project() is invoked
  • cmake/raylibPlatformCustomLibraryConfig.cmake: optional and contain cmake definitions of libraries and generic option (like setting CMAKE_STATIC_LIBRARY_SUFFIX)
  • cmake/raylibPlatformCustomTargetConfig.cmake: optional and contain cmake definitions that applies on the raylib target (ex: target_link_options(raylib PRIVATE "-sUSE_GLFW=3"))
  • src/raylib_platform_custom.c is the implementation of the platform that gets included in rcore.c (similar to platforms/rcore_desktop.c)
  • src/raylib_platform_custom.h is a new header file containing several definitions that are used in the code

Let me give an example of the last one: in rlgl.h there is this code:

    #if defined(PLATFORM_DESKTOP) || defined(PLATFORM_DESKTOP_SDL)

so I changed it to

    #if defined(PLATFORM_DESKTOP) || defined(PLATFORM_DESKTOP_SDL) || defined(PLATFORM_CUSTOM_ENABLE_OPENGL_ES2)

and PLATFORM_CUSTOM_ENABLE_OPENGL_ES2 is a define that needs to be defined (or not) in the src/raylib_platform_custom.h

The name PLATFORM_CUSTOM_ENABLE_OPENGL_ES2 as well as the other entries in this file have been inferred by what the #if is supposed to mean but not knowing the code, that was my best bet.

I understand this is a lot (to explain, but in the end not a lot of changes!), this is why I decided to include the external folder with 2 examples of 2 custom platforms and 2 examples of projects using each. Please check the external/README.md file for details. As you will see the 2 custom platforms are simply clones of 2 built-in ones, but they get used as a custom/external platform, NOT a built-in one (and again, the fact that this folder is checked in with raylib is so that I can provide this examples in the first place)

@orcmid
Copy link
Contributor

orcmid commented Dec 2, 2023

For this to work as in-development, it needs to be in a separate branch of raylib and not merged into raysan5:master. Alternatively, keep it a branch in your fork and discuss it here in Discussions, although that might be clumsy.

There is too much experimental and incomplete material here to be swallowed into raysan5:master.

@ypujante
Copy link
Author

ypujante commented Dec 2, 2023

@orcmid ok. I am closing it then and will open another one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants