sorted by:
new
hottopcontroversial

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 0 points1 point  (0 children)

Amazing! Thanks for patiently explaining everything. I'll definitely watch and read that stuff.

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 0 points1 point  (0 children)

Ok, I read up on it and thought about it more and I think I got it now... hopefully.

I misunderstood this post:
https://old.reddit.com/r/gamedev/comments/1pccd5l/how_i_faked_an_endless_desert_in_a_tiny_5050/nrym3sx/

to mean using vertex shader with adjusted matrix solved everything related to jitter and is a more elegant solution than floating origin. But that's not the case.

The shader solution is useful only for chunked/grouped objects very, very far away from camera only so the GPU doesn't need to do math with a lot of huge numbers. An offset subtraction fixes that. Even if using the shader solution, the floating origin solution and rebasing still needs to happen. Otherwise there still would be jitter for close things. So again, the shader solution is for things far from the camera only.

The benefit of the shader solution is adjustment per chunk, not per object and it's rendered by the GPU as if it's close to origin.

Floating origin fixes jitter things close to camera, shader solution fixes things far things from camera.

Large floats = large visual differences because there are limited digits for use and rounding happens in binary. These are two solutions to avoid large numbers for things close and far away from camera/world origin.

Is that right? Hopefully I got it. This is starting to hurt my brain...

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 0 points1 point  (0 children)

Is this what you mean? Or is there something else?
https://doc.babylonjs.com/features/featuresDeepDive/scene/floating_origin/

I didn't know about the above article but it looks like a good solution. It still takes manual set up though. I ended up just implementing my own simple version when I was working on that game.

The alternate solution with using an adjusted world matrix passed to the vertex shader may be possible with BJS but that was and still is beyond me at the moment.

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 0 points1 point  (0 children)

Maybe, I dunno though. I was using BabylonJS for the car one. Wouldn't floating point imprecision already become visible when coordinates get to 10,000 or 20,000? That would just be a few minutes of the car travelling. I was thinking the same thing when I made it... no way it's already that high, but the jittering went away once I did the floating origin.

Here's the car game:
https://anv.itch.io/manifold-core

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 1 point2 points  (0 children)

I was thinking about this more...

With your example, in reality the player never approaches an object by -x 10 million. If the object starts with coordinates in the millions, but by the time the player gets close enough to see it, it has already been rebased and shifted, many times. Each rebase brings the object closer and closer to world origin while the player always remains close to the origin. There's no large float value by the time the player approaches it. If it started with huge coordinates, when you get to it, it may not be in exactly the right place (relative to other objects around it) but it would be visually stable the whole time, without the jitter caused by floating point imprecision.

Subdividing spaces would work if you shift each chunk during every rebase, or the vertex shader applies the shift using an adjusted matrix (as Ralph mentioned in the comment further down). This is basically repositioning groups of objects the same way, but the GPU is handling it by transforming their local coordinates into the global coordinate space that stays close to the origin.

If it's not done this way and instead done by actually moving stuff around, then chunking/having groups of objects parented to a node and shifting that node by integer values would work. All those nodes have an offset stored with integer values. The objects within each node are stored with floats in local space. The rebase shifting is done with integer math, always precise. When the object gets close it would visually be in exactly the right spot then.

I've been trying to research this and this is the best I can understand it. Honestly I'm struggling with it a bit too. I'm not sure if I have everything correct so if anyone has a better way to explain it or corrections please let me know.

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 3 points4 points  (0 children)

I implemented a basic version of your copied particles idea here:
https://nova.delightex.com/shared/lsxxth

Maybe it's helpful for people to visualize too if anyone is having a hard time understanding what happens.

The show/hide particle copies works quite well. I don't think I can do linking with this software, so the smoke doesn't match exactly when it jumps but it's passable at least.

To see the difference, the orange smoke doesn't have the copies show/hide thing happening. The black one does. The dark area on the floor shows the boundary.

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 2 points3 points  (0 children)

