raylib 7.0 wishlist!

[raysan5]

Previous: raylib 5.0 wishlist
Previous: raylib 6.0 wishlist

raylib 6.0 is out so, it's about time to consider possible improvements towards raylib 7.0 release.

As usual, priority is library maintainability and better platforms support over new features.

Here it is a list with some of the improvements planned for for raylib future:

Modules

module: rcore

• REVIEW: rcore_template: Add better explanations and make the sample code included more generic
• REVIEW: rcore_drm: Avoid OpenGL calls in RenderBlankFrame(), it should use rlgl instead (if really required)
• REVIEW: rcore_desktop_win32: Review input system, multi-monitor support and content scaling (HighDPI)
• REVIEW: rcore_web_emscripten: Improve input system, high-dpi, drag&drop support; align functionality with glfw backend
• ADDITION: rcore_desktop_x11: Add new platform backend for X11 windowing system
• ADDITION: rcore_desktop_wayland: Add new platform backend for Wayland windowing system
• ADDITION: rcore_desktop_cocoa: Add new platform backend for Cocoa windowing system, plain C, avoiding Objective-C
• ADDITION: Minimal processes execution API: InitProcess(), CheckProcess(), PauseProcess(), CloseProcess() - [rcore] Process manipulation API for Windows and POSIX-compliant platforms #5822
• ADDITION: SetClipboardImage() for supported platforms
• REVIEW: Move gestures system from rcore_<platform> to rcore, platforms could fill the touch information and rcore or rgestures process the gestures
• REVIEW: Automation events system, part of the implementation can be (maybe) moved to user side, to avoid internal files management (use memory buffer instead?)
• I+D: Investigate alternative embedded platforms and realtime OSs support

module: rlsw

• ADDITION: Consider mipmaps support for faster texel fetching
• REVIEW: Optimize for intrinsics and custom low-end platforms (ESP32, RISC-V)
• I+D: Basic shaders support using a GLSL parser to C code (precompiled shaders)

module: rshapes

• IDEAS?

module: rtextures

• REVIEW: Consider removing N-patch system, provide as separate example
• REVIEW: Blending modes system, provide more options or better samples
• REVIEW: rltexgpu compressed textures loading, improve support for KTX2 and consider Dreamcast .pvr

module: rtext

