News

A longer video clip for this week’s BuGS update.   I have implemented a chunk of the game logic.  Now, when I press ‘g’, it starts a game and the first centipede moving at fast speed with 12 segments appears at the top.  A spider is added 2 every seconds after it is killed or goes off screen which is the behaviour from the original game as far as I can tell.  I can “shoot” centipede segments and spiders with ‘c’ and ‘p’ respectively and the score goes up.  When all segments are killed, the game goes to the next level.  The colour changes and new centipedes are added.  The second level has 11 segments moving slowly and one segment moving fast.  The third is the same except the 11 segments are fast.  Then, 2 single segments and 10 slow segments.  Then the 10 segments move fast.  This pattern continues on.  When 40000 points is reached, then we skip the slow segment variety of centipedes.  Ultimately, you get to a level which has 12 fast single segments and the pattern restarts with a single centipede with 12 segments.  All of that game logic is there.

Similarly, the logic for the spider is there.  Like I said, one appears every 2 seconds after being removed for some reason.  Once the score is above 5000 points, the spider moves fast.  One aspect of the spider from the real game that isn’t implemented is that at certain score thresholds, the spider is restricted to fewer rows at the bottom of the screen.  This is on my todo list.

Also, the scorpion is implemented.  It can first appear on the 4th level and appears randomly.  I don’t know the rate from the real game and I am going with 1 in every 512 frames on average so almost one every ten seconds.  I think that feels about right but I can adjust that.  I have also implemented another threshold from the real game.  Once the score reaches 20000 points, 3/4’s of the scorpions cross the screen quickly, 1/4 cross slowly.  So, the scorpion logic is fully implemented.

Like I said, I have a bit more spider logic to implement.  I also need to add logic to add fleas.  There are some interesting thresholds there also, like above 60000 points, fleas drop at fast speed.  I want to add the ability to shoot mushrooms to test out some of that code.  And I want to start tracking how many lives the player has and add a way to trigger a player death.  I think I will do all of that without actually adding the player and the shot stuff.  I have written some collision detection code in the sprite code for those things but that will need to be tested and hooked up.  But it is starting to turn into something which looks more like a game which is really nice.

Thanks so much for all the feedback.  I think when I decided to reveal my project here and then committed to providing a weekly update, it has really helped me to keep focus on the project so I have some progress to show.  I am proud of the work I did this week.  The last couple of weeks may have looked like big steps but they were definitely more incremental.  I was hooking up existing code in many cases the last couple of weeks or tweaking some things.  This week, I feel I added a good amount of game logic which makes me happy.

And I forgot to say that I am still recording these at 2.8MHz on GSPlus.  I haven’t tried this build on real HW but I did run one earlier in the week and it still kept up at stock speeds.  I am still hopeful that the full game will run on a standard GS.  The only thing I am worried about is how costly polling the mouse will be.  Can I use the Misc Toolset for reading and clamping the mouse?  Or are those routines going to be too slow for a 60th of a second frame time?  If anyone has any feedback about what to expect, that would be great.  Thanks.

Source Code

Changes

This week, I only got a couple evenings to work on the code but I was able to implement all of the score code.  When a bug is shot, the score goes up by the “right amount”.  The score is held in two different formats.  One is a 32-bit unsigned integer which is pretty easy to update.  This representation will be used for things like “when the score is >= 60000, the fleas drop faster”.  The other representation of course is a sequence of tiles which have digits in them.  So, when an amount is added to the score, I do the add to both the 32 bit integer and I add the same amount to the tiles.  I don’t try to turn the 32 bit integer into a decimal number because I suspect it is faster to just do the add twice but it does mean I could have a bug in one or the other add routine and the two representations of the score could deviate from each other.  But hopefully not…

I still want to rough out all of the game logic which iterates through all of the levels and starts with the right colour and the right number of segments moving at the right speed.  I can also add the logic for driving the speed of the other bugs based on score thresholds now that I have a score.

The other news is that I am the proud winner of an eBay auction for an ADB trackball and it is currently in Denver making its way to me.  Once that arrives, I will suddenly have a bunch of incentive to start implementing the player…

Source Code

Changes

As far as coding, the only real progress was to implement the code for adding new head segments if the centipede reaches the bottom of the play area.  You can see that being demonstrated in the video.  I shoot all but one segment.  Because it is the last segment, it accelerates and I let it reach the bottom.  Once that happens, then single head segments are randomly added on the left and right side until there are up to 12 segments on the screen.  There are some oddities in this video clip that I hadn’t seen before like segments passing through each other.  So that is a bug to track down.  But this is another piece required for the game.

Other than coding, the main thing I did this week was research.  I played and recorded a number of games using mame on my Mac.  And I watched some videos of other people playing the real arcade on YouTube.  The goal was to try to figure out the rules around things like when do the spiders and fleas go fast, when does a flea appear, when does a scorpion first appear, and other things like that.  I also read a few strategy guides for the game which had some of this info.  There are multiple variants out there where these things are different, probably to play with the difficulty of the game.  But I think I have all of the basic rules down for these things.  I have created empty score.s and level.s files where I will start to implement some of this logic.  So that is where I go next.