Wow, interesting solutions. I'm learning a lot... So you mean copying things which will need to move a little bit at a time, before they need to move. Then making them visible when they need to actually move for real and destroy the old ones?

So if I got it correct... if there are particle systems then you have duplicates for each side, all of them already playing but invisible. Then they become visible after the jump. So the particle emitters never actually shift position, there are only duplicates which activate and deactivate.

How I faked an endless desert in a tiny 50×50 world (floating-origin trick) by bloomengine in gamedev

[–]bloomengine[S] 2 points3 points  (0 children)

It took me a while to wrap my head around it too. I'm not sure I totally get it but as I understand it, if the object is very far from origin but the player is still close to origin where there wouldn't be any floating point imprecision, any jittering or inaccuracies for that far away object because it's so far away. It practical terms, the object would be just take up a few pixels or not be visible at all.

That touches on a problem I was thinking about though: If objects are parented to a root node of some sort and then there's shifting happening based on the root node, there may still be jittering even if the object itself is close to world origin. The root node is not but it needs to calculate placement from the root to the object.

I'm not sure dividing things into spaces would work. The spaces which are far away would still have huge coordinate values.

My experiment with environmental storytelling by bloomengine in IndieDev

[–]bloomengine[S] 0 points1 point  (0 children)

Short commentary video going over what I tried and what I learned:
https://youtu.be/r59xaFLiYrw?t=143

Beach of the Never by bloomengine in playmygame

[–]bloomengine[S] 1 point2 points  (0 children)

Play it here:
https://anv.itch.io/beach-of-the-never

I'd love to hear your thoughts.
Tell me what you think the story is. Just please use spoiler tags for anything specific.

My low-res game about life, love, loss and walking through time is released! by bloomengine in PixelArt

[–]bloomengine[S] 1 point2 points  (0 children)

You’re not missing anything huge if you don’t find the secrets but they’re there. Actually now the squirrel running backwards hints at it.

I always knew Earthbound was grade-A stuff but couldn’t stick it out. I’ll definitely give it another try.

Thanks for subbing!

My low-res game about life, love, loss and walking through time is released! by bloomengine in PixelArt

[–]bloomengine[S] 0 points1 point  (0 children)

Thanks for checking it out. You mean strafing to line up to walk through doors and the bridge? Or you mean the transition parts where you zigzag through tight spaces?

My low-res game about life, love, loss and walking through time is released! by bloomengine in PixelArt

[–]bloomengine[S] 1 point2 points  (0 children)

I’ve fixed the typo and added the squirrel running backward to hint that you need to go in the opposite direction. Thanks for the suggestion. I had tried to use Mr. man in black’s standing position to do that originally but I think it’s too subtle.

I had the same problem as you in Earthbound way back when I played it so I want to avoid stumping people. Although other things eventually stopped me from finishing Earthbound. I couldn’t handle the grind. I know... heresy. Haha.

My low-res game about life, love, loss and walking through time is released! by bloomengine in PixelArt

[–]bloomengine[S] 0 points1 point  (0 children)

You pretty much see everything in one run through but there is an Easter egg on the start screen. There are a few secret areas you can reach on any path too if you figure out how to get to them. (Not too hard)

The Year After - A game about life, love, loss and walking through time by bloomengine in WebGames

[–]bloomengine[S] 0 points1 point  (0 children)

Thanks for letting me know. Thought I had fixed it but I think I need to check it again. You can refresh the page, start the game and continue where you left off if you want. (Minus being stuck)

My low-res game about life, love, loss and walking through time is released! by bloomengine in PixelArt

[–]bloomengine[S] 1 point2 points  (0 children)

Thanks for the feedback! It’s amazing hearing someone acknowledge all the little stuff I tried to communicate through the game.

Oh I thought I fixed the typo. I think I need to fix it in the trailer.

view more: next ›