It is a good thing I did not fully think this through at the beginning… otherwise I might not have started this “project”.
It gets ever more complicated!
–
Current implementation of “Mode”.
Still in CC (I don’t know why I am holding on to this!!!)
Bits
xxxx MZcc
Meaning:
If M is set (negative flag) than the object is a move.
If Z is additionally set, than the move starts with a Reset0Ref.
cc is the count of moves to be made +1. cc Is a two bit value from 0-3, thus we can loop 1-4 times a move.
(also moves, that do not zero!) – you might see later why I needed this!
Last night I finished with being able to draw an “object” Vectorlist and being able to add “normal” vectorlists.
Today I started with a simple “zoom”. Just adding/subtracting “1” to each coordinate in respect to the quadrant they are on screen:
I 1 I 0 I ----------- I 3 I 2 I (y,x) 0: +1, +1 1: +1, -1 2: +1, -1 3: -1, -1
Thus zooming out from point 0,0!
This very fast went haywire – naturally, vectors positioning went over 8 bit borders, and vectors were moving off screen. The logical step was to implement some checks/splits….
Global positioning check (off screen)
Using Y,X registers to keep track of global position for Y,X position respectively!
Definition of out of bounds:
MAX_SINGLE_POS EQU 100 ; must be smaller 127
MAX_GLOBAL_POS equ (MAX_SINGLE_POS * 4) ; must be smaller 127*4
The global max value must be thus, that the screen edge can be reached with 4 moves (4 moves are by now the maximum the move counter can hold). Additionally to a 4 loop of moves we have the option to have one additional “correction” move. The correction move is necessary for exact positioning. Since we may need to “split” up the quad move into two seperate quad moves by “halfing” them.
-> If one halves something, there “might” be a remainder…
8bit Zoom adds!
These are stupid!!!
Since the vectors can be to large or to small after a “zoom”, I have to check them, and react on them being out of bounds.
Is there an easier way to add “one” to the coordinates than:
; handle Y coordinate lda Y_POS, u bmi y_negative adda #ZOOM_VALUE ypositiveOk bra y_store y_negative suba #ZOOM_VALUE y_store sta Y_POS,u ; handle X coordinate lda X_POS, u bmi x_negative adda #ZOOM_VALUE bra x_store x_negative suba #ZOOM_VALUE x_store sta X_POS,u
Also:
There are two out of bounds variants, the value can either be too large or to small
(> 127 or < – 128 – or whatever boundary I chose).
Since the “zoom” effect is centered to 0,0 every “positive” position will zoom to positive and every “negative” position will zoom to negative.
Above piece of code does that – but it looks involved, for what it does, either I can’t think straight at the
moment – or it has to be so complicated…
8bit Out of bounds checks!
equally stupid!
... lda Y_POS,u bmi check_y_neg cmpa #MAX_SINGLE_POS bgt doSplit bra check_y_done check_y_neg cmpa #-MAX_SINGLE_POS blt doSplit check_y_done lda X_POS,u bmi check_x_neg cmpa #MAX_SINGLE_POS bgt doSplit bra check_x_done check_x_neg cmpa #-MAX_SINGLE_POS blt doSplit ...
Splitting – drives me nuts!
The approach I implemented the most was:
If a coordinate is larger than the screen boundaries, check whether the direction of the vector is “inbound” or “outbound”.
Example:
if the added sums of positioning is 510 , 0 (y,x) and the maximum global y positioning is 500, than that y coordinate it out of bounds (to far to the top)
If the vector that was last added to the global coordinate was for example: 30, 0
Than I call that vector outbound, because it goes further away from the center.
If that vector would have been: -30, 0
Than I would call that vector inbound. (this has to checked for each quadrant seperately)
The very simple approach I took was:
INBOUND
Global pos is out of bounds after adding delta, but we are “inward” bound, so the next vector will possibly be displayed -> we add a move to our new (although OOB position) and display, the next vector normally – when that vector is oob the move will be removed “naturally” again. This means we should remove the start of this scene up to this vector and add a new move to the end of “this” vector (to global coordinates in Y and X registers).
OUTBOUND
Global pos is out of bounds after adding delta, but we are “outward” bound, so the next vector(s) will not be displayed we therefor remove all following vectors until the next scenario, THIS vector however will still be displayed once the previous vector is OOB than that case will delete this one!
(Definition:
Scene/Scenario
This is one “Vectorlist” in the “classical” sense. It starts with a Reset0Ref (mode byte), followed by moves and than by vectors. A scene is finished when a next Reset0Ref is encountered(mode byte). )
I implemented above… and this works… up to a point.

If you look at the INFINITY vectorlist, you will see a problemetic second vector!
That vector is, what I now call “locally outbound”.
Zooming INFINITY will delete 95% of the vectorlist, once that “locally outbound” vector is out of bounds.
So… above implemented “Bound variants” were stupid. Grrr!
New INBOUND
We remove THIS vector (the current that just became OOB) and add a Reset0 and move to current position instead. The vectors before were obviously displayed, otherwise we weren’t here. So – we build a new scene for this.
BUT:
We must also ensure, that the last scene is not empty now (only moves)
if this is the case, we must remove all those moves!
New OUTBOUND
Delete all following vectors till next scene starts, but only those which are OOB.
If there is one in bounds, add a new Reset+Move to that one and thus start a new scene!
—
Above are implemented – but not working correctly yet.
Apart from above not working 100% correct there is also another “trap” which I fell into:
As of now when a vector (move or draw) exceeds the maximum possible length, than it is splitted into two equal halves.
The “bug” is, when we next zoom, each vector gets its “zoom” value added. But the former 1 vector is now two vectors.
So instead of adding 1 zoom offset, now 2 zoom offsets are added to the same “entity” (split one into two – is logically still the same entity).
Thus as of now, with each “split” of a vector the zoom factor for that vector-entity doubles!
The only way to circumvent that is to add a flag to “split” vectors, that they should be skipped by the zooming. This means we need another “mode”, and this means I will have to abandon the “CC” for good now.
But not today… its in the night and I am tired.
Tomorrow there will be no update to this.
(Man! This was supposed to be an “easy” filler in between, but there are so many things to consider. Or I am just to dumb for this :-O – it certainly feels this way)

– This was supposed to be an “easy” filler in between, but… –
Hehe, isn’t that what always happens? Almost all of my major Vectrex projects started this way. Keep up (your spirit and) the work!