8 ms·

The author gave just a simple example, the DVD animation, but it is much more than this, this technique is the industry standard in game art for all the backgr

• pdpi 4y ago
  The other reason you want to use a function of time and avoid using state for things like animations is that you don't want animation speed to be frame rate dependent.
  • sublinear 4y ago
    Game state isn't usually frame rate dependent either
    • creshal 4y ago
      A lot of games have some internal "physics rate" or similarly termed tick rate at which the logical state is updated. The better you can decouple the graphics pipeline from it, the better.
    • bluGill 4y ago
      Not anymore, in the past it was. Some games in the 8bit world ran slower in Europe vs the US because Europe TVs used PAL which was 50hz refreshes, while the US had NTSC with 60hz refreshes (some games counted on NTSC being interlaced and so updated at 30hz which made NTSC games slower). IIRC some PC games depended on frame rate as well, but I don't recall any specifics.
      • dpkirchner 4y ago
        Skyrim infamously allows your frame rate to influence game physics, with hilarious results. https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_tell_me_what_the_actual_fuck_is_going/ https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_...
        • connicpu 4y ago
          This is one of the traps when you go for the naive approach to framerate independence: simply using the frame delta for stepping your calculations. Results for physics engines are very wacky! It's usually better to step your physics engine at a fixed rate (e.g. 60hz), and make the frequency of steps performed independent of the graphics framerate. Perform some slight interpolation on the position of rendered objects and nobody can tell the difference
      • earthling8118 4y ago
        The original DayZ mod had an issue with this. If your framerate was lower your character would run slower. It's a very subtle effect, but when you ran several km alongside someone with a weaker computer they'd end up further back and you'd have to wait for them to catch up.
    • munificent 4y ago
      Render state usually isn't, but internal simulation and physics often updates using a fixed time step because it avoids many many problems caused by variable frame rates. https://gafferongames.com/post/fix_your_timestep/ https://gafferongames.com/post/fix_your_timestep/
  • j1elo 4y ago
    When things aren't done properly, the whole experience can fall down. I recently played Minnit [1], a very small and cute game with a very unique proposal: that you only have 1 minute of gameplay before being warped to a starting point. But time is not checked asynchronously but as a function of the frame rate, so my playthrough was basically sped up and lasted for 45 seconds each time. Turned out I didn't realize until almost the end, when a _very_ difficult movement seemed almost impossible to make in time (I did end up achieving 100% doable things in the game, but it cost me a good amount of attempts!) Gamedevs, please, do not count frames and assume they'll be whatever amount per second you believe they'll be. Because they won't. [1]: https://store.steampowered.com/app/609490/Minit/ https://store.steampowered.com/app/609490/Minit/
    • Kiro 4y ago
      Didn't that mean you also moved faster?
      • j1elo 4y ago
        Yes, that's how I was able to complete most parts of the game (which in general isn't difficult at all). But at least one of the extra optional things does get much more difficult if you don't have almost perfect execution, so faster movement speeds were actually a handicap as my control movements had to me much more precise. To be clear: it was at that time that I discovered that some wrong settings in the Steam Deck had been affecting the in-game FPS, so after correcting them and getting to the designed runtime speeds, the challenge got from impossible to barely achievable :)
    • __MatrixMan__ 4y ago
      As a newbie in a graphics course I once animated something using xlib and openGL. I hadn't bothered install my graphics card driver, so everything was nice and slow. I brought it into to the professor's office (it was our final) to demo it, and it was so fast on his machine that you couldn't see it. I freaked out, but he had seen that kind of problem before and just sprinkled some sleeps throughout so it was visible to a human and gave me a B.
  • wolfi008 4y ago
    In other words, don't write state, only consume it. (Time is also state.)
  • barbariangrunge 4y ago
    Removing frame rate dependence isn’t central to this concept, it’s almost a coincidental side effect. You can easily remove frame rate dependence in the first example
  • Pxtl 4y ago
    You do that by using delta-t instead of 1 when doing a stateful operation. The fact that a stateless function does it for you automatically is gravy.
• vendiddy 4y ago
  Comments like this are the reason I love HN. Learned something new today!
• drittich 4y ago
  Please go on - I'm a novice at game dev and this kind of lore is gold and like gold, hard to find.
  • clucas 4y ago
    Here's a little tidbit of wisdom in this vein: http://web.archive.org/web/20221230074845/http://the-witness.net/news/2022/02/a-shader-trick/ http://web.archive.org/web/20221230074845/http://the-witness... EDIT to add: Also https://www.youtube.com/@MartinDonald https://www.youtube.com/@MartinDonald has some good stuff as well. And here's a subset of Handmade Hero you might find interesting: https://www.youtube.com/playlist?list=PLEMXAbCVnmY6Mnkt-EZC_yZcHEGcA-w11 https://www.youtube.com/playlist?list=PLEMXAbCVnmY6Mnkt-EZC_...
