It is currently Sun Oct 22, 2017 9:35 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Tue Sep 20, 2005 12:46 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
The color written at $3f00, that is mirrored to $3f04, $3f08, $3f0c, $3f10, $3f14, $3f18 and $3f1c, is the transparent color. Only writes to $3f00 and $3f10 are taken care (so a write, for example to $3f1c, is without effect).


This is what is confusing people; the values in the palette at $3f00 are irrelevant for the determination of transparency. Transparency isn't about what you see on the screen (though what you see might match it); it's about what is considered opaque and what is considered transparent.

Like I said before, all that matters are low two bits of the palette index of the pixel, as specified by the CHR (tile) data. CHR data specifies only the low two bits of the palette index. If all you had was the CHR data for a given background and sprites, if you didn't know the palette or the attribute bits, you could still determine which pixels of the background and sprites will make it to the screen.

It's not about ROY G BIV! :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 22, 2005 1:55 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
blargg wrote:
Quote:
It's not about ROY G BIV! :)


Eh???

OK thanks to you guys and now have correct sprite transparency effect, but there is one more thing bothering me. If a sprite's pixel is 0 then it has no priority, but if it is 1-3 then it has priority. Is this correct? Also Sprite 0 has a higher priority then Sprite 63?

What I am having trouble with is Castlevania, when you enter the castle you are supposed to disappear like Mario does when he goes down a pipe, but for some unknown reason you do not disappear.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 22, 2005 2:01 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
You must track the visible sprites, the drawed sprites. Go from 0 to 3Fh - a solid sprite is pattern AND 3. If true, check the priority bit - for LOW priority, you allow a new sprite pixel only if there's no pixel (sprite OR background at current location); else, if HIGH priority, you draw it.

Code:
                  64 SPRITES
SPRITE #0 ------------------------- SPRITE #3F
 HIGH PRIORITY -------------- LOW PRIORITY


Amem. ^_^;;

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 22, 2005 2:34 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
WedNESday wrote:
f a sprite's pixel is 0 then it has no priority, but if it is 1-3 then it has priority. Is this correct?


A pattern value of 0 is transparent... so I guess you could say it has no priority. So yes @ this... even though it's kind of worded weird.

Quote:
Also Sprite 0 has a higher priority then Sprite 63?

Yes. Sprite 0 is always drawn 'on top' of all the other sprites. Sprite 63 is always drawn below the other sprites.

As for your Castlevania problems... I don't really know what the game is doing to pull off its effect... so I can't really help you much more than explaining the general workings.

Probably what the game is doing is putting an opaque sprite with background priority right where the game wants simon to disappear. Simon likely has foreground priority, but a HIGHER sprite number (indicating he has lower priority than the sprite which is there to "hide" him).

What will happen is... sprite priorities are calculated first ... so that when Simon and the Hide sprite overlap... the NES will look at them and see the Hide sprite has a higher priority than Simon... so it will take the Hide sprite's pixels and compare those to the BG. Since the Hide sprite has background priority, the BG wins and gets displayed to the screen.

What you might be doing... is you might be letting Simon win the priority fight because he has foreground priority... even though he has a higher sprite number than the Hide sprite.

That's just a guess though.... like I said I don't really know what trick CV is pulling.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 23, 2005 11:09 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
See if this concise summary helps.

A transparent pixel is one for which the lowest two bits of the palette index are clear (index AND 3 = 0). For each pixel on screen, do the following:

- Scan through the first 8 sprites that intersect the pixel, starting at sprite 0 (there may be fewer than 8 that intersect a given pixel, of course). Stop on the first sprite whose pixel is non-transparent. The result of this is either nothing, or a single non-transparent sprite pixel. The sprites are not scanned any further.

- If a non-transparent sprite pixel was found and either a) the sprite is in front of the background (bit 5 of attributes is clear), or b) the background pixel is transparent, then draw the sprite's pixel.

- If a sprite pixel wasn't drawn and the background pixel is non-transparent, draw the background pixel.

- If neither sprite nor background pixel were drawn, then draw pixel as palette index 0.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 23, 2005 2:49 pm 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
Thanks everyone, now I have it sorted (it was my own fault lol)...

_________________
http://www.jamesturner.de/


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 23, 2005 8:50 pm 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Quote:
You must track the visible sprites, the drawed sprites. Go from 0 to 3Fh - a solid sprite is pattern AND 3. If true, check the priority bit - for LOW priority, you allow a new sprite pixel only if there's no pixel (sprite OR background at current location); else, if HIGH priority, you draw it.


Maybe i missunderstood something fx3, but you are advicing him to go from sprite 0 to 63?
If it is that the case the emulation will not be ok.
Sprites have temporary memories that only can hold 8 sprites and 2002.5
is set if its found one more and the other are not drawn on the screen (thats becouse a real nes show flickering whem 8+ sprites are in the same scanline).

