I had last Friday off ( sssshhhh.. I was sick \m/ ) so started testing out Flixel Engine.
Here's a video of what I did.
PS: Frame jerks are because of the screen-grabbing. It actually runs pretty smooth @ 60 FPS.
Sprite Credits - Original creators @ Konami, then guys @ nesmaps.com and nes-snes-sprites.com for ripping em.
My first take on the engine and it's flexibility:
Pretty cool features - I didn't have to write too much code for this. It took me just 3 days to rig this whole thing up. All i had to do was create 3 classes. I must admit, there are not many "valuable" tuts around that give you an insight, but the EZPlatformer demo did pave the way. But to be noted - I spent around 2 days for my classes itself (player state management and collision detection) and around 4 hrs to get the hang of flixel itself.
The feature I loved the most was "follow". You can ask the camera to follow a Sprite (in this case my "Player" that extends from FlxSprite).
The part what I didn't like - so little info about FlxTilemap. It seems to have so many methods for me to use - but couldn't get anything working. It may be simple for off-the-shelf platformer but this was a little different. I didn't want collision from all the tiles, and I wanted different behavior when collision occurred across Land, water, etc and I wanted the fall-through.
So finally I decided to use my own Collision detection. Was it easy? Piece of cake - at least for this. Everything worked with just AABB systems.
Here's how I went about it -
Iteration 1:
Decided to create rectangles with "Type" information from my previous editor. Went smooth. I got about 50-55 FPS. (around 300 rectangle-intersection tests per frame)
Iteration 2:
Since this is a side-scroller and same "Type" of tiles extend for a while, I thought I could reduce the count of rectangles by combining the neighbors. So 5 rects of same type next to each other become 1 rect with combined dimension (horizontal only). So the count reduced to 51 \m/ and I got around 55-60 FPS.
Iteration 3:
Why waste all tests when only part of the screen was visible? (Yeah yeah.. octree and quadtree concepts). I created a "Shell" class that encapsulates the rectangles. I set a threshold like 10 - so it will create 6 partitions to hold these 51 rects split by their X co-ordinates. (yeah.. very simple one to start off with). If the outer-shell collides then it checks those inner rects for collision. Some logging revealed an average of 10-20 collision tests (reduced from 51).
[Best Case: When player is in the air - 51 tests reduced to just 6]
However FPS remained the same - around 60. Not much of an improvement -optimization outcome reduces exponentially x_X
Too much text, I'll stop. Hope to post my Player state management soon. It was more fun than this ( pinky promise ).
But here's something to ponder ( always makes me go WTF ) - The original Contra by Konami was written (probably) in Assembly Language and optimized for 8-Bit machines and the game play was still out of this world \m/