Collision detection with UDGs

[Hedge1970]

Hi, does anyone know why I can’t detect collision using Screen$(Y,X) when it’s a UDG?

Thanks for any help

[R-Tape]

Hi, does anyone know why I can’t detect collision using Screen$(Y,X) when it’s a UDG?

Thanks for any help

I'm afraid the BASIC designers chose not to include this feature, SCREEN$(Y,X) only does the font. It would have been possible to do, but for some reason was not. Ho hum.

From Geoff Wearmouth's ROM disassembly:

Code: Select all

; This function returns the code of a bit-mapped character at screen
; position at line C, column B. It is unable to detect the mosaic characters
; which are not bit-mapped but detects the ASCII 32 - 127 range.
; The bit-mapped UDGs are ignored which is curious as it requires only a
; few extra bytes of code. As usual, anything to do with CHARS is weird.

Other options:

-You could make a custom font that includes your UDG graphics, so if you make a little man UDG as letter "A", you can use SCREEN$ on it.
-use colours for collision detection, ATTR(Y,X)

[Hedge1970]

Perfect, that was a much quicker response than I was prepared for so thank you. I will try att() instead - been using that for colour detection in other areas. Cheers All

[PeterJ]

[mention]Hedge1970[/mention],

If you don't mind adding a small amount of machine code there is a very nice easy to use routine called 'SCREEN$ 2' in 'Super Charge Your Spectrum'

https://computerarchive.org/files/comp/ ... ectrum.pdf

Take a look on Page 103

[Joefish]

You get much, much better performance from using ATTR(...) anyway. Just remember to plan your colours so different things are distinct.

Another tip for BASIC optimisation - make sure your empty space is always filled with the same attribute. Now you can check the atribute is what you expect before moving your character safely. If it's not what you expect, don't decode it there and then in your main code loop. Use a GOTO or a GOSUB and work out what the ATTR value represents in a subroutine after your main program loop, that you only call if something is abnormal. It keeps your main game loop tight, and the player is unlikely to notice a momentary delay on the point of colliding with something.

[djnzx48]

It is possible to detect UDGs with SCREEN$, you just need a few POKEs. Here's a column from YS #20 that tells you how to do it.

[llewelyn]

Hi, does anyone know why I can’t detect collision using Screen$(Y,X) when it’s a UDG?

Thanks for any help

Oh boy! Thank you for asking that question Hedge 1970 because I did not realize that was exactly what I needed to know! And thanks for all the answers folks. I was wondering how to approach a similar problem and didnt know how to ask about it because I hadn't figured out that was the way to do what I would be needing to.

Sometimes other peoples questions are exactly the clue one needs as to how to do something. The attributes property has always puzzled me now I get it.

[Hedge1970]

It is possible to detect UDGs with SCREEN$, you just need a few POKEs. Here's a column from YS #20 that tells you how to do it.

That’s going to take some time to understand but thank you.

The game is working with att() so just a few tweaks to do, 9 very basic levels and it will be a bucket list item ticked - only took 30 years longer than I thought

[Hedge1970]

Hi, does anyone know why I can’t detect collision using Screen$(Y,X) when it’s a UDG?

Thanks for any help

Oh boy! Thank you for asking that question Hedge 1970 because I did not realize that was exactly what I needed to know! And thanks for all the answers folks. I was wondering how to approach a similar problem and didnt know how to ask about it because I hadn't figured out that was the way to do what I would be needing to.

Sometimes other peoples questions are exactly the clue one needs as to how to do something. The attributes property has always puzzled me now I get it.

Your welcome and I do agree often time trying to understand the question you need to ask is all it takes