raylib 2.0 release planning

[raysan5]

I'm just listing in this issue the latest planned features that remain to be added for the official release of raylib 2.0.

In the last 6-7 months raylib has really changed a lot and some long-term objectives for the project have been accomplished, specially remarkable the complete removal of external library dependencies, currently all required dependencies are seamlessly build with raylib library (and included with raylib sources).

Current list of changes included in this future release could be found in CHANGELOG.

This is the list of remaining points I'd like to accomplish (a part of taking care of some random bug):

• [x] LoadFont() - improve font packaging on atlas #375
• [x] LoadFontSDF() - support signed distance field font atlas generation #376
• [ ] TCC compiler setup as default to be included with Windows Installer #435
• [x] Prepare Notepad++ scripts for TCC compiling (source and examples)
• [x] Review Notepad++ intellisense for new raylib functions (XML)
• [x] Review raylib examples -> some could be broken...
• [x] Replace the dwarf model and textures for something more aligned with raylib style (low-poly?)
• [x] Complete review of Wiki for different platforms compile/usage.

Those are the my main concerns, feel free to comment if some important point is missing.

[gen2brain]

I would just add this issue to list https://github.com/raysan5/raylib/issues/306 , some examples do not compile because headers are not installed system wide, some Linux distro for example.

Also, are you going to wait for new mini_al release? I browsed through commits and those assembler instructions improvements (I think both arm and x86) sound really nice.

[raysan5]

Hey @gen2brain! Thanks for the feedback! :)

About #306, not sure yet how to address it, don't want to go for the #include <raylib/raylib.h> style and some of the libraries don't need to be exposed for most of the users.

What about just installing raymath.h and easings.h? raygui.h and physac.h could be useful but are intended for specific use cases (and have their own repos).

About mini_al release, I agree, it's better to wait for it but I think it will be ready sooner than finishing all the points above.

[gen2brain]

I think raygui.h is not used in examples, so if physac examples are not installed by default that is ok solution. With maybe just easings.h renamed to something ray like.

And for physac examples maybe to add some flag, but not install it by default.

[victorfisac]

I'll review in the following days issues related to PBR example and Physac.

I realize, in some functions, Notepad++ displays a different overload helper (random example: when writing DrawTexturePro(), the overload helper displays the parameters to complete of DrawTexture()). It would be so nice to get it fixed... It can confuse newbie users.

[raysan5]

Hey @victorfisac! Just working on Notepad++ auto-completion right now! Uploaded several related files in commit https://github.com/raysan5/raylib/commit/8ae8d3ac782825d732a0680bd1ad80db420718a9.

You can check them in projects/Notepad++ folder. Also added a tool to parse raylib.h to auto-generate Notepad++ autocompletion.

About the "overload" functions issue, it seems related to Notepad++ internals, no idea how to solve it...

[RDR8]

currently all required dependencies are seamlessly build with raylib

Watching you folks work is really fun. It's an interesting group. Kudos for your accomplishments so far.

[raysan5]

Just launched a raylib 2.0-dev pre-release, I need it to be available for the imminent publishing of rGuiLayout and rGuiStyler tools.

If you're not following raygui project, those tools are intended for tools creation based on raylib. That project took most of my time for the last 5 months. :)

Keep working on raylib...

[sherjilozair]

I'd say https://github.com/raysan5/raylib/issues/530 should be part of the release.

[Martinfx]

Hi, please @raysan5 re-release with last commits, i cannot compile on freebsd.

[raysan5]

hi @Martinfx! Just re-relased as 2.0.1-dev, sorry for the inconvenience...

[a3f]

@raysan5 I think 2.0.1-dev is an unfortunate tag, if you are going to release the final version as 2.0.0, because the version number would decrease. We could replace -dev with a -rc (release candidate) suffix? e.g. v2.0.0-rc1, v2.0.0-rc2 and so on...

[a3f]

