raylib 6.0 wishlist!

[raysan5]

Previous: raylib 5.0 wishlist

raylib 5.5 was released recently and it's about time to consider a future raylib 6.0 release.

Actually, there are already multiple issues, PRs and Discussions open for potential raylib improvements. As usual, I'll try to prioritize library maintainability and better platforms support over new features.

Here it is a list with some of the improvements and a some work plans for raylib future:

NOTE: To be completed...

General

Academics

raylib is widely used in academic world, to teach new students graphics programming basics but also to generate demos or academic research visualizations. I want to focus efforts on knowing more about that kind of uses, where I think raylib has a great expansion potential.

• Create a reference document containing educational institutions using raylib on their courses: raylib-academics.

Webpage

raylib.com needs a redesign, it has barely changed in +11 years and considering the increasing popularity/visibility of the library I think it could looks a bit better. I draft a new design a while ago, keeping the minimalist style but a bit more aligned with nowadays standards. I'd also like to add more wasm interactivity, showcasing what raylib can do for web development.

raylib project creator

Recently a new support tool for raylib users was released: raylib project creator. This tool is intended to simplify the setup process for new projects, generating preconfigured projects for multiple systems. The tool still requires some testing, specially on platforms other than Windows, and there are some improvements that I want to add:

• Load/save project configuration file, in plain text file (using rini library), to allow project sharing for regeneration and to connect with future new tools.
• Improve assets/resources management: Define src/dst paths.

raylib project builder

One of the key features provided by most commercial engines is the automatic project building for multiple platforms. Building a raylib project for several platforms could be very complex, specially for new users, so I'm considering creating a tool to simplify that specific process. Using a project configuration file, generated with raylib project creator, show a visual UI interface to simplify building for several platforms.

NOTE: This is a complex project and it would require time and resources, still on design phase

Modules

module: rcore

