Another raylib release is here: raylib 1.8.

Again, several modules of the library have been reviewed and some new functionality added. Main changes of this new release are:

• Procedural image generation functions, a new set of functions have been added to generate gradients, checked, noise and cellular images from scratch. Image generation could be useful for certain textures or learning pourpouses.


• Parametric mesh generation functions, create 3d meshes from scratch just defining a set of parameters, meshes like cube, sphere, cylinder, torus, knot and more can be very useful for prototyping or for lighting and texture testing.


• PBR Materials support, a completely redesigned shaders and material system allows advance materials definition and usage, with fully customizable shaders. Some new functions have been added to generate the environment textures required for PBR shading and a new complete PBR material example is also provided for reference.


• Custom Android APK build pipeline with simple Makefile. Actually, full code building mechanism based on plain Makefile has been completely reviewed and Android building has been added for sources and also for templates building into final APK package. This way, raylib Android building has been greatly simplified and integrated seamlessly into standard build scripts.


• rlgl module has been completely reviewed and most of the functions renamed for consistency. This way, standalone usage of rlgl is promoted, with a complete example provided. rlgl offers a pseudo-OpenGL 1.1 immediate-mode programming-style layer, with backends to multiple OpenGL versions.


• raymath library has been also reviewed to align with other advance math libraries like GLM. Matrix math has been improved and simplified, some new Quaternion functions have been added and Vector3 functions have been renamed all around the library for consistency with new Vector2 functionality.


• As always, examples and templates have been reviewed and improved to work with new features; some new examples have been added and templates have been prepared for real multiplatform support including Android and HTML5.

For a detailed list of changes, check CHANGELOG.

Just enjoy learning with raylib 1.8!

Awesome job man.

I have one small suggestion for the cheatsheet page. The struct section doesn't list the struct members, meaning i have to dig into either examples or source to find what they are. Think it would be possible to get them up on that page?

Hey Murry!

Yeah, I know, actually it took me a while to took the decision of avoiding structs members... if adding that information cheatsheet would become pretty big... I'm thinking about a better way to add that info, maybe a direct link to GitHub code down the structs box? Any idea?

Hmm, i think a separate page on structs might be good.

That or you could maybe have an expanding section on the page.

Thanks for the ideas! I'll think about it! :)

Ok i got vertex buffers uploading properly to the gpu now. Had to watch some vids on opengl to properly understand but feel much better about this for the experience.

I just have a few questions, just for the sake of learning.

