5 ms·

Some other interesting libraries I've seen along these lines: - Sokol (sokol_gfx in particular): https://github.com/floooh/sokol https://github.com/floooh/soko

by gary_0 5y ago

Some other interesting libraries I've seen along these lines: - Sokol (sokol_gfx in particular): https://github.com/floooh/sokol https://github.com/floooh/sokol - wgpu (see wgpu-native for the C API): https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu It kind of seems like graphics abstractions for modern hardware are getting pretty "figured out". There are wrappers that work for most DirectX/Metal/OpenGL applications so they can run just about anywhere, and new 2D/3D applications have a lot of accessible/open-source options to build on top of. Projects like Mesa's Zink will centralize the burden of maintaining legacy APIs away from hardware manufacturers. Valve's Proton is making waves. WebGPU is on the way. The future looks bright.

pjmlp 5y ago
That isn't nothing new, 10 years ago, before free beer Unity and Unreal, one would be using something like Ogre 3D.
- girvo 5y ago
  Or Irrlicht, if you were me as a younger lad and scared off by Ogre at the time. There's always been a vibrant landscape of these sorts of tools, so it's neat to see another one
Animats 5y ago
Oh, I wish. There are plenty of game engines and graphics libraries for C++. We have enough of those. This is not yet true for Rust. There seem to be, but if you start to push the performance limits, problems appear. I've been writing a client for Second Life, which, despite all the hype from NFT land, is still the best metaverse around. It's just sluggish, so I'm trying to fix that. The stack I'm using is Rust->Rend3->WGPU->Vulkan->NVidia. Rust is doing fine. No problems at the language level. For this, I need Rust's safe concurrency; there are a lot of threads manipulating shared data. 18 months on, I only needed a debugger once, and the problem wasn't in my code. Rend3/WGPU provides a cross platform layer. Put in meshes, materials, textures, and transforms, and have a loop endlessly calling the render function. Other threads change the scene in parallel with rendering. Rend3 handles memory allocation and scheduling. Vulkan gives you access to the GPU's memory. Managing it is someone else's problem. WGPU provides a common interface to Vulkan, DirectX, and Apple's Metal, which all do pretty much the same thing, but incompatibly. WGPU sits below most of the major game engines on Rust. It all works, but not fast enough. There are locking bottlenecks at the Rend3 and WGPU levels which cause the render thread to be stalled when another thread is loading content. The whole point of Vulkan is that you can do both at once, but the Rend3 and WGPU levels don't quite have that working yet. The right functionality is there, but not the optimization needed for serious work. Nobody seems to be building AAA titles in Rust. I'm pushing the scene complexity to AAA title levels[1], and I seem to be close to the first person to do that. Not where I wanted to be. If you want to work on the lower levels, the WGPU and Rend3 projects, which are open source, need more good people. [1] https://video.hardlimit.com/w/peBesyAgtzfRWS5FnDQQtn https://video.hardlimit.com/w/peBesyAgtzfRWS5FnDQQtn
- 1ark 5y ago
  Embark Studios started an all Rust operation a few years ago. https://github.com/EmbarkStudios https://github.com/EmbarkStudios
  - Animats 5y ago
    Yes, and they're still working on the basics. Their system for writing shaders in Rust may be useful, but it's not done yet.