Source Code

Changes

I worked on the ability to shoot centipede segments.  I still just have keys on the keyboard tied to adding different bug types and shooting them.  It randomly picks a segment and shoots it.  The segment explodes and turns into a mushroom as in the real game.  When only one segment is left, it goes fast again like the real game.  This weeks video focuses on shooting bugs.  When a scorpion is shot, nothing special happens other than an explosion.  When a flea is shot, it goes faster until it is shot a second time and then it explodes.  And segments are seen being shot in the video.  This is again 2.8 MHz.  So that is the progress for this week.

I still want to make it easier to define what segments to add with what levels.  And now I could add the code to “play the game” except without any actual player.  I could proceed through levels and auto-shoot bugs using the keyboard with everything game-wise just happening as it would in the real game.  Then, I need to add the player, score, sound, etc.

Source Code

Changes

This video may not look too different from the last one but there are a number of new things.  Note there is a 11 segment slow centipede and a 1 segment fast centipede.  So, it now supports drawing two centipedes running at different speeds.  Also, you will see that the single segment centipede detects when it runs into a segment on the larger centipede and it changes direction.  In general, head segments will detect when they collide or are about to collide with another segment and they will change direction.  Once everything is at the bottom, things are very chaotic and they end up packed into a small space so collisions are happening all the time and there is lots of direction changing but I think it is behaving correctly.  Finally, there was a problem where head segments did not always detect a mushroom and change direction last week.  That is fixed.

Next, I have more centipede work to do.  I want to add code to support shooting centipede segments.  Also, when only one segment is left, it needs to accelerate to fast speed if it was going slowly.  Once a centipede segment reaches the bottom, single segments start to randomly get inserted on the side until up to 12 are on the screen.  That reminds me, I did test with 12 head segments all animating independently and it worked fine at 2.8MHz which I was worried about.  The other thing I want for centipede code is to be able to describe what kind of centipedes to add at the start of the level as data.  Right now, the two centipede you see in the video are “hard coded” as a 11 segment and a single segment, two different speeds, entering at those points.  I want it to be a bit more generic so I can vary it easily between levels.  So that is next week.  More centipede work.

Source Code

Changes

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.

Source Code

Changes

I have written the code to animate the centipede segments at least at slow speed.  Double speed centipede segments are not implemented yet. The code is also there to animate the body segments which follow the head.  I used a ring buffer so whenever I figure out where to put a head segment, which way it should face etc, I keep that around in the ring buffer and body segments just update an index into that buffer and use the stuff already calculated for the head segment.  Should work but ran out of time to test it so you don’t get to see that this week.  This clip is running at 2.8MHz.  There are a couple of odd things.  At one point, a hidden mushroom appears when the centipede segment gets close.  This seems to indicate a bug in the flea code.  I suspect the flea left the mushroom behind but didn’t mark the tile dirty so it didn’t get displayed.  Also, the head segment goes a bit nuts at the end and just cycles up and down in a couple of tile columns.  Not sure what that is.  So, the next step is some bug fixing of what I did this week and maybe try to display some body segments.

Oh and I haven’t coded anything to handle a centipede contacting a poison mushroom so that is to come also.

I withdraw my “hidden mushroom” issue.  There is a flea dropping as the centipede passes.  The flea drops the mushroom so it isn’t a mushroom appearing for no reason.  I have the flea, spider and scorpion running at fast speed so the flea flashes past so fast compared to the centipede that it looked to me at first that the mushroom “just appeared”.

And I found and fixed the bug which makes the centipede drop to the bottom of the screen as though it is poisoned.  The issue was one of comparing “number” versus “offset”.  My check for the LHS or RHS of the screen was looking for a tile number (incrementing by 1) but I had a tile offset (incrementing by 2 to use as a word index into arrays with tile info).  As soon as the centipede got low enough on the screen, every tile was considered to be the edge of the screen and it just dropped straight down thinking it always had to change direction.  Adding the missing *2 in the comparison fixed it.  So, no known bugs left now and on to sleep and more features for next week.

Source Code

Changes

I didn’t get as much time this week to work on it as I wanted but I did implement some of the ideas from last week’s discussion.  I changed the array of structs to structs of arrays.  This was a minor win really since I did a bunch to reduce the cost of the old implementation already.  The big change is that I implemented the code to redraw the dirty tiles right after the beam.  I am using the vertical counter in $e0c02e and $e0c02f to do this.  By doing this, the background is already redrawn by the time the beam hits the bottom and I only need to draw bugs and update game state before the next frame.  With this, I am almost smooth again on 2.8MHz.  This is 2.8MHz on GSPlus.  I haven’t tried it on real HW yet though so buyer beware.

Source Code

Changes

Well, here is a video of it running.  This is 8MHz on GSPlus.  It also runs well on my real HW with a Transwarp GS.  But adding the centipede drawing pushed me over the edge for 2.8MHz.  Until then, I had the flea, spider and scorpion drawing well.  Also, I am not actually moving the centipede yet, just animating it in place.

Source Code