After last weeks slapdash introduction of the player and the performance hit from the toolbox call and some non-optimized work on my part, this week that is all cleaned up. We are back to smooth operation at 2.8MHz and full X/Y motion on the player. I eliminated the toolbox call to poll the mouse and coded something based on what John sent last week (thanks!). The video shows the player moving around in all directions. But there is more work to do in this area. The player is not blocked by mushrooms. I do have collision detection code in the routine which draws the player to the screen but it is untested and not hooked up either. Shooting is still all faked out. But it kind of looks like I am playing a game. The other big change is that I used to have some C code which ran at launch which built a bunch of static tables and this took a few seconds to execute at 2.8MHz (less that 5 I would estimate). The plan always was to eliminate that and replace it with some codegen instead. I needed more tables for the mouse code so I did that work this week. There is no table generation on launch any more. Now, the tables are generated by a script which produces a couple of .s files which are assembled and linked into the project. I may need some more tables for efficient collision detection also but at least I have the scripts now for that.
The next thing I am going to tackle is the code to block the player from passing through mushrooms. This will be an interesting algorithm to code. I will need to traverse the set of tiles crossed by the mouse delta and detect non-empty tiles and block further motion in that direction. My current plan is to first try to apply a small part of the delta to end up tile aligned. Then, move in the X or Y direction based on which has the largest remaining delta one tile width unless blocked. If blocked, try to move in the other direction one tile width (or whatever remains of the delta). I also want to look at the real game and see if I can see it capping the speed of the player. It would be great if the player could only move 8 pixels in a single frame because then the player would only move into one new tile maximum in any direction making the algorithm easier. But if I do that, fast motion on the mouse would be reduced on screen and that could lead people to needing to pick up the mouse because it is physically moving in some direction more than it is virtually on the screen. Some testing on real HW will be needed to see how it feels.