Raylib's author was very happy to announce that you can compile an entire raylib program with no dependencies other than, say, being a win32 app https://x.com/raysan5/status/1980322289527976202
Oh that sounds really interesting. I was searching for something like that to render something on a fun-hacky-ledscreen with an embedded processor. All things I found weren't satisfying.
But if I understand that correctly, I should be able to just compile this and then software render stuff? For my tiny 192x128 pixels this should be fast enough on any kinda system. Time for fun animations
The mantra for the library is "raylib is a simple and easy-to-use library to enjoy videogames programming." It's for hobbyist, learners, tinkerers, or just those that want to enjoy minimalistic graphics programming without having to deal with interfacing with modern machines yourself.
The default Windows installer bundles the compiler and a text editor to make poking at C to get graphics on the screen (accelerated or not) a 1 step process. Raylib is also extremely cross platform, has bindings in about every language, and has extra (also header only, 0 dependency) optional libraries for many adjacent things like audio or text rendering.
When I first started to learn C/C++ in the 2000s I spent more time fighting the IDE/Windows/GCC or getting SDL/SFML to compile than I did actually playing with code - and then it all fell apart when I tried to get it working on both Linux and Windows so I said fuck it and ignored that kind of programming for many years. Raylib is about going the opposite direction - start poking at C code (or whatever binding) and having it break and worry about the environment later when you're ready for something else.
I never ever bothered to compile SDL/SFML from source, what is so hard dumping the binaries into a folder, set the include paths for the compiler and linker?
Although I may imagine newbies may face some challenges dealing with compiler flags.
Not much to a developer. To a novice (potentially very young) user there's confusion why there are 3 versions for e.g. Windows, which to pick from and why, how to set the compiler/linker flags for the build tuple, and then confusion about how to make it work on the alternative targets for their friends (e.g. the web target or the Linux ARM Pi target for class) and why that has to be different steps. None of that is particularly complicated once you go through it all, but it is a bit of a barrier to the "see something on the screen" magic happening to drive interest. Instead, raylib is just a header file include, like a text based "hello world", regardless of platform - even if you don't want to use the pre-made bundle.
Or, more simply, it makes the process "easy as a scripting language" rather than "pretty easy".
> what is so hard dumping the binaries into a folder, set the include paths for the compiler and linker?
The problems already start with getting the precompiled libraries from a trusted source. As far as I'm aware the SDL project doesn't host binaries for instance.
This site is for hackers, which basically means people who like to do things like this. If you can't understand why someone would be interested in this, probably you should remain silent and try to understand hackers rather than commenting.
As someone working on a game engine with a multithreaded SSE/NEON implementation of ~GL 1.3 under the hood, this is rad for many reasons other than portability or compatibility. You get full access to every pixel and vertex on the screen at any point in the rendering pipeline. This allows for any number of cool (also likely multithreaded) postprocessing effects that you don't have to shoehorn through a brittle, possibly single-platform shading language and API.
As someone who was once a child trying to figure out how to compile and link things to use SDL, I think there's some educational value in letting people make games without having to dive deep into how to use C++ toolchains.
I think there's still value in learning the C++ language and making a game or a demo is quite rewarding although raylib does have bindings for basically every conceivable language.
I'd make the opposite argument about educational value.
If you learn to compile libraries and programs you have, so to speak, passed an exam: you are ready to "make games" with confidence because you know what you are doing well enough to have no fear of tool complications.
What should be minimized is the accidental complication of compiling libraries and programs, for example convoluted build systems and C++ modules.
If you learn to compile libraries and programs, you just learn how to compile libraries and programs. That doesn't teach you anything about how to "make games." It doesn't even make game development significantly easier.
I think the real answer to educating people about making games without the complications of low level programming would be using a framework like Godot or languages like Python or Lua.
Of course technical concerns aren't directly relevant to making games, but they are still necessary. Productive development means overcoming technical hurdles, not only domain specific challenges.
What if you cannot adopt some library that would do something very useful because you lack the skill integrate or replace CMake or Bazel or Autoconf? Unnecessary technical constraints impact game quality.
What if due to insufficient automation the time between tests after making a very small change is 10 minutes rather than 10 seconds? Reduced productivity impacts game quality.
Very useful skills to have. But they don’t need to be learned during the very first lesson on the very first day unless you are trying to filter people out for some reason.
It's slower indeed, but it's easier to write and debug, more portable, and gives you total control over the render pipeline. It's good for experimentation and learning, and would still be trivial to compile and run 20 or 50 years from now. And with how obscenely fast modern CPUs are, it might even be fast-enough for a simple 3D game.
Someone always points out how Doom wasn't "real 3D" like it's some sort of gotcha. Games are smoke and mirrors, it's all a 2D grid of pixels at the end.
What's cool about this is that computers are so fast that you could probably make a decent 2D game using only this software-rendered OpenGL 1.1 library.
If you keep resolution low, manage your scene complexity carefully and commit to the art style, you can make reasonable 3D games that run even on 20 year old hardware. I did so as an experiment on my game [1] [2] and now that I can see that it works, I am working on a second, more "serious" and complete one. Computers are fast.
Edit: I missed this was software rendered. I’m one gen-iteration ahead. Prob would still be possible to render my game cpu side provided I use the most efficient sprite depth ordering algorithm possible (my game is isometric pixel art like rollercoaster tycoon)
Ha! That’s what I’m stuck with for Metropolis 1998. I have to use the ancient OpenGL fixed function pipeline (thankfully I discovered an AB extension function in the gl.h file that allows addition fields to be passed to the GPU).
I’m using SFML for the graphics framework which I think is OpenGL 1.x
Basically the idea is to throw away yet again the current set of execution pipelines, and have only two kinds of shaders, mesh shaders which are general purpose compute units that can be combined together, and task shaders which have the role to orchestrate the execution of mesh shaders.
So basically you can write graphics algorithms like in the software rendering days, with whatever approach one decides to do, without having to try to fit them into the traditional GPU pipeline, yet running on the graphics card instead of the GPU.
This is how approaches like Nanite came to be as well.
I saw a few of these things in the 90s and they definetly were not cool. They were slow, clunky or produced artifacts. You needed close integration between the game and renderer for perf.
It seems to have more features and limited support for multithreading, with more recent updates compared to the original project. Sadly it was archived in late 2023.
An order of magnitude more ;) You need to implement user-programmable shaders, both ARB assembly and GLSL. That needs a GLSL parser, a shader interpreter (talking about compiling it to machine code would add another magnitude of complexity).
You also need to implement multitexturing (probably the easy part) but also all the texture combiner stuff too. This one is not hard but also a good chunk of code...
All in all, at least 40K if you ask me, but that's a very lowball estimate.
Of course if you don't care about implementing the full spec, you can get away with a lot less.
I implemented the OpenGL API for fixed function hardware once, and chose the cut off at 1.5 with some extensions like framebuffer objects. 1.x has a lot of cruft that nobody should use, but is still easy to implement. 2.x has a lot of stuff like shaders that are a lot more work to implement in software.
Congrats for only reading the header ;) It's actually a pretty decent OpenGL 1.1 software implementation, obviously not complete and spec-correct though. It's more like those MiniGL drivers back in the day, implementing just enough of the spec so the game can run ;)
In a similar way, this implements just enough so Raylib's OpenGL backend can run! It was done so you can use the library without external graphics dependencies if you really want to.
No, the doc-header of the header! Apologies if I wasn't clear. I just thought the GP zoomed in on the word "-style" in the first line without reading more (it's probably since it's not a full 1.1 implementation, just something which can do enough to shim a good chunk of 1.1 functions so the RL GL1.1 backend can run)
Still, if you post a link to a roughly 5k line raw source file, rather than like, some post about it, roughly nobody is gonna read much of the file before commenting.
This is kind of a systemic problem with HN: all the early comments on anything substantial are necessarily themselves insubstantial because the posters have not had time to read it.
I know. I hold myself to a rule that I never comment if I didn't read the article.
I made an exception with this, because the "article" is simply a 5kloc header file. I only read some of it.
I don't have a problem with the submission but I don't know why you would expect someone to read enough of the header to realize that the opening line in the header saying "OpenGL 1.1-style" is underselling it and it's actually a "pretty decent OpenGL 1.1 software implementation".
I don't think making sarcastic remarks about someone failing to read enough of this header to work out that it's a pretty complete opengl implementation contrary to the implication at the start of the header is really doing much to fight the problem of people not reading articles before commenting.
Yes, that's arguably somewhat true of items like these:
Go Subtleties You May Not Know (harrisoncramer.me)
66 points by darccio 5 hours ago | flag | hide | 28 comments
Evaluating Argon2 Adoption and Effectiveness in Real-World Software (arxiv.org)
14 points by pregnenolone 3 hours ago | flag | hide | 1 comment
The Gypsy Life of Robert Louis Stevenson (hudsonreview.com)
37 points by Caiero 5 hours ago | flag | hide | 5 comments
That is, you might already be familiar with Robert Louis Stevenson's life story, Argon2, or the subtleties of Golang. Even if so, though, you probably won't be familiar with the book review in the current issue of the Hudson Review (of a book that came out last month), Cramer's particular take on those subtleties (which he posted two weeks ago), or even the Argon2 evaluation in the paper (which was posted in April).
I would argue that people posting comments in these threads consisting of only their pre-existing general knowledge of Stevenson and Argon2 are still failing to make substantial contributions to the conversation, because they will tend to repeat pre-existing errors whose correction is the largest contribution of the linked writings, or simply repost the predictable opinions they share with many other people. It's the opposite of the spirit of curious inquiry the site ostensibly seeks to foster.
And the majority of frontpage posts are about things that are in fact brand new:
Greenland Ditches Starlink for French Satellite Service (dagens.com)
323 points by saubeidl 4 hours ago | flag | hide | 189 comments
(news reporting from two days ago)
Knocker, a knock based access control system for your homelab (github.com/fariszr)
21 points by xlmnxp 2 hours ago | flag | hide | 29 comments
(new software project last month)
Evaluating the Infinity Cache in AMD Strix Halo (chipsandcheese.com)
90 points by zdw 6 hours ago | flag | hide | 33 comments
(news reporting from today on performance evaluations using an ASUS sample motherboard not available to the general public)
Show HN: Cadence – A Guitar Theory App (cadenceguitar.com)
55 points by apizon 5 hours ago | flag | hide | 8 comments
("Hello HN, I just released this music theory and ear training mobile app" a few weeks ago, with a trademarked name that will certainly have to be changed after a cease & desist)
MinIO (apparently) becomes source-only (github.com/minio)
144 points by LexSiga 5 hours ago | flag | hide | 107 comments
(a new release process change in this project from four days ago)
rlsw – Raylib software OpenGL renderer in less than 5k LOC (github.com/raysan5)
204 points by fschuett 14 hours ago | unvote | flag | hide | 69 comments
(a new software renderer committed on September 29)
LLMs can get "brain rot" (llm-brain-rot.github.io)
395 points by tamnd 20 hours ago | flag | hide | 245 comments
(a new paper published one week ago)
There is nothing substantial that anyone could say about any of these things without reading the article or bug thread or trying the software.
OpenGL is an API. Software renderers for it—like the one that originally came with Windows NT, or even early versions of Mesa—have been out for a long time.
I haven't messed with it for a while, but last I checked it really wasn't that much code to make it run on the GPU. Maybe an extra 100 lines or so. Although you couldn't use windowed mode, had to be fullscreen.
This is an implementation of the OpenGL API interface. It is not OpenGL. It does not support GPU acceleration. It does math with floating point on the CPU. It then draws points and lines on a 2D surface provided by raylib.
Could this be adapted to use SIMD, or a GPU? Sure. That is not what this is today.
The default Windows installer bundles the compiler and a text editor to make poking at C to get graphics on the screen (accelerated or not) a 1 step process. Raylib is also extremely cross platform, has bindings in about every language, and has extra (also header only, 0 dependency) optional libraries for many adjacent things like audio or text rendering.
When I first started to learn C/C++ in the 2000s I spent more time fighting the IDE/Windows/GCC or getting SDL/SFML to compile than I did actually playing with code - and then it all fell apart when I tried to get it working on both Linux and Windows so I said fuck it and ignored that kind of programming for many years. Raylib is about going the opposite direction - start poking at C code (or whatever binding) and having it break and worry about the environment later when you're ready for something else.
Although I may imagine newbies may face some challenges dealing with compiler flags.
Or, more simply, it makes the process "easy as a scripting language" rather than "pretty easy".
The problems already start with getting the precompiled libraries from a trusted source. As far as I'm aware the SDL project doesn't host binaries for instance.
1 - Open https://www.libsdl.org/
2 - Download section on bottom left => SDL Releases
It has been there at least since SDL 2.0 early days, not feeling like tracking changes on Wayback Machine.
But I also just use the precompiled libs :)
What should be minimized is the accidental complication of compiling libraries and programs, for example convoluted build systems and C++ modules.
I think the real answer to educating people about making games without the complications of low level programming would be using a framework like Godot or languages like Python or Lua.
What if you cannot adopt some library that would do something very useful because you lack the skill integrate or replace CMake or Bazel or Autoconf? Unnecessary technical constraints impact game quality.
What if due to insufficient automation the time between tests after making a very small change is 10 minutes rather than 10 seconds? Reduced productivity impacts game quality.
And sure you can do 3d rendering on modern CPUs. It's just better on GPUs. Like thousands of times better.
[1] https://news.ycombinator.com/item?id=45270981
[2] https://totenarctanz.itch.io/a-scavenging-trip
Really cool news about raylib. I will seriously consider using this.
Ha! That’s what I’m stuck with for Metropolis 1998. I have to use the ancient OpenGL fixed function pipeline (thankfully I discovered an AB extension function in the gl.h file that allows addition fields to be passed to the GPU).
I’m using SFML for the graphics framework which I think is OpenGL 1.x
Game to show what’s possible: https://store.steampowered.com/app/2287430/Metropolis_1998/
Any way I can buy you a beer?
It is possible to "pay what you'd like" on itch though :) [1]
The demo up there is in pre-alpha, but I push out a big update every 4-6 months.
[0] https://linktr.ee/yesboxstudios
[1] https://yesbox.itch.io/metropolis1998
Why do you have to and do you also use parts of the old immediate-mode API?
https://home.otoy.com/render/octane-render
Other is making use of mesh shaders, which you need a recent graphics card for it, still making its way across the ecosystem.
https://developer.nvidia.com/blog/introduction-turing-mesh-s...
Basically the idea is to throw away yet again the current set of execution pipelines, and have only two kinds of shaders, mesh shaders which are general purpose compute units that can be combined together, and task shaders which have the role to orchestrate the execution of mesh shaders.
So basically you can write graphics algorithms like in the software rendering days, with whatever approach one decides to do, without having to try to fit them into the traditional GPU pipeline, yet running on the graphics card instead of the GPU.
This is how approaches like Nanite came to be as well.
https://dev.epicgames.com/documentation/en-us/unreal-engine/...
https://youtu.be/MGZQAH5J1OQ
(Mar 5 2022) TinyGL 0.4.1 is out (Changelog)
(Mar 17 2002) TinyGL 0.4 is out (Changelog)
"our plans are measured in centuries"
Funny how history turns out.
It seems to have more features and limited support for multithreading, with more recent updates compared to the original project. Sadly it was archived in late 2023.
How many lines to implement OpenGL 2.0 (non ES) ?
You also need to implement multitexturing (probably the easy part) but also all the texture combiner stuff too. This one is not hard but also a good chunk of code...
All in all, at least 40K if you ask me, but that's a very lowball estimate.
Of course if you don't care about implementing the full spec, you can get away with a lot less.
https://github.com/rswinkle/PortableGL
Cool project, and fun to play with.
In a similar way, this implements just enough so Raylib's OpenGL backend can run! It was done so you can use the library without external graphics dependencies if you really want to.
edit: I stand corrected by the downmods!
I made an exception with this, because the "article" is simply a 5kloc header file. I only read some of it.
I don't have a problem with the submission but I don't know why you would expect someone to read enough of the header to realize that the opening line in the header saying "OpenGL 1.1-style" is underselling it and it's actually a "pretty decent OpenGL 1.1 software implementation".
I would argue that people posting comments in these threads consisting of only their pre-existing general knowledge of Stevenson and Argon2 are still failing to make substantial contributions to the conversation, because they will tend to repeat pre-existing errors whose correction is the largest contribution of the linked writings, or simply repost the predictable opinions they share with many other people. It's the opposite of the spirit of curious inquiry the site ostensibly seeks to foster.
And the majority of frontpage posts are about things that are in fact brand new:
(news reporting from two days ago) (new software project last month) (news reporting from today on performance evaluations using an ASUS sample motherboard not available to the general public) ("Hello HN, I just released this music theory and ear training mobile app" a few weeks ago, with a trademarked name that will certainly have to be changed after a cease & desist) (a new release process change in this project from four days ago) (a new software renderer committed on September 29) (a new paper published one week ago)There is nothing substantial that anyone could say about any of these things without reading the article or bug thread or trying the software.
This is an implementation of the OpenGL API interface. It is not OpenGL. It does not support GPU acceleration. It does math with floating point on the CPU. It then draws points and lines on a 2D surface provided by raylib.
Could this be adapted to use SIMD, or a GPU? Sure. That is not what this is today.
[1] https://kingscrook.itch.io/kings-crook