• REVIEW: Font system dealing with glyphs, avoid traversing the full list of characters for every drawn codepoint (Font glyph performance improvements #4513)
• ADDITION: Support ligatures (optional flag), consider using kb_text_shapes library
• I+D: Investigate support for the recently opened Slug font rendering algorithm

module: rmodels

• ADDITION: rlobj, custom OBJ format loader with all the needs to fit into raylib. Key requirement: return paths and properties for additional files.

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.
• ADDITION: Support microphone input, basic API to read microphone

Examples

• REVIEW: Improve examples, some of the latest additions could be improved...

Others

webpage

raylib.com needs a redesign, it has barely changed in +12 years and considering the increasing popularity/visibility of the library I think it could looks a bit better. I'd like to keep it minimalist but a bit more modern.

Some possible elements to be reviewed:

• Projects showcase
• Remove unneeded elements
• Interactive architecture (wasm)
• Quick-start guide/link

Support Tools

rexm - raylib examples manager

Recently rexm tool was added to raylib to manage examples, it would be nice to improve that tool with a visual interface.

• New visual UI to select and configure examples automatically
• Support raylib building with different config options

rpc - raylib project creator

This tool is intended to simplify the setup process for new projects, generating preconfigured projects for multiple systems.rpc v2.0 is in development, including the following improvements:

• New redesigned UI
• New project templates
• Additional validation layers
• Common config file to be shared with rpb

rpb v1.0 is available on itchio.

rpb - raylib project builder

rpb allows to build a raylib project for a desired target platform (as far as supported building from host platform). It uses a pre-configured project, generated with rpc, and including a config.rpc file to process required inputs and assets. It includes a visual UI interface to simplify building for several platforms.

• Platform selection on UI
• Building of required libraries
• Build of project

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.

[ValorZard]

Some sort of webgpu backend would be neat!
Though, since raylib heavily depends on OpenGL, that would need some sort of OpenGL to webgpu translation layer…

[raysan5]

I'm afraid this is out of scope for now but you can check raygpu as an alternative.

[Destructor17]

AFAIK Google puts some effort to make ANGLE run on top of WebGPU. I guess it is not usable right now, but one day it may become translation layer you need. Also expect 5-10MB binary bloat from ANGLE

[groksuperheavy-commits]

• ~~~~

[knuxyl]

What I want the most is OPUS audio and WEBP image support.
Opus is the best audio codec available.
Every image I've tested WEBP in lossless mode would come out smaller than PNG. I don't know decode performance but I haven't had a problem. JXL from just experiencing opening it seems to have a signficant decode time.
I'd prefer these implemented through their reference implementations or external libraries instead of using SDL so GLFW platforms could benefit as well.

[raysan5]

raylib supports file-formats using single-file header-only self contained libraries, afaik, there is no OPUS or WEBP library offering that functionality and implementing such a library could take a considerable amount of work.

[NighthowlerStudios]

raylib supports file-formats using single-file header-only self contained libraries, afaik, there is no OPUS or WEBP library offering that functionality and implementing such a library could take a considerable amount of work.

Actually... @raysan5 ! https://github.com/matanui159/jebp

Only problem is this doesn't support lossy WEBP's, which is understandable if you don't want that, though it seems a lot prefer lossless anyway.

[Peter0x44]

I bet you could vibecode this

[Starchaser0]

support for hit-testing (so i can make custom titlebars) :D

[raysan5]

It can be implemented on user side using CheckCollisionRecs()

[Starchaser0]

It can be implemented on user side using CheckCollisionRecs()

i would have to use an external windowing system (e.g. SDL3) tho, right?

i would prefer to keep everything within Raylib if possible :)

[raysan5]

what? no

[Starchaser0]

what? no

my bad, i should have clarified... ive actually tried this before, using window position manipulation, but that method doesnt work on Wayland, since Wayland doesnt allow windows to modify their own geometry

ive successfully implemented a Wayland-compatible custom titlebar with Slint (by hooking into Winit and manually initiating a winfow drag) and SDL3 (via SDL_HITTEST_DRAGGABLE), but i havent found a way to do it with Raylib. maybe im just stupid, who knows 😅. i would appreciate some advice if thats the case :)

sorry to bother you

[maiconpintoabreu]

GLSL Parser for rlsw.h.

[raysan5]

This could be a lot of work but definitely a very interesting project, adding to the list as I+D!

[Peter0x44]

simple_wgsl might be able to handle this, if extended.

[JoeStrout]

I'd really like clipboard support for images. GetClipboardImage() and SetClipboardImage(image) would parallel the current clipboard text APIs nicely.

(Happy to work this up and submit a PR if that's helpful.)

[raysan5]

GetClipboardImage() is already implemented in raylib 6.0, probably not supported on all platforms. SetClipboardImage() could be added.

[maiconpintoabreu]

The GetClipboardImage is missing the Wayland implementation and the X11 is limited by size.

[JoeStrout]

Perhaps we could add the Wayland implementation for 7.0? (I'm not too concerned by a size limit, unless it's obnoxiously small.)

[tipudeveloper]

i could propably add the GetClipboardImage for wayland as a wayland user

[casperbear]

Example on how to properly open full screen in the best (native) resolution on the current monitor. (with and without FLAG_WINDOW_HIGHDPI). Possibly requires a new function to get list of available resolutions.
To me this looks like something a developer needs on week 2 after starting an app, if they want to send it for testing on another machine.

[Neblinus]

Maybe I can suggest something I did for a prototype of mine?
Probably not good but maybe useful.

Before the window configuration, I had a function that would set the window to fullscreen for less than a second to get the dimensions of the display itself.

After that, it would, on another function, loop through an array of resolutions (that I defined by looking at Steam hardware survey and taking the most used resolutions for desktop), checking some conditions:

• If the current resolution element of the array was equal to the screen dimensions and its width/height relation would result on integer scaling factor (pixel-perfect game), it would set the window to be fullscreen
• If any of the width or height of the current resolution element of the array was bigger than the screen dimension, it was skipped
• If all of the width and height of the current resolution element of the array was smaller than the screen dimensions * 0.7 (so the UI was never too shrinked), and it would result on integer scaling, it would be set as the target dimension of the window, and it would set the window to not be resizable.

Now, I didn't implement everything as I said there (didn't thought about some at the time), but I think it can be an useful idea.

