Jump to content
  • 0
SplitSpine

Outside objects coming into view

Question

As a new programmer on very limited hardware, how do you make sprites and background appear from outside the monitors border?

It seems very easy for the RIGHT and BOTTOM sides, since you just use higher X & Y values then the screen mode use.

But you can't use negative values on sprites....

So what's the trick I'm missing?

Share this post


Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0

The trick is that even though the X and Y values are technically "unsigned" (i.e. non-negative), you can still get the effect of negative numbers by going ahead and subtracting from 0. The value will "underflow", but you can write the bits to the VERA anyways and it will treat it like a negative number.

Another way to look at it is that you've moved the sprite so far off the right side of the screen, that the VERA eventually wraps part of the sprite around to the left edge.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
16 hours ago, StephenHorn said:

The trick is that even though the X and Y values are technically "unsigned" (i.e. non-negative), you can still get the effect of negative numbers by going ahead and subtracting from 0. The value will "underflow", but you can write the bits to the VERA anyways and it will treat it like a negative number.

Another way to look at it is that you've moved the sprite so far off the right side of the screen, that the VERA eventually wraps part of the sprite around to the left edge.

Thanks for the explanation, it was really helpful.

I used the basic sprite example to test it out.

Seems that X coordinate starts over at $400 or 1024 (so the same as $000 or 0).

Still not sure how to make an "underflow" even in assembler, well I might be able to do it to 1 byte, but the X coordinate consist of 2 bytes.

 

Quote

10 REM 'ADDRESS 12:5
20 VPOKE $1,$FC00,0
30 REM 'ADDRESS 16:13 (STARTING AT $10000) AND 8 BPP MODE
40 VPOKE $1,$FC01,$88
50 REM 'X COORDINATE 7:0
60 VPOKE $1,$FC02,250
70 REM 'X COORDINATE 9:8
80 VPOKE $1,$FC03,3
90 REM 'Y COORDINATE 7:0
100 VPOKE $1,$FC04,55
110 REM 'Y COORDINATE 9:8
120 VPOKE $1,$FC05,0
130 REM 'Z-DEPTH: IN FRONT OF LAYER 1
140 VPOKE $1,$FC06,$0C
150 REM '16 PIXELS FOR WIDTH AND HEIGHT
160 VPOKE $1,$FC07,$50
170 REM 'COPY SMILEY SPRITE DATA TO VIDEO RAM
180 GOTO 500
180 FOR I=0 TO 255
190 READ A
200 VPOKE 1,I,A
210 NEXT I
220 REM 'ENABLE SPRITES
230 POKE $9F29,PEEK($9F29)OR$40
240 END

500 DATA 00,00,00,00,00,16,16,16,16,16,16,00,00,00,00,00
510 DATA 00,00,00,16,16,07,07,07,07,07,07,16,16,00,00,00
520 DATA 00,00,16,07,07,07,07,07,07,07,07,07,07,16,00,00
530 DATA 00,16,07,07,07,07,07,07,07,07,07,07,07,07,16,00
540 DATA 00,16,07,07,07,16,07,07,07,07,16,07,07,07,16,00
550 DATA 16,07,07,07,07,16,07,07,07,07,16,07,07,07,07,16
560 DATA 16,07,07,07,07,16,07,07,07,07,16,07,07,07,07,16
570 DATA 16,07,07,07,07,07,07,07,07,07,07,07,07,07,07,16
580 DATA 16,07,07,07,07,07,07,07,07,07,07,07,07,07,07,16
590 DATA 16,07,07,07,07,07,07,07,07,07,07,07,07,07,07,16
600 DATA 16,07,07,16,07,07,07,07,07,07,07,07,16,07,07,16
610 DATA 00,16,07,07,16,07,07,07,07,07,07,16,07,07,16,00
620 DATA 00,16,07,07,07,16,16,16,16,16,16,07,07,07,16,00
630 DATA 00,00,16,07,07,07,07,07,07,07,07,07,07,16,00,00
640 DATA 00,00,00,16,16,07,07,07,07,07,07,16,16,00,00,00
650 DATA 00,00,00,00,00,16,16,16,16,16,16,00,00,00,00,00
670 GOTO 190

 

Share this post


Link to post
Share on other sites
  • 0

"Underflowing" is just what happens when you try to subtract a larger unsigned number from a smaller unsigned number.

So, okay, let's suppose you have some 8-bit value, such as %00001011 (which is 11). If I subtract %00001100 (12) from it, I get %11111111 (255), because the math "underflowed". Instead of just stopping at zero, the computer kept going. It's exactly the same thing as when you start with %11111111 (255) and add 1, the computer "overflows" to %00000000. When crossing 0 with a subtraction, it's called an "underflow".

And in fact, whenever you see a binary number with the highest bit set, you can also think of it as the negative version of the number you get when you invert all the bits and add 1. So %11111111 (255) can be seen as -1, or %00000000 (0) plus 1.

The reason the VERA "starts over at $400" is because the sprite position is only 10 bits wide (see also: VERA reference). $400 is %0100 00000000, in which the lower 10 bits are all zero. So the VERA sees that as %00 00000000. The assembly instructions you'll work with will generally work in 8-bit units instead of 10-bit units, but if you have some pair of bytes %00000000 and %00000000, and subtract %00000001 and %00000000, you'll get %11111111 and %11111111. You can just chop off the top 6 bits from the second byte when you write them to the VERA, because the VERA will only see it as %11 11111111 anyways.

Edits: Trying to figure out the best phrasing to teach the concept...

Edited by StephenHorn

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use