Leprechaun, player movement musings
So, I've reviewed the source code and re-aquainted myself with it. Since the kernel and the sort routines are working, my next focus is on player movement. From a code perspective this will turn into a bunch of IF statements, but first I need to come up with the truth table to ensure no conditions get missed. I'm doing this in a spreadsheet. Each row is one set of conditions. I take a generic condition (e.g. Grid = open) and break it into two conditions (Grid = open & Grid_Down = {Gold,Open,Hole,Rope} and Grid = open & Grid_Down = {Dirt,Rock,Ladder} ) then assign results to each (falling, & more conditions required).It's going to be interesting to change this into code, but it make sure I don't miss any possibilities and have thought through each "what happens if".Right now my plan is to handle player input/enemy AI & movement on a round-robin basis. So each frame only one sprite will move. The only exception to this is falling, which will be handled via a sprite index counter 180 degrees out of sync with the main counter.Now, the main disadvantage of handling it this way is both the player and the enemy will move at the same speed. The alternative is to use fractional positioning and move every sprite every frame. But that may be tough to sync with handling player input & enemy AI only every N frames.The reason for doing the player input & enemy AI only every N frames is to save clock cycles. Since I have to decode the bitmap for a lot of the decisions, that's going to take a lot of processing power.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
2 Comments
Recommended Comments