• REVIEW: Windowing: Fullscreen strategies and HighDPI management for multiple platforms, ToggleFullscreen()/ToggleBorderlessWindowed() ([rcore_desktop] Upon entering fullscreen, uses original window size #3929, [rcore] ToggleFullscreen() not working as expected with HighDPI mode enabled #3972, [rcore][glfw] Window System Improvements #4215, REVIEW: Fullscreen system refactor #4507)
• REVIEW: Keyboard Input System: keycodes vs scancodes. Make sure all platforms are consistent on the values stored, there could be naming inconsistency (GLFW vs SDL), raylib returns keyboard processed values for US-keyboard by default, maybe lower-level physical codes can be required at some point for different keyboard layouts support (REVIEW: Keyboard Input System, keycodes vs scancodes #4595)
• REVIEW: PLATFORM_DRM: Possible issues at initialization on Raspberry Pi (?)
• Platform iOS support: Similar to audio implementation, there could be some possibility to support iOS platform following a similar implementation, some works has already be done in that regards (will it support iOS? #2681 [rcore] Porting raylib to iOS and implement rcore_ios.c #3880)

module: rshapes

• REVIEW: Lines drawing pixel-offset: This is a very tricky issue because it's dependant on GPU, drivers and OpenGL implementation, when drawing using GL_LINES there could be a 1-pixel-offset to the line position, specially dramatic when draawing rectangle lines.
• REVIEW: Rectangles with rounded corners, similar to 1-px-offset issue, corners do not seem to look right, the number of sections should be calculated in function of the rectangle size and the corner radius, could be tricky. ([rshapes] DrawRectangleRoundedLines() results not aligned with DrawRectangleRounded() #4601)

module: rtext

• REVIEW: Font system dealing with glyphs, avoid traversing the full list of characters for every drawn codepoint (Font glyph performance improvements #4513)

module: rmodels

• REVIEW: Keyframes/poses computation based on model data ([rmodels] LoadModelAnimationsGLTF() computes poses interpolating between the anim duration and fixed 60 fps (GLTF_ANIMDELAY) #4426, [rmodels] glTF animation import uses odd framerate as basis for time to frame conversion #4472, [rmodels] Animation issue with the GLB/GLTF files #4569)
• REVIEW: Models Animation System: How to deal poses / skeletons, independenly of mesh: blending, get poses updated... ([rmodels] Added implementation of UpdateModelAnimationBonesWithBlending() function #4578, REDESIGN: Model Animation System #4606)
• REVIEW: Models loading from memory, allow loading data in second thread for optimization (?)

module: raudio

• REDESIGN: Audio System: Wave vs Sound mechanisms and structures, keep an internal identifier for sounds (snd.id) similar to OpenGL texture.id. That is a similar implementation to OpenAL Soft.

module: utils

• ADDITION: Virtual File System, improved support ([rcore] Virtual File System callbacks/macros required #4551)

Examples

• UPDATE: Recompile all examples for latest raylib and emscripten.

TODO: New examples and examples to review

Others

building

• REVIEW: Config System (config.h) to allow easier enabling/disabling of features on building ([config.h] Consider changing how defines are used in raylib to support configuration from build systems #4411 [Config.h] Make all the defines in config.h be override-able by the build system #4554)

extras

• Scene/Entities Management System (Simple scene system to ease getting started with 3d game dev #4495)
• Improved 3d functionality: r3d

others

• TODO.

Note that most of the improvement points come from open issues and PRs for review.

It's a long list and it requires lot of work. Note that not all those improvements are expected to be implemented, it's just a reference to follow for future raylib.

As always, contributions are welcome. Feel free to comment.

[Fancy2209]

An SDL Mixer backend as an option instead of MiniAudio would be nice for RAudio in my opinion

[raysan5]

I'm afraid it implies a big number of external dependencies... not aligned with raylib design...

[Fancy2209]

I'm afraid it implies a big number of external dependencies... not aligned with raylib design...

What about SDL's base audio API that doesn't have external deps?

[JeffM2501]

Fullscreen Refactor

Define what ‘fullscreen’ means to raylib and refactor the current API to match that definition. Also add specific functions to change display resolution. Evaluate ways to have consistent behavior with minimal API changes.

Posted 11-18-24
#4507

Font Rendering Refactor

Store glyphs in ranges for faster lookup. In my testing SUPPORT_UNORDERED_CHARSET is one to two times slower than a straight lookup. We can do better than brute force lookups every glyph.
Posted 11-18-24
#4513

Store spacing in font and add Set FontSpacing, and scale it with the glyph scale.

Add function to read monospaced bitmap font (extras?)

Optional Callbacks for file format readers

Allow drop in libs to install callbacks into raylib to handle various file extensions.

Move all non-default file loaders into single header libs that can be dropped in to add support for a file format instead of requiring a rebuild of raylib.
A way to load meshes and no upload them to GPU
LoadModelEx? With a boolean to upload or not, allows mesh loading in a thread.
Standardized binary mesh format
Read/Write mesh in binary from memory, does not need to be interchange format. Maybe also store a list of key/value pairs for metadata?

Audio Platform

Give audio the same type of platform abstraction that core has, keeping MiniAudio as the default backend.
Separate Gamepad Initialization
Don’t initialize gamepads by default, require them to be initialized as a sub system.

Review/refactor gamepad platforms to ensure they are fully functional.

Blend Mode for Render Textures

There is a lot of confusion around blend modes when drawing transparent items to a render texture. Evaluate if there is a good blend mode that we can add to give expected results when drawing to a render texture (one that does not set the destination alpha). Add an example as well.

Oriented Bounding Box Collision example

Add an example that shows how to do oriented bounding box collisions

Software Rendering example

Add an example that shows how write to an image and update a texture

Basic Scene System for Raylib-extras

A simple octree based system that can hold nodes with meshes and/or meta-data

[raysan5]

Many points mentioned here! I'm adding some of them to the main post!

[huntindeed]

Vulkan support? It looks like raylib is gaining popularity and may soon have even more projects that would greatly benefit from it.

[raysan5]

I'm afraid at this moment I don't have the resources required to consider that option, but feel free to work on it and contribute with a Vulkan layer. Just note it must follow rlgl API.

[Peter0x44]

@huntindeed why would your projects benefit from it?

Not saying they wouldn't, but curious for the use-case.

[DeGGeD]

Hello and Happy New Year!

Based on recent feedback from fellow colleagues, would it be possible to add OpenGL ES 3.2 support to enable compute shaders on mobile platforms?

Thanks.

[raysan5]

I take note but not a priority, even OpenGL ES 3.0 requires some review.

[Fancy2209]

If Mixer is too much, could at least an RAudio implementation using the base SDL library be possible? Or is are SDL Audio APIs missing functionality from RAudio?

[JeffM2501]

I would like to see rAudio get the same kind of platform treatment that rCore did, so that it would be possible to drop in different audio backends, with miniaudio as the default if you don't specify one.
The rCore platform split worked out very well for 5.0, so I think that design pattern should be applied in more places for hopefully similar results.

[raysan5]

This change can be considered but at this moment I don't visualize the complexity involved... In contrast to rcore that had already multiple flags dividing code by platform, raudio relies on miniaudio backend for most of the platforms and I feel raudio is tighly coupled to it... still, raudio_<backend>.c could be nice for some specific platforms, like consoles...

[Bigfoot71]

What do you mean by:

Improved 3d functionality: r3d

Is it something external to raylib?
A header integrated into raylib?
What are the minimal required features?

[raysan5]

Oh, I just copy-pasted some of my notes and I got a reference to r3d as an extra layer over raylib with additional functionality that worth reviewing, just in case something could fit on raylib or some new code example.

[lamweilun]

Any chance we can just get ANGLE as a backend option, or maybe as a separate option entirely to complement OpenGL ES?

I know there's already some discussion over here and there's also a Medium post of someone linking ANGLE on MacOS to run with Metal and getting massive improvements to graphical performance.

[raysan5]

@lamweilun Afair, ANGLE is already supported by raylib, it only requires compiling for OpenGL ES 2.0 and linking with ANGLE libraries... but it has not been tested in some time... in any case, I'm not sure about those "massive improvements", ANGLE is an emulation layer over Direct3D (and other APIs).

What is the specific use-case for ANGLE that available backends do not cover?

[Peter0x44]

Using angle does not require any modifications to raylib, the process is basically:
build raylib for gles2.
link angle in place of libglesv2 and libegl.

[bosoni]

[raysan5]

There is already an open discussion on that line...

[mrylmz]

Add a library prefix for the entire API to address name collision issue's. It is a very common problem in C lacking namespaces.

[orcmid]

@mrylmz See #3620, #2490, and #1217 among others.

Meanwhile, and probably for the indefinite future, there are other ways to address collision issues, especially with windows.h.

[casperbear]

Ability to draw a text with outline of specified color. F.e. to draw a readable text over 3d scene in a game.

[raysan5]

Supporting a text outline is not trivial. There is already a shader example showing how to do it. It's up to the user.

[casperbear]

Imagine you enter a shop in an rpg, and there is an animated 2d video, usually short (2-5 seconds) and perfectly looped. I'm not even sure what video format / OpenGL feature they usually use (if there is one), but it would be good to have one exposed in RayLib.

[raysan5]

It exists and it's called RenderTexture. Use it to render frames to it and draw the RenderTexture wherever in the screen, for example in a monitor.

[Boyfinn]

As for the improved 3D functionality part:

• Better integration of the "Transform" type for handling 3D.
• Better integration of the "Quatenrion" type for handling rotations in 3D space, instead of vector angles.
• Better integration and tools for using transform matrices, ex: transform hierarchies, model draw call with "Matrix" type as a transform argument/parameter.

[Bigfoot71]

For hierarchical transformations, wouldn’t it be better to do it via the Transform struct?

For example, using a nullable pointer to the parent transformation. Well, if it were to be used internally, unless implementing real scene management, recalculating the hierarchy for each call to 'DrawModel' without any system to prevent redundant calculations would be far from perfect.

Indeed, a DrawModel function that directly takes a matrix could be cool, but then you can create your own hierarchy system based on your own scene representation system with this function.

In my opinion, raylib shouldn’t do it for you because it would probably do it in a way that could be unpleasant and restrictive in the long run.

That’s just my opinion, but if a 3D scene management system were to be added to raylib, it should be optional, so it doesn't annoy those who might want to do it differently.

[Boyfinn]

I understand that a full blown scene management system would be a bit out of scope for Raylib. But since Raylib already has a type for Transforms and by extension; Quaternions, I'm a bit confused as to why they aren't more widely used outside of Raylib's internal program architecture.
Besides, I think it would be better for both professional and educational interests to use Quaternions for handling rotations instead of VectorAngles or EulerAngles, seeing as Quaternions for 3D spatial rotations are pretty much industry standard and thus what is being taught at 3D graphics programming classes.

Going back to the subject of Transform/Matrix hierarchies, even a simple variable for storing a pointer to a parent transform like done here: (https://github.com/juniper-dusk/raylib-transform/tree/main)
Would certainly be useful, and still be flexible enough for the user to implement their own scene system.
Edit: Looking at the transform hierarchy repository linked above, there's also an implementation for DrawModel that takes a transformation matrix in src/TransformExample.cpp

[Bigfoot71]

So the idea would be:

• Add an "overload" of DrawModel taking a matrix
• Add a nullable pointer to a parent transformation in Transform
• Add some functions like GetLocalXXX(Transform t) and GetGlobalXXX(Transform t)
• And favor quaternions in the library

For the last point about quaternions, I agree that it would be better in itself, but Euler angles and vector-based ones are much easier to understand and work with directly for beginners, which is also the goal of raylib.

Honestly, I couldn't take a stance on this, each approach has its pros and cons, although I would probably favor quaternions as well.

---

Edit: I'm thinking about it, but raylib generally follows a copy-based approach in many cases. This can lead to less careful management of the lifespan of the data being used. Therefore, the use of pointers in Transform should be approached with caution.