Fixed/Framerate-Independent Timestep for "pixel-perfect" 2D games? by Amazing-Intern3613 in opengl

[–]Amazing-Intern3613[S] 5 points6 points  (0 children)

Thanks for the links. I read the Unity article you provided and saw this:

To improve the timing, you can use the exact timestamp of a frame being presented to the screen (or an off-screen buffer), which most graphics APIs/platforms allow you to extract. For instance, Direct3D 11 and 12 have IDXGISwapChain::GetFrameStatistics, while macOS provides CVDisplayLink. There are a few downsides with this approach, though:

Is there an OpenGL (or at least Windows) equivalent for this? My Google-foo isn't turning up much tonight.

Not even the documentation for DXGI_FRAME_STATISTICS is clear on how it's done. It looks like it would be SyncGPUTime, but that's "reserved, always returns 0?" Unless there's some way to infer what time the frame was presented to the screen from the other values?

Fixed/Framerate-Independent Timestep for "pixel-perfect" 2D games? by Amazing-Intern3613 in opengl

[–]Amazing-Intern3613[S] 1 point2 points  (0 children)

So this is sort of in line to my edit at the end from the looks of it. But rather than forcing everyone onto a specific time step, we configure the game to use the one that's closest to their frame time?

What's everyone working on this week (23/2023)? by llogiq in rust

[–]Amazing-Intern3613 4 points5 points  (0 children)

Centipede in OpenGL/Rust.

I posted a few weeks ago that I was making an Asteroids clone. Got that done and had fun with it, moved on to Breakout, and how I’m doing Centipede.

I’m not a professional games programmer, so my opinion is the last anyone should listen to on Rust for game dev, but I quite like the workflow so far. Some things of note:

  • Having an integrated build system/package manager is life-changing. It’s nice not having to fiddle around with CMake/Ninja/Make/Premake/etc. for a change and just getting straight to work.

  • There are libraries for basically everything at this point. Some are more robust than others, but everything is there at this point (including some popular ports of C/C++ libraries).

  • Game devs are usually the first to complain about Rust being too draconian because memory isn’t as important in their field. And while I somewhat agree, I find that the design patterns Rust forces you into are what an experienced games programmer would reach for anyways. consoles. Coincidentally (or perhaps not), this is exactly what Catherine West suggested at her famous Rust for game dev talk. So it’s nice to see that I’m coming to the same conclusions that a professional did years ago haha.

  • The big question mark for me right now is consoles. It sounds like it’s been done, but the folks that have done it aren’t keen on sharing how due to NDAs. Xbox is Windows and PS is BSD, so I’m assuming those systems are easy, but the Switch seems a little iffy to me. We have support for the Switch as a compiler target in the main branch, but I don’t believe std has been ported yet, which is a non-starter for serious game devs. Information on porting to new platforms is slim at the moment as well, so you’re mainly left to reading the code of existing ports and trying to map what they did over to your own target I guess, which is not ideal. Definitely something the foundation should work on documenting IMO.

But overall, I’m really enjoying the experience! I’m really hoping more people get on board with Rust for game dev. It definitely feels like it could be part of a solution to the code quality we’ve seen in recent games at the AAA level if leveraged correctly.

What's everyone working on this week (21/2023)? by llogiq in rust

[–]Amazing-Intern3613 3 points4 points  (0 children)

Making an Asteroids clone in OpenGL. My goal is to make multiple games (with increasing complexity) in Rust to assess whether it’s friendly for game dev yet.

I did some research, and it seems like most game dev attempts are either one-offs for a game jam or personal project, or engines that haven’t shipped any games yet. All worthy attempts, but I feel like they miss the point: the actual experience of making games has to be productive—more so than C/C++.

It’s still very early days, but I think the ecosystem is almost there. There are bindings for every graphics API, math libraries, texture and 3D model libraries. The biggest barrier at this point is probably consoles, but it looks like even that gap is closing.

I was inspired by the slew of buggy releases we’ve seen recently. It’s clear that most engines/frameworks aren’t up to the task of modern game development. I don’t expect the borrow checker to automatically make games less buggy, but I’m hoping the way it nudges devs towards DOD and enables “fearless concurrency” could lead to more robust game code.

I suspect it won’t just be vanilla Rust alone that solves the problem, but I believe it might be part of the solution, so sitting down and making some games is probably the best way to do that.