Related: As multiple distributions will probably include a raylib v2.0 package soon, should we perhaps make some formal guarantee for backwards-compatibility?
e.g. All v2.* releases are backwards-compatible with v2.0 or at least add a master-2.0 branch to which we cherry-pick bug fixes, but don't add new features?

[raysan5]

@a3f you're completely right... just realised it... relaunching it!

[raysan5]

@a3f, that would be the ideal situation but there are so many things that I'd like to improve and features to add that... I don't know the best way to manage it...

Maybe we can try, at least, to keep the v2.* API stable (no changes, no deletions), allowing ABI to change and possible function additions.

[jubalh]

How comes the tarball is ~90MB big o_O

[jubalh]

It would be good if CMake folks could update https://github.com/raysan5/raylib/wiki/Working-on-GNU-Linux to list all options. Simple table with option and meaning would be beneficial. Partly done by the section Building Examples but a table with all the options would be good.

Especially since some things are different and others are the same between different build systems:
differnt:
make - RAYLIB_LIBTYPE=SHARED
cmake - -DSHARED=ON

same:
make - PLATFORM=PLATFORM_DESKTOP
cmake - -DPLATFORM=PLATFORM_DESKTOP

If I interpret the current documentation correctly you need:
make PLATFORM=PLATFORM_DESKTOP RAYLIB_LIBTYPE=SHARED # To make the dynamic shared version. - Recommended to create the shared lib with make.
But only cmake -DSHARED=ON to build the the shared lib with cmake.

All of those things that some things are different and others are the same but it is not clearly documented isn't very nice.
It should be fairly easy for the people who created the files for the build systems to adhere to one common style or at least document it completely in that wiki article.

I think this is something that should be done before 2.0.0 release.

[jubalh]

Building with cmake:
cmake -DPLATFORM=PLATFORM_DESKTOP -DSHARED=ON -DUSE_EXTERNAL_GLFW=ON actually builds:
libraylib.so.1 and libraylib.so.2.0.0

While it is possible that we build two libraries to support both ABIs I doubt that this was intentional so I wanted to ask here about it too.

[a3f]

at least document it completely in that wiki article.

I refactored all the CMake options into a single CMakeOptions.txt file a few weeks ago. A User can fill that to their liking or call ccmake for interactive configuration. I amended the Wiki entry to reflect this.

actually builds: libraylib.so.1 and libraylib.so.2.0.0

These two need to be bumped to API version 2:

https://github.com/raysan5/raylib/blob/fb4265f64659a50a5a86f9f283e7468b7998c60f/src/CMakeLists.txt#L6

https://github.com/raysan5/raylib/blob/fb4265f64659a50a5a86f9f283e7468b7998c60f/src/Makefile#L46

[jubalh]

I refactored all the CMake options into a single CMakeOptions.txt file a few weeks ago. A User can fill that to their liking or call ccmake for interactive configuration. I amended the Wiki entry to reflect this.

Not sure what you are saying here.
A list with all the options is missing in the wiki isn't it?

And is -DPLATFORM=PLATFORM_DESKTOP -DSHARED=ON needed or is the latter sufficient?

These two need to be bumped to API version 2

Yes, that's what I thought.

[a3f]

Not sure what you are saying here.

I am saying I added a notice:

_NOTE:_ raylib is configurable and can be be built in a variety of ways. Please read src/CMakeOptions.txt for a full listing of available options and values. Alternatively, you may use the curses UI provided by ccmake(1) for configuring raylib.

[jubalh]

In this case I still think that the options between build systems should follow the same naming. And that a list would be beneficial.

After all raylib is for beginners who want to start developing games.
Having different build systems might for some be confusing enough. At least they should be well documented, and not ask them to read the build scripts.

It's also easier for packagers to have a quick look at the overview.

[a3f]

In this case I still think that the options between build systems should follow the same naming

I agree.

And that a list would be beneficial.

src/CMakeOptions.txt on its own is quite readable IMO, but there you go: https://github.com/raysan5/raylib/wiki/CMake-Build-Options.

[raysan5]

@a3f thank you very much for adding this table to the Wiki!

[jubalh]

