Weekly BuGS Status Update

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.

In terms of the build, I am using the infrastructure here: https://github.com/jeremysrand/Apple2GSBuildPipeline

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…

Source Code


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.