It is currently Mon Dec 18, 2017 4:09 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Jan 28, 2015 2:32 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Yeah, pretty sure that it's simpler than the DACs from the components themselves, it's just that, huh, it isn't that useful as I said. Another system that used the 16th bit was the 32X, which acted as a priority bit (it flipped the priorities of the 32X and Mega Drive layers), which was definitely a lot more useful. In the same vein, quite a bunch of image formats take the 16th bit as an 1-bit alpha mask.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 1:45 am 
Offline

Joined: Fri Feb 15, 2013 12:00 am
Posts: 27
tokumaru wrote:
The final issue I can think of, is that disabling sprites mid-frame is a risky task. If it's not done at a precise time or when the sprites are arranged in a certain way, you might get corrupted sprites the next frame or when they are re-enabled.


Could someone point me to the specifics of this, maybe it's on the wiki? I have in mind a split with 8 sprites on a line.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 4:22 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
tsu wrote:
Could someone point me to the specifics of this, maybe it's on the wiki? I have in mind a split with 8 sprites on a line.

It all started with this. It's a long thread, but I think there's a conclusion concerning how to avoid the glitch near the end of it.

Note that this is only when both sprites and background are disabled, which in when the PPU truly stops rendering graphics (and you can use $2006/$2007). If only one of the layers is disabled, the PPU only "masks" that layer off by not displaying its pixels, but still processes it internally.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 4:33 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
The sprite memory is dynamic ram that needs to be refreshed frequently (by being read or written to). Basically, it's only good enough to hold its data for the length of a vblank interval (~20 scanlines). Anything more than that and the data will start to decay (random bits will change over time).

I don't know if there are other issues than that with turning sprites on mid-frame, but it's perfectly fine to turn sprites off mid-frame and leave them off for the rest of the frame as long as you restore them with an OAM DMA on the next vblank. Edit: Apparently not? I've never encountered this problem, but read what Tokumaru has to say about it.


Last edited by rainwarrior on Mon Feb 02, 2015 1:34 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 6:46 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
I don't know if there are other issues than that with turning sprites on mid-frame

There are. Read that thread and you'll understand.

Quote:
but it's perfectly fine to turn sprites off mid-frame and leave them off for the rest of the frame as long as you restore them with an OAM DMA on the next vblank.

No no, there's a glitch that happens when you interrupt the refreshing process that happens during rendering. IIRC, when rendering is turned back on, the refreshing process will resume in a bad state and overwrite some of the OAM values, after you have updated them with the DMA, effectively corrupting sprites. To avoid this, you have to turn rendering off at a specific time in the scanline (near the end of it I think), and I believe that the sprites that are in range at the time play a part on it too, but I never understood the details of this glitch.

EDIT: Here's what tepples did to avoid the sprite corruption: viewtopic.php?p=76125#p76125


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 11:09 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
Now that the PPU's actual sprite processing behavior is better understood, here's the revised advice: You have to turn off rendering between x=128 + 6 * (number of sprites in range) and x=256. Get it as close as you can to the right side [TPIR]without going over[/TPIR] and you should be fine.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 11:31 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
tepples wrote:
Now that the PPU's actual sprite processing behavior is better understood

Didn't we have this information already when you first noticed the glitch? Also, I don't see anything in that wiki page that suggests how to deal with this problem.

Quote:
here's the revised advice: You have to turn off rendering between x=128 + 6 * (number of sprites in range) and x=256. Get it as close as you can to the right side [TPIR]without going over[/TPIR] and you should be fine.

So, in addition to aiming for the end of the scanline, the less sprites in range you have the safer you are? Sounds reasonable.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 1:28 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
tepples wrote:
Now that the PPU's actual sprite processing behavior is better understood

Didn't we have this information already when you first noticed the glitch?

Reply hazy, as I noticed the glitch in December 2008, and the page's revision history prior to 11 June 2009‎ was not saved.

Quote:
Also, I don't see anything in that wiki page that suggests how to deal with this problem.

I was giving the time to guarantee "n has overflowed back to zero (all 64 sprites evaluated)": 64 to clear secondary OAM, 64 to check all Y coordinates, and 6 more for each in-range sprite to copy tile number, attributes and X coordinate. This finishes by 176 when the maximum eight sprites are in range.


