P/M collision detection: PAL vs NTSC

[vitoco]

Is there any difference on how player/missiles collision detection works between PAL and NTSC?

 

I am programming some simple games for the NOMAM's BASIC 10Liners Contest and I previously found that when I clear the collision registers (store any value in HITCLR=$D01E) to check for any overlap, I have to wait for the next vertical blank before I read the required bits. As I am using TurboBASIC XL, a simple PAUSE 0 does the trick.

 

BUT yesterday I found something strange: I developed a game using Altirra in a PAL configuration and all worked as expected, until I changed the video to NTSC to see how my game looked like. In this video mode, the code couldn't detect some of the collisions between players or a player and a missile. One of them just went through the other. I thought it was a bug in Altirra, but when I tried the game in real hardware, I couldn't play it in my NTSC 800XL... In my PAL 800XL all went OK. (Wow, Altirra IS the best emulator).

 

I solved this issue using PAUSE 1, adding an extra vertical blank. Now the game can be played in both flavours of Atari XL.

 

Anyway, I want to know why I need an extra VB in NTSC!!!

 

[phaeron]

The rule for reliably detecting collisions is simple: you must write HITCLR before ANTIC+GTIA draw any points on screen that have collisions, and wait until possible collisions have been drawn before reading the collision registers. Problem is, this is hard to do in BASIC because it lacks the speed to do precision timing. What's probably happening is that the shorter NTSC frame is causing your game logic to run out farther into the middle of the frame, so that by the time you write HITCLR it's too late and the period from HITCLR to reading the collision latches doesn't capture anything. Adding an additional frame of delay fixes the problem because then ANTIC+GTIA have a chance to redraw the entire frame and capture the collision. One possible fix is to change the ordering to PAUSE, read collisions, write HITCLR. This makes the time window from read-to-clear really short to avoid having it occur while the screen is being drawn.

[Rybags]

Since the PAUSE gives a wait for Vblank type function you could reorder the way your program does things a bit.

Probably best to read collisions immediately after the pause, then set new player positions as soon as possible after that.

 

Being a 10-liner puts a lot of restrictions on what you can fit but another trick could be to do the game logic before the pause but keep copies of "old" position for the objects so you can immediately do that repositioning but still have the old position if they're needed when handling collisions, e.g. player picking up objects which are playfield where you need to work out which one was picked up.

[vitoco]

What's probably happening is that the shorter NTSC frame is causing your game logic to run out farther into the middle of the frame, so that by the time you write HITCLR it's too late and the period from HITCLR to reading the collision latches doesn't capture anything. Adding an additional frame of delay fixes the problem because then ANTIC+GTIA have a chance to redraw the entire frame and capture the collision.

Well, that makes sense. In the code I have:

 

(1) wait for VB

(2) change player horizontal position

(3) move player data for vertical position

(4) clear collision registers

(5) wait for VB

(6) check for collisions

 

The pause in (1) is to avoid some glitches when moving the main character. It seems that in NTSC video mode, steps (2), (3) and (4) can be performed in a way that when step (4) is complete, it is just before the end of a frame, so when it reaches step (5), nothing more need to be drawn and therefore no new collisions are detected, and the PAUSE waits almost no time. I guess it could also happen to PAL if steps (2) and (3) takes a bit longer or shorter... it is just a timming issue that is difficult to manage in BASIC. An extra VB seems to be the cost we have to pay for reliability.

One possible fix is to change the ordering to PAUSE, read collisions, write HITCLR. This makes the time window from read-to-clear really short to avoid having it occur while the screen is being drawn.

 

Unfortunately, I think that HITCLR must be written after all the players are repositioned in screen, or it might register an old collision or false collision, for example when 2 players move at the same speed to the same direction and are close enought that they might overlap for a while between the reposition of each of them. It will depend on how many things had to be done between the player's reposition and the check for collisions if we had to PAUSE an extra VB.

 

Thanks for the responses...