Testbed Environment Requirements

[zachwlewis]

Continuing the discussion from Handling off screen entities:

[SOLVED] Handling off screen entities

I’m very interested in finding a way to optimize some aspects of FlashPunk (especially collisions), and had messed with the core many times to make it work seamlessly with my little projects.

But the main thing I noticed is that there’s hardly a single way to get better performance. It will always vary depending on specific cases.

That said, I’m pretty sure some improvements can be done, and I wish we can all work on that. (Already had a couple ideas* floating around for a while and I’m willing to see if they lead somewhere comforting adjective.)

What I ask is to have a little playground to test them, a game-prototype with basic features (camera movement, sprite animations, dynamic scale, not-so-standard hitboxes, etc.), so that we could all try to improve the fundamental functions of FP and make it a bit faster. I know I could try to code the test-game myself, but having a somewhat real one would really help the process (so that actual problems can be addressed). Maybe I’m asking a bit too much… could you/anyone provide it?

Also… Would really be nice to have a github repo with the game-prototype + FP so that it can be forked | modified | improved by the community.

Some have already been proposed/partially implemented but…

• internal viewport/culling
• proximity grid for collisions
• polygon mask (maybe with MarchingSquares as an alternative to Pixelmask)
• layers array -> dictionary
• namespaces
• …

It would be painless enough to create a FlashPunk testbed. What types of tests would be desirable? Off the top of my head, here are some thoughts.

• Large number of same Graphic onscreen
• Large number of different Graphic onscreen
• Large number of same Graphic extending offscreen
• Large number of different Graphic extending offscreen
• Very large Graphic
• Simple collision between many objects extending offscreen
• Very complex collision between two objects onscreen
• Very complex collision between many objects onscreen
• Very complex collision between many objects extending offscreen
• Large number of same Entity that don’t need to update offscreen
• Large number of same Entity that do need to update offscreen
• Single Emitter with large number of particles
• Multiple Emitter particles

Do you see any redundancies or omissions?

[azrafe7]

Yeah, all of the thing you listed are the things I wish to see in a testbed (a graphic one because in this case a unit test seems dificult to code from my point of view).

Plus…

• Have you tried to play Chevy’s Papillon (from some time ago - built in a couple of days but with its problems)
• Have you noticed the mem spike up when changing rooms
• Grids/Tilemaps checking for collisions and rendering outside screen bounds
• Masks/Graphics/Entities with non-standard origin
• …

And then there are some things I’m not quite satisfied about, like having to write four lines of cryptic code to use a MotionTween, but that’s debatable and not regarding performance.

EDIT: To sum up… let’s discuss and move towards the next major version of FP (as is been discussed in some other thread).