>>108793768
>are there any cool abstraction layers
SDL? I'm not sure.

>>108794921
GLFW also works.

>>108793768
You don't.

File: 1694980413180895.jpg (115 KB, 1101x737)

115 KB JPG

Glad you made this thread OP, I'm actually looking for alternatives.

I heard "someone" say that graphics APIs just waste your time, but what are the alternatives?
Make your own rasterizer? But there is no way to just draw a single pixel on the screen outside of software rendering (the APIs basically force you to draw triangles? Yes or no?). And you want to take advantage of the GPU so you're not doing expensive things on the CPU.

I recently (yesterday lol) learned of SDL GPU, an abstraction that sits above Direct, Vulkan, Metal. Sounds good, but you lose some freedom, right? Maybe I just want something simple, to draw individual pixel by pixel. But I want to draw the pixel on the GPU and do all the expensive stuff on the GPU. You can't really access the GPU without a well known API because Windows/etc. don't allow arbitrary applications to access the raw device, yes or no?

>>108793768
glfw+glad, learnopengl.com
goodluck

Just use OpenGL there is nothing wrong with learning it. Sure a lot of it "doesn't make sense" but it's been around so long like C and C++ that all of the weird quirks have been explained throughly a million times, there are tutorials everywhere and the most common patterns are all well documented and common knowledge by this point, you're not exactly trying to make a scientific breakthroughs here you are just trying to put graphics on the screen. The "idea" that somehow learning OpenGL teaches you the wrong thing and that you can't unlearn the bad parts and is gonna hold you back is absurd. If there was a best graphics API then yeah it would be a waste of time to learn anything but that, but we live in an imperfect world and there is no perfect graphics API, they all have flaws. Nobody ever said "I wished I never learned OpenGL" only people who never learned it try to act like it would be so below them to use it. If anything, you will find out that it's "all you need" and you can stop messing around experimenting with graphics APIs because you don't need anything else. And since you need to know all the basics to learn OpenGL anyways you can't say it's a waste of time, since it's only the API that is bad, everything else you deal with everywhere else like math and buffers, shaders and so on.

>>108795033
>graphics APIs waste your time
that person was retarded, different developers need different abstraction layers

> make your own rasterizer
don't do this unless you're learning how gpu apis work or doing some novel nanite-type compute shader renderer

> there is no way to draw a single pixel to the screen
it's abstractions all the way down, if you were trying to do everything yourself you would have to be writing device driver tier code for a specific vendor's gpu. Nobody does this because it's pointless

>sdl_gpu
yes thats the point, you agree to a limited subset of features and device extensions, in exchange you get to target a single api that will just work on mac / linux / windows

>I just want a simple api to draw pixel by pixel
gpus don't work this way, they want everything to be done massively in parallel for optimal performance.

>you can't access the gpu without a well known api because windows doesn't allow arbitrary access to the raw device

you can but you need to know how device drivers work and its harder and more work (for no gain) over just using the api.

Just learn OpenGL and then Vulkan. Then use SDL_GPU if you want cross platform support. OpenGL is deprecated in the sense that there are better APIs available (albeit with lower levels of abstraction). But knowing it makes learning the other GPU apis easier.

I've been making a game engine

if you aren't manually telling the cpu which pixels to draw on the screen you aren't doing it right

also opengl isn't even that hard to learn
just look at how much you need to do for vulkan just for a triangle
https://github.com/SaschaWillems/Vulkan/blob/master/examples/triangle/triangle.cpp

>>108793768
The only resource I used was Learning Modern 3D Graphics Programming by Jason L. McKesson. He's since closed his website (arcsynthesis), but several people have backups of the book floating around.

>>108795122
how's that going?
once you get the hang of it it's pretty easy / rhythmic

>>108793768
>opengl
stateful behavior
learn vulcan

>>108795141
it was going well for a few months, recently I've lost motivation because I don't really have a clear objective. The hard part is sitting down with no distractions and learning new concepts, but once you understand what you want to implement the implementation part is easy / rythmic like you said, and having AI as a force multiplier to just explain you anything you need to know makes creating a game engine in 2026 a way easier project then it was just 10 years ago