I also actually used hasht-tables like structures (Lua tables) for the Steam defined dimensions for O(1) lookup operation, IIRC.

P.S.: I can give the source code if you find it useful.
Also, on the third dot, if I wasn't clear, if width <= screenWidth * 0.7 && height <= screenHeight * 0.7

P.P.S.: I checked my code and realized that it would actually set the greatest defined resolution (from the said array) that had both width and height lesser than a little bit of each of the screen dimensions. So, a (example) virtual dimension of 1210x815 (completely random and non-standard) would be set to a 1024x768 window, but a 1280x800 screen would set the game window to fullscreen.

[orcmid]

@Neblinus That's fascinating. Especially the focus on integer/rational scaling. I have a languishing mini-project called nfoPixels that could use some of those ideas. The limitation of nfoPixels is that the developer of a raylib-based project has to apply the scaling in using raylib and I have not dug into what that means for pixel-level functions. The problem I wanted to solve had to do with producing code that would scale up when confronted with a high DPI monitor on which text would suddenly become unreadable and the created window too visually small at the assumed resolution baked into the application (as in most raylib examples). I did/do not want to patch raylib to do it.

For nfoPixel, I am neglecting the full-screen, bordered/unbordered, exclusive/non-exclusive business that comes up with AAA games. It looks like your approach can be more compatible with those cases. I will have to do some rethinking if I ever recover from the breaking changes in raylib 6.0.

[Neblinus]

@Neblinus That's fascinating. Especially the focus on integer/rational scaling. I have a languishing mini-project called nfoPixels that could use some of those ideas. The limitation of nfoPixels is that the developer of a raylib-based project has to apply the scaling in using raylib and I have not dug into what that means for pixel-level functions. The problem I wanted to solve had to do with producing code that would scale up when confronted with a high DPI monitor on which text would suddenly become unreadable and the created window too visually small at the assumed resolution baked into the application (as in most raylib examples). I did/do not want to patch raylib to do it.

For nfoPixel, I am neglecting the full-screen, bordered/unbordered, exclusive/non-exclusive business that comes up with AAA games. It looks like your approach can be more compatible with those cases. I will have to do some rethinking if I ever recover from the breaking changes in raylib 6.0.

Thanks!!

Humm...in my experience, the problem of scaling on a pixel-perfect basis is that you cannot have art/assets that aren't pixel-perfect-compatible (so, for example, if you have a .ttf font that wasn't designed for pixel-perfect games, it will become blurry or just awful on a game that follows such pattern).

It also kinda invalidates the use of linear filters, etc.

I have checked my code and it seems the integer-scaling-factor checking was only on my TODO, but you can actually take some idea here and there from it if you want

I'll let a pastebin link to it, if you want to take a look:

https://pastebin.com/TaD57EA4

Its written in Lua, but I'm sure you can understand it.
You can safely ignore the middleclass library (just for easier OOP support) and Logilog (a logging library I wrote).

[orcmid]

@Neblinus
Humm...in my experience, the problem of scaling on a pixel-perfect basis is that you cannot have art/assets that aren't pixel-perfect-compatible (so, for example, if you have a .ttf font that wasn't designed for pixel-perfect games, it will become blurry or just awful on a game that follows such pattern).

It also kinda invalidates the use of linear filters, etc.

That's interesting. I expect that one would use the scaling on the selection of font size (in points/pixels) and line heights in the nfoPixels case. The problem with nfoPixels is that it requires too much understanding and active use, although it's fine for me with the demo screen that my VCrayApp utility creates whenever it rebuilds a cache of raylib *.c-file .objs. I also haven't taken it all the way through beyond a sketchy nfoPixel.h and worked through any non-trivial raylib app.

