It is currently Thu Dec 14, 2017 2:03 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: sprite address
PostPosted: Thu Aug 04, 2005 10:58 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 4:45 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
(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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 10:28 am 
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.


Top
  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 12:39 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 4:13 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 5:42 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 7:33 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 14, 2006 9:39 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
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)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 14, 2006 1:28 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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"


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 14, 2006 2:23 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Thanks, that must've slipped my.. erm.. scrollbar.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: calima, krzysiobal and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group