>>108795111
>in exchange you get to target a single api that will just work on mac / linux / windows
That's the thing, with other abstractions for various things (not just graphics programming) I've used in the past that promised to "just work" I inevitably ran into parts of it that did not work or required some workarounds. And the problem was because I didn't understand the underlying system, I wasn't smart enough to fix it. So recently, I have taken the mindset of doing the basic low-level thing that everyone says is pointless, understanding it, and iterating on it until I have a working system where I fully understand what all the pieces are doing, so if something goes wrong I know how to fix it.

An example: I got tired of hearing
>yeah this is a well-known Unity bug or quirk or feature, so you have to do this workaround
I think that's a lame excuse, and it kept popping up for various things within Unity. So I said, well, why don't I make a game without Unity? I started with a struct that defines what a Game_Object is along with various properties (position, size, sprite, or whatever else it might need) and a main loop that defines the game logic. Started simple and iterated on top of that, until I had a clean and working system that I not only understood but also was able to fix when something didn't work as expected and also easily add features as needed.

My point being, I was hoping to do something similar with graphics programming. There is a mildly famous book called Graphics Programming From Scratch, that has you building your own rasterizer by starting with drawing a single pixel and understanding the mathematical concepts to draw multiple pixels, iterating until you are able to draw full 3D shapes. I did it before and liked it a lot, but it's mainly an educational experience, since the technique requires you to use software rendering, making it (almost) useless for modern games.

So I suppose I will have to suck it up and use the APIs.

File: Screenshot 2026-05-10 231206.png (85 KB, 1913x639)

85 KB PNG

SDL GPU won't help you to start. compare it to the amount of stuff you have to do to even draw on screen it's just plain madness. It's there for some portability between Vulkan, DX12 and Metal but this is still an absolute insanity of a setup and management for simple graphics. Just ignore it until you learn something simpler first, it's not worth the effort.

I believe OpenGL ES 3.1 is the graphics API that you should start with. Maybe even OpenGL ES 2.0, and once you learn it you can iterate over the new features until you reach ES 3.1.

Anecdode: Once I tried to implement multiple textures into my batching renderer and turned out this is slightly problematic in OpenGL ES. apparently you can't use int attributes, you have to pass natural indices as floats. There were some inconsistencies with GLSL features between platforms, so I could not use switch nor index an uniform array with non-constant attribute.

varying vec2 v_uv;
varying float v_texture;
uniform sampler2D s_texture[8];

vec4 color;
int texture = int(v_texture);
if (texture < 0) color = vec4(1.0, 1.0, 1.0, 1.0);
else if (texture == 0) color = texture2D(s_texture[0], v_uv);
else if (texture == 1) color = texture2D(s_texture[1], v_uv);
else if (texture == 2) color = texture2D(s_texture[2], v_uv);
else if (texture == 3) color = texture2D(s_texture[3], v_uv);
else if (texture == 4) color = texture2D(s_texture[4], v_uv);
else if (texture == 5) color = texture2D(s_texture[5], v_uv);
else if (texture == 6) color = texture2D(s_texture[6], v_uv);
else if (texture == 7) color = texture2D(s_texture[7], v_uv);
else color = vec4(1.0, 1.0, 1.0, 1.0);

and I still don't understand how the texture binding works. I think I understood it for the few minutes I wrote the code and just forgot it all the next time I fell asleep. you have to glActiveTexture(GL_TEXTURE0 + i), then glBindTexture(GL_TEXTURE_2D, id) and then also set sampler2D uniform to that GL_TEXTURE0+i ??? what an odd indirection

or use raylib

>>108795314
OpenGL will teach you things that are wrong, and when it comes time to learn to write modern graphics software you'll have to un-learn the things OpenGL taught you.

>>108795335
good job parroting a sentence you just heard in jb video. can you name a single thing? because I can name at least ten concepts that are completely API-agnostic
let's face it, most people only really want what fixed pipeline OpenGL 1.1 did, and maybe add batching for performance and some phong lighting shaders.

>>108793768
Learnopengl is the best resource

Dont use Opengl 3.3, just skip to Opengl 4.6. Opengl 4.6 with modern techniques (AZDO) looks very similar to what you would do with vulkan or dx12 anyways. Upload stuff into buffers at the start of the frame, multidrawindirect all your objects, rely on compute shaders, etc.

