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

41–50 of 62 posts

Re: Interactive 3D ASCII scenes

#42

Post by chrisseaton »

fatiherikli wrote: post #41

Love it! Just a note, it is not actually 3D, it is an isometric representation of a 2d scene, as same as Monument Valley. Game devs call it 2.5D :)

Why doesn't it count as 3D? I seem to be able to move the character in 3 dimensions. Some parts of the floor are higher than others. What else does 3D mean?

Could you represent this map using just two components for each point? I don't see how.

Re: Interactive 3D ASCII scenes

#44

Post by bscphil »

chrisseaton wrote: post #42
fatiherikli wrote: post #41

Love it! Just a note, it is not actually 3D, it is an isometric representation of a 2d scene, as same as Monument Valley. Game devs call it 2.5D :)

Why doesn't it count as 3D? I seem to be able to move the character in 3 dimensions. Some parts of the floor are higher than others. What else does 3D mean? Could you represent this map using just two components for each point? I don't see how.

I believe usually "3D" implies that some change of perspective is possible, e.g. by changing the orientation of the camera.

Re: Interactive 3D ASCII scenes

#45

Post by davedx »

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.

Weird statement. All games and game engines I've worked with have used frame deltas to modulate everything from animation and movement to AI and UI's. I've worked on mobile games to AAA games.

Can you link to a physics engine that doesn't support variable timestep?

Re: Interactive 3D ASCII scenes

#46

Post by klohto »

edhelas wrote: post #6

Why WASD ? A lots of people on the Internet doesn't have a Qwerty keyboard.

And a lots of people don't even use standard keyboard layout, should they be supported as well? Don't be ridiculous, WASD for controls has been used since Quake.

Re: Interactive 3D ASCII scenes

#48

Post by kakarot »

giornogiovanna wrote: post #36
kakarot wrote: post #35

Earlier quoted context omitted.

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.

That really depends.

Pegging your fixed timestep engine to rAF could have the consequence of dropping frames when you have a large gap between two frames and enough physics frames get called at once that the next rAF window gets missed. If your performance is bounded by the physics simulation, you could potentially trigger a spiral of death and never catch up.

Of course there are ways to mitigate this, but that just further complicates things.

You have the right idea, adding each frame delta to an accumulator and triggering a physics step when reaches the appropriate value, however rAF is not the answer because it can create a potentially infinite frame delta.

It's usually best to not peg your fixed-timestep physics to rAF or at the very least, pause the game entirely when the window isn't focused.

Post reply on HN