Logic of HIT_BACKGROUND

[Eisengrim]

I need help understanding how IntyBasic's HIT_BACKGROUND works. I thought that for any individual screen card, the 'on' bits are the foreground and 'off' bits are the background. When I experiment with HIT_BACKGROUND I get inconsistent results - sometimes a sprite hits what I think of as background, sometimes it doesn't. I've looked at nanochess's Barzack game, where the rooms are drawn with DATA statements, and it looks like HIT_BACKGROUND is detecting the 1s in the data blocks, not the 0s. Can someone explain how HIT_BACKGROUND determines what is really the background, and if it differs in FGBG vs Color Stack modes?

[intvnut]

The BACKGROUND in  HIT_BACKGROUND refers to BACKTAB, aka. the grid of 20 × 12 tiles. (BACKTAB stands for background table. It's the name either GI, APh, or Mattel gave it.)

 

It doesn't mean "pixels assigned a background color," but I can see how you might have thought it would.

 

The hardware collision detection looks for on pixels (1 in the bitmap) in the BACKTAB. IntyBASIC just reports the hardware collision info. If you use any colored-squares pixels, colors 0 through 6 count as on, and 7 counts as off.

[Eisengrim]

Thanks, that helps me understand how it's supposed to work. I'm drawing my screen with data statements, most of which is a black screen with value $0000. What I'm seeing is Sprite 0 will detect with HIT_BACKGROUND if it hits most screen elements other than $0000, but will cruise right through a screen element with value $0200 (a blue block). Is that because the block is considered full of 'off' pixels?

Edited June 7, 2020 by Eisengrim
typo

[carlsson]

Yes, $0200 will plot a blank space with blue background so all pixels are "off". If you are using Color Stack mode, I believe you have an entirely filled character at \095. If you are working in BG/FG mode, you need to define your own $FFFFFFFFFFFFFFFF character and plot it with blue foreground in order for it to work.