I got the centipede animating correctly. I can animate a centipede with multiple body segments smoothly with spiders, scorpions and fleas coming continuously. The movie shows the emulator running at 2.8 MHz. There are two speeds for the centipede in the game and this is the slow speed. You will also notice that the centipede touches a poisoned mushroom and drops to the bottom of the screen as it should. Then, it moves left/right and up/down at the bottom of the screen as it does in the game. If not for the poisoned mushroom, it would have moved down row by row until reaching the bottom.
Next step is some more refinement of the centipede code. I need to support a slow centipede on screen at the same time with a fast centipede. Nothing I have done precludes that but I need to add the code to handle it. It is a bit tricky also because the slow one takes two extra frames to enter the game from the top and after those two frames, the fast centipede needs to enter. I also want to test with 12 independent centipede head segments. That is the worst case performance problem. Bodies are easier to update because they just follow the head segment. If there are 12 head segments then each frame, those 12 head segments need to be updated.
Also, you will notice that head segments don’t care if they run into and animate on top of other segments. The game doesn’t work like this. I have to add some tile information to try to detect these collisions and make the head turn around if it runs into another head or body segment.
Finally, I want to add the code to handle shooting the centipede segments and turning them into mushrooms as happens in the game. Not sure I have ever demo-ed it but I can “shoot” the scorpion, flea and spider. I use “s” to add a scorpion and then “S” to shoot the scorpion. Similarly, f/F adds/shoots fleas and p/P adds/shoots spiders. I have c set to add a fixed configuration of a centipede (single head and 11 body segments right now) and plan to have C hooked up to shoot a random segment. That way, I can test that part of the game before I add the player. So, that is where I am at this week. More centipede work to come.
The thin white lines in the middle indicate the game was re-drawing dirty tiles above this point for the next frame. There is a light blue line about 3/4 of the way down which is the draw routine for the scorpion. The other colours are for drawing the flea, spider and centipede. The orange is the final bit which is an update step where all of the active sprites are updated internally to figure out where things should be for the next frame. That tends to be at the top of the screen and after a short delay (or not), it starts chasing the beam again and redraws the dirty tiles from the previous frame with the thin white lines on the border showing the cost of those redraws.
It is just a way to visually get a sense for what is taking the most time. With the centipede at the bottom, there are lots of dirty tiles so the last few rows of tiles are pretty costly so that is much of what is seen on the screen. The border colours for drawing some of the other bugs don’t appear at all much of the time because it happens between frames entirely. The big improvement in performance was getting the tile redraw happening right after the beam so that for the most part, once the beam gets to the bottom of the screen, the background is fully redrawn for the next frame. Plus the scorpion is redrawn because it is always in the top 3/4 of the screen. Once the beam gets to the bottom, it only needs to draw the flea, spider and centipede segments and then start figuring out what the next frame will end up looking like.
Sound will be the final thing I do. I plan to have a fully playable game that is oddly silent first. Honestly, I have never done any sound programming on the GS so when the time comes, expect to see me here asking questions. Of course, I have never drawn to the screen of the GS directly and always used toolbox routines before this. And I have never done a pure assembly project on the GS. In the past, it has been pure C or C with a bit of assembly mixed in. So, this project will be a series of firsts for me.