29th of April – Damn – I can’t give up…

One score number blinks for one frame quite a bit to the upper left.

You see that?

That’s from the video I posted yesterday.

GLITCH!

I went on another hunt. Sorry glitch – I said you were a feature – but I still do not like you.

I can tell you what it NOT is.

• It is not some sort of “wrong” zeroing of the integrators. I implemented a special Vide – breakpoint for that. All zeroing is done exactly right. And actually – there are only a couple of places where zeroing is happening and they are easily checked.
• It is not that wrong coordinates are used. Nearly all objects (except the spiraling Dragon and the circling Bomber) have FIXED coordinates, they never change – all that ever changes is the scale factor.
• It is not some sort of wrong scaling. If that was it – the “jump” would always be in line with the original (only the radius around the home would change).
• It has nothing to do with the starfield, I switched it completely off at some point.
• It has nothing to do with the internal object list – or a wrong removal of objects. Although that can’t be proven – these routines are 30 lines long, straight forward. Tested under all possible circumstance, watched and debuged. I am absolutely positive – thats not it.
• It is not a wrong setting of VIA CNTL  or VIA AUX. I had that at one point and it looked similar “glitchy”. But I also have now a specialized breakpoint in Vide for that. No wrong values there.

A Hunter glitch “just one step to the left”…

I am almost certain – despite the above said “nots” – that the glitch always occurs when an object was just removed.
See the hunter “glitch”? At the bottom you also see the remnance of an old explosion (15 in the middle) – that was just removed -> and there a glitch.

Also – the Terrible X takes one step right.

Even if I present here quite a few “glitch” pix. There can be litteraly hours where no glitch is happening at all.
If it were some kind of “honest” bug – and it would be reproduceable – I’d found it LONG ago.

Also – the Terrible X takes one step right -2.

Also – it does not seem, that the “removed object” that might be responsible for the glitch – has anything to do with the “glitch” movement. The position of the removed object – or in case of an explosion – a “particle” seems to have no relevance.

Bomber glitch…

As you see – all kinds of objects are subject to the glitch. It does not matter what “enemy” or friend you are.

The biggest glitch I have seen!

I wonder – there were two “scores” removed just befor that glitch (see the dim 42 and 10?) – since the glitch has such a “huge step” – does the width of the glitch have anything todo with the count of objects removed?

The glitch CAN NOT be seen on any emulator I know of. Its a thing of the real thing!

By now (until proven otherwise) – I think it is an as of yet unkown feature of the VIA chip – or some other vectrex hardware.

I will tell you soon why I think that. First let me explain, how (and more importantly when) I used to do my object removal.

Object removal

First – only two object are removed: Explosions and scores – all other object are not removed, but “converted” to (guess what) – explosions and scores.

Within the “MoveTo” call of the explosion I use the time to check whether it should be displayed at all. I have all time in the world there – and if the explosion should not be displayed, because the time is up or it is out of bounds. I “break” the move.

Following is the corresponding code within the “remove”:

The startup code is used to “break” the current move. Most of that is probably not neccessary – but it grew in my desperation.

My suspision now is – despite all that MoveTo – “break” code. The move is not “broken” all the time.
I don’t know if the VIA timer is messing up, the line connecting to the RAMP or ZERO signal or if other internal VIA register have a stalling effect when called after exactly ?? cylces (VIA CNTL or VIA AUX).

Anyway in my desperation – today I changed the “remove” handling.
(every explosion and score now is 3 cycles slower… grrrr…)

Now instead of doing a remove within the “MoveTo” – I set the scale of the next “round” to 0 (zero) and take that as a marker, that the object should be removed. With that I can remove the object relatively “cheap” before the move!

(lta = lda 🙂 )

I have been testing a few hours since – and not seen a glitch.

Of course that sadly does not mean that I have won – since it tends to hide so well.
But if it turns out I got it – I still don’t know what caused it. That is also somewhat unsatisfying.

Lets call it a tie…

Malban