Ray
4.6K posts
@raysan5
Passionate about gamedev technologies. I create things. Created #raylib, #raygui, #rres and many other tools as @raylibtech. FOSS at: https://t.co/sIUDDNc2tV
Still very buggy but it does have some interesting plants, even with debug stuff. But as you can see, I need to fix how leaves are placed right now, it's not correct. still looks like 90s software, maybe I should just roll with the aesthetic...
Nuevo episodio de nuestro podcast! La Vieja Guardia 8x04 20260519 Raylib revisited laviejaguardia.vg/la-vieja-guard…
I had Claude implement a Vulkan backend for raylib that beats the OpenGL backend in runtime speed for every general use case. Except two. I've been pulling off some pretty crazy shit in record time that simply would be impossible pre-AI. A lot of people seem to be struggling with accepting this. Unfortunately, I cannot openly post things related to my real work. So decided to burn some Claude tokens on my personal account over the weekend and apply all I have learned to something which I could openly post. First, I had Claude generate a system to run image equivalence tests on every deterministic raylib example: github.com/rygo6/raylib_t… It goes through and output three images from each deterministic example it equal steps. Also relies on a change in rcore to force the timesteps to be controllable. All the images from the current rlgl implementation are saved in image_equivalence/rlgl_baseline Then I fed Claude the entire Vulkan spec. I also fed it a bunch of pedantic instructions on the style I write Vulkan with a bunch of my personal C Vulkan code. For example, if you look at the generated Vulkan code and say WTF are all the info struct inlined into the Vulkan calls with compound literals!? That's not claude. That's me :) It would produce a very different style on it's own. Also told it to match the naming and comment style of existing rlgl and the try to produce similar file structure to rlgl. Instructed it on how to edit the file, how to build, how verify a test passes, what to do when a test passes, what to do when a test fails. Then let it cook for several hours. The first Vulkan backend it produced was actually slower than rlgl. Largely because I told it to use all of the newest Vulkan extensions it possibly could and it only needs to run on n NVidia 4090. Which led it to use the VK_EXT_shader_object extension and avoid VkPipelines entirely. Which turns out VK_EXT_shader_object is 3x-4x slower than the NVidia OpenGL driver for doing the same kind of dynamic renderer. Good to know! I actually didn't know VK_EXT_shader_object sucked so bad until I did this. At which point I then instructed it on how to set up performance tests. Which are in the raylib_tests/performance folder. Taking several of the heaviest examples, and synthesizing a few new ones, to cover a wide range of graphical scenarios. Then I instructed it on how to build, edit, run those performances tests. Also instructed it on how to break out isolated spike projects to test comparable Vulkan features and OpenGL features in isolation to find which specific ones by themselves are faster in Vulkan. Then use those Vulkan features proven in isolation to be faster to then design an entire Vulkan backend which could pass all of the image equivalence test. Then instructed it to iterate on this until every performance was faster the OpenGL backend. Giving it free reign to discern which exact Vulkan features to use so long as the testing showed it to be faster than OpenGL. Then instructed it once it found an architecture that is faster to OpenGL. Then run all the image equivalence tests again to ensure they all still pass. Rinse and repeat until all image equivalence tests are passing and all performance tests are beating opengl. It then cooked for another several hours or so and produced the output I have committed in this branch: github.com/rygo6/raylib/b… Here is the performance test overview: htmlpreview.github.io/?https://raw.g… The one where OpenGL still beats Vulkan by a significant margin is the raymarching example. Not because of Vulkan. But supposedly because the Nvidia OpenGL driver is faster at executing shader code, so when you have a scene where the bottleneck is entirely in the shader fragment section, the Nvidia OpenGL driver can execute that faster than the Nvidia Vulkan driver. Which I also didn't know. Also of note, despite the runtime performance being better, the RAM and VRAM usage is a little worse. Which has to do with the baseline of the Nvidia Vulkan Driver being worse than the Nvidia OpenGL Driver. However, I'd expect this to completely different on Linux and AMD. Aside from being able to autonomously produce a usable backend for raylib. I found this exercise to be significant because, ultimately the performance of raylib rlgl is not so much rooted in rlgl as it is rooted in Nvidia's OpenGL driver. Which is really good. There are a couple decades of careful manual optimization put into the Nvidia OpenGL driver to make it super performant for that style of renderer. Which Claude could figure out how to beat with Vulkan. Now what exactly is the code like? C99 and Vulkan are very formulaic. When everything is structs and methods, there is a lot less room for it to do 'crazy shit' with architecture. Also, between raylib's rlgl which is very well patterned and consistent, and my personal Vulkan code which is also very specifically opinionated, it had a lot of specific, explicit, pattern to follow. Glancing over the resultant generated code I'd say, I'd probably significantly change about a quarter of it manually. Cleanup and rearrange. Rewrite some of the methods. Maybe instruct on some different struct layouts and relationships to use. Give it some different foundational data structures to use. Which, since Claude is aware of everything in here, I could radically rearrange all the struct layouts, and data relationships, and layout new data structures. Then prompt Claude, "I changed all of this ____ make the code work with it", and it would. Reworking all the methods to match the new data design probably in about 10 minutes. Probably the roughest part is where it did reflection on SPIRV to figure out how to wire the existing GLSL OpenGL shaders to Vulkan. There is nothing like that in all of my Vulkan code so it was on its own there. I might spend a day going over that. Which after that, it'd arrive me at about the same result had I done everything manually. But in about 4 days instead of what would have probably been 4 months. Most of which would have been a lot of formulaic boring testing, trial and error which I'd rather not do. Given all of that. If you code generated with Claude is crap and you can do better. Well then by all means, produce some evidence by implementing a vulkan backend for raylib that beats this :) That would be a worthy donation to open source. That is of course if you can actually do it and you aren't just bullshitting everyone when you say you can do better than AI.
Just 24h left to start the #raylib 6.x gamejam! 😱 +420 participants are waiting for a theme for the jam! YOU can choose the theme(s) that will move +420 developers the following 6 days! The two most voted!!! Choose wisely! 🔥 Still on time to join! --> itch.io/jam/raylib-6x-…
unironic productivity hack for 2026 use a pencil and paper to write down your ideas
