It shouldn't be too hard to add a command to VDPX to detect if there's a colission between sprite x and layer y.

Quote:

Interesting. C64 has a bit to set for sprite collision detection to also detect collisions with 'foreground graphics'. Just as sprites can move between foreground and background colours, something also impossible on MSX1 (or 2, or 2+, or TurboR...). In fact does any of the new graphics chips currently under development have a simple solution for this, with which I don't mean harshly maintaining two entire layers that you can move or Z-index independently?

The VDP from the Sega Master System is basically a beefed up VDP from MSX1. It has a priority bit per tile, with which you can choose if that tile will be displayed before or behind sprites. Maybe you mean something like that?
A Sega Master System-like screen mode would have been nice to have on MSX2.

Obviously the priority cannot only be if the sprite is below or above a tile, but it should also be possible to have the sprite between the foreground and the background colours of the tile. So the main character can walk between a house and the fence, for instance. On MSX you can currently only do something like that with 8px block copy and precalculating the whole tile including the character, or you can get really creative with overlapping sprites. I vaguely recall the new Goonies remake does something nice here.

I'm not really following. Do you mean adding a VDP feature for priority per colour for tiles?
That would seem a bit strange to me as then the colour will then be linked to priority which is probably not always what you want? Priority per tile seems more flexible to me, unless you want priority per pixel, but then you might as well just add more layers.

Priority will not be by definition per colour, but per foreground/background split. On MSX you have one foreground and one background colour per 8px line in a tile, on C64 the split of colours in an 8×8 tile is a bit different. But the end result on C64 is that you can paint a dark background, and foreground bushes in two shades of green, and the main character walking behind the bushes.
Or a background pattern with stars, and foreground patterns with tile-based objects that you can't hit (Nemesis), and a completely hardware-based collision solution for sprite-versus-foreground-colour.

Indeed on MSX the whole concept of foreground vs background colours seems that you simply have two colours, which don't have a specific role.

Of course you can get the same effect on a different video chip by using multiple layers and your own collision routine, but that's so much overhead you have to manage no matter how fast this chip is.

In terms of current VDP limits, I'm wondering how easy and fast you can dynamically redefine sprite colours as a character walks behind objects, without using more sprites. In other words: as the character walks behind a bush, simply paint the character sprite with appropriate green pixels. The total number of colours per sprite line will have to remain at most three though, which makes this very challenging.

It's easier to disable sprite pixels which should be hidden behind a tile, this won't cost you any extra sprites.

it is easier, but not fast for sure.
You have to store (hopefully pre-calculated) the mask for the foreground objects as bit fields and
you need a lot of "and" and byte rotations for masking the two shapes (a part the dynamic definition of the SPTs)...

Actually, I think that something could be done directly in VRAM by the VDP

Assume you have in VRAM the bitfiled masks of the foreground shape (or better of the complement):
Say:
11110000
11111000
11111100
11111110

and again in VRAM (outside the SPT) the shape of the sprite to be hidden.

You can use the logical "and" between the above mask and the sprite shape when coping it in the SPT, this will hide the sprite partially.
the problem is : HOW implement rotations ?
I.e. how to implement the single 1pixel steps of the sprite that goes under the foreground ?

I do not see any logical instruction able to shift a bit-field mask, am I wrong?