[preda]

UPD: the example that I was missing is to call InitWindow with zeroes for width and height - that should open in fullscreen (provided the flags are correct). Ok, then the proposal is much simpler, to mention this special case in the .h RLAPI void InitWindow(int width, int height, const char *title); // Initialize window and OpenGL context

But InitWindow(0, 0) does not work for PLATFORM=Web or WebRGFW. There size (0, 0) fails to initialize the window. (tested in Raylib 6.1).

[SHARKgamestudio]

More advanced collision detection functions, such as OBB?

[raysan5]

That kind of functionality can get very complex very easely, I prefer to leave it to physics engines or higher level user modules.

[tipudeveloper]

i agree its very easy to implement box2d with raylib

[NighthowlerStudios]

Webcam input methods? Just one function to snap the current frame from the webcamera or other hardware camera? Trying to find some nice libraries for that but all I can think of is platform specific API calls for each target. While I'm at it, microphone buffer grab methods as well.

[NighthowlerStudios]

I know you previously talked about using external libraries for this here https://www.reddit.com/r/raylib/comments/o0seqt/trying_to_display_webcamera_to_display_using/

but with how simple people tend to use those libraries just to grab a photo once and not much else, not sure how you feel about the idea

[raysan5]

This is interesting to investigate but camera access seems very platform specific to me... but worths investigating...

[pierroelmito]

A LoadRenderTextureEx with additionnal parameters for Multiple Render Target support from Raylib API would be nice.

[raysan5]

This is a feature just a few users need, some time ago some functions were already added to rlgl to support GBuffers on user side, you can check the related examples

[ArdisanZX]

Support for the .it and .s3m tracker module music formats? I feel like this would complete support for the popular tracker module formats, at least until developers add their own more obscure ones.

[raysan5]

That would be nice but raylib only uses single-file header-only libraries for file-formats support, do you know any library for .it and .s3m?

[orcmid]

https://github.com/martincameron/micromod might be helpful. Modified BSD license. Haven't looked closely yet.

[lefloysi]

more advanced options for working closer to the metal with graphics. mesh generation with custom vertex formats is something im missing in raylib. i dont know how possible this in c. i only implemented this system with templates and custom iterators that were really cool to build meshes.

[tipudeveloper]

then shouldn't you just use something like OpenGL of Vulkan?

[Skyedra]

Support to load/blend/play animations that have Shape Keys / Morph Targets in glf files. There is some really cool stuff we can do with them!

[maks7567]

I might be dumb, but I'm not full time programmer either... But I think, is[.....]ButtonDoubleClicked() would be nice.... Thank you.
(I do realize it can be done, but I meant, Natively 😅)

[maks7567]

No you're totally right. But you know😄... It'll make things a bit more tidy for the end user (programmer). And eventually making Raylib more native and fun to use. Btw, I'm creating a GUI, that's why I needed this feature.

[raysan5]

This is a functionality with many side-cases and platform-dependant implementations, I prefer to leave that functionality to higher level libraries or user code... Said that, raylib includes a gestures system that, afair, already implements it in a cross-platform way as IsGestureDetected(GESTURE_DOUBLETAP), because touch can be mapped to mouse (default behaviour).

[orcmid]

@AlomeProg > I can read English reasonably well, but writing in English is difficult for me. I hope my answer has been helpful to someone.

Alexey, not to worry. Your English is clear and precise.

[AlomeProg]

@AlomeProg > I can read English reasonably well, but writing in English is difficult for me. I hope my answer has been helpful to someone.

Alexey, not to worry. Your English is clear and precise.

Thank you, but the credit goes to Qwen3.6. I’m using it as a translator in this case.

[orcmid]

@AlomeProg

Thank you, but the credit goes to Qwen3.6. I’m using it as a translator in this case.

LOL, I have been known to do that. In such cases I also ask to have it translated back to see if my intention has been satisfied.

[AlomeProg]

