How do *you* handle screen coordinates?

[D-Type]

Hi All,

I'm writing this little City Bomber program that automatically (using a loop) moves a plane left to right across the screen and when you press a button, it should drop a bomb.

How does the program know where to start the bomb from? I take this from the position of the plane at the time the button is pressed. 

Because of screen scaling I'm using, my loop that moves the plane goes from $-3F to $40, because zero is in the middle of the screen.

If I want to do some other calculations on those positions, it's awkward, because it depends on which side of the screen you're on, there are only $80 x-axis positions. You can't use simple rotates or + or - $80 to get an absolute number, if you get my drift.

So here's the question: If *YOU* are moving things around the screen using a loop, do you make the loop from, say $0 to $7F and then everytime you write to the screen, you offset it to account for 0 being in the middle, or do you make your loop like mine i.e. $-3F to $40 and deal with any other problems due to the scaled screen being e.g. only $80 pixels wide?

Or maybe I'm missing something that I'll also need to consider if I'm not scaling the whole screen to $-3F to $40?

Hopefully this makes sense...I'm new to this scaling thing, it's a bit mind bending 

Any other tips?

Here's a code snippet:

     40 -3F                                     \ end start -- ; These are the x-axis loop parameters
     DO                                         \ Start the x-axis loop
       CR ." Stack:" .S  ."  Timer:" D009 C@ U. \ Send stack contents & 50Hz frame timer top byte to serial port
       _Wait_Recal
       _Intensity_5F
       -3F -3F _Moveto_d \ x y -- ; Move to the bottom left of the screen
       7F 20 CITY _Draw_VL_ab                   \ scale #vectors addr -- ; Draw the city from RAM
       \
       _Recalibrate
       I J _Moveto_d _Dot_here \ I = x-axis loop index, J = y-axis loop index (not shown)
       20 4 PLANE _Draw_VL_ab                   \ scale #vectors addr -- ; Draw the plane
       \
       BOMBY C@ C0 =                            \ -- f ; Is there a bomb on screen?
       IF
         _Read_Btns 0 <>                        \ -- f ; has a button been pressed?
           IF
             J BOMBY C! I BOMBX C!              \ Store initial coordinates of bomb
           THEN
       ELSE                                     \ Bomb is on screen
         _Recalibrate
         BOMBX C@ BOMBY C@ _Moveto_d _Dot_here  \ Move beam to current bomb position and display a dot
         BOMBY C@ 1- BOMBY C!                   \ Update bomb position
         \
         \                                      \ Debug code below, where the offsets start getting messy!
         BOMBY C@  ."  BY:"  U.                 \ Dump bomb Y position to serial port
         BOMBX C@  ."  BX:"  U.                 \ Dump bomb X position to serial port
         BOMBX C@
         8 /       ."  Block:"  DUP U.          \ Each city block is 8 pixels wide, to serial port
         4 *       ."  Offset:" DUP U.          \ Each city block consists of 2 XY positions = 4 characters
         CITY +    ."  City Array Address:" U.  \ Index into the city tower height array
       .
       .
       THEN
     .
     .
     LOOP

[Malban]

Hm.

for positioning on screen I usually use only ONE scale factor, not different scale factors for different objects (Release does not count - there the exact opposite is true - I use alway the same coordinates - but the scale is different with each movement).

I chose the one, with which I relatively easy can position to "all" coordinates on the screen.

Usually that is a scale around $80.

With a scale of that you can (from the center) more or less go to each corner (exactness depending on the vectrex).

The abs highest positive coordinate than beeing $7f (+127) and the the abs highest negative coordinate being $80 (-128).

Using these coordinates if you want to do "round" trips you can just inc or dec... because +128 == -128 and -129 == +127 in that scenario, no need for any checking.

It only gets "weird" when you do collision detection comparing coordinates - than you have to consider carry flag, overflow flag, perhaps negate a value ... or the like. Sometimes for collision detection I use absolut values (add $80 to everything. The 0,0 point than is the lower left corner... but you still must check the V flag...).

There is one exception to always using the same scale - if I for some reasons have to move across the WHOLE screen (from -128 to +127) - than I just double the scale and the vectors exactly double the usual extend.

It looks like you use a scale of $ff (WaitRecal and Recalibrate "leave" with that scale - and you never change it). Perhaps you should think about using a lower scale.

Also you should use "Recalibrate" only when needed - since this routine steals a lot of time (dunno I guess about a 1000 cycles).

Sometimes it is needed, because it more or less ensures a STABLE 0,0 coordinate.