• baxuz 4y ago
  GPU shaders have time? As for game logic-it does make sense. Tying logic and rendering to a system timer / frame counter leads to all kinds of issues.
  • skrebbel 4y ago
    GPU shaders don't "have" time but you can cheaply send them the current frame's time wrt some start time as a uniform input variable.
  • Drakim 4y ago
    It's extremely common to send a time input to GPU shaders, although this time input doesn't need to be tied to anything like a system timer or frame counter, it can be arbitrary and adjusted at will. Think of it like this: Imagine you have an expensive tween animation for particles, and every frame you have to use your CPU to calculate where the particle should have moved as part of it's animation, and send those updated coordinates to the GPU. Imagine you have millions of such objects, so it's quite the burden for the CPU, both in terms of calculating the tween animation, but also in terms of constantly updating every particle's x,y values over and over. Instead, you could seed each particle on the GPU with x1,y1,x2,y2 values, and then just provide a global "time" value for them all to share. When you update time = time + 1, all particles on the GPU will recalculate their position without needing to be helped by the CPU. The trick is that they don't save this new position though, instead, they do the job all over again from scratch at time = time + 2, which is a lot cheaper since we didn't need to "save" our previous result, which is hard work on the GPU.
    • baxuz 4y ago
      Great explanation, thanks!
• rpigab 4y ago
  For those interested in shaders, check out Shadertoy and try to find really easy to understand ones or code your own: https://www.shadertoy.com/ https://www.shadertoy.com/ For instance, here is a DVD logo bounce animation in Shadertoy: https://www.shadertoy.com/view/wdcXRj https://www.shadertoy.com/view/wdcXRj
• barbariangrunge 4y ago
  A lot of state resembles caching, and making sure those “caches” are updated properly is hard. The whole codebase begins to have to know about everywhere somebody decided to cache values, and every coder has to remember they exist and to update them all correctly even for minor code changes. Which means it causes a ton of bugs. This, and shaders in general, are great examples of better ways to do things. Often: Dynamic calculation > state
• agumonkey 4y ago
  dissolution of state through parametrization
• Cthulhu_ 4y ago
  Hmm, the only serious experience I've had with game development was a FPS style game during school; one of the things I remember was that updating the position of a player or e.g. a bullet was to take the previous location, the velocity, and the time elapsed between the previous and current state. This was demo code btw, not my own - I wasn't smart enough for that yet. Still amn't. Anyway, now I wonder if this could be done in this style. Bullet position = its origin, vector and then you can determine its location at any point in time, instead of updating its position at every tick. Doing that one will likely cause issues across a network or if framerate (or game tick rate) is unstable / unpredictable.
  • TrainedMonkey 4y ago
    > Anyway, now I wonder if this could be done in this style. Bullet position = its origin, vector and then you can determine its location at any point in time, instead of updating its position at every tick. It certainly can! Not an expert, but what you are describing can probably be done as a bullet shader. > Doing that one will likely cause issues across a network or if framerate (or game tick rate) is unstable / unpredictable. I kind of want to know if a seamless experience is possible without a server... but for now I assume there is one. At that point client frame rate / tick rate does not really matter. Each client sends current character position and origin + vector of all the bullets to the server. Note that current location of the bullets is not important to update the world state - only the origination point and direction. Based on that it can independently do all the hit calculations. Of course this makes cheating possible and any kind of latency extremely annoying, but margins of this post and my available coffee break time are too thin to offer my amateurish take on those problems.
  • munificent 4y ago
    > updating the position of a player or e.g. a bullet was to take the previous location, the velocity, and the time elapsed between the previous and current state. Yes, the technical term for this is Euler integration: https://en.wikipedia.org/wiki/Euler_method https://en.wikipedia.org/wiki/Euler_method It's good enough for a lot of parts of a game simulation, especially if you have a fixed framerate. But it can get wonky if you have a lot of stuff moving around this way and interacting with each other. Full fledged physics engines in games tend to use more sophisticated algorithms to do the integration to avoid that. > Bullet position = its origin, vector and then you can determine its location at any point in time, instead of updating its position at every tick. Unfortunately, no. The linked blog post is a really cool way to think about simple animations but you will very often hit a wall (metaphorically and literally) where this technique no longer works. The key problem is that the state of an object at time T depends on all possible interactions the object may have had before T. In the linked article, the only interactions are bouncing off walls, which are regular enough in time that you can model them analytically. (But even in this trivial example, it still doesn't really work. Notice that if you resize your window, the DVD box jumps all over the place. That's because the analytic solution can't understand the notion of a window whose size changes. All it can do is calculate where the box would be now if the window had always been its current size. I digress.) You can analytically calculate the position of a bullet at any time T given its origin and velocity, but only if the bullet doesn't interact with anything else. If you have, say, a human controller play that is running through the path of the bullet and gets hit, your simulation needs to understand that the bullet won't keep moving after that. For a use case as simple as this, you may be able to model it statefully by just deleting the bullet entirely once it hits something. But, in general, there is always some level of state that you'll need in order to simulate anything beyond trivial complexity.