nesdev.com
http://forums.nesdev.com/

sprite address
http://forums.nesdev.com/viewtopic.php?f=3&t=465
Page 1 of 1

Author:  hap [ Thu Aug 04, 2005 10:58 am ]
Post subject:  sprite address

Does the sprite address (0x2003) change during rendering like the bg address (0x2006) ?

I'm currently simply reading sprites from address 0 and up, that doesn't seem to cause problems, except for Akira (J). It locks up because it uses the sprite zero bit for its splitscreen effect. If I hack in a sprite_address=0 once per frame (or even nastier, in 0x2002: if (scanline==akirasplitline) status=status|0x40;), it works.

Author:  hap [ Tue Dec 13, 2005 4:45 am ]
Post subject: 

(didn't want to open a new topic for this, as it's the same subject)

Tatakai no Banka..

This game, the Japanese version of Trojan, writes $80 to the sprite address every other frame, before doing a sprite dma transfer. This causes sprite 0 to be located at $80, which results in the sprite 0 hit being wrongly timed in-game, which results in dirty graphics (seen as flickering).

The Wiki says something about sprite 0 and 1 being fetched from the high 5 bits of the sprite address, instead of address locations 0 and 4. This would fix the problem in Tatakai no Banka, but I doubt that such behaviour happens on the real NES; looks more like a hack to get this game working, since no other games I've seen have such a problem as described above.

Author:  Guest [ Tue Dec 13, 2005 10:28 am ]
Post subject: 

I wonder if sprite 0 hit is really a "sprite $2003 hit" instead, i.e. the address in $2003 determines the sprite that should record at hit in $2002 bit 6.

I can see why a game might load sprites at $80 every other frame, as a quick way to compensate for the eight-sprite limit imposed by the PPU.

Author:  Quietust [ Tue Dec 13, 2005 12:39 pm ]
Post subject: 

hap wrote:
The Wiki says something about sprite 0 and 1 being fetched from the high 5 bits of the sprite address, instead of address locations 0 and 4. This would fix the problem in Tatakai no Banka, but I doubt that such behaviour happens on the real NES; looks more like a hack to get this game working, since no other games I've seen have such a problem as described above.


I assure you that it is NOT a hack - this strange behavior has been verified to occur on a real NES PPU. The Sachen game "Huge Insect" relies on this same behavior.

Author:  hap [ Tue Dec 13, 2005 4:13 pm ]
Post subject: 

It doesn't make much sense though. It would be logical to me if this applied to the whole sprite array, instead of only sprite 0 and 1.

Author:  Quietust [ Tue Dec 13, 2005 5:42 pm ]
Post subject: 

It doesn't make sense to me either, but that's how it works. If you don't believe me, you can test it for yourself.

Author:  hap [ Tue Dec 13, 2005 7:33 pm ]
Post subject: 

Sorry, I'm always a bit skeptical at first :P .. I believe you.

The game still looks glitchy now that sprite behaviour is fixed, but this time I blame Capcom. It's probably been ported by the same team who did Senjou no Ookami/Commando.

Author:  hap [ Sat Oct 14, 2006 9:39 am ]
Post subject: 

Hello there hap of the past, are we still blaming Capcom?

I don't think he'll answer, so a better reason for this topic kick:
Quote:
10/14/2006 - bsnes v0.018 released
[...]
Changelog:
- OAM address reset now occurs when screen display is enabled, per recent research
- ...

I see NES emulators resetting the sprite address at the start of vblank when the PPU is enabled. Could someone confirm this and/or test if disabling or enabling the PPU resets the sprite address? (considering the assumption that the SNES hardware development team contained some who worked on the NES hardware)

Author:  blargg [ Sat Oct 14, 2006 1:28 pm ]
Post subject: 

Ask and ye shall find ye hath already received heh...

Also, Google is your friend for allowing a search of the message boards here: "sprite address blargg site:nesdev.com"

Author:  hap [ Sat Oct 14, 2006 2:23 pm ]
Post subject: 

Thanks, that must've slipped my.. erm.. scrollbar.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/