But most of the time a Rest0Ref is the better choice - much faster.

Malban

[gauze]

I think Malban is saying the same thing I am going to say but I'm a bit out of it now so maybe not, the simple version for POSITIONING I use 1 scale, the scale for the DRAWING is a separate thing. So the position is the same "format" for everything on screen, no math or transitions needed. scale 127 is what I always use for position but I am not an advanced programmer at all.

[D-Type]

Ah, interesting...so far I've been doing everything by trial and error, not really thinking too hard about the DAC circuit works (that'll come later) and the relationship between scale and strength. What I didn't realise is that Recalibrate is resetting the scaling factor to $FF, which will I think will give me a performance degradation if I just carry on using it. Changing SF to $7F (or $80 as Malban mentioned, would it make a difference?) would thus improve performance /and/ allow $7F/-$80 8-bit "round trips" - nice!

From previous reading I've done, I have the idea that it's generally best to use the highest strengths and alter the scaling factor accordingly for best performance - within reason, if the amplification in the DAC isn't linear, I'm guessing that'll probably give inconsistent drift, as well as making the code complicated. Malban said previously:

The scale has DIRECT influence on the time a vector takes to be drawn.

Optimally you should draw every vector with a strength of +127 or -128 and only adjust the scale.
The single drawn vector will than be fully optimized. Thing is - you have to change the
scale every vector (if the vectors come in different lengths) - which costs time,
that the overall cost for a list of differently sized vectors increases again.

In VFrogger I chose scale 6 as my personal minmal scale and drew every object with it.
(VectorPatrol e.g. is often drawn with a scale of 9).

Read more: vectorgaming.proboards.com/thread/2116/recal-query-operation-usage-solved#ixzz5PJXe3A5n

He also said:

for positioning on screen I usually use only ONE scale factor, not different scale factors for different objects

Read more: vectorgaming.proboards.com/post/new/2150#ixzz5PJYkur5P

Wouldn't a usually-fixed scale factor give a performance degradation when your repositioning isn't very far away?

Regarding using Recal instead of Reset0Ref, the code is thrown together at the moment and I'm only using 1/3 of the available cycles per frame. There are two reasons why I'm using Recal;  The "cityscape" drawing is a dynamic (i.e.constructed in RAM) 32 line VL covering half the screen in one go, and it makes the screen 'pulse' a bit (changing the SF might help that somewhat) and as yet, I'd not written the Forth to BIOS interface for Reset0Ref. Let me quickly do that...

CODE _Reset0Ref \ -- ;
   1E # ( X DP D) PSHS,      \ Save Registers
   D0 # LDX,   X DPR TFR,    \ DP to D0
   Reset0Ref JSR,            \ Call Vectrex BIOS subroutine
   1E # ( X DP D) PULS,      \ Restore Registers
   NEXT ;C

Thanks for your thoughts, guys, it's really appreciated and clarified thinks in my mind a lot.

I'll have to publish something sooner or later, I can't keep on asking questions and not give anything back to the community!

[gauze]

The part where you mention about scale making the drawing or moving take longer, that's right, and in that time where the timers are counting down on the 6522 telling the gun how to move and turn on and off and whatever you can actually do some calculating in there saving sme cycles elsewhere which is an advanced topic and probably no point in looking into it until you are at the 30000 cycle limit per frame or near it. Premature optimization and all that.

[D-Type]

So I've tweaked my code to use 7F as the Scale Factor for 'big lines' and better positioned Wait_Recal and Reset0Ref calls in the code - makes it more consistent and easier to understand the code, plus it save a few cycles 

So then to another associated issue I'm seeing that maybe is an easy answer for someone...

I'm moving a aeroplane vectorlist 'sprite' across the screen i.e. x-axis from -7F to 80. Regardless of the y-axis, when the plane moves past x=0, it jumps up by one pixel i.e. y=y+1. I thought it was a minor problem with the calibration on my Vectrex and I thought nothing of it for the past couple of months when I first noticed it.

However, (via VecFever+Vectrex) in testing my tweaks to make the SF 7F, when I move the plane across the screen with y=80 i.e. right at the top, it jumps to the bottom of the screen when passing x=0. Hmm, that doesn't seem like a calibration issue, so I tried it on VIDE and it does exactly the same thing! 

I can't immediately see anything wrong with my code, so thought I'd ask if there are any known gotchas in that area that could cause this?

A video says a 10,000 words...



The new code:

: BZ \ -- ;
\  2 RND +! \ New seed for Random
 INIT
 C0 BOMBY C!
 BEGIN
   -7F 80
   DO \ y axis
     80 -7F
     DO \ x axis
       CR ." Stack:" .S  ."  Timer:" D009 C@ U.
       _Wait_Recal _Intensity_5F
       -7F -7F _Moveto_d_7F
       7F 20 CITY _Draw_VL_ab
       \
       _Reset0Ref
       I J _Moveto_d_7F
       20 4 PLANE _Draw_VL_ab

\\\\ OTHER CODE IN HERE

       THEN
       KEY? IF ABORT THEN
     LOOP
   -10 +LOOP
 AGAIN
;

[Malban]

Actually I am not good enough at FORTH to REALY understand your code.
Just a few thoughts.

1)
In Assembler the signed integer range goes from
-128 to +127 (in hex $80 to $7f), $80 is actually = -128.

So for that reason I am a bit startled that you go from $80 to -$7f, that would in assembler only be one "decrement".

2)
Internally the y position is kept usually in register A and the x position is kept in register B.
Also usually you pass those to values in register D to the moveTo function.
Register D is actually a 16 bit register consisting of the two 8 bit registers A + B, so register D = 256*A + B.

If your FORTH program does some kind of optimization and references the positions not in their seperate A/B registers but in "register d" (and thus e.g. incrementing x position by D = d+1 and incrementing y position by D =d+256) - an overflow of the B register would carry over the the A register and thus resulting in a very similar behaviour that you witnessed.

;

I am to tired right now to read up on FORTH... where do I and J get their values from? Or are they internally "linked" to loops?

Malban

[D-Type]

Thanks for your thoughts, I too am too tired to work this one out, it's 1:30am

I can go from $-7F to $80 because I'm using them in Forth as loop limit parameters (like for/next) and Forth uses 16 bit values i.e. $80 isn't -128, it's +128.

I'm using the $80 value when drawing vectors, because I took the ultimate limits from the code below i.e. 7F7F to 8080 are the diagonal corners of the screen:

Recalibrate:    LDX     #Recal_Points   ;$7F7F
               BSR     Moveto_ix_FF
               JSR     Reset0Int
               BSR     Moveto_ix       ;$8080
               BRA     Reset0Ref
I typed these in as loop limits at day one and it worked...except for this annoying one pixel blip problem!

I and J are simply the current loop index values, I puts the current inner loop value on the stack, J does the same for the outer loop. They're taken from the User stack, that's where this Forth manages it's loop parameters. (There is no K or L in any Forth standard, although they could easily be added.) 

The definition of I and J is this: (note, D is pushed to the stack initially because this implementation of Forth holds the top of stack in the D register, it's fastor and more compact)

CODE I \ -- n R: sys1 sys2 -- sys1 sys2 loop index
6 # ( D) PSHS, U 0, LDD, U 2 , SUBD, NEXT ;C

CODE J \ -- n R: 4*sys -- 4*sys 2nd loop index
6 # ( D) PSHS, U 4 , LDD, U 6 , SUBD, NEXT ;C
I'll work through your reply over the weekend, when my eyes are more open, but it doesn't sound like there's a specific gotcha that you're suggesting, so I guess I'm going to have to single step it with Forth or VIDE.

Thanks again!

[D-Type]

Aug 31, 2018 17:56:10 GMT -5 Malban said:

If your FORTH program does some kind of optimization and references the positions not in their seperate A/B registers but in "register d" (and thus e.g. incrementing x position by D = d+1 and incrementing y position by D =d+256) - an overflow of the B register would carry over the the A register and thus resulting in a very similar behaviour that you witnessed.

The above tipped me off. In the time gap between brushing teeth and hopping into bed, I did a couple of experiments and it boils down to Forth being a 16-bit system. The loop indexes are 16-bit, so -7F is FF81 in reg D and when I was combining I and J from the stack, I was assuming that they were 8-bit numbers...but they're not. The quick 'n' dirty fix is to change:

I J _Moveto_d_7F
20 4 PLANE _Draw_VL_ab

to 

I FF AND J FF AND _Moveto_d_7F
20 4 PLANE _Draw_VL_ab

This fixes the main problem, but it further highlights that loop indexes are now wrong because the plane starts at the bottom now for one left to right, then skips to the top. I need to remind myself how binary numbers and 2's complement work again. Job for tomorrow... 

[gauze]

2s complement is simple: if digit is negative, invert bits then add 1

4 = 0000 0100
invert bits 1111 1011
add 1 = 1111 1100 = -4