
Originally Posted by
SSkilly
Projectile collision is fine as is, I'm highly doubtful that porting it to work on the GPU would improve anything, would probably make things slower, simple distance checks are very fast calculations.
gpus are extremely fast on simple calculations, which is what collision is. a simple compute shader would greatly increase speed, granted that you batch upload easily usable data (hitboxes, positions, entity types) and do sanity checks on the end result, instead of each entity that's being looped.
it's not the distance checks that are the issue, it's the fact that projectiles are collisions are checked every update which then loops through the visible entity lists, performing checks on them. multiplying that by 250 (50*5, 50 projectiles, 5 tps (prod and many pservers), typical for a mbc fight with ally projs off) means that you have to have a 0.0668ms gethit (not counting the rest of the thread, the actual number is likely much lower due to c3d/r3d taking up a big chunk of cpu) if you want to keep 60 fps. that being said, this is mostly an issue for old pcs to compute or if you wish to push fps into the high 200s on newer pcs.
multithreading with workers might be an alternative solution, haven't tried as it looks pretty scuffed. (having to compile separate .swfs and run them in bg)
mentioned optimization ideas both as you said you were working on it past release and also for other people, as people who would go out of the convenience of just using an 'easier' source for fps might also welcome them. also mentioned that going too hard on optimization in flash might not be a bright idea, as at that point you could just port over to unity with nearly the same effort for more fps, tools, support.