>>108795674
So what exactly do these allow you to control? since the obvious intuition is that you just need a canvas to send pixels to. I mean specifically the new APIs such as Vulkan and DirectX12.

>>108795790
Nothing really, the hardware they talk to is the same. the OpenGl let you do the same exact stuff. the new APIs just have way more responsibilities shifted to the user instead of the driver handling it automatically. With the exception of _hardware_ raytracing (you can still do software raytracing in Opengl), litteraly everything you can do in vulkan/dx12 you can do in opengl. Its complete snake oil that beginners feel the need to use vulkan and make their workload 100x harder for no reason.

>>108795790
Lower level abstractions mean that the driver can be leaner and make less assumptions about your rendering engine. Vulkan exposes different memory types, you can specify if you want your buffer to be GPU only accessible memory, or host visible, which is slower. On OpenGL this is all transparent and the OS will pick whatever it wants. Which might be shit for your usecase.

>>108795314
A texture array _should_ have worked for your scenario. Then in the shader you'd define a single sampler2DArray for the entire array and access it with a single texture() call where the third texture coordinate is the texture index (as a float).
Vendor support might not have been there yet when you tried that out but by now it should work quite well.

>>108793768
Graphics programming was fun until they introduced shaders.

>>108796083
nothing says you have to use them

>>108796083
Shaders are the only fun part of graphics programming

>>108793768
I could teach you everything you need to know about how to make a functional 3D game for $0 maintenance and it would run on a brick.

OpenGL is very good, it's still the best system available that everything is based on.

OpenGL is a graphics API, it is not a renderer.

>>108796083
they're just programs that run on the gpu, what's so terrible about them?

>>108795033
im working on my own emulated gpu
still runs on opengl technically but its still scratching that autistic "from scratch" itch for me + i get to make my own api/driver
but yea it is possible to access it directly, naturally since drivers are mostly userspace code and the kernel portion just provides the interfaces to pass blobs/requests back and forth, however there's no point thanks to how diverse gpu architectures are

File: A_Hat_In_Time.gif (1.72 MB, 435x498)

1.72 MB GIF

>go read the "no graphics API" post
Anyone who takes Blow seriously must be retarded. Understand: Blow has been programming a Sokoban clone for 10 years. That's not practical in any professional scenario. Try telling your manager that you'll need 10 years to put a 3D object on the screen.
Not to mention that this son of a bitch completely ignores tooling, which literally uses gAPI for debugging, also ignores portability, etc. Indeed, for someone working on a Sokoban clone, gAPI might be a waste of time, but anyone with a real job knows very well that we need graphics API.

>>108795972
From the end users perspective vulkan offers nothing other than hardware raytracing.

>tfw ywn be a graphics/engine programmer in the 00s era
That period was the most comfy, hardware capable enough to do cool stuff, but still needed to be very technical to use it. every since mid 2010s, you can just slap random shit in and dont have to even care.

>>108796566
truke.
my g is thinmatrix. he shits out games in java and opengl and makes more progress in a month than blowjob made in a decade. :3

>>108795033
>And you want to take advantage of the GPU so you're not doing expensive things on the CPU.
this is extremely outdated advice i wish people would stop pushing. if you arent doing ue5 tier gaytracing, a software renderer will do just fine. in fact, most of the gaynigger games people are making in opengl and vulkan can be done in a homebrew software renderer. doom ran on a software emulator in the 90s. cpus are much more powerful now. its incredibly niggerlicious that everyone insists you MUST USE THE GPU BECAUSE ITS THERE OH MY FUCKING GOD!!!! YOU HAVE TO USE IT YOU MUST PLEASE SIR USE THE GRAPHICS API!!!!

>>108795033
between all the retarded and belligerent imageboard tourist garbage there was this post on HN. if you're not the avera/g/e larper you'll find this intriguing.
https://www.sebastianaaltonen.com/blog/no-graphics-api

nevermind, some faggot with a forced meme (as in the tranny-coded game was hard shilled on /v/ and the retards there went with it) avatar image already mentioned it

