Is collision function broken?

collision() function isn't a very reliable way to have collision detection when sprites are moving around on all axes.. But the collision() does work if the two sprite are coming at each other on the same axis path..

Try changing c=263 to c=290 to get a better result..

Another from of collision detection I use is with the spriteposx() or spriteposy() function...


a=addsprite(1,1)
b=addsprite(1,1)
bx=256
by=290
ax=256
ay=256

propsprite a,1,1
movesprite a,ax,ay

joypad:          
do
j=joypad()
propsprite b,2,2
movesprite b,bx,by  
sleep 1
if j.2 then bx--
if j.3 then bx++
if j.0 then by--
if j.1 then by++
if spriteposx(b) = spriteposx(a)[and] spriteposy(b) = spriteposy(a) then print "collision"
loop


Still not very reliable though unless the two sprite are coming at each other on the same exact axis path...

Thanxs ScroGer for the code, and maitrus for the explanation


Too bad, because i was thinking in collision between a normal and a transparent sprite....


ah maitrus, im working to understand your code, im not lost... ;D tomorrow i think i send you a mail...

thanxs

The collision function reads the status register from the VDP. The status register flags this one bit, that tells the programmer that two non-transparent pixels in two sprites overlapped.

It's not documented because it's really not a good way to check for collisions between sprites . I think the example is still there because I forgot to remove it. Otherwise, I should add this function to the documentation!

e.g. status register from the famous genvdp.txt:

----------------------------------------------------------------------------
6.) Status Register
----------------------------------------------------------------------------

Reading the control port returns a 16-bit word that allows you to observe
various states of the VDP and physical display.

d15 - Always 0
d14 - Always 0
d13 - Always 1
d12 - Always 1
d11 - Always 0
d10 - Always 1
d9  - FIFO Empty
d8  - FIFO Full
d7  - Vertical interrupt pending
d6  - Sprite overflow on current scan line
[b] d5  - Sprite collision[/b]
d4  - Odd frame
d3  - Vertical blanking
d2  - Horizontal blanking
d1  - DMA in progress
d0  - PAL mode flag

Presumably bit 0 is set when the system display is PAL; however this same
information can be read from the version register (part of the I/O
register group - not the VDP), so maybe this bit reflects the state of
having a 240-line display enabled.

Bit 1 is set for the duration of a DMA operation. This is only useful for
fills and copies, since the 68000 is frozen during 68k -> VDP transfers.

Bit 2 returns the real-time status of the horizontal blanking signal.
It is set at H counter cycle E4h and cleared at H counter cycle 08h.

Bit 3 returns the real-time status of the vertical blanking signal.
It is set on line E0h, at H counter cycle AAh, and cleared on line FFh,
at H counter cycle AAh.

(Note: For both blanking flag descriptions, the H counter values are
very likely different for 32-cell and interlaced displays; they were
taken from a test with a 40-cell screen.)

Bit 4 is set when the display is interlaced, and in the odd frame,
otherwise it is cleared in the even frame. This applies to both
interlace modes.

[b] Bit 5 is set when any sprites have non-transparent pixels overlapping one
another. This may hold true for sprites outside of the display area too.
This bit is most likely cleared at the end of the frame.[/b]

Bit 6 is set when too many sprites are on the current scan line, meaning
when the VDP parses the 21st sprite in 40-cell mode or the 17th sprite in
32-cell mode from the sprite list.
This bit is most likely cleared at the end of the frame.

Bit 7 is set when a vertical interrupt occurs. This happens at line E0h,
roughly after H counter cycle 08h. I do not know under what conditions
it is cleared, presumably at the end of the frame. Reading the control
port does not clear this bit. (this could be incorrect)

Bit 8 and 9 (FULL and EMPTY flags, respectively) are related to the FIFO;
here's what Flavio Morsoletto has to say about their use:

   "The FIFO can hold up to four 16-bit words while the VDP's busy
   parsing data from VRAM. Once the 68K has written the fourth word,
   FULL is raised. If the processor attempts to write one more time, it
   will be frozen (/DTACK high) until the FIFO unit manages to deliver
   the first stacked word to its rightful owner. EMPTY only goes 1 when
   there is nothing on the stack. The intermediate state is signaled by
   both of them showing 0."

This situation only occurs during the active display period, as the
data port can be written to as many times as needed during blanking.

I've noticed most emulators keep the EMPTY flag set, so it appears as
if the FIFO was always empty instead of being in the neutral state. This
is probably for games that would normally check and find the FIFO in a
neutral state, then write data and expect to poll the FULL flag afterwards.


And add collision detection of transparent sprites help a lot too...

You can make a map of 8x8 transparent sprites, and use it for collision detection of objects, so you dont have to draw sprites for all objectsm and you can use the tile background.

I use this technique a lot in other programming languages, and works great

But if you only add one 8x8 or 16x16 sprite, and then repeat the same in the screen, count like new sprites?

i think you only waste a little vram, not sprites, repeat the same

For example in a NES code i make for fun long time back, i make 4 8x8 sprites, UP, DOWN, LEFT, RIGHT

And repeat in the screen.If you are pressing UP, and found a UP sprite, i stop the scroll, but if you are pressing UP, and found a DOWN sprite, i do nothing... ;D

Build your own collision routines. Each game has its own specific collision requirements, so a custom solution is always best. Compile collision data to be suited for a initial broad-phase collision sweep ( grid / quadtree / proprietary ) instead of relying on complex data such as sprites.

www.metanetsoftware.com/technique/tutorialA.html
www.metanetsoftware.com/technique/tutorialB.html

Here are two tutorials on collision for a 2D platformer .. written for modern hardware, but can be adapted easily.

Sorry my english is very basic... jeje



Look at the image

if you are pressing left, and found a LEFT sprite, you stop the scroll, or the main character sprite... the same for RIGHT, UP, DOWN

I use this solution for a NES game, and work right, and not slowdown the game