Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Off-screen sprite collision detection behaviour

Reply to topic
Author Message
  • Joined: 11 Mar 2018
  • Posts: 55
  • Location: New Zealand
Reply with quote
Off-screen sprite collision detection behaviour
Post Posted: Sun Feb 05, 2023 11:02 am
Hi all,

I'm wondering if anybody has some insight around what's going on with the sprite collision flag in the Master System's VDP.

I've been working on getting more of the VDPTEST.SMS tests passing on my own emulator, and the "Offscreen Y, col" is giving me a bit of confusion..

Looking at the implementation of the test, I see it places two of the same sprite at y=f0, x=7c. The test clears the status flag, waits on a couple of specificc VCounter values (to ensure we've waited a frame?), then expects the flag to be set. I see that the test does pass on real hardware.

However; I've been working on my own test rom (using devkitsms), and have observed different results.

In my test, I allow the user to move a pair of sprites around with the d-pad, and display whether the collision flag has been set or not. In this case, my results seem to show that the collision flag does not get set outside of the active area.

PAL SMS: The collision flag only appears to be set when the collision occurs in the active area. If the collision occurs a single pixel above or below the active area, then the flag is not set.

NTSC Megadrive (Genesis): Similar results to the master system, but will also detect a collision for a single line off the bottom of the screen.

I've also had a go at trying my test rom in a couple of other emulators that pass VDPTEST.SMS, and see that in those, collision-detection is running above/below the active area (which does not seem to happen in real hardware, at least by the method I'm testing).

I'm mostly wondering here: What exactly might be triggering the flag to be set in the VDPTEST.SMS case, while not setting the flag in my own test?

I don't think my personal test-suite is quite ready yet, but I'll attach a copy here for anyone interested. It includes two versions of the test for this flag:

1. VDP TESTS / VDP SPRITE COL
Four sprites are rendered, all move together with the up and down keys. Left and right are used to move the middle sprites only to trigger the collisions (left to have a collision on the top line of the sprites, right to have a collision on the bottom line of the sprite). The collision flag is read during the frame interrupt and shown in the "COL:" field on the screen.

2. VDP TESTS / VDP SPRITE COL NI
In this case, I try to make the behaviour a bit closer to VDPTEST.SMS. Two sprites are drawn exactly on top of one another, moved with the d-pad. Interrupts are disabled. A busy-loop polls for input and checks the collision flag, setting the "COL:" indicator if the flag is set. As this test isn't running a 'once per frame' loop, the "COL:" indicator remains set until manually cleared by pressing button '1' on the gamepad.
Sneptest-beta.zip (15.52 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Feb 05, 2023 2:04 pm
maybe this is not the issue, but the SAT table contains Y values decremented so if VDPTEST asm code sets a sprite Y to a $F0 in the table, then your devkitSMS code should use $F1 to get that...
  View user's profile Send private message Visit poster's website
  • Joined: 07 Nov 2016
  • Posts: 11
Reply with quote
Post Posted: Tue Feb 07, 2023 12:53 am
JoppyFurr wrote
Hi all,
I've been working on getting more of the VDPTEST.SMS tests passing on my own emulator, and the "Offscreen Y, col" is giving me a bit of confusion..


Hi, I'm working on a lot of VDP tests, derived from Flubba's VDPTEST, for more than 2 years and currently I'm stuck for more than a month trying to nail that behavior. The "Offscreen Y, col" pass due to the state left by the sprite table and the previous test ("Offscreen X, no col"). If you disable the previous test or alter the sprite table (remove supposed "unused" data), the offscreen y test will give an error.

I have some notes about experiments I did with Flubba's VDPTEST. The offscreen Y test requires that SAT + $84 and SAT + $89 have a value from a list of valid bytes:

SAT + $84:
(byte >= $6c && byte <= $71) || (byte >= $74 && byte <= $79) ||
(byte >= $7c && byte <= $81) || (byte >= $84 && byte <= $89) ||
(byte >= $8c && byte <= $91) || (byte >= $94 && byte <= $99) ||
(byte >= $9c && byte <= $a1)

SAT + $89: byte != {$00,$0e,$3f}

After the first experiments, I made a series of private ROM tests and discovered more odd behaviors, like no difference if $D0 is set in the range of SAT + $00 to SAT + $73, and SAT + $74 to SAT + $FF can contain zero except offsets SAT + $84 and SAT + $89.

Beyond specific bytes in the SAT, the test must turn on (or off?) the screen during some position of the active area. This is what may trigger the odd behavior that also includes the values in the SAT table. From what my tests suggest, the collision is set on the next line after the screen is turned on, without need to set sprite Y, not due to collision happening offscreen.
  View user's profile Send private message
  • Joined: 11 Mar 2018
  • Posts: 55
  • Location: New Zealand
Reply with quote
Post Posted: Fri Feb 10, 2023 10:31 pm
Hi enik2,

Thanks for the detailed reply. I think this clears things up enough to know that implementing off-screen collision detection is not what the real SMS does.


Cheers,
Joppy
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!