2020-11-17:
I am jumping the gun on the weekly update and issuing an update in the middle of the week because I have a game that works more or less. There is no sound and some weird issues to figure out. But I have been playing actual games tonight and it is kind of working. It is hard and seems harder than the original. Part of that I think is because the play field is 25×25 tiles on my version but is 30×30 on the real game. Makes everything cross the screen that much faster. But this is a major milestone on the development of the game.
2020-11-13:
I planned to work on blocking the player from passing through mushrooms but I decided against doing that. Instead, I added the code to manage the number of lives the player has and detect collisions between the player and a bug. Also, every 12,000 points, an extra life is added. In the video above, I hide the player on the bottom left corner and then “shoot” bugs to get 12,000 points. You will see the extra life added. Then, I crash the player into bugs until all the players are used up and the game ends. Finally, I start a second game. So, the mechanics of the player’s lives is there now.
I did investigate the way the player moves in the real game. It looks like the player moves a max of 4 pixels per frame. In my code today , the player can move up to 63 pixels in a single frame or almost a third of the play width. I am considering dividing the input by 2 and capping it at 8 but I will need to see how that feels. I am concerned about requiring too much motion from the mouse.
Also missing in the above is that when the player crashes into a bug in the real game, the bug explodes but doesn’t increase the score. I need to figure out which bug the player collided with and make it animate an explosion while leaving the other bugs stopped. I will need this code anyway if I want to allow actual shooting which may be where I go next anyway.
2020-11-06:
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