raylib 2.6 roadmap

[raysan5]

raylib has grown a lot in the last years and like in the past, I feel is time to sit down and think carefully about raylib next steps. It's very easy to lose focus and keep adding features to make raylib the next big engine... that's not raylib pourpose.

So, for next raylib installment, I'll try to focus efforts on library stability and core features to improve the multiplatform raylib experience. I'll try to leave aside new 3d features... 3d requires lot of effort and time.

Proposed improvements:

• DONE [core] Frame stuttering when using Sleep() mechanisms. This issue worries me, when avoiding the BUSY_WAIT_LOOP, it seems there is a micro-second delay every second or so, it seems related to the time required to recover from the system halt. I investigated it but I couldn't find a solution yet. Help is welcome! [core] Stuttering on animated elements every second or so #865 Possible solution: 42d56d2

• DONE [core] Input mechanisms review, try to unify it between platforms. Specially focus on:

  • SKIP Raspberry Pi input system, reviewed several times in the last year to replace raw keyboard input reading mechanism by evdev based input reading (inputs already processed by OS), both mechanisms are enabled at this moment for compatibility reasons (SSH keyboard support) but most probably only evdev one should be available. [core] Keyboard input system not working properly #863
  • DONE Android and HTML5 touch input system should be reviewed to properly scale inputs when framebuffer does not match display resolution and it's consequently scaled and offseted. [core] Review touch inputs scaling #163
  • DONE Desktop and HTML5 inputs should be redesigned to support mouse and touch inputs as they were the same, so the same applications could work indistintly with mouse and touch. [core] Broken touch input for web demos #726

• DONE [core] Improve High DPI support. This is tricky, High DPI means that depending on the screen DPI your fixed pixel-size applications will look bigger or smaller on the screen. Solution implies re-scaling application framebuffer and mouse/touch inputs to match an equivalent resolution for the new DPI... it looks like a hack to me and doing that scaling brokes any pixel-perfect design of the original application, for example fonts. Additionally, every OS deals with that in a different way, some OS could automatically scale mouse input or even display window. I have to find a solution... [core] Mouse position reports incorrect values on macOS #826, [examples] shaders_julia_set doesn't fill screen on Macbook Retina #837

• DONE [rlgl] This module has already been redesigned several times to improve draw batching mechanism. It was lately reviewed to improve push/pop vertex transformations, similar to OpenGL 1.1. Right now, those stored transformations are not applied to mesh drawing, it shouldn't be difficult to support it: [models] DrawModel() does not use current matrix from rlPushMatrix() #901 [core] GetWorldToScreen() does not support current matrix from rlPushMatrix() #902

• DONE [textures] Review ImageDraw() function. This is the base function for all Image drawing funtions (including text drawing on Image), that's the core for the basic 2d software renderer provided by raylib, it has some issues and it should be reviewed. [textures] Review/rewrite ImageDraw() function  #555

• DONE [raudio] This module was redesigned some time ago to use the amazing miniaudio library but base design still comes from the previous OpenAL implementation, I would like to review and improve internal library structure and also promote its standalone usage mode. Some points to review:

  • DONE Review AudioBuffers vs AudioStream structures, maybe they can be unified and exposed to the user for custom audio streamming implementations.
  • DONE Review Music structure to avoid an opaque structure and expose Music parameters to the users, it will also make things easier for people creating bindings to raylib.
  • SKIP Support for WAV music streaming, same as any other audio format. Right now WAV files are fully loaded into memory.

• DONE [examples] Some examples do not work on some platforms and require review, some new examples are also proposed:

  • DONE Review examples based on shaders on HTML5/RPI. [examples] raylib 2.5 Web examples review #847
  • DONE Review examples based on shaders on RPI. [examples] raylib 2.5 Raspberry Pi examples review #851
  • DONE Some new examples proposed: [examples] Some new examples proposed #890
  • SKIP Examples using Camera on Android

• SKIP [rlvk] It's been long time I want to dig into Vulkan backend but the truth is that I can't find the benefits for raylib. In any case, I don't discard jumping into it if I had enough time.

Well, this is the intended roadmap for next raylib. Nothing set on stone!

