News

http://www.rand-emonium.com/2021/02/11/bugs-version-1-0-released/

BuGS

Thanks everyone for all your support here on this channel!

Source Code

Changes

This version has a change that preloads the sounds from resources into main memory after the initial screen is shown.  It used to do that at the beginning of the first game which introduced a long delay when starting that first game.  Now, responsiveness is better.  Also, there is more in the readme with a number of acknowledgements.

Source Code

Changes

The changes since v0.9.5 address some typos in the readme.  Also, @roughana suggested adding borders on the left and right side of the screen to delineate the play area from the rest.  I have added those and I think they look pretty good.

Still racing towards a v1.0 at this time I think so feedback definitely welcome.

Source Code

Changes

This release should fix the “magical appearing mushroom” bug from the previous beta.  I have written a Readme file which is part of the distribution which describes issues with emulators, track balls, stereo cards, etc.  It also includes support for Speccie’s Versions application to make network based updates possible.

I think this is a v1.0 candidate and feedback definitely appreciated if you find any issues that should be fixed before that milestone.  Thanks everyone!

Source Code

Changes

The primary change is a fix for how sound samples are started.  Prior to this, I thought the sound was “muddy” on real HW.  The root cause was that I wasn’t ensuring that the DOC was free when trying to write to it and now I am also doing a read check to make sure that the change made it under most circumstances.  That ensures that both left and right channels are started and the sound is much better.

The only bug I know of which I am tracking is the “mysterious appearing mushroom” bug.  There are times when a mushroom seems to appear out of no where.  I added some debug code to try to find a situation where a mushroom exists in the tile data but not on screen which is one way this can happen.  But the debug code was never triggered so I don’t think that is happening now.  I can’t reproduce it reliably and see this once every 5 or 6 games.  But if you see it have any idea of how this is happening, it could help me find and fix this bug.  Thanks.

I believe I have found the mysterious appearing mushroom bug last night.  The problem was that a centipede segment which is mostly offscreen was supposed to be marked as occupying an off-screen tile.  And that should ensure that collisions are not handled and some other things like that.  But, I messed up the offscreen tile.  I have tile numbers which are in increments of 1 and tile offsets which are in increments of 2.  I should have put in a tile offset but I instead used a tile number.  That meant that the offscreen tile actually mapped to the middle tile on the game board (it was half of what it should have been).  Then, if you happened to “shoot” an off-screen segment right as a level is starting, it would lead to a mushroom appearing on the centre of the screen.  By fixing the tile offset of the offscreen segments, I was no longer able to reproduce it.  The next beta build should have that fix in it.

Source Code

Changes

I have some bad news that my prediction that work was going to distract me has come true.  I only got one evening this week to work on the game and I pushed forward with support for two player games.  But I don’t really have anything of substance to show this week – just work in progress.  And my schedule looks pretty full this weekend.

I am committed to getting a v1.0 though.  I will negotiate a deal with my spouse to get one or two days next weekend to try to focus on it assuming that my evenings continue to be burned during the week.  Thanks for your patience.

Source Code

Changes

I don’t think I will post a video this week since visually, there isn’t too much new to see.  And there is a pretty good build out there so if you want to see what it looks like, give it shot.  Of course, the big effort this week was to fix the mysterious crashing bug I had and thanks to the support here, I believe it is addressed.  I have started work on two player support since then.  When you use ‘2’ to start a game now, two players are initialized and internally there is a playerNum value which tracks which of the two players is playing.  If I force that value to be set to player 2 at the beginning of the game, I can play through a game as “player 2” and the right score and lives counters are now updated.  But this work isn’t done.  I actually have to implement the code to swap back and forth between the two players, prompting whose turn it is, handle the case where one player dies quickly while the other player perhaps has multiple extra lives and continues to play for a while after the other is done.

Work is threatening to get much more busy so I am considering deferring the online high score list for a follow-up v1.1 or v2.0 release and declare v1.0 without that feature.  I worry that I will end up distracted and not able to finish if I don’t focus on achieving v1.0.  Once that is done, if work doesn’t distract too much, I can try to implement the online high scores and my daughter has offered to do the server side work and that is good experience for her.

Source Code

Changes – none since last status update

I found the crashing bug I was experiencing and I believe it is fixed with this build.  And I believe it also explains the other crashes people saw on other configurations.  The problem is that the sprite code is in a different bank from most of the other code.  The player and shot sprites try to write to a pair of words to describe a collision if any is found during the draw.  These were defined to be in the same bank as the sprite code but the data bank register was incorrect.  So the writes happened to the wrong bank and what happened to be there got corrupted whenever a player or shot was drawn.  On my machine, that was tileBelow data.  I have fixed the writes so they happen to the correct address and I can no longer reproduce the crash and the code looks right to me.  So, this build should be better.  Thanks for everyone’s help.

The wrong bank was leading to the flea smearing across the screen.  What was happening for me was the the tileBelow array was getting corrupted.  The flea animation uses tileBelow to figure out what tiles need to be marked dirty and need to be redrawn based on the flea’s changing position.  Because tileBelow was corrupted, the wrong tiles ended up being marked dirty.  That meant that the flea was not being erased anymore between frames so it smeared down the screen.  Worse, the flea detects it has reached the bottom of the screen when the tileBelow says that it is an invalid tile offset.  Because the tiles that the flea is tracking are no longer correct, it doesn’t detect the bottom of the screen and the flea continues animating beyond the bottom of the screen, corrupting the SCB.  Basically @digarok nailed it when he said that there was off-screen writes happening.  I just needed to figure out why that was happening because the flea code should make it impossible, as long as the tileBelow data was correct, which it wasn’t.

Source Code

Changes