Hi, my name is Ray and it's my first time posting here.
Just wanted to show you raylib (www.raylib.com), a simple and easy-to-use C library to learn videogames programming.
Some years ago I started teaching videogames programming to people with artistic profile, most of them had never written a single line of code. After trying several tools, I decided to create a simple C library to teach videogames programming basis in quite raw way but making it simple enough for beginners, specially focusing on simple code structures, clear naming conventions and lot of code examples, so created raylib.
In the last 3 years project has grown quite a lot (https://www.youtube.com/watch?v=o8T9oNfsCOs&t) and thousands of hours have been invested in the project with the feedback of more than 250 students that have learnt with it.
Despite raylib is multiplatform, I also created an easy Windows installer with a complete development environment pre-configured (and portable). Obviously, raylib is free and open source (https://github.com/raysan5/raylib).
Here it is current API (raylib 1.6): http://www.raylib.com/cheatsheet.html
Any feedback is really appreciated! :)
Just wanted to show you raylib (www.raylib.com), a simple and easy-to-use C library to learn videogames programming.
Some years ago I started teaching videogames programming to people with artistic profile, most of them had never written a single line of code. After trying several tools, I decided to create a simple C library to teach videogames programming basis in quite raw way but making it simple enough for beginners, specially focusing on simple code structures, clear naming conventions and lot of code examples, so created raylib.
In the last 3 years project has grown quite a lot (https://www.youtube.com/watch?v=o8T9oNfsCOs&t) and thousands of hours have been invested in the project with the feedback of more than 250 students that have learnt with it.
Despite raylib is multiplatform, I also created an easy Windows installer with a complete development environment pre-configured (and portable). Obviously, raylib is free and open source (https://github.com/raysan5/raylib).
Here it is current API (raylib 1.6): http://www.raylib.com/cheatsheet.html
Any feedback is really appreciated! :)
I can across your raylib project the other day on Reddit. I have yet to use it but I've read through the source and examples and I think I might just have to try it.
I will reply once I have had a go with it.
I will reply once I have had a go with it.
I really like the API.
It's so refreshing to see an API without namespace prefixes, very pleasing for the eye!
Every basement programmer has his own "BobsCoolAPI_DrawText", even though name collisions are never-ever going to happen to them since they work alone with their friend Bob and both of them suffer from a severe case of Not Invented Here syndrome.
I've always liked and recommended immediate-mode OpenGL1.1 + glfw to beginners (and experts alike).
Nothing beats getting a quads on a screen with 10-15 lines of code.
And now this is similar, but also works with emscripten, android, and openglES and has other neat built in short-cuts.
I looked at the source of it, and unfortunately some parts of this is not very efficient at all. (not that it has to be, particularly)
As in changing a texture triggers a draw call. Drawing text has a rlPushmatrix, rlPopmatrix, rlRotate call per char even though it's absolutely not necessary.
I kind of hoped that behind the scenes textures would be automatically put on atlases (or at least array textures).
And everything would be bucketed by textureID/primitive type/alpha blending mode and other sensible render flag combinations.
So that at the end of the frame there would be a single drawcall per each used vertex array type.
This would consume a lot of memory if all those arrays were fixed size and large,
but I feel the performance trade-off would be well worth it. This would also work perfectly well in OpenGL1.1 using glVertexPointer and glDrawArrays.
As in - it could also be very, very fast without changing the API or programming model for the most part.
It's so refreshing to see an API without namespace prefixes, very pleasing for the eye!
Every basement programmer has his own "BobsCoolAPI_DrawText", even though name collisions are never-ever going to happen to them since they work alone with their friend Bob and both of them suffer from a severe case of Not Invented Here syndrome.
I've always liked and recommended immediate-mode OpenGL1.1 + glfw to beginners (and experts alike).
Nothing beats getting a quads on a screen with 10-15 lines of code.
And now this is similar, but also works with emscripten, android, and openglES and has other neat built in short-cuts.
I looked at the source of it, and unfortunately some parts of this is not very efficient at all. (not that it has to be, particularly)
As in changing a texture triggers a draw call. Drawing text has a rlPushmatrix, rlPopmatrix, rlRotate call per char even though it's absolutely not necessary.
I kind of hoped that behind the scenes textures would be automatically put on atlases (or at least array textures).
And everything would be bucketed by textureID/primitive type/alpha blending mode and other sensible render flag combinations.
So that at the end of the frame there would be a single drawcall per each used vertex array type.
This would consume a lot of memory if all those arrays were fixed size and large,
but I feel the performance trade-off would be well worth it. This would also work perfectly well in OpenGL1.1 using glVertexPointer and glDrawArrays.
As in - it could also be very, very fast without changing the API or programming model for the most part.
Edited by pragmatic_hero
on
Hi pragmatic_hero!
Thank you very much for your feedback! Really appreciate it!
raylib has changed a lot in the last 3 years and I try to keep improving it, specially the rlgl module that maps a pseudo-OpenGL 1.1 style functions to OpenGL 3.3+ and OpenGL ES 2.0. I thought about the better way to store the draw calls data (texture, shader, VBOs/VAO, transform, blending...) and then reorganize array for a more optimum drawing (similar to SpriteBatch in XNA) but at the end I decided to keep it simpler... I think that's a point to work on.
About texture atlasing, I preferred the students to do it themselfs (manually or automatically), keeping raylib texture management simpler.
Again, thanks for your review! :)
Thank you very much for your feedback! Really appreciate it!
raylib has changed a lot in the last 3 years and I try to keep improving it, specially the rlgl module that maps a pseudo-OpenGL 1.1 style functions to OpenGL 3.3+ and OpenGL ES 2.0. I thought about the better way to store the draw calls data (texture, shader, VBOs/VAO, transform, blending...) and then reorganize array for a more optimum drawing (similar to SpriteBatch in XNA) but at the end I decided to keep it simpler... I think that's a point to work on.
About texture atlasing, I preferred the students to do it themselfs (manually or automatically), keeping raylib texture management simpler.
Again, thanks for your review! :)