On Wednesday, 15 July 2015 at 12:34:18 UTC, Ola Fosheim Grøstad
wrote:
When I say "game dev", I actually mean engines for demanding
interactive audio-visual applications for mobile and desktop.
That could be custom sound editors, video editors, paint
programs, computer games, art installations, information kiosk
applications, interactive simulations, educational software etc.
Though they are not as demanding interactive as shooters (maybe
except for realtime interframe, but that's a video playback, not
an editor). So what's true for shooters may be not true for other
games. My point is if you care about market adoption you should
look at numbers and should not overlook sizeable targetable parts
of the market.
On Wednesday, 15 July 2015 at 09:05:07 UTC, Ola Fosheim Grøstad
wrote:
Yes, I think one only need a local GC for gameworld
objects/NPCs/AI/scripting, so a GC could be limited to a
specific graph/allocator right after execution when the memory
is hot (programmer guaranteeing that there are no unregistered
external pointers). It could indeed complete quickly for many
game worlds.
This would work for request-response services too. Notice that
memory allocated during request usually doesn't live longer than
the request and requests are independent. But it's less pleasant
than jvm and .net that just work in most realistic scenarios and
do it reliably.