Use case of OpenGL when Vulkan exists? I'd understand using OpenGL on something like a Wii (technically OpenGX) or other older hardware that doesn't support Vulkan, but OpenGL really was crap.

>>108796566
Quality over quantity.
You're absolutely right that many games could be published in a 10 year span, and in fact, many really do. Guess how many of them I play. Guess how I judge and decide which games are worth spending time on. You think I want to play that game that took 1 year to make for profit or 10 years because of autism.

>>108796566
the "industry" aka game engines looking to entrench their respective monopolies wanted a graphics API that wasn't a graphics API, ie. vulkan. only joe blow types raw dog vulkan.
that blog post emphasizes the pitfalls of vulkan from the viewpoint of what it actually is, a gpu abstraction api. given that vulkan abstracts pure retardation there's plenty of low hanging fruit.
the other graphics api, webgpu, abstracts the gpu too. arguably metal abstracts the gpu more than it does graphics. all of them are massively retarded and leveraged by no one besides game engines and massively homogeneous gpgpu like llm inference. that's the fucking "industry" you derive your pride from.

>>108797780
i think anons point was more so that a sokoban clone shouldnt take 10 years because you are an autistic faggot over graphics apis

File: OIP.HePhrJMHKTBWxffaVa17IgHaF7.jpg (17 KB, 474x379)

17 KB JPG

>>108797845
It shouldn't, and Jon thinks so too. But the tools to make it be done faster without compromising on it being done well, don't exist and nobody is making them for him so he has to do that first.

We can reduce things all day; oh it's just a video game how important is it, oh it's just sokobon how complex is it really.
But clearly, this man obsesses over it, and I think it's bullshit to chide him for it.
And clearly there is much more to realizing the game that just making the gameplay itself. There is engine, and language work that adds value beyond just the game it's being made for. When the game is done the world also gets a programming language, game development tools, new APIs, etc. it's not "just a sokoban clone". That's way too reductive.

I'm not trying to be mean with this next remark but I want to make a point.
I know about Jon and his game, I appreciate his dedication to the crafts (plural).
Anon might make 10 games in that time and even if he pays for ad space I will likely never even see his game in my discover queue, and if I somehow magically played it, I'm playing a product of profit, not a work of passion. Would it even be fun, would it actually be something to be proud of or is the only important thing tricking a sucker into paying your salary.

We as a people should encourage passion projects that at least /try/ to strive for something of merit.
The profit projects are almost never good in any right so who cares about following their trends.
I want something that lasts, not something fast.

>>108793768
OpenGL is obsolete. If you're on Windows you'd have been using DirectX since DX9. If you're on Linux you should've switched to Vulkan. And if you're on Mac then you should kill yourself out of shame.
The only context in which OpenGL, or a derivative of it, is used nowadays is in the web browser. It's for making faggy javascript shovelware slop browser games with WebGL.

>>108797894
opengl can already run on a vulkan driver with zink so who gives a shit if it's "obsolete"
at least it allows you to draw shit without gorillion lines of boilerplate

>>108797894
you are jonathan blow himself if you use vulkan for anything instead of a game engine. also you're supposed to use webgpu for the web now. this means you need to use a game engine for the web if you'd like to finish your game before you die of old age.
anything else is reddit larper posturing.
of course you could just make your game in opengl and webgl, and ignore the ad hominems of retards who've no idea let alone qualitative experience of what they're talking about.

is learnopengl still the way to go?

>>108797687
This would be big if true, but I don't know of literally one single person doing this for a serious project in the field of games.
What I do know is that when people try this in the field of 2D GUI rendering, which admittedly is a lot more autistic about perfect antialiasing and blending, they get pretty bad performance.
Most importantly, they get BTFO by Blend2D, which is made by some genius who has been working on his JIT library since 2005. I just want to show some triangles on the screen, I don't know if I'm ready for that.
https://laurenzv.github.io/vello_chart/

>>108797968
>the field of 2D GUI rendering, which admittedly is a lot more autistic about perfect antialiasing and blending
all those people are retarded
ExtTextOut() go brrrrrr

>>108793768
You need to stop being a bum and get a real job

>>108797759
Lole I thought it is a blog post rant, but went down the rabbit hole and kept reading until he started showing code snippets.