Please, let me know your thoughts! :)

[AregevDev]

Maybe adding a viewport system?
LibGDX let's the user's choose between them.

Inspiration: https://youtu.be/D7u5B2Oh9r0
This could be set via a config flag or by its own function.

I am not experienced enough to implement such thing, only a suggestion.

Nice work, keep up

[raysan5]

@AregevDev it can already be coded by the user, actually, there is an example showing window scaling: core_window_letterbox. It can be combined with Camera2D for 2d games.

[chriscamacho]

I think taking a step back and generally improving stability is a very good idea.

Bloat really could kill raylib (this is a very real issue)

some parts of raylib could be moved into separate raylib sub modules, for example.... audio, core and 2d, 3d, examples could all be split off

glfw offers some fps management (hints) which work well, but used to have issues with some platforms

if resolution independence (like core_window_letterbox) was built into raylib (as a fundamental), then things like mouse projection and view port handling would be a lot easier, for example I have to code my own version of mouse projection in a project because I wanted resolution independence and a separate 2d menu area from a 3d area.... having this resolution independence could have a number of other benefits too...

If I get time (hahaha) I hope to investigate some of the mentioned issues, keep up the fantastic work!

• [rlvk] It's been long time I want to dig into Vulkan backend but the truth is that I can't find the benefits for raylib.

Well OpenGL is deprecated on macOS and will no longer work someday which would kill cross-platform support. I mean Vulkan won't be part of macOS either as far as I understand but there is MoltenVK so it should work. Or maybe Vulkan and Metal should be implemented.
And Vulkan of course also offers much higher performance and is more CPU/GPU balanced, it's made for today's world. OpenGL isn't. I think rlvk would be a good thing for raylib.

Also you mentiond in Discord once that DrawGrid should maybe have a color argument. Maybe that should be on the list?

[chriscamacho]

Well OpenGL is deprecated on macOS
alas as far as I understand it vulkan won't be a part of MacOS either, as they have decided to go their own way... in favor of Metal, a glimmer of hope is MoltenVK, so Vulkan may well be the future of cross platform... we can only hope...

[zertyz]

Ray, thanks for sharing this great lib!

I felt tempted to write here after reading your plan on improving stability and the multi-platform experience. Using the same code on Raspberry Pi, Android, Web and, of course, the desktop, not just improve the value of the software written, but is also totally tuned for the young generations of future developers.

I'll use your lib on 2 new projects: first, teaching my nephews (8 and 12) to program -- probably using Lua. Then slowly introducing them to C/C++ when they feel the need to show their work on their mobiles, web, desktop...

The second project is for the monitoring of an online, mission critical service. The UI the monitoring app will be running on a Raspberry Pi in standalone mode, attached to a TV and controlled by the TV's remote. It will also wake up the TV & Play sounds when important events are detected by the auto monitoring features of the appliance. Wonderful to think the monitoring team can inspect the operation metrics also via web and mobile, although we are prepared to face the reality of multiplatform UI development.

Just wrote to introduce myself... As soon as I get familiar to your lib, I'll probably submit some PR's focusing on the principles stated on the OP.

-- Luiz.

[raysan5]

@zertyz thank you very much for your feedback! :D

Both project seem fantastic! Good luck!

You're welcome to contribute! Waiting for it!

[topcheese]

I just discovered this yesterday and I think I'll start using it in some projects. Long story short I also just recently discovered the Zig programming language, and decided to learn and use it. The developer of that also created an audio library http://libsound.io/ that I was going to use in some projects.
I had miniaudio on the top of my list to use, but now I'd be interested in possibly using libsoundio as an alternative. I'm not even close to that point yet, and I thought I'd just mention it. Thanks for the excellent library!

[raysan5]

@topcheese hey! thanks for leting me know! Hope you enjoy raylib! :D

[topcheese]

Funny thing is I plan to use the Ring language instead. They recently added support, and I'm trying to test it on Linux right now. I'll have to update you later on my progress with it.

[hpcorona]

He, great job here!!

I have a question, regarding support for iOS.

Is this supported? i don't see any reference even in the code.