[REQ:ASM] Sprite collisions basics

[jman]

Hello,

I can successfully check for collisions between S0+S1 against S4 enabling bit 12 only of CLXCON and then checking for bit 10 of CLXDAT.
However I don't understand why I can't detect S2 against S4. Only change I did is checking bit 12 of CLXDAT:

    moveq    #0,d1
    move.w    clxdat(a5),d1
    btst.l    #12,d1
    bne.s    do_this_and_that

I'm afraid I'm overlooking something really trivial because I've read over and over the AHRM and it looks very simple actually; this is why I'm not pasting any code but if it's needed...

tia

[phx]

I remember I had some difficulties with clxcon as well, but that was 20 years ago.

One important thing is that you cannot read clxdat multiple times. The bits will be cleared and only become valid again after the video beam has drawn the next frame.

[gggcumming]

Slightly off topic - but would be interested to hear if anyone actually managed to make good use of sprite collision detection in a reasonably complex game - I always liked the idea but found it too restrictive to make work.

[jman]

Originally Posted by phx

One important thing is that you cannot read clxdat multiple times. The bits will be cleared and only become valid again after the video beam has drawn the next frame.

You are right and I was stupid because even though I perfectly knew this I did check that register multiple times, silly me.
I have to copy the register content into a safe place (like I already do) and then forget about it.

@gggcumming: I must confess I'm ignorant on the subject. I thought that sprite collision routines were the base for _every_ amiga game, whenever one had to check (e.g.) for boundaries, collisions, paths and so on. Is my assumption wrong?

[Codetapper]

Most Amiga games do simple rectangle intersection for collisions, or testing a point in a rectangle. You can also use the blitter without a destination set to check for collisions.

If you relied on sprite collision, almost no Tiertex games would have collisions as they don't use sprites! Also when you re-use the sprite channels, I'm not sure how reliable the CLXDAT value is - as you could use the same sprite for enemy bullets and player bullets, and both player and enemy ships. Knowing which sprite hit the other would be a nightmare!

[Harry]

In Fourmaze, also not all objects are sprites, and the game screen is 640 px wide, so i used a precompiled lookup table for pixel exact collision.
Usage of table is approximately like this:

//check if vertical match possible
if(((obj2.y+obj2.height)>obj1.y) && ((obj1.y+obj1.height)<obj2.y)){
  //check if horizontal match possible
  int tmpYOffset=obj1.y-obj2.y+obj2.height;
  //reserved value for no collision due bouncing objects (table uses same format/height for all animation frames)
  if((table1[frame][tmpYOffset]!=INT_MIN) &&
    //check if horizontal match occured
    (table1[frame][tmpYOffset]>(obj1.x-obj2.x)) && (table2[frame][tmpYOffset]<(obj2.x-obj1.x))){
    //your collision code here
    ...
  }
}

Of course, you still have to write a piece of code where the tables are precompiled by checking where the masks of both objects overlap (for each frame). Contents of the tables is the starting and ending horizontal offset range in which the collision happens.

In each case one table is needed for each possible combination of player <-> enemy. This approach may result in some dozens of small tables, so most games go for the rectangle approach; some (like the flight sequence of Turrican 2) use rectangles smaller than the player object to prevent "telepathic" contact like it occurs in Beast1 (remember being hit by the jumping worms?).