3 ms·
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
by pelasaco 3y ago
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.
- db48x 3y agoRaycasts 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.
- Rapzid 3y agoI 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?
- db48x 3y agoThe original complaint was that Godot’s C# bindings have a raycast method that returns a dictionary. The reply article point out that this is a legacy of an earlier, less performant, C# implementation and that the work to clean it up was already under way. My point is only that raycasts are already something that you want to avoid; the extra work of allocating a dictionary each time you call it is unfortunate but not fatal.