I’d like to see Texture3D support in Raylib (and while we’re at it, Texture1D as well) for completeness. As I can see, glad.h already contains the necessary definitions for these, but they just aren’t exposed in the library itself. How difficult would this be to implement, and what parts of the codebase might this change affect? From an API perspective, I imagine it could be mostly similar to the existing Texture2D interface, simply adding a “3D” (or “1D”) suffix and removing functions that don’t make sense for 3D and 1D textures.

My primary use case for this is shader-related work.

I’m also considering implementing this myself in a fork of Raylib and then submitting a PR, but I’m relatively inexperienced with graphics programming and not confident I’d be able to implement everything needed correctly.

[casperbear]

I'll comment on a wild assumption that work to add Texture3D support is somewhat similar to Texture2DArray (which I did in my fork).
"How difficult would this be to implement" - if your knowledge of RayLib (internally, the code) is none to limited, then several days of investigation and work to add principal support, i.e. to add some flags to texture struct (or create a new one) and load the texture from list of images.
"what parts of the codebase might this change affect?" For principal support - rlgl.h and rtextures.c, possibly stb_image*.h if something doesn't load as needed from files to images. Then it very much depends on how pervasive you want this new texture type to be, i.e. with what functions (as in DrawMesh, DrawMeshInstanced) you envision you will pass that texture to the shaders. I would stay away from DrawBillboard in the beginning. There is very sophisticated code that juggles current/previous context, flushes commands to GPU on a counter, and has backward compatibility with older OpenGL. A mesh is more sophisticated than a billboard but that drawing pipeline around billboard compensates for that.
"I’m also considering implementing this myself in a fork of Raylib" - go for it! If nothing else, you'll understand a lot.
"and then submitting a PR" - well, do it for your own needs first. After you implement it for your needs, chances are you will realize that to add it properly is quite complicated.

[raysan5]

I'm afraid I prefer to avoid that kind of additions, most users don't need it and it adds considerable maintenance work increment.

[AlomeProg]

Thank you for the quick response. I understand raysan5’s point of view. Thanks to casperbear for the detailed answer. Now I have something to think about and some things to examine more closely. I think I’ll go the fork route and try adding the functionality I need, thereby both learning the codebase and assessing how difficult it is to implement the features I want.

A small addition for casperbear: as I understand it, 3D and 1D textures aren’t used for direct rendering onto a mesh; rather, they serve as data purely for the GPU. Otherwise, I find it hard to imagine how that would even work. So theoretically, this approach should be simpler than working with a Texture2DArray, which, in my understanding, is just an array of textures where you need a way to specify which texture from the array to use.

In summary… graphics are complex but interesting.

[Boyfinn]

LoadMeshFromMemory() and LoadModelFromMemory()

[ThreeBrickBoys]

Can we get MSAA 4X HINT for render textures?

[raysan5]

Sorry, no plans for this feature, you can look for it on closed PRs.

[ThreeBrickBoys]

At least a way to save the current screen to a texture/image, like takeScreenshot but not saved to the disk? I want to be able to render a simulation in raylib and not have to save every photo to the disk. But nothing beats MSAA 4X for anti-aliasing...

[Peter0x44]

This already exists. LoadImageFromScreen

[ThreeBrickBoys]

Thanks Peter. I can't believe I didn't find it

[Peter0x44]

That's exactly what Take screenshot uses. Read code, it helps.

[rolpon-cpp]

Add a networking side/part of raylib. It doesn't need to be super fancy or complex, just a wrapper around well known networking stuff like enet or gamenetworkingsockets. It could really speed up multiplayer gamedev!!!

[raysan5]

It was created long time ago (rlnet) but unfortunately maintenance was a big problem and was removed. You can use nbnet instead, created by a community member, very good: https://github.com/nathhB/nbnet

[preda]

It was created long time ago (rlnet) but unfortunately maintenance was a big problem and was removed. You can use nbnet instead, created by a community member, very good: https://github.com/nathhB/nbnet

