learn-wgpu VS SDL

https://sotrh.github.io/learn-wgpu/

Wgpu is a Rust-based library that takes a similiar general API shape as Vulkan but is simplified. When I first tried to learn Vulkan I found the complication to be overwhelming (primarily because there are no defaults for ANYTHING) but once I learned wgpu it was substantially less so. It is still quite complicated though.

Wgpu is aiming to be almost as powerful as Vulkan, but it's not there yet because the features that are needed to do the modern techniques that make Vulkan really good (as compared to opengl) either aren't there yet or are so bug-ridden as to not be usable in practice yet.

It has some ability to run in a web browser, probably with JS, too, but I'm unfamiliar with the details there.

Nice.

Speaking of Snake game, if you want to go even deeper, you can try to use the wgpu crate to combine Rust and WebGPU to write everything from scratch. Here is the tutorial:

https://sotrh.github.io/learn-wgpu/#what-is-wgpu

I once wrote a code editor with wgpu, from font rendering to char/line state management (very rough) for music live coding:

https://github.com/glicol/glicol-wgpu

It runs in browsers, even including Safari!

https://sotrh.github.io/learn-wgpu/ This is probably the best resource out there for learning wgpu specifically. If you're unfamiliar with graphics, the learnopengl one is good. If you've got experience though, jumping right into that one is a shout or looking at some vulkan ones as they're pretty similar in terms of architecture.

- https://sotrh.github.io/learn-wgpu

Most of The WGPU I learnt is from https://sotrh.github.io/learn-wgpu/ but it doesn't really talk about designing n stuff, I thought of checking out the source code for Bevy or even games like veloren. But well, their codebases are pretty big to get started in the first place.

So I was wondering if opting for option 1 would be better to begin with. OpenGL has a much bigger community and wgpu only has its documentation which I hear is not quite up there yet. There is this excellent tutorial for wgpu that I read through, but it seems like wgpu can be a lot more complicated than starting with OpenGL.

You see, for the past several years I have used many programming languages and many more game frameworks and libraries. Programming languages like Java, C#, C++, and even, sadly, JavaScript (I know...). Game frameworks like LWJGL, SDL2, Raylib, MonoGame, SFML, and many more. Essentially, I have seen it all. Out of all of them, I think SDL2 was closer to what I was looking for, though, Raylib was the one I used the most at the beginning. And the reason I liked SDL more was because it was more"lower-level" than Raylib or SFML. Additionally, it had that C-style of programming that I have always been fond of. However, despite that, I decided to go against any of these libraries.

> cross platform/web/mobile distribution

Unfortunately, each and every platform has its own unique quirks[], and I think the problem is too large for a project like LÖVE to tackle.

In fact, LÖVE's authors have already done "90% of the work in 10% of the code": you can make a ZIP file, change the extension to .love, and just distribute that. Install LÖVE, double-click YourGame.love, and you're done. You can also concatenate the game executable with the ZIP file to create a self-contained binary distribution for that target platform (super old & cute trick; it's possible because ZIP's "header" is in fact, at the end of the archive).

[]: In 2016 I've attempted a "one game per month" challenge; but I also wanted to distribute executables for Windows, macOS, and Linux, so that all of my friends could just play them. It went something like this:

- Windows: distributing executables from your personal domain is considered a crime; the browser and the OS will yell at the user, block the download, blacklist you, etc.

- macOS: simply concatenating won't work; you need an elaborate dance to create a .app bundle, and distribute that in a .dmg - good luck building that on a Linux host, also good luck debugging without an actual Mac. Nevermind code signing, you can bypass that with shift-right-click-open. Oh wait, macOS 15 won't let you.

- Linux: are you ready for the .so hell?

- BSD: bonus! The documentation for SDL_GetPlatform doesn't even enumerate all of the possible values! You need to source-dive to get them: https://github.com/libsdl-org/SDL/blob/f45ce45603a00e92332f9... - plus any possible patches in ports; most developers won't ever care, and will just hardcode "Linux". Checking for $DISPLAY is also unreliable: macOS users may have XQuartz installed, Wayland purists may run without XWayland, etc.

The current status of X11 is that it works.

The current status of Wayland is that it doesn't.

It's really that simple. I think this exchange can help you understand my position better: https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201...

>Wayland has a myriad of unresolved problems regarding surface suspension blocking presentation and the FIFO (vsync) implementation being fundamentally broken leading to reduced GPU-bound performance.

To which someone replies:

>If we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4). Having this as the default in SDL3 (which isn't being used yet!) is important for signaling to other stakeholders that we actually do need to get solutions in place for detected issues.

To which the committer says:

>SDL is not your tool for "signaling to stakeholders" about what is important. It's an actual library used by real developers and users!

Likewise. My PC is not a tool for signaling library/DE developers that there are more and more people using Wayland now and that they can finally stop maintaining X11 legacy code. I use my PC for real things. I couldn't care less if things are running on X11 or Wayland so long as they work.

If Wayland isn't working with my use case, I just won't use it. I won't switch to Wayland juts to beta test it, and then spend years begging people who know how to hack Linux to implement the features I need that I had on X11.

If Linux drops X11, and Wayland still doesn't work. I won't use Wayland. I'll use Windows.