@a3f thanks! Highly appreciated.

[raysan5]

Just a recap on the state of proposed features.

• Improved font atlas creation (and SDF font) is almost ready. I've been working offline on those features (in a custom example) and it's not uploaded yet, I couldn't find the time for proper refactoring and integration.

• TCC compiler is already working with raylib, for 32bit and 64bit host systems, I created Notepad++ NppExec scripts to support MinGW-w64 and TCC compilers with different configurations, similar to a Makefile (using conditions and GOTO...) but I think I will simplify those compiling scripts to just use TCC... and provide separate scripts for MinGW users.

• About replacing current dwarf model in examples, already borrowed some amazing 3d models from my students (CC BY-NC 4.0) but I didn't update the examples yet with the new 3d material.

• I also reviewed some platforms info on the Wiki... but still some work to do

[raysan5]

Mostly complete, only some final touches... examples review and multiple platforms testing (Android, RPI and HTML5).

[raysan5]

Some update on the process:

• [x] Dwarf model finally replaced by a set of beatiful medieval building 3d models, created by one of my students: Alberto Cano.
• [x] Font atlas generation from TTF completely rewritten, added support for SDF fonts, still testing it and preparing some sample.
• [x] Examples need to be manually tested on Raspberry Pi device
• [ ] Android build system for raylib examples (APK generation) needs to be reviewed and tested
• [x] Android and HTML5 building instructions in Wiki need to be reviewed, they are really outdated!
• [ ] Windows Installer package (with raylib, Notepad++ and compiler) needs to be prepared, actually, I'm thinking about preparing two packages, a TCC-based minimal one (~15MB) and a MinGW-based one (~180MB). That's a manual process that takes some work...

[mackron]

A new version of mini_al should be done soon. All major features are in, including the Core Audio backend for our macOS friends. I'm just working on testing.

[raysan5]

That's amazing @mackron! I'll wait for it then.

Also thinking about a full review of raylib audio module, there was some inconsistencies between sampleCount and frameCount.

[mackron]

There was also an improvement to the mixing code I've been wanting to do which removes the locking code and replaces it with a lock-free ring buffer, but unfortunately I just don't have the time to work on that right now :(

[raysan5]

@mackron no worries! take your time for the improvements, I'll integrate them when ready.

Also adding support for MP3 files using your dr_mp3.

[KTRosenberg]

Is there a reason that in the ausio module .wavs can't be loaded as MusicStreams?
Also, I discovered this project when searching for a simple way to play looping background music, but there doesn't seem to be an option for arbitrary loop-points. However, looking at the code it looks like all I need to do is move the frame count. If that's right and I can run raylib back on my main computer (a mac) then maybe I can slide in that feature. I'm not sure if there's something more complex that I might have missed though.

[raysan5]

Usually wav are used for small sounds instead of music, so they were not considered for streaming... that's the only reason...

About arbitrary loops, it could be a good addition but I think it could require more work than expected... didn't analize the feature carefully...

[KTRosenberg]

Fair enough regarding the .wavs. Re: the arbitrary loops, is it more complicated than setting the frame counter in MusicStream's update function? Usually game music has a prelude part that isn't repeated.

[KTRosenberg]

Also, it would be good if the wiki page on installing the standalone audio module were completed. On mac I have been encountering issues. For example, the AudioBuffer conflicts with CoreAudio's AudioBuffer struct, which means that either I am compiling incorrectly or this is a mac-specific issue. If it's the latter, I would recommend renaming to RayAudioBuffer.

In addition:

#if defined(SUPPORT_FILEFORMAT_FLAC)
        case MUSIC_AUDIO_FLAC: /* TODO: Restart FLAC context */ break;
#endif
#if defined(SUPPORT_FILEFORMAT_XM)
        case MUSIC_MODULE_XM: /* TODO: Restart XM context */ break;
#endif

Shouldn't it be possible to reset FLAC at least?

[raysan5]

I'm publishing raylib 2.0. Closing this issue.

Please, feel free to open additional issues regarding audio.