I didn't understand half of the shit he wrote, but what I did understand is that today IS NOT a good time to write a game engine. I want to wait for a modern, simple and elegant graphics API that deprecates old spaghetti architecture

>>108797759
its funny that blow thinks this is a good API when this "no graphics api" is just more vulkan/dx12 cruft with manual synchronization, pipeline compilation, manual memory management , etc.
Opengl is unironically perfect if you use 4.6 stuff and build a slim wrapper on top of the state machine and framebuffer bullshit.

>>108795033
>but what are the alternatives?
using raylib like a normal person

>>108798037
that's a good takeaway
>>108798206
the rasterization pipeline has been a great abstraction for graphics, but there's also been a lot of innovation that can only work in the context of modern gpus being huge simd barrel processors that basically appear as a bunch of bad-at-branching cpus.
like I said elsewhere, "no graphics api" describes not opengl but modern "graphics apis":
>The complexity of graphics APIs, shader frameworks and drivers have increased rapidly during the past decades.
he then continues with
>It’s time to start discussing how...to simplify how we interact with the GPU.
he's discussing a better gpu abstraction api. in essence, "no graphics api" refers to dropping the graphics api charade of modern gpu abstraction apis. my takeaway is that people need to stop building graphics applications on top of gpu abstraction apis. we need a graphics framework for vulkan.
of course, unless you're writing a game engine or phd thesis you're better off with opengl than webgpu or all that trash.

>>108798637
Funny enough OpenGL already kind of is a graphics framework for Vulkan since Zink is a conformant OpenGL 4.6 implementation.

I couldn't really figure out how rendering worked in Raylib so I just went back to OpenGL.

Deprecated. Learn vulkan or some abstraction layer like sdl3 one

>>108799219
Me too. And I didn't like how some of the things work in raylib.

>>108798637
If there was a simple gpu abstraction API, everyone and their mom would be able to write nice and clean graphics libraries on top of it, with the API they like. Then graphics applications would be built on top of those.
For example, in that world Raylib would be an actually good library for simple games that just want to rasterize triangles, instead of being a piece of crap OpenGL wrapper that hides some of the shit but not all of it.

>>108796047
I have one windows laptop, one linux desktop and two embedded linux boards. there is always some unique thing not working on each of them because of different drivers. Even though its all glsl v100.

>>108799500
>>108799500
>If there was a simple gpu abstraction API, everyone and their mom would be able to write nice and clean
libraries for literally every gpu use case on earth, including cuda most prominently.
>>108799163
and that's how it should be. it's so painfully obvious that opengl should have continued to be a library on top of vulkan (and architecturally overhauled api-wise if needed) that it must be a grand conspiracy that it hadn't been.

File: 1778388527666355.jpg (126 KB, 1024x865)

126 KB JPG

>>108795129
>just gimp yourself to software rendering because i'm too retarded to handle talking to a satellite processor

>>108797894
"OpenGL is obsolete" they have been saying this for 15 years now. maybe in two more weeks it will be "obsolete".

>>108797794
Why would engine developers want such a terrible graphics API. The immutable pipeline model is profoundly retarded.

>>108800013
the greatest games of all time run on software renderers. your halfassed garbage pixelshit game doesnt need a graphics api.

>>108800236
large monolithic projects tend to cargo cult the dumbest patterns out there. it may also just be a case of monkey's paw

>>108795033
>I heard "someone" say that graphics APIs just waste your time, but what are the alternatives?
let me guess, Jonathan Blow-the-shit-out-of-baseddevs? He didn't mean don't use them, but they're all shit, and you better learn by implementing your own software renderer, then you can use whatever tool there is.
>don't allow arbitrary applications to access the raw device, yes or no?
You can program them with their ISA, or an IR like Spir-V. Those APIs like OGL are just meant for cross-platform and cross-device compatibility, and for ease of use, they still need to implement a driver for them (in linux/bsd Mesa).

>>108795111
>Just learn OpenGL and then Vulkan. Then use SDL_GPU if you want cross platform support. OpenGL is deprecated in the sense that there are better APIs available (albeit with lower levels of abstraction). But knowing it makes learning the other GPU apis easier.
This. But OpenGL(ES) is still good enough and has better support for most applications.