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

71–80 of 83 posts

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

#71

Post by db48x »

bluescrn wrote: post #64
db48x wrote: post #19

Earlier quoted context omitted.

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.

I learned to code in the 8-bit days where you'd count to 1000 in a BASIC for loop to create a significant delay. I guess I've not got out of the mindset that doing anything 1000x is quite a lot (particularly when you're aiming to do it 60 or more times per second). But as somebody working in Unity (and often on mobile), there's still many cases where 1000 of something is a lot, and should perhaps be cause to rethink…

I agree that profiling is the ultimate arbiter.

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

#72

Post by db48x »

pelasaco wrote: post #52
db48x wrote: post #19

Earlier quoted context omitted.

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.

I don't think how it can be wrong. I wrote a beaten-up game, 2.5D. Player(s) + Enemies + NPCs + Weapons + Bullets.. I can imagine that in some moments, we were easily doing a few hundreds of raycasts per frame.

Raycasts are a very useful tool, and you shouldn’t avoid using them if they’re the only thing that will work. But a _fully general_ raycast is always the most expensive option. For example, an axis–aligned raycast will always be cheaper and might do the job just as well.

The previously mentioned case of doing hundreds of raycasts all starting in the same location but each in a different direction could be done with rasterization instead. That’ll involve a single loop over all the triangles in the world instead of one loop over the same triangles for each raycast. And for NPC vision you could rasterize billboards instead of the full character geometry. You can probably simplify the world geometry too.

That’s all I mean.

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

#73

Post by andrewmcwatters »

kaveh808 wrote: post #62

The killer feature of whatever game engine replaces Unity in developers' hearts and minds is going to be the platform delivery aspect. Once you can press a button and get Win/Mac/Linux/Android/iOS/etc versions of your game built, you're in business. All the higher-level features (3D, ray casting, etc) will be contributed by the community over time.

I think you mean lower-level.

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

#74

Post by Rapzid »

db48x wrote: post #72
pelasaco wrote: post #52

Earlier quoted context omitted.

I don't think how it can be wrong. I wrote a beaten-up game, 2.5D. Player(s) + Enemies + NPCs + Weapons + Bullets.. I can imagine that in some moments, we were easily doing a few hundreds of raycasts per frame.

Raycasts are a very useful tool, and you shouldn’t avoid using them if they’re the only thing that will work. But a _fully general_ raycast is always the most expensive option. For example, an axis–aligned raycast will always be cheaper and might do the job just as well. The previously mentioned case of doing hundreds of raycasts all starting in the same location but each in a different direction could be done with r…

I mean it's game dev, there's always work arounds and efficiency hacks.

But what does any of this has to do with improving the ABI?

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

#75

Post by JuanPosadas »

LarsDu88 wrote: post #46
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…

It's hard to tell without seeing a screenshot or video of the game in question, but there are almost certainly ways to optimize this problem. If there are on the order of even several dozen enemies on the screen at any given time, you could simply maintain runtime sets of different factions and only do line-of-sight checks between hostile groups within a certain proximity. There's probably hundreds of better ways to…

> raycasts getting fired every frame

Also don't need to do this every frame, do X% each tick (not frames literally), rotating which objects get their checks.

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

#76

Post by otto2 »

hutzlibu wrote: post #59
bluescrn wrote: post #45

Earlier quoted context omitted.

The usual solution for something like this is just to spread the work over multiple frames. Most game enemy logic doesn't need running every single frame. Update 10% of your bots every frame. Also consider whether 360 rays is really needed to begin with, one ray per degree sounds like an arbitrary first-pass value. Can you cast a smaller set of rays first, and only cast the in-between rays if certain conditions are m…

"Can you cast a smaller set of rays first, and only cast the in-between rays if certain conditions are met " Yes I can do this. But my case is really special as in basically the players have to do this by themself. As it is (also) a hacking game, meaning they have a limited scan budget and need to figure out to spend it the most useful for their bots.. but since they also want to evade projectiles and other bots, the…

You can still optimize this. If the scan has to establish line-of-sight between bots, your engine can establish that, and when firing raycasts, to skip those that are known to be misses. It doesn't change anything for the bot that fires raycasts. You could also calculate extremes (leftmost and rightmost) and return positives in between. This would decrease number of raycasts by two orders of magnitude. Also add a possibility to skip every 2nd, 3rd etc frame so that you can evaluate if it impacts game play.

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

#77

Post by hutzlibu »

ehutch79 wrote: post #69
hutzlibu wrote: post #35

Earlier quoted context omitted.

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

Wait. I was thinking 1000s of objects doing raycasts.

Ideally yes, this is what I would like to do, to be able to control armies of bots. So because of the limitations, there are only 2-3 smart bots and lots of dumb ones.

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

#78

Post by imtringued »

>Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense.

Yeah but you have a 32 bit data type and a packed 32 bit array, so why not have the same for 16 bit? Not just that, there are also SIMD operations that work better with 16 bit numbers.

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

#80

Post by davidgerard »

jmull wrote: post #9

Strong response. I'm not sure I would have been so generous to the author of the article this is in reply to. But I suppose that's a skill of a successful open source leader -- to turn interactions with critics into productive discussions rather than arguments, and perhaps even turn the critics into supporters. It seems to have been that author who chose the FUD-ful title "Godot is not the new Unity". I guess there a…

The original author is also diving in to help with the problem he saw, which is an ideal outcome for a bug report from a new user.
Post reply on HN