This week, I fixed up some bugs I mentioned last week with the “can shoot” indicator leaving some dirty pixels behind and the spider misbehaving on player death. But I also did a fair bit of play testing and added more issues to my bug list. I also worked on sound. I have sound for the flea and the scorpion working now and you can hear them in the video. Also, I added code for stereo. The sound of the spider, scorpion, flea, player shot etc is panned left to right based on their position on the screen. I found quite a bit of inconsistency about whether channel 0 is left or right. The emulators I am using (GSplus and mame) say 0 is left but Apple’s docs say the opposite. Specifically, GS tech note 19 says that even channels should go to the right and odd to the left. The documentation for the 4soniq also says that 0 is left. It seems like my ancient sound card though treats 0 as right. I may have to take a soldering iron to it. Is there real inconsistency out there among the sound cards? Maybe I need to make L/R configurable which is annoying.
And as a Christmas present to everyone on the appleiigs channel, here is v0.9 of BuGS. This is not a bootable image, just the executable. If you are using an emulator, I suggest using mame. I am using “apple2gs -skip_gameinfo -mouse -window -resolution 1408×1056 -ramsize 4M -sl7 cffa202 -hard1 <boot image>” as my arguments to mame and that is working for me. It does work under GSplus but the mouse control isn’t ideal and you will probably find it frustrating. I haven’t tried other emulators. I have tested this on real HW and it seems to work there although the sound is decidedly more “muddy” than I get on emulators. Keep in mind this is a pre-release build and there are known bugs that are documented here: https://github.com/jeremysrand/BuGS/blob/master/BUGS.md
My next step needs to be some more bug fixing and some more play testing!
This week, I got rid of the calls to the free form synthesizer functions in the sound toolbox. I am still using the sound toolbox to load the waveforms into DOC RAM. But to setup the Ensoniq registers and stop/start playback, I am using the ROM routines for reading and writing to the registers that you get from GetTableAddress. I decided not to hit the GLU soft switches directly but I am programming the Ensoniq itself now. I think the sound is better, especially the rapid fire which stops and starts quickly. I have sound working for firing, killing bugs, player death, refreshing mushrooms after death, the background “beat”, the spider sound and the extra man sound. I still need to add the flea and the scorpion sound. I have a bit of sound RAM left but may need to do some optimization to fit in the scorpion sound and I don’t have a source for it.
Next steps include adding the flea sound which involves adjusting the frequency over time, finding the scorpion sound and adding it. I am on the trail of a crashing bug which sometimes happens at the beginning of a 2nd, 3rd, etc game. It does seem like some memory which is used to track segments on the screen is overwritten with $70 $02 $70 $02. I saw it once and added some debug to find out what is happening and got to this memory corruption. I need to keep pushing this backwards to find the source so I will be adding some more debug to validate things to try to find when this happens at the earliest point.
I would also like to do some work on stereo. Right now, everything is coming out the left. I want to build another table which maps a tile number to a L/R volume. Then, I can have a couple of oscillators playing a bug sound or something like that and adjust the volume on each accordingly. That way, a spider entering from the left or the right has sound which enters from the left or right. Shooting from the left will play a firing sound on the left, etc. I think it shouldn’t be too bad to implement.
Oh, and there is a bug which I am not sure is in the sample above. If you die just as the spider enters, the spider sound may keep playing. I think the bug is that the spider can enter at all actually. I will put it on my bug list right now. Yes, BuGS has a BUGS.md file in the repository which is a bit confusing.
The other bug which is in BUGS.md already is that when the player dies, sometimes the “can shoot indicator” doesn’t get cleaned up. If you look closely at the beginning of the video, you can see a pixel or two of “garbage” on the lower RHS. That is the “can shoot indicator” not getting cleaned up from the previous game when I was making this video. A round of bug fixes needs to come soon too.
I have decided to make the GitHub repository for BuGS public. So if you want to look at the code or try to compile it yourself, go for it – https://github.com/jeremysrand/BuGS
Not sure I will be taking any pull requests right now. Maybe once I declare v1.0, I will be more open to something like that. But if you want to browse the code and send me feedback, I would definitely appreciate it.
I think the pre-requisites are ORCA/C, ORCA/M, Golden Gate, ProFUSE, make and perl. Now, I am only doing builds within Xcode on an Intel Mac. I have some feedback that with some minor changes to some scripts and makefiles, this build infrastructure can work on Linux but I haven’t in general ported those fixes into BuGS. Those fixes are in the above GitHub repository so if you want to build outside of MacOS, those may help get it working. And I would probably accept a pull request to fix the BuGS build for non-Mac platforms if you or someone else happened to have one. At the moment, it isn’t a priority for me but in the medium/long term, it would be ideal if the build wasn’t tightly coupled to any one platform. Let me know if there are other questions or problems when trying to build the code.
And yes, I used perl to generate code. I was planning on using python and to be a “modern coder” who learns the new fangled stuff (not that python is all that new fangled). But when the time came and I needed to implement the code generation, I decided to take the easy path and use a language I have worked with in the past. In my defence, perl is quite good at text processing…
BuGS is not silent any longer although sometimes you might wish it was. There is sound now when you fire, when you die, when you kill a bug and when the mushrooms are refreshed after you die. There still needs to be sound added for the background “beat” which plays during the game, the spider, flea and scorpion sound and the “extra life” sound. I have the sounds for the “beat”, spider and flea but I am not playing them yet. I am still looking for a source of the scorpion and extra life sound. The big problem I have is with stopping/starting sounds. I am using FFStartPlaying to trigger sounds that I have already loaded into DOC RAM but there doesn’t seem to be a way to stop them from playing. As per @fatdog‘s recommendation, I am using 5 generators for the fire sound and when there are many shots in close succession, I use a different generator. But that just leads to multiple sounds overlapping in time and it sounds pretty bad. If I use FFStopSound seems to unload the sound. I tried to change the volume of the sound to “turn off” the previous shot but it seems you cannot change the volume while the sound is playing, at least at this level.
So, I am coming to grips with the need for going around the sound toolbox routines and hitting the ensoniq registers myself to do what I need. That is probably where I need to go next.
This week I finally implemented the code to prevent the player from moving on top of mushrooms. The implementation wasn’t too bad. I look at up/down first and if moving in one direction, I ask if the tile system if the tile the player is entering is occupied. If it is, then I reduce/increase Y to be a multiple of 8 so it is on the previous tile boundary. That tends to be an inc/dec followed by an and operation to be a multiple of 8 which is pretty fast. Because max displacement in a single frame is 8 pixels, that should always do it. Similarly for left/right which I handle after up/down. It does mean that if you move on a diagonal, say left and up and you are blocked in the up direction at your starting point, then you will not move up even if after the left displacement, the up direction is now clear. I could retry the up/down movement after a successful left/right movement I suppose but I think this should be OK. Other than that, I dug into two weird long standing bugs around centipede behaviour that I hadn’t investigate yet. One was related to when a segment is added on the left or right after the centipede reaches the bottom of the screen. If the point of entry is blocked by a mushroom, the change direction code would turn the segment around, facing away from the game screen which was bad. I now ignore obstructing mushrooms when a segment is entering the game screen. The second one was a bug where slow moving head segments did not correctly detect collisions with other centipede segments and change direction. This lead to weird problems where two slow moving head segments could end up stacked. You might think you only had one segment left but there were two stacked. That is now fixed.
I don’t have any other known serious bugs right now and game play is basically complete. The remaining items are high scores, two player and of course sound. I did some searching for samples from the original arcade but I couldn’t find anything online yet. Worst case, I think I can capture some audio samples using mame. But that will have multiple sounds playing concurrently during normal game play so isolating the flea, spider, scorpion, etc sounds will be tricky and annoying. Suggestions definitely welcome. I also spent some time reading docs about sound on the GS. Should I use the Sound Toolset? Or do I need to go right down to hitting the sound GLU registers for performance reasons. Again, wisdom about game sound programming on the GS definitely appreciated.
I had a busy week and didn’t get too much done. I added the code to reset all of the damaged mushrooms after each death so you can see that in the attached video. Also, I added the code to restrict player movement in a single frame to a maximum of 8 pixels. This does make the game pretty much unplayable under GSPlus because the mouse movement is restricted to the size of the host machine’s screen and I was finding it difficult to deal with, even before the capping of movement. So, I used Kelvin’s awesome program Ample to get mame working. I can now launch either mame or GSPlus from my build environment. With mame, I pretty much have to run at 2.8MHz though so boot times are slow. If I run at accelerated speed, it seems like it also accelerates the vertical blank because the game is crazy fast. So, I will continue to use GSPlus for quickly booting a emulated GS and testing things out but when it comes to real play testing, I will be using mame or real HW. The video this week is captured using mame and does show the new “reset all of the mushrooms” after each of the three deaths.
Next, I should finish the work on player movement and actually implement the code for not allowing the player to pass through mushrooms. Now that capping movement to 8 pixels per frame is done, the algorithm for preventing motion through a mushroom shouldn’t be too bad. After that, it is either work on some niceties like high score lists, two player game support, ability to pause the game or maybe it is time to actually add some sound. Depends on how ambitious I feel I guess. In other good news, in order to use up my banked vacation, I will be off work and looking for something to do starting December 12th so I am hoping to focus more on it over the holidays. We will see.
Just a short update and no video today because not much has changed since Wednesday when I posted the previous video. I pushed pretty hard and churned out some buggy code for the video you saw so I spent some time yesterday tracking down some bugs and cleaning things up. I also decided to remove the border colour performance monitor stuff. I may re-add in the future (probably should make it build conditional actually). Finally, I put in some code to update the high score if the game completes with a higher score than any previous in the session. There is no persistence of high scores, nor is there a top 10 high score list. What I actually want to do is save the high scores to a file locally but I hope to add some code using Marinetti to send high scores to a server and have a global high score list. But I will have to ask you all kindly not to hack the high score list because it will be an insecure interface for sure. That feature is at the bottom of the list though.
What is likely in store for me next week is some more bug fixing followed by implementing the “repair all of the damaged mushrooms after death and add some more points to the score”.
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 in the development of the game.
I forgot to reduce my speed to 2.8MHz for the screen recording. This was recorded at 8MHz in GSPlus but I have played games at 2.8MHz and it worked fine. I tried to boot up my real GS and play it on there but my CFFA 3000 is acting up for some reason. I think maybe my CF is bad. Not sure yet but I am eager to get the machine working again and try it on real HW.
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.
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.
This one is less impressive in that I have now exceeded the 60th of a second at 2.8 MHz on an emulator so probably substantially blown the window on real HW. The cause is I did add a call to ReadMouse through the GS toolbox in the game loop. You can see that when the centipede is at the top of the screen, it is often drawn too late and isn’t visible on the frame. So that makes the game that much harder with invisible centipede segments. Now, some of this is my fault. I don’t have good code yet for drawing the player. I am restricting the player to the bottom row of tiles. That way, I just have the address of the scan line of that row and add an offset to that based on the X coord of the mouse. But I don’t really know which tile(s) the player has made dirty so I am marking them all as dirty. Maybe if I optimize this and do it properly, I may recover enough to make it work with the ToolBox call but I am doubtful. What I need to do is generate a bunch of data tables so I can quickly figure out the address of the player to draw at and the 1, 2 or 4 tiles that are dirty because of that draw. If I do that, it will be slightly faster and I will be able to move in X and Y directions. But I still have more code to put in the game loop to block the player from passing through mushrooms, handle shooting and collisions etc. So, I am on the edge of this all falling apart at 2.8MHz. I probably need to go around the toolbox.
Other work this week – I finished all of the bug game logic. The flea is added based on thresholds which change as the score goes up. As the number of mushrooms disappear in the infield, the flea will start to drop. I also implemented the code to restrict the spider to lower and lower rows as the score goes up. And I added code to handle shooting mushrooms. I hooked up ‘m’ to randomly shoot a mushroom. I realize I didn’t demo any of that in this video.
The other obvious thing is the change to the LHS of the screen. I added BuGS branding, moved the number of lives from the RHS to the LHS and put player 1 and player 2 info in there. There is really not any support for player 2 yet but I have centralized all of the information that needs to be tracked per player so I have a way to add that reasonably easily in the future.
Feedback about the new display is greatly appreciated. I am not sure I like the multi-coloured BuGS branding at the top. Also, the lower case u was my own attempt at creating a tile for that so it stands out a bit more like an oddball than I would have liked. Next week, I will need to look at the mouse code. I have already perused the Firmware manual which I am guessing is the right place to go for details.
