Vectorblade I
Last week …
I could still shoot, enemies appeared – but the shots went thru all enemies. No collision detection.
Also the fighter could not move anymore.
If it had been a “normal” level I would have died, but since it was a challenging stage – all enemies passed by, and the next level started – and everything was fine again.
So tell me – how do you find a bug like that?
You go on a quest – a bug quest, and slay all foes. In the ivory tower back guarded behind a hord of dragons – it lurks.
The solution was:
clr starCount
What happened?
I collected something special and that started the wheel. The wheel is a “break” in the current game scenario – after the break the current game continues exactly where you left. Except stars, stars are random, so I thought I do not have to keep all star information . After the wheel I just did an “initStars()” – and the game (most of the time) just continues.
But.
Stars are dynamic. depending on how much time I have left, I spawn new stars – or remove “old” ones.
What happened was, that the “wheel break” just happened to be when
there was much on the screen, and the dynamic kicked in and removed the
stars that it deemed were to many.
The dynamic “starRemove” is such, that at least ONE star element must be kept.
What I missed was, that “initStars()” does not reset the starCount – so after the initStars() there were 0 (zero) stars present, but the counter still counted 4.
After the initStars() I spawned one set of stars (since at least one must be present).
In one of the first game rounds – the program discovered – “oops I go near the 50Hz mark, I better remove some stars” – and since it thought “hey 5 stars are available – lets remove some”, ALL stars were removed (the one).
The thing is – within the FIRST displayed star object, the player positions are updated (in the inMove section), and also the collision detection is prepared. This is why at LEAST one star must be present!
And so I could not move any longer, and the shots had no collision detection, since they were never “prepared”.
For today – I crown myself “King of debug” – for finding this really obscure and hard to encounter… BUG!
Berzerk
I am nearly finished with my updated BERZERK version – as a final gimmick I asked VTK if he’d like to add a little title tune. He liked and did and so did I.
I gave him a beta version to test – and he said…
“I never liked the robot death sound.” That is just a single BLEEP. Sounds yucky…
I said – “hm, that part is not well disassembled, apparently Fred Taft did not like disassembling sound routines… but I’ll look at it!.
Commenting the sound routines was actually easy going… and while documenting them I think I discovered a bug in the original routines.
At one stage, psg channels 1+2 were updated, but the sound routines actually used 1+3. So I changed BERZERK to update the “corrected” routines – and voila, the death sound of the robots sounds so much better than a simple bleep!
Vectorblade – new VIA
This one was terrible. It took me the better part of a whole day to “find” that “bug”. See – a couple of weeks ago I bought a new “cranky” Vectrex. Last week that one started to show strange behaviours. Due to the nature of the behaviours I thought… VIA – probably about to break.
I have a couple of new VIAs lying around, so I breathed new fresh live into the Vectrex – and yes it works again fine (and is still cranky).
Than yesterday – out of habbit – I played a round of Vectorblade – and what happened? During a warp failure, I killed one of the warp aliens – and CRASH. The game hung up – and I couldn’t do anything anymore.
After hours of debugging, and writing test routines… I was not nearer to any sort of discovery than before.
After a while I tested “old” versions (now and than I save all Vectorblade source code) – and lo and behold – a version from the 29th of Janurary didn’t crash.
Strange! From April to June beta testers played Vectorblade for hours – and nobody discovered any CRASH?
What followed was comparing old/new routines and steppings and and and…
Actually I can’t 100% pinpoint the problem – but the gist seems to be:
My new VIA!
Again – that bastard behaves differently than all other VIAs of mine (and the testers)!
It seems this particular VIA can stall the Timer 1. Either it disables the interrupt generation or it sets Timer 1 Hi to a large value (I didn’t wait 20 minutes to test it out… but I rather suggests that it is the interrupt anyway).
A little writing about the circumstances when this bug appeared:
a) all move and many draw routines are finished with a loop that checks whether Timer T1 has run out. T1 active means the electron beam is still moving, when the T1 timer reaches zero, the moving is finished – a very easy test
b) usually you wait before you start a new timer
c) The “smartdraw” routines I use do not check the timer T1 while the object is drawn, they are programmed in such a way, that they implicitly NOW how much time is needed/passed – and exit always correctly
d) always, – EXCEPT when an object is exploding – than the timer used to draw is on purpose larger, than the routines are written for. This enlargens and deforms the objects – that is my explosion
e) such an explosion has X steps, from the “normal” scale to a final explosion scale (about 15 steps or so)
Now…
The warp failure alien, when that explodes… in the fourth step of enlargement of the explosions, the last vector… sets as usual the “greater” scale. The complete object is finished with a T1 interrupt flag loop.
But with my new VIA that loop never exits – in that particular instance anyway!
(I checked, that is really the only instance in all explosions, and with all sprites I use – there must be an absolutely terrific timing coincidence here!)
THAT was a bitch to debug, no emulator ever will capture something like that.
I found it – and the solution is very easy – just leave out the wait loop.
The scale the functions are built for is “7” – which means, the whole loop is nonesense, since it NEVER loops anyway.
Nonetheless this “fix” is something I don’t like, because I still don’t know what EXACTLY happens, and how to REALLY circumvent it…
Vectrex programming is … “!”&%$”&!$!!!”