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

Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

gist.github.com

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#31

Post by moffkalast »

db48x wrote: post #19
LarsDu88 wrote: post #13

Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycast…

If you’re doing thousands of raycasts per frame in any game, 2D or 3D, then something has gone wrong. Raycasts are very general, and there is often a more specialized way to get the same information that won’t require as much work.

Maybe there's thousands of guns being fired.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#32

Post by 3seashells »

jayd16 wrote: post #7
jackmott42 wrote: post #4

Earlier quoted context omitted.

In the context of function parameters at the edge of C# and c++ I don't think it will ever amount to a large amount of memory being wasted. The cache point may be relevant, but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. So maybe not so bad.

>but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. How do you figure? Are you saying there should be no tight loops that hit engine code, none that live in the C#/scripting lifecycle or all tight loops should be rewritten in C++? The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games ev…

Tight loops mean:develope one specialized function call which gets a field of data and works on it.. Resurfacing after the job is done.

You may even invert direction, handing over a pure script language function (no context) + the data, so the c++ engine may crunch the data at least in parallel small script vms without stack, similar to a shader.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#34

Post by dundarious »

26fingies wrote: post #18

It seems weird to extrapolate where Godot will live in the game development ecosystem from its current performance characteristics for certain operations. It's like trying out Windows 95 and saying "Microsoft isn't going to dominate the PC world because Windows 95 crashes a lot!" Maybe.. but these sorts of technical minutae are not the things that determine winners as far as I can tell.

“Godot is not the new Unity” is a present tense statement, issued at a time when many studios are considering a hasty and impromptu transition from Unity -- they are looking for a suitable equivalent now, not many years into the future. It's a sensible question about today and the very near future.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#35

Post by hutzlibu »

ehutch79 wrote: post #24
hutzlibu wrote: post #17

Earlier quoted context omitted.

"If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on..." Yup .. but maybe not stupidity, but rather a non generic game. In my case I need lots of raycasts, to determine what exactly the player and the enemy bots can see. Basically I have a simulation in 2D (using box2d directly in js as a wasm libary) - and all the bots and the player only (mostly) get information…

Wait. that doesn't sound like you're doing 1000s of raycasts? Just a few, maybe a dozen? also, sounds like you're using JS, not Godot?

Well, I would like to be able to do 1000s of raycast per frame (360 for each bot), but cannot and yes, I do not use godot, but my own engine (with pixijs for graphics and a emscriptem port of box2d for physics https://github.com/Birch-san/box2d-wasm.) Godot uses box2d, too, so that would be convenient, if I switch to godot, but only if it is worth the performance improvement, which it currently does not seem to be. Maybe next year.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#36

Post by kaibee »

Kiro wrote: post #26
LarsDu88 wrote: post #13

Somehow, I feel like reading that article diminished the original critique, however, inefficient raycasts aren't some sort of pathological edge case. Raycasts are the most commonly used spatial queries in a 3d game. Hopefully this discussion will lead towards this issue being resolved. I actually found Sam Pruden's complaint a bit odd since it sounds like he's developing a 2d game. If you're spamming 1000s of raycast…

Isn't that how you do line-of-sight/shadows, with thousands of raycasts for all pixels on screen?

Absolutely not. There's uh, a lot of tutorials on YouTube about how to go about implementing this kinda thing, depending on the kind of game (top-down 2d, vs 3d etc). Sorry don't have time to do a full write up lol.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#37

Post by hutzlibu »

fidotron wrote: post #27
hutzlibu wrote: post #17

Earlier quoted context omitted.

"If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on..." Yup .. but maybe not stupidity, but rather a non generic game. In my case I need lots of raycasts, to determine what exactly the player and the enemy bots can see. Basically I have a simulation in 2D (using box2d directly in js as a wasm libary) - and all the bots and the player only (mostly) get information…

> because the roundtrip js to wasm is expensive. Is this a thing? I've been using ammo (wasm bullet) and while wasm interfacing certainly has a mismatch with idiomatic js I haven't knowably hit a problem with that bridge.

It used to be waaaay more expensive and has gotten much better now. But it still costs, all I know is, that when I do 600 raycasts each, it costs me around 8 ms on medium hardware. Batching it reduces the cost to 2 ms for me. For simple things like GetPosition I did not noticed a perf hit, but for getting vertices I also did. So mid term, I will batch all often used calls into wasm. For now raycasting was the biggest bottleneck.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#38

Post by hutzlibu »

rngname22 wrote: post #23
hutzlibu wrote: post #17

Earlier quoted context omitted.

"If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on..." Yup .. but maybe not stupidity, but rather a non generic game. In my case I need lots of raycasts, to determine what exactly the player and the enemy bots can see. Basically I have a simulation in 2D (using box2d directly in js as a wasm libary) - and all the bots and the player only (mostly) get information…

If the game is 2D and you can divide space into tiles/blocks and walls/obstacles have their own blocks/tiles (or you can easily establish a grid over your world and determine what cell each actor is in), I wonder if there's way to use BFS in a maze-solving manner to calculate shortest path between a given actor and the target you want to check visibility for, and if the distance in blocks/tiles returned by BFS/pseudo…

Well, the world is destructible, so when there is a small hole (of dynamic size) in a wall, then a enemy bot should really only see the player, if there is no rubble blocking the path. Meaning tiles are waay too big for my simulation and raycasting the most straightforward way, also some enemies can evade projectiles and obstacles, but also have to scan them first.

And it works already the way I want it. It could just be more performant, so more details and realism would be possible.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#39

Post by fidotron »

hutzlibu wrote: post #37
fidotron wrote: post #27

Earlier quoted context omitted.

> because the roundtrip js to wasm is expensive. Is this a thing? I've been using ammo (wasm bullet) and while wasm interfacing certainly has a mismatch with idiomatic js I haven't knowably hit a problem with that bridge.

It used to be waaaay more expensive and has gotten much better now. But it still costs, all I know is, that when I do 600 raycasts each, it costs me around 8 ms on medium hardware. Batching it reduces the cost to 2 ms for me. For simple things like GetPosition I did not noticed a perf hit, but for getting vertices I also did. So mid term, I will batch all often used calls into wasm. For now raycasting was the biggest…

Thanks for that! I will have to take a deeper look.

Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)

#40

Post by meheleventyone »

fidotron wrote: post #27
hutzlibu wrote: post #17

Earlier quoted context omitted.

"If you're spamming 1000s of raycasts per frame for your 2d game, there's probably something else going on..." Yup .. but maybe not stupidity, but rather a non generic game. In my case I need lots of raycasts, to determine what exactly the player and the enemy bots can see. Basically I have a simulation in 2D (using box2d directly in js as a wasm libary) - and all the bots and the player only (mostly) get information…

> because the roundtrip js to wasm is expensive. Is this a thing? I've been using ammo (wasm bullet) and while wasm interfacing certainly has a mismatch with idiomatic js I haven't knowably hit a problem with that bridge.

Yeah it’s quite common on most interop boundaries because there is always some amount of marshalling. It used to be a thing in Unity that it was significantly faster to run your own tick for all entities from a manager that hooked the callback from native code than to have to cross back and forth n entity times.

For anything you’re doing in WASM it’s much better to batch and cross the boundary as little as possible in hot loops. For example a performant renderer wouldn’t translate all the API calls but put together a command buffer to be returned to JS and then forwarded to the API in one go.

Post reply on HN