WedNESDay: i dont know if your engine is pixel by pixel or whatever, but you should limit the sprites that are visible.
Trying to draw all 64 sprites will give (of course) a better sprite image on screen (no flickering) but will not behave like a real NES.

fx3: as i said if i missunderstood something take it if i had say nothing. :)

_________________
ANes


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 24, 2005 4:52 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Quote:
Trying to draw all 64 sprites will give (of course) a better sprite image on screen (no flickering) but will not behave like a real NES.


Remember, the NES sprites do not inherently flicker; all flicker is done intentionally in software (as an alternative to having some (portions of) sprites just disappear). Also, not emulating the limit of 8 sprites per scanline enhances some games, but causes graphical errors on others which use some sprites to mask others (you could allow the user to choose which they want).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 24, 2005 10:44 am 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
Thanks for all of the replies but I have managed to solve the problem now.

Btw, WedNESday draws the screen on a scanline for scanline basis.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 24, 2005 7:16 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Anes wrote:
Maybe i missunderstood something fx3, but you are advicing him to go from sprite 0 to 63?
If it is that the case the emulation will not be ok.
Sprites have temporary memories that only can hold 8 sprites and 2002.5
is set if its found one more and the other are not drawn on the screen (thats becouse a real nes show flickering whem 8+ sprites are in the same scanline).


Supposely, you evaluate ALL the sprites at clock cycle 256. ^_^;;
Yes, there's a 8-sprites buffer, indeed, which follows the same rule for priority.

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 24, 2005 8:41 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
Fx3 wrote:
Supposely, you evaluate ALL the sprites at clock cycle 256. ^_^;;
Yes, there's a 8-sprites buffer, indeed, which follows the same rule for priority.


No you don't, but that's how most emulators do it. If you want to do it 100% correctly, you evaluate them while the scanline is rendered using a procedure I described in a topic somewhere around here...

_________________
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: Sun Sep 25, 2005 9:35 am 
Offline

Joined: Sat Nov 13, 2004 6:25 am
Posts: 96
Are there any NES programs who behave differently depending on which of those two methos is used to emulate the PPU?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 25, 2005 10:16 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Quote:
Fx3 escribió:
Supposely, you evaluate ALL the sprites at clock cycle 256. ^_^;;
Yes, there's a 8-sprites buffer, indeed, which follows the same rule for priority.
Quote:
No you don't, but that's how most emulators do it. If you want to do it 100% correctly, you evaluate them while the scanline is rendered using a procedure I described in a topic somewhere around here...



Thats right if you read brad doc it says that sprites are evaluated during scanline render wich gives you 256cc / 64sprites: 4cc takes each evaluation. so you should have a counter that when 4 cc pass evaluate sprites 0.. etc. Which i really dont know if scanline cc 0 evaluates first i mean:

Code:

static BYTE cc = 0;

 if (cc_sprites == 0)
   //Check Sprite In Rage and test how many
   cc = 3;
 else
   cc--;



OR

Code:

static BYTE cc = 0
 if (cc_sprites == 3)
   //Check Sprite In Rage and test how many
   cc = 0;
 else
   cc++;



Checking all 64 sprites in a sinlge cc, is not accuratest at al (maybe some games uses it WedNESDay) and if you keep checking after a 8+ has been found its a waste of time to your emulator, you should stop checking when sprite 7 (0 - 7) is in range and reset you "csprites in ranges" var.

I really dont know if games take adventage of it, but the only thing i know is that when i uses the method i explained above, battletoads didnt hang and when i use the "one cc check all sprites" battletoads started to hang (altmost for me).

_________________
ANes


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 25, 2005 10:23 am 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
WedNESday draws the screen (and has no issues with priority or anything else) by drawing the scanline and then going back and drawing the sprites on a pixel for pixel basis. When it has found 8 sprites it then stops. So far this method is very simple and proves very accurate.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 25, 2005 10:27 am 
Offline
User avatar

Joined: Tue Dec 21, 2004 8:35 pm
Posts: 600
Location: Argentina
Quote:
WedNESday draws the screen on a scanline for scanline basis.

mmm... scanline rendering (if you are rendering optimized) will give you a liittle more speed in the emulator, but it will not be accurate, there are some programs or games that do H split effects and you will not detect that.
Another thing is cc calc, its a little more complicated when its by scanline.

I suggest you change by pixel. I ussed scanline basis in my emulator dev beggining and i gave a lot of problems regarding cycles calc and those things.

Sprite 0 hit is another issue can you detect exactly when its hited.

And remember that a scanline is 341/3 cpu cc not 256 ppu cc.
256 is for rendering the playfield and the other falls in hblank.

_________________
ANes


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

All times are UTC - 7 hours


Who is online

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