←back to thread

163 points mariuz | 1 comments | | HN request time: 0s | source
Show context
bengarney ◴[] No.43617928[source]
Really interesting analysis of where the data lives… cutting 3-4 textures would save you more memory even in the 100k actor case, though.
replies(2): >>43618098 #>>43618115 #
cma ◴[] No.43618115[source]
If the memory savings he got were fully read or fragmented with other stuff on cache lines that are read in every frame (not likely for static world actors), it could be ~10% of CPU memory bandwidth on mobile every frame at 120hz on an lpddr4 phone.

A big problem with them is they are so heavyweight you can only spawn a few per frame before causing hitches and have to have pools or instancing to manage things like bullets.

I think in their Robo Recall talk they found they could only spawn 10-20 projectile style bullets per frame before running into hitches, and switched to pools and recycling them.

replies(2): >>43619650 #>>43623175 #
teamonkey ◴[] No.43619650[source]
Pooling is pretty standard practice though, it would be the go-to solution for any experienced gameplay programmer when dealing with more than a dozen entities (though annoyingly there isn’t a standardised way of doing it in Blueprint).
replies(2): >>43619995 #>>43625933 #
1. dijit ◴[] No.43619995{3}[source]
To be completely fair though, blueprints themselves are oft-maligned for performance.

They're fantastic for prototyping, but once you have designed some kind of hot-path most people typically start converting blueprints to code as an optimisation.

In such a scenario adding pooling becomes a trivial part of such an effort.