- johnnyanmac 5y ago
  It's a tough problem when it comes to AAA adoption. I'm not even certain if Rust has been in the game developer's conscious enough for a robust, performant engine to arise yet. i.e. if we assume that a studio deadset on making a Rust engine for a AAA game was given 5-6 years of full time engine development, they'd still be in the thick of things. And on top of that, there's just so much tooling built around existing engines/software/IDE's to be built for truly productive AAA work. There's so much to work on and developers as of now aren't convinced enough of the potential benefits to jump into that foray (at least, not on the company's dime).
  - Animats 5y ago
    It is. I'm doing this because in the "metaverse" space, defined as virtual worlds with user-created content, the existing game engines are not that helpful. They all rely on heavy content preprocessing in some desktop environment. Virtual worlds full of items created by huge numbers of users don't have that step. Which means Unity and Unreal Engine are out, at least in their current versions. (This, by the way, is why you can't sell furniture NFTs in Decentraland; the unit of updating is the land parcel with everything on it, edited offline.) Everybody who has a good, editable virtual world has their own engine. Roblox is doing some very nice work, but the system is entirely proprietary. Watch this build in Roblox. It's not just blocks any more.[1] That's a very nice 3D editor, using constructive solid geometry. [1] https://www.youtube.com/watch?v=fpiRDk510Wg https://www.youtube.com/watch?v=fpiRDk510Wg
flohofwoe 5y ago
Sokol author here (thanks for the mention). I think it's important to note that Magnum has a much wider scope than both sokol-gfx and WebGPU (see here: https://magnum.graphics/features/extras/ https://magnum.graphics/features/extras/). sokol-gfx and WebGPU are "just" 3D API wrappers, while Magnum is a much more complete C++ framework for writing 3D applications. I've been following Magnum (and the author Vladimír Vondruš) for a long time, it's an excellent project with a lot of great ideas, and a nicely balanced C++ API (which is a feat of its own). Also I'm kinda jealous of the documentation: https://doc.magnum.graphics/magnum/ https://doc.magnum.graphics/magnum/ :) PS: also don't forget BGFX (https://github.com/bkaradzic/bgfx https://github.com/bkaradzic/bgfx) which sits somewhere in the middle between sokol-gfx/WebGPU and Magnum when it comes to API abstraction and feature set.
127 5y ago
It's been 30 years and GUI toolkits are worse than they were in 1995
reassembled 5y ago
Check out gunslinger, a pure C99 game framework, with a very clean design, inspired at least in part by Sokol. The development has been making huge strides and they have a ton of great example code, as well as a fairly active discord channel: https://github.com/MrFrenik/gunslinger https://github.com/MrFrenik/gunslinger
- krapp 5y ago
  What they don't have are example games, which is the first thing I look for in a game framework. I need to know at the very least that it's complete enough to build a simple game.
  - reassembled 5y ago
    Gunslinger does have many interactive demo apps that can be run in the browser via the webassembly target. This includes a clone of Snake and another sample game. https://mrfrenik.github.io/gunslinger https://mrfrenik.github.io/gunslinger The same code can be compiled natively as well. https://github.com/MrFrenik/gs_examples https://github.com/MrFrenik/gs_examples
    - krapp 5y ago
      I stand corrected, then.

by gary_0 5y ago

pjmlp 5y ago

That isn't nothing new, 10 years ago, before free beer Unity and Unreal, one would be using something like Ogre 3D.

girvo 5y ago
Or Irrlicht, if you were me as a younger lad and scared off by Ogre at the time. There's always been a vibrant landscape of these sorts of tools, so it's neat to see another one

Animats 5y ago

Oh, I wish. There are plenty of game engines and graphics libraries for C++. We have enough of those. This is not yet true for Rust. There seem to be, but if you start to push the performance limits, problems appear. I've been writing a client for Second Life, which, despite all the hype from NFT land, is still the best metaverse around. It's just sluggish, so I'm trying to fix that. The stack I'm using is Rust->Rend3->WGPU->Vulkan->NVidia. Rust is doing fine. No problems at the language level. For this, I need Rust's safe concurrency; there are a lot of threads manipulating shared data. 18 months on, I only needed a debugger once, and the problem wasn't in my code. Rend3/WGPU provides a cross platform layer. Put in meshes, materials, textures, and transforms, and have a loop endlessly calling the render function. Other threads change the scene in parallel with rendering. Rend3 handles memory allocation and scheduling. Vulkan gives you access to the GPU's memory. Managing it is someone else's problem. WGPU provides a common interface to Vulkan, DirectX, and Apple's Metal, which all do pretty much the same thing, but incompatibly. WGPU sits below most of the major game engines on Rust. It all works, but not fast enough. There are locking bottlenecks at the Rend3 and WGPU levels which cause the render thread to be stalled when another thread is loading content. The whole point of Vulkan is that you can do both at once, but the Rend3 and WGPU levels don't quite have that working yet. The right functionality is there, but not the optimization needed for serious work. Nobody seems to be building AAA titles in Rust. I'm pushing the scene complexity to AAA title levels[1], and I seem to be close to the first person to do that. Not where I wanted to be. If you want to work on the lower levels, the WGPU and Rend3 projects, which are open source, need more good people. [1] https://video.hardlimit.com/w/peBesyAgtzfRWS5FnDQQtn https://video.hardlimit.com/w/peBesyAgtzfRWS5FnDQQtn

1ark 5y ago
Embark Studios started an all Rust operation a few years ago. https://github.com/EmbarkStudios https://github.com/EmbarkStudios
- Animats 5y ago
  Yes, and they're still working on the basics. Their system for writing shaders in Rust may be useful, but it's not done yet.
johnnyanmac 5y ago
It's a tough problem when it comes to AAA adoption. I'm not even certain if Rust has been in the game developer's conscious enough for a robust, performant engine to arise yet. i.e. if we assume that a studio deadset on making a Rust engine for a AAA game was given 5-6 years of full time engine development, they'd still be in the thick of things. And on top of that, there's just so much tooling built around existing engines/software/IDE's to be built for truly productive AAA work. There's so much to work on and developers as of now aren't convinced enough of the potential benefits to jump into that foray (at least, not on the company's dime).
- Animats 5y ago
  It is. I'm doing this because in the "metaverse" space, defined as virtual worlds with user-created content, the existing game engines are not that helpful. They all rely on heavy content preprocessing in some desktop environment. Virtual worlds full of items created by huge numbers of users don't have that step. Which means Unity and Unreal Engine are out, at least in their current versions. (This, by the way, is why you can't sell furniture NFTs in Decentraland; the unit of updating is the land parcel with everything on it, edited offline.) Everybody who has a good, editable virtual world has their own engine. Roblox is doing some very nice work, but the system is entirely proprietary. Watch this build in Roblox. It's not just blocks any more.[1] That's a very nice 3D editor, using constructive solid geometry. [1] https://www.youtube.com/watch?v=fpiRDk510Wg https://www.youtube.com/watch?v=fpiRDk510Wg

flohofwoe 5y ago

Sokol author here (thanks for the mention). I think it's important to note that Magnum has a much wider scope than both sokol-gfx and WebGPU (see here: https://magnum.graphics/features/extras/ https://magnum.graphics/features/extras/). sokol-gfx and WebGPU are "just" 3D API wrappers, while Magnum is a much more complete C++ framework for writing 3D applications. I've been following Magnum (and the author Vladimír Vondruš) for a long time, it's an excellent project with a lot of great ideas, and a nicely balanced C++ API (which is a feat of its own). Also I'm kinda jealous of the documentation: https://doc.magnum.graphics/magnum/ https://doc.magnum.graphics/magnum/ :) PS: also don't forget BGFX (https://github.com/bkaradzic/bgfx https://github.com/bkaradzic/bgfx) which sits somewhere in the middle between sokol-gfx/WebGPU and Magnum when it comes to API abstraction and feature set.

127 5y ago

It's been 30 years and GUI toolkits are worse than they were in 1995

reassembled 5y ago

Check out gunslinger, a pure C99 game framework, with a very clean design, inspired at least in part by Sokol. The development has been making huge strides and they have a ton of great example code, as well as a fairly active discord channel: https://github.com/MrFrenik/gunslinger https://github.com/MrFrenik/gunslinger

krapp 5y ago
What they don't have are example games, which is the first thing I look for in a game framework. I need to know at the very least that it's complete enough to build a simple game.
- reassembled 5y ago
  Gunslinger does have many interactive demo apps that can be run in the browser via the webassembly target. This includes a clone of Snake and another sample game. https://mrfrenik.github.io/gunslinger https://mrfrenik.github.io/gunslinger The same code can be compiled natively as well. https://github.com/MrFrenik/gs_examples https://github.com/MrFrenik/gs_examples
  - krapp 5y ago
    I stand corrected, then.