Correction: It's actually 128 to check all 64 sprites' Y coordinates because of the alternating reads and writes. This means it finishes by 64 + 2 * 64 + 48 = 240.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 2:30 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
tepples wrote:
This finishes by 176 when the maximum eight sprites are in range.

Interesting... So anything between 176 and 256 should work? That's a pretty decently sized window of time (about 26 CPU cycles). Good to know!

This information really should go somewhere in the wiki, written in a way that's clear to programmers even if they don't understand every tiny detail of the PPU's internals. Something along the lines of "if you need to disable rendering early, do it between pixels 176 and 256, otherwise you'll interfere with how sprites are evaluated and will possibly get corrupt sprites on the next frame, even if you do a sprite DMA".

Now that I think of it, the NES has a number of "gotchas" that people sometimes forget about. Things like this sprite glitch, the colors pointed by the VRAM address register being drawn when rendering is disabled, the alternate dot crawl pattern, the color that's blacker than black, the DPCM controller glitch, the audio channels clicking... Maybe we could make a page listing all of these gotchas, so that people can quickly validate their programs against it.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 3:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
Maybe we could make a page listing all of these gotchas, so that people can quickly validate their programs against it.

If you have anything to add to Errata, go ahead.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 4:42 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10172
Location: Rio de Janeiro - Brazil
tepples wrote:
If you have anything to add to Errata, go ahead.

Nice! I don't even know if I ever saw this page before, but if I did, I completely forgot about it.

Some items could be worded better, and others explained a little bit further (missing suggested workarounds?), but this is pretty much what I had in mind, and it will do the job just fine.

Personally, I find the name "errata" a little misleading, because the people who publish them are usually the same people who made the mistakes in the first place, and we're obviously not Nintendo.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 5:42 pm 
Offline

Joined: Fri Feb 15, 2013 12:00 am
Posts: 27
Thanks, tokumaru, that's the thread I was recalling. I just didn't bother using the search feature because my last search for "hblank palette update" returned nothing, but DuckDuckGo had it on the first result. Maybe I should have put "+" in front of each part. But I'm very appreciative of what we have.
I've been feeling guilty the last few days when I use an Internet search like Google: I saw on TV that just two Google searches uses enough power to boil a cup of tea.

That thread, I'm reareading it now. Two other things about it: 1) it reminded me that I can use any tile number for sprite zero, not just tile 0. 2) Is there any clarification about sprite0's solid pixel length: should it be 8px wide (mines 6) in order to be sure the hit will land. It doesn't seem logical that way. But it was asked in that thread. I shall finish reading.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 6:34 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19355
Location: NE Indiana, USA (NTSC)
I'm pretty sure sprite 0 hit will work even with only one opaque sprite pixel that overlaps one opaque background pixel, so long as it isn't at x=255, and it isn't at x=0 to 7 while the background or sprite layer is windowed off in $2001.


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 9:37 pm 
Offline
User avatar

Joined: Sun Jan 25, 2015 6:51 pm
Posts: 77
Location: Tokyo
This thread got a bit too technical for me so I kinda backed away (sorry about that) Thanks for all the input. I've decided to stick to 13 colours for the entire tilemap, and just do one split for the HUD.

rainwarrior wrote:
For instance, MMC5 8x8 pixel attributes were only used in 1 game, to my knowledge (Just Breed), and it was a Japan-only RPG. It's a thing you could technically pull off on an NES, but it's not characteristic of NES games at all.


Just a thought on this but the majority of Famitracker NES tunes use the VRC6 chip and that was used in 3 games? So based on that I think it's an artists job to get the most out of what the NES could do, not what the NES is characteristic of (like with chip tunes).

_________________
twitter: http://twitter.com/hawkun
Pirate Pop Plus - gameboy styled game for 3DS, WiiU & Steam


Top
 Profile  
 
PostPosted: Mon Feb 02, 2015 9:45 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3166
Location: Nacogdoches, Texas
You know, (I'm not really going to help with the topic, but) have you ever actually thought about making your game on the NES? (You probably already said so, but I'm just too lazy to look.) I just fail to see the point of going to the extreme that you are to try and replicate the original hardware when, obviously, you can just use the original hardware. :wink:


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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