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

51–60 of 62 posts

Re: Interactive 3D ASCII scenes

#51

Post by [deleted] »

davedx wrote: post #45
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.

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?

[deleted]

Re: Interactive 3D ASCII scenes

#52

Post by Someone »

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.

The libraries that generate(d) such graphics typically only could render such scenes because limiting all edges to the three major axes and discarding perspective (distances on the projection do not get smaller the further the line is from the viewer in the 3D scene) makes it computationally a lot easier to render scenes.

To distinguish them from “true 3D” libraries, a name had to be found. 2.5D seemed fitting.

Re: Interactive 3D ASCII scenes

#53

Post by luminati »

Woke up this morning feeling quite crappy. Then saw this. All faith in humanity (And the internet) has been restored. Thank you! [On a sidenote: How would one go about learning to build this? Any learning resources on understanding all the math and physics behind this?]

Re: Interactive 3D ASCII scenes

#54

Post by giornogiovanna »

davedx wrote: post #45
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.

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?

You definitely use frame deltas when updating things (I mean, how else would you know how much time has passed), but when doing physics, that frame delta is constant for the lifetime of the simulation.

Box2D User Manual > We also don't like the time step to change much. A variable time step produces variable results, which makes it difficult to debug. So don't tie the time step to your frame rate (unless you really, really have to).

https://stackoverflow.com/a/21273467 (Bullet) > maxSubSteps: Should generally stay at one so Bullet interpolates current values on its own. A value of zero implies a variable tick rate, meaning Bullet advances the simulation exactly timeStep seconds instead of interpolating. This feature is buggy and not recommended.

Edit: The archived version of the (404-ing) Bullet Wiki also says "Bullet maintains an internal clock, in order to keep the actual length of ticks constant. This is pivotally important for framerate independence. The third parameter is the size of that internal step."

Re: Interactive 3D ASCII scenes

#55

Post by giornogiovanna »

kakarot wrote: post #48
giornogiovanna wrote: post #36

Earlier quoted context omitted.

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…

Damn, you're right, it's more complicated than I thought. But what else would you use? setInterval suffers from the same problem, doesn't it?

Re: Interactive 3D ASCII scenes

#56

Post by TOGoS »

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.

It seems to be a 3D world, projected onto a 2D screen, just like almost every other '3D' game. I think they're nit-picking because they think of isometric projections as being less "3D" than perspective ones.

Re: Interactive 3D ASCII scenes

#57

Post by tvararu »

bartread wrote: post #40
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…

I was surprised to learn that many commercial HDR 4K TVs have a 50Hz real refresh rate. Sub 60Hz screens are bountiful and common.

Re: Interactive 3D ASCII scenes

#58

Post by nacs »

tvararu wrote: post #57
bartread wrote: post #40

Earlier quoted context omitted.

> 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…

I was surprised to learn that many commercial HDR 4K TVs have a 50Hz real refresh rate. Sub 60Hz screens are bountiful and common.

It's also common on a lot of mobile devices as well -- iOS can actually vary the refresh rate on a device from 30Hz (energy-efficient) to 60hz ('standard') upto 120Mhz ("ProMotion") and I'm sure Android probably does this also.

Re: Interactive 3D ASCII scenes

#59

Post by aqi »

luminati wrote: post #53

Woke up this morning feeling quite crappy. Then saw this. All faith in humanity (And the internet) has been restored. Thank you! [On a sidenote: How would one go about learning to build this? Any learning resources on understanding all the math and physics behind this?]

This was built through incremental edits from a Python proof-of-concept, which you can see here: https://github.com/yeahpython/ascii-renderer/blob/master/fun... It doesn't have any real physics, but reading through it might help reveal how the rendering works.

For the physics, I'm basically colliding against a grid of tiles, so this might be a helpful tutorial to do the same: https://jonathanwhiting.com/tutorial/collision/

Re: Interactive 3D ASCII scenes

#60

Post by luminati »

aqi wrote: post #59
luminati wrote: post #53

Woke up this morning feeling quite crappy. Then saw this. All faith in humanity (And the internet) has been restored. Thank you! [On a sidenote: How would one go about learning to build this? Any learning resources on understanding all the math and physics behind this?]

This was built through incremental edits from a Python proof-of-concept, which you can see here: https://github.com/yeahpython/ascii-renderer/blob/master/fun... It doesn't have any real physics, but reading through it might help reveal how the rendering works. For the physics, I'm basically colliding against a grid of tiles, so this might be a helpful tutorial to do the same: https://jonathanwhiting.com/tutorial/coll…

Thank you!
Post reply on HN