8th of April: Infinity(2)

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)