Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interactive 3D ASCII scenes

yeahpython.github.io

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Interactive 3D ASCII scenes

#31

Post by giornogiovanna »

kakarot wrote: post #18
daxterspeed wrote: post #8

Since the movement speed is tied to requestAnimationFrame, the speed of the game changes with the update frequency of the user's monitor. Since all my monitors are at 144Hz this game is ridiculously fast for me.

To clarify, there's nothing wrong with tying your movement to requestAnimationFrame() and it is in fact encouraged, but you must modulate it by the frame delta.

That is only true if you write your own physics. Otherwise, your physics framerate should be fixed, usually at 30FPS. Many physics engines don't support variable timestep, and in the ones that do, it can lead to instability and general weirdness.

Re: Interactive 3D ASCII scenes

#32

Post by codetrotter »

leni536 wrote: post #10

About WASD controls and alternative layouts: apparently JS supports key codes. [1] https://www.w3schools.com/jsref/event_key_keycode.asp [2] https://keycode.info/ Edit: Apparently it is deprecated: [3] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve... [4] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve... Also there doesn't seem to be a way to detect the user's preferred layout before press…

> Also there doesn't seem to be a way to detect the user's preferred layout before pressing any keys, that would make printing the instructions hard

I am using a programmable keyboard that I’ve set up with a Dvorak-based layout. Here: https://configure.ergodox-ez.com/layouts/ENb6/latest/0

Games defaulting to WASD are fine as long as they allow changing the keybindings in the game.

I prefer that games do not try to detect keyboard layout because they’d probably get it wrong anyway.

Re: Interactive 3D ASCII scenes

#33

Post by kakarot »

giornogiovanna wrote: post #31
kakarot wrote: post #18

Earlier quoted context omitted.

To clarify, there's nothing wrong with tying your movement to requestAnimationFrame() and it is in fact encouraged, but you must modulate it by the frame delta.

That is only true if you write your own physics. Otherwise, your physics framerate should be fixed, usually at 30FPS. Many physics engines don't support variable timestep, and in the ones that do, it can lead to instability and general weirdness.

I don't understand how not writing your own physics engine automatically negates what I said.

If a developer has implemented a third-party physics engine, they should refer to that engine's documentation.

Re: Interactive 3D ASCII scenes

#34

Post by giornogiovanna »

kakarot wrote: post #33
giornogiovanna wrote: post #31

Earlier quoted context omitted.

That is only true if you write your own physics. Otherwise, your physics framerate should be fixed, usually at 30FPS. Many physics engines don't support variable timestep, and in the ones that do, it can lead to instability and general weirdness.

I don't understand how not writing your own physics engine automatically negates what I said. If a developer has implemented a third-party physics engine, they should refer to that engine's documentation.

Typically physics engines can't be "modulated by the delta" (which I assume means varying the dt when integrating), you just have to tick the physics world multiple times and keep the roundoff for next time. [0] gives a good example of implementing this kind of thing.

If you implement your own, you can make dt a parameter instead of a constant, but this is more complicated, and can lead to tunnelling when the framerate is too low.

[0]: https://gafferongames.com/post/fix_your_timestep/

Re: Interactive 3D ASCII scenes

#35

Post by kakarot »

giornogiovanna wrote: post #34
kakarot wrote: post #33

Earlier quoted context omitted.

I don't understand how not writing your own physics engine automatically negates what I said. If a developer has implemented a third-party physics engine, they should refer to that engine's documentation.

Typically physics engines can't be "modulated by the delta" (which I assume means varying the dt when integrating), you just have to tick the physics world multiple times and keep the roundoff for next time. [0] gives a good example of implementing this kind of thing. If you implement your own, you can make dt a parameter instead of a constant, but this is more complicated, and can lead to tunnelling when the framera…

Well first it depends on what you mean by typically. Number of total engines in the wild? Or current market share?

But besides, if you are using a fixed physics engine you should not be using rAF. It's not meant for that. Your comment is just a bit tangential.

Re: Interactive 3D ASCII scenes

#36

Post by giornogiovanna »

kakarot wrote: post #35
giornogiovanna wrote: post #34

Earlier quoted context omitted.

Typically physics engines can't be "modulated by the delta" (which I assume means varying the dt when integrating), you just have to tick the physics world multiple times and keep the roundoff for next time. [0] gives a good example of implementing this kind of thing. If you implement your own, you can make dt a parameter instead of a constant, but this is more complicated, and can lead to tunnelling when the framera…

Well first it depends on what you mean by typically. Number of total engines in the wild? Or current market share? But besides, if you are using a fixed physics engine you should not be using rAF. It's not meant for that. Your comment is just a bit tangential.

Bullet, Box2D and PhysX all highly recommend using a fixed timestep, and no, you should definitely be using requestAnimationFrame with a fixed timestep, just like in the fix-your-timestep article. The number of frames to advance the simulation by is still determined by the screen's refresh rate, after all.

Re: Interactive 3D ASCII scenes

#37

Post by all2 »

idid wrote: post #21

would love to see how this could transform into a rougelike (or a rougelike with the same aesthetics). really cool job! will poke at the source.

Inventory, items, enemies, weapons, towns, crafting, destructible levels (could a voxel based system work in ASCII?), ...

Someone farther up linked to Monument Valley [0], and that has a really pleasant rotating mechanic so that the player can have more than one view of a level / set-piece.

A little wave-collapse [1] function for automated level building.

I suppose I could go on. This does fall into the trap of "why don't we just ... ?" which I don't like. But I also like to dream a little.

Re: Interactive 3D ASCII scenes

#40

Post by bartread »

daxterspeed wrote: post #8

Since the movement speed is tied to requestAnimationFrame, the speed of the game changes with the update frequency of the user's monitor. Since all my monitors are at 144Hz this game is ridiculously fast for me.

> Since the movement speed is tied to requestAnimationFrame, the speed of the game changes with the update frequency of the user's monitor. Since all my monitors are at 144Hz this game is ridiculously fast for me.

Damn. I just checked this and you're right: https://developer.mozilla.org/en-US/docs/Web/API/window/requ.... Learned something there so thanks for pointing this out.

I'd always believed that callbacks were locked at 60 fps, although I'm not sure why. Clearly this means all my own games will run at the wrong speed on machines with a higher refresh rate, and will probably appear jerky on displays with a lower rate (assuming such still exist).

Post reply on HN