there is a rlUpdateMesh function, (it doesn't seem to be used anywhere though)

but for some reason you have the number of verts you are updating as a number, and if you go over it, it changes from using glBufferSubData to glBufferData. why would you ever want this as an abstracted internal switch like this? i can't think of a case where it would be useful to have this in the same function. One is generating a new buffer and the other is just modifying it. so calling sub, is fast enough to happen per frame, but normal will crash the program calling per frame? I just want to make sure i understand this correctly.

And of course the only time you would actually want to remake the buffer is when you are adding new verts, but wouldn't it be better to just have empty buffer to fill into, and only expand it if it outgrows it.

I'm thinking from the direction of that i want to eventually mess with some modelling tools, so this is of interest to me. Of course this isn't the intended use of raylib, but it's fun to mess with.

Really enjoying the library so far, it's the only engine i've even found accessible to hack in. I'm thinking of maybe looking into writing a collada importer, and perhaps even thinking about bones/skinning.

Super awesome stuff.

Muzz

but for some reason you have the number of verts you are updating as a number, and if you go over it, it changes from using glBufferSubData to glBufferData. why would you ever want this as an abstracted internal switch like this? i can't think of a case where it would be useful to have this in the same function. One is generating a new buffer and the other is just modifying it. so calling sub, is fast enough to happen per frame, but normal will crash the program calling per frame? I just want to make sure i understand this correctly.

And of course the only time you would actually want to remake the buffer is when you are adding new verts, but wouldn't it be better to just have empty buffer to fill into, and only expand it if it outgrows it.

(disclaimer I haven't viewed the source yet)

Sound like he reallocs the buffer only when it needs to grow. That isn't optimal though, modern drivers can do buffer orphaning where if you do glBufferData again while the buffer is in use by a previously dispatched command it will create a new buffer and defer freeing the buffer until nothing is using it.

Of course this requires that the driver recognizes what you are trying to do...

ratchetfreak
Sound like he reallocs the buffer only when it needs to grow.

Actually, that was the idea of using glBufferData() or glBufferSubData() but I'm concerned that driver can decide the moment when freezes that memory if buffer is being used.

About rlUpdateMesh(), I don't like that function. I created it to allow users to update mesh buffers data... but buffers ids are hardcoded because Mesh struct VBO ids are also fixed (on Mesh loading) for every type of data... I don't like that approach, not flexible enough for the user... but this is the current implementation.

On the other side, internal dynamic buffers (the ones used for basic shapes drawing) have a fixed size and only the required vertex attributes. They are updated every frame with new data... if size limit is reached while filling those buffers (well, actually, the CPU counter-part) a draw call is dispatched and buffers reseted. That approach has a big issue, when dealing with lot of data to draw, buffers are not updated-drawn fast enough and pipeline is stalled (fill rate issue?), limiting the amount of data that can be drawn on screen, check raylib/examples/others/bunnymark.c for an example on this.

Muzz
Really enjoying the library so far, it's the only engine i've even found accessible to hack in.

That is one of the goals of the library, try to make it easy enough to learn from it... but also for that reason I avoided using more complex approaches for internal dynamic buffers like using a multibuffer system or detecting if data changes from frame to frame to avoid re-uploading same data to GPU, making it more efficient.


PS. By the way, seeing the posted GIF, did you know that with CTRL+F12 you start/stop automatic GIF recording? I implemented that feature for my students...

Ah cool. i'll use the gif recording from now on, thanks!

Thanks for the clarification on the usage of those functions, very useful. I think i'm getting a pretty good understanding of how all this functions.

EDIT: i can't work out where the gif saves out to?

EDIT: i can't work out where the gif saves out to?

It should be in the same folder as the executable. Name should be screenrec00.gif.

Crazy question - any chance of UWP support?

I know, I know. UWP is... not fantastic, to put it diplomatically. But if one good thing came out of it, it was the Xbox Live Creators Program. Basically, anyone can use an off-the-shelf, retail Xbox One as a dev kit without going through Microsoft proper, provided that your app supports UWP.
I'm a part-time educator, and would be over the moon if my students could use raylib to work on Xbox. So, any hope in the future?

Thanks for all the work you do!

Hi Sam!

Actually UWP support through Angle (OpenGL ES 2.0) was on my TODO list a couple of raylib versions ago and just discarded it... it's not too complicated but it requires some time and currently my TODO list is endless... >_<

But who knows, FreeBSD platform support was just added last week by another user and the last couple of days I've been helping another Raspberry Pi user to get raylib working on Raspbian desktop with OpenGL 2.1 (a part of the native OpenGL ES 2.0 support)...

I really like UWP, actually, before raylib, I created two games for Windows Phone platform... with not much success...

So, any hope in the future?

I can not assure anything but don't lose hope... ;)

Well, that's encouraging! In the meantime, I'll continue keeping an eye on this project.

(Also, I can't speak to the quality of the UWP API itself - it's just that Microsoft's push into a walled garden usually leaves a bad taste in my mouth. :P)

Best of luck in the future!

Hey Sam!

Just spent a couple of days playing with this and got raylib working on UWP. I setup a Visual Studio 2015 project to test it, check this new raylib branch: https://github.com/raysan5/raylib/tree/testing_uwp

Rendering works ok through Microsoft ANGLE (translates OpenGL ES 2.0 to Direct3D 11) but no-inputs and no-audio for the moment. Actually, don't know how to manage inputs or audio from C to get it working on UWP, it probably should be managed from C++ App.

Application life cycle should be managed from provided App.cpp.

Please, let me know your thoughts. Any help on this new platform would be very welcomed! :)

Apologies for the delay, I just noticed this message. I'm going to mess around with the new branch this weekend - thanks a ton for working on this! You're probably right about managing inputs/audio from C++ code too- I might try to patch it in later just for kicks, but it'll require some documentation-digging.

I'll be sure to test in on Xbox as soon as I can as well.