Some support for communication for Web as well. To easily create multi-player Web games.
The technologies underneath could be WebSockets or WebRTC. Both require some server-side support in production. To offer a multi-player game without having to provide a server, some of the "free-plan" server-less providers could be offered, e.g. things like: Firebase RTDB, Pusher, Ably or something else.

The goal would be to make it as easy as possible to create a proof-of-concept raylib game where two players, in the browser on their respective mobile phones, join a two-player game.

There would be a need to expose this in the form of an API that can be implemented on all platforms. On the desktop would be easier by going to the network level (TCP or UDP) while on the Web the same API would use what's available at the JS level.

[ValorZard]

As someone with experience with WebRTC, doing that would be enormously complicated to setup and maintain as part of Raylib.
It really should just be a seperate library (or else you’d have to bundle OpenSSL with Raylib)

[preda]

As someone with experience with WebRTC, doing that would be enormously complicated to setup and maintain as part of Raylib. It really should just be a seperate library (or else you’d have to bundle OpenSSL with Raylib)

I was thinking more on the lines of: provide a communication API as part of Raylib, that is implemented using TCP or UDP on desktop and implemented by passthrough-to-JS on Web. Thus avoiding the need to bundle OpenSSL with Raylib for example.

[ValorZard]

That wouldn’t really work, SCTP (the protocol that WebRTC uses) is not compatible with UDP.

You may want to look into WebTransport when that gets stablized. It uses QUIC instead and is comparatively a lot simpler to maintain

[mfbulut]

Can we add IsKeyPressedRepeat function
It is a really useful to have I usually add it myself

[Peter0x44]

raylib/src/raylib.h

Line 1202 in 9ef6850

RLAPI bool IsKeyPressedRepeat(int key); // Check if key has been pressed again

It already exists???

[mfbulut]

my bad i didn't noticed it

[Boyfinn]

struct uniform support for the shader API?

[SewerynKaminski]

Cross platform screen saver suppression support.

[CarlLee]

Vector graphics and animations would be nice

[rossberg]

[windowing] Provide means to detect a monitor's client area, i.e., the equivalent of glfwGetMonitorWorkarea.

In line with the current API, this could e.g. be in the form of functions like

RLAPI Vector2 GetMonitorClientAreaPosition(int monitor);            // Get specified monitor's client area position
RLAPI int GetMonitorClientAreaWidth(int monitor);                   // Get specified monitor's client area width
RLAPI int GetMonitorClientAreaHeight(int monitor);                  // Get specified monitor's client area height

[gk646]

Basic web handling functions:

• Send Post Request
• Get request

This makes users avoid another dependency. Can be implemented natively for platforms like Windows and Mac and using libcurl on linux and android (?)

Id be happy to submit something

[Peter0x44]

I vibecoded this before, it's not too difficult.
Though I feel it should be separate from raylib, it has no reason to be tied to it.

[gk646]

Fair, just kinda takes away another annoying dependency for when you want to do basic web things, which is one of the themes of raylib too. But i guess it might be too far from the library purpose.

[ELopSi]

Logical Render

• Stretch
• Pixel Perfect
• Letter Box
• Integer Scale

Raycast 2D

• Raycast Ray, Rect, Circle
• CheckCollisionRayRay
• CheckCollisionRayRect
• CheckCollisionRayCircle
• ...

Logical Render

The current way I work with Raylib 6 is using the Camera2D to render the screen to a texture and do all the shenanigans I want. But it would be nice to have an option that is just set and forget, something like SetLogicalRender(camera2d, PIXEL_PERFECT).

SDL3 can be a good reference: https://wiki.libsdl.org/SDL3/SDL_SetRenderLogicalPresentation

Raycast 2D

Raycast 3D already exists in the API, but it would be nice to have a proper Raycast for 2D as well. Maybe this is the most missing feature for me. I do a lot of 2D development in Unity, which for now has the best Raycast 2D to work with for me.

Maybe is a good reference: https://docs.unity3d.com/ScriptReference/Physics2D.Raycast.html

I know it is possible to get a similar effect using line collisions, but I think a proper Raycast 2D would be better. Working with lines in a way where you always need to set start and end position is always confusing in complex logic, like player vision or area scans.

This is my wishlist for 7.0,
Thank you very much for the awesome work in the project.

[raysan5]

About the logical renderer, it can be managed on user side, no plans to follow SDL approach, actually there is an example for that: https://www.raylib.com/examples/core/core_window_letterbox.html

About Raycast can also be left to user, actually raylib is not a physics library and it does not intend to be despite providing some collision detection functions for convenience. Highly recommended using Box2D ot Box3D.

[ELopSi]

Oh yeah, I already kind of know that. But it’s worth a try.

The logical render was only for convenience, because in my head it makes sense to have this option, but yeah, the user can manage it indeed. The 3D side has a minimal Ray system; I thought maybe the 2D side could have one too, xD.

Anyway, thanks for the reply. I wish the best for the project and can’t wait to see the news for 7.0.

[jestarray]

what is the rational behind removing n-patch? I currently use it and I don't see why remove it

[raysan5]

Simplification, I think it belongs to a higher level engine. It requires a specific opinionated structure that can be implemented on user side. In any case, at this moment there are some functions missing in raylib to configure texture coordinates from a rectangle, so, I needs to analize the cost carefully.

[Ne0nWinds]

I have a proposed change to how input is handled in rcore.

At low frame rates, raylib can miss pressed and released events. This is because the input system is poll-based and simply compares the current button state (at the time of polling) with the button state of the previous input poll. If the frame rate is low, and the user presses and releases the same button in-between frames, the IsPressed and IsReleased set of functions will return false, despite the user doing both of those actions.

I have used raylib to make small visualizations that had an animation speed of 10-15 FPS, and this was particularly noticeable.

My proposed solution would be to just add a separate pressed and released state to Core.Input, signifying whether or not a key/button was pressed/released at any point during the entire frame. The main counter-intuitive consequence of this is that IsMouseButtonPressed and IsMouseButtonReleased (or equivalents for other input devices) can return true in the same frame. However, I'd argue that more accurately describes what happens when a user quickly pressed a button.

I have a small example of what I'm proposing here: Ne0nWinds@31ce9c5
This is just implemented for the mouse buttons on win32, but can be extended to other buttons/keys/platforms. This commit allows the mouse pressed/released functions to work as expected, even at super low frames rates like 5 FPS.

This would be a small change to each platform layer. I think most platforms have some kind of "key down/key up" event queue that would make this work. However, for platforms/input devices that only have polling-based input, we can simply fall back to the following behavior in PollInputEvents:

if (cur && !prev) pressed[i] = 1;
if (!cur && prev) released[i] = 1;

Thanks, and let me know what you think!

[jestarray]

in 7.0, I want to try and get the SDL platform working with Android, that way we'll have 2 android backends. It's also worth noting that PLATFORM_DESKTOP_SDL should probably be renamed because SDL works more than just the desktop, since I got it to work on Android too

[cos1110]

I've been experimenting with some mesh creation APIs of my own, and essentially all of the work as to make mesh creation a bit more API-friendly, instead of dropping raw arrays.

However in this case I find it very interesting to utilize exactly all of the existing capabilities of the API itself.

// using rlgl to draw a rect as per example
rlBegin(RL_TRIANGLES);
        rlColor4ub(color.r, color.g, color.b, color.a);

        rlVertex2f(position.x, position.y);
        rlVertex2f(position.x, position.y + size.y);
        rlVertex2f(position.x + size.x, position.y + size.y);

        rlVertex2f(position.x, position.y);
        rlVertex2f(position.x + size.x, position.y + size.y);
        rlVertex2f(position.x + size.x, position.y);
rlEnd();

// now using the magic function to retrieve a mesh
Mesh myRect = rlRenderBatchToMesh();

[rmn20]

I wish there was support for loading vertex colors from wavefront obj models. Float vertex colors would also be great. 8 bits are enough for most use cases, but it doesn't work for baked lighting as you get ugly clipping. Baked lighting is still used in PS1/2-like indie games, and both the PS1 and PS2 supported a 0-2 vertex color range. I already implemented these changes locally so perhaps this could be a pull request.