It is currently Wed Dec 12, 2018 7:20 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Fri Aug 31, 2018 9:02 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7817
Location: Seattle
Because for some reason, I haven't seen anyone else explicitly mention this ...

You could just have a set of lookup tables for each of the 4 steps of a fade.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 9:05 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
re: tepples, buffer.

Yeah, i think it is sound to prepare a buffer in ZP (if you can afford it - has someone actually topped out on zp?) or elseplace in RAM, for the Vblank period to pick up in case of a pending update, much like OAM. It also means you can can manipulate your buffer however you want.
Someone asked for a colour cycler on NESmakers.com, i made this little thing, which relies on having a buffer:

Code:
PickPaletteToCycle:
;notice -- this routine will clobber anything that is in registers a, x and y. If something in a,x or y needs to be stored for later use, do so before calling this routine.
lda #0 ; you can replace this with another literal, or a variable if you wish (expected values 0-7. Don't go higher or you'll run into some other RAM section)
asl a
asl a ;these multiply your literal or variable with 4 so we can get the right offset for each palette in increments of 4.
tax
CyclePaletteRightOnce:
ldy PalDataInRAM+3,x ;pocket colour 3 in reg y
lda PalDataInRAM+2,x
sta PalDataInRAM+3,x ;move colour 2 to 3
lda PalDataInRAM+1,x
sta PalDataInRAM+2,x ;move colour 1 to 2
sty PalDataInRAM+1,x ;move pocket (y) to 1
rts

(For NM* specifically though, PalDataInRAM is actually double the size as it stores 16 subpalettes in a buffer. 0-7(*4) is 2 full sets for background palettes, 8-15(*4) is the same for sprites. 0-3 seems derived from 4-7, and respectively so in the sprite region.

*NESmaker has different labels.
pending variable = updatePalettes
PalDataInRAM = bckPal
Also note that only 4-7 and 12-15 will actually get uploaded this way via its NMI palette uploader. This will not likely be the case when using the code snippet in your own engine, though.

_________________
http://www.frankengraphics.com - personal NES blog


Last edited by FrankenGraphics on Fri Aug 31, 2018 10:14 am, edited 5 times in total.

Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 9:13 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2124
Location: Fukuoka, Japan
@lidnariq

After everyone comment, since 4 steps seems the most common, yes, a lookup table could actually do the job. I know I'm using one to rotate the palette during gameplay so to fade in/out for an introduction would be a very easy way to do it. This way the palette is defined by hand for that specific fade.

I will keep that in mind if programmatic ones are not reacting properly. Thanks!


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 11:09 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3722
Location: Mountain View, CA
lidnariq wrote:
Because for some reason, I haven't seen anyone else explicitly mention this ...

You could just have a set of lookup tables for each of the 4 steps of a fade.

I did cover it in my post. :-)


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 1:30 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1765
FrankenGraphics wrote:
DRW wrote:
The $0D problem shouldn't be an issue because there's really no reason to use the gray colors in the $xD column in the first place. The shades in $x0 are pretty much identical.

This seems to be a fairly widespread notion, but fortunately for us artists, it's actually not true. I think the idea of them being close to the same has gotten popularized because, for some reason, fceux doesn't make a distinction between $00 and $2d, so $2d looks way too bright.

But independently from the question how close they look to each other, isn't it true that basically no game uses the gray colors in the D column, except for a handful of obscure ones?

As far as I remember, there are some issues with them, not only color $0D, but also the other ones. Something about the possibility that they might be rendered as black instead of gray or something like that.

The fact alone that basically no major NES game ever uses the colors in the D column would be reason enough for me to ban them from any of my games.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 1:38 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7817
Location: Seattle
Not only did plenty of games use the $xD hues, but in fact, plenty games even used the problematic color $0D. This has come up enough times before that we felt the need to make a page on the wiki about it.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 2:07 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7012
Location: Canada
Just FYI, adding that special case for $0D to the example code I linked in my earlier post is just another 4 bytes:
Code:
fade_apply_:
   ; in: A = value to subtract from palette, copying from nmt_buffer
   @sub = temp+0
   sta @sub
   ldx #32
   @loop:
      lda nmt_buffer+31, X
      sec
      sbc @sub
      bcs :++
      :
         lda #$0F
      :
      cmp #$0D
      beq :--
      sta palette-1, X
      dex
      bne @loop
   rts


I mean, you could also solve this with tables, but this is a lot more compact. (Also maybe takes an extra ~125 cycles but your fade frames are probably not CPU intensive to begin with.)

With tables you could easily redefine the steps arbitrarily (e.g. $30 > $10 > $00 > $2D > $0F) but it costs a bit of ROM space. You can also do more than 4 steps with tables (the harder question is what colours to use for those extra steps). Another alternative for a slow fade would be to flicker back and forth between steps to represent a blend between them. You can also try to use emphasis bits, turning on all 3 darkens everything a bit (though will white out the screen on an RGB PPU).

Hue shifts are also very fun and easy. Colours from $X1 to $XC can just be rotated to the next colour. Maybe doesn't really fit the bill of a "fade" but might add some extra animation to the fade mechanism just by having some more visible steps.


In my own use, I usually just want very quick fades. 4 frames is plenty to smooth off the feeling of suddenly cutting to black, and allows the user to get on with things quickly.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 2:14 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
@DRW

In addition to lidnariqs' confirmation that it was used, here's where the $xD colours can be problematic:

-playchoice10 (arcade machine)
-vs. system (arcade machine)
-famicom titler (obscure commodity in japan which had the famicom hardware bundled into a movie subtitle imprinting machine.)
-i think there was one more obscure licensed commodity in japan that used this.
-people who've modified their NES:es to use a PPU from one of the above, for example a pretty invasive RGB mod that surfaced some years ago and then faded into obscurity which iirc used donors from the above?

These systems will show black instead of the two gray tones. I think i read on the wiki this was intended by nintendo as a form of copy protection.

notice that the arcade boards use a quite different palette to begin with - much brighter. And they include a vivid yellow and some other clear base colours not present on the NES/famicom.

I'll link to the discussion we've had on this recently tomorrow. But anyway - $2d and $3d is within NES and famicom specs and were used. Arcade machines and PPU swap mods are not.
(It is nice to include a compatibility mode, or in lieu of that, at least note somewhere that it won't look quite as intended on playchoice etc).

_________________
http://www.frankengraphics.com - personal NES blog


Last edited by FrankenGraphics on Fri Aug 31, 2018 2:21 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 2:20 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7012
Location: Canada
FrankenGraphics wrote:
These systems will show black instead of the two gray tones. I think i read on the wiki this was intended by nintendo as a form of copy protection.

There were a few different playchoice Vs. System versions that had basically scrambled the order of colours in the palette. That was the copy protection. (This is only important if you want to put your game into a Playchoice 10 Vs. System machine though.)

The two greys were omitted from the one that didn't have this copy protection, actually. I think they were just left out because Nintendo didn't really use them for their games anyway (I think the $D column was an accident of design?). That's the version of RGB PPU that shows up in NES mods though, since it's otherwise compatible (excepting the emphasis problem).

It's all described here, I think: https://wiki.nesdev.com/w/index.php/PPU_palettes


Last edited by rainwarrior on Fri Aug 31, 2018 2:59 pm, edited 3 times in total.

Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 2:35 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7817
Location: Seattle
rainwarrior wrote:
There were a few different playchoice versions that had basically scrambled the order of colours in the palette. That was the copy protection. (This is only important if you want to put your game into a Playchoice 10 machine though.)
Vs. System. Not Playchoice.

Specifics are definitely rather immaterial, though; either way they're arcade machines of which many orders of magnitude fewer were made.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 3:31 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1765
FrankenGraphics wrote:
But anyway - $2d and $3d is within NES and famicom specs and were used.

Yeah, but I personally would still omit the D column completely.

Even if those colors were used, they were used rarely. And I don't know of any game by Nintendo itself where these colors were ever used at all.

Also, the fact that the dangerous black is in this very column shows me that the D column seems to be more of a curiosity and not a regular choice of colors.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 4:58 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2124
Location: Fukuoka, Japan
What came out of that thread is that I should be careful with that column of color once I work on the actual project :lol: For now I do not have original assets so I don't think they are using those color. I will confirm, just in case.

My goal is mostly a quick fade and once the colors are all black, I need to load the next image/text that will be shown during that state.

One thing I will need to check is for reloading new text, if I use the example in C from Shiru (which at first was not planing to) could be more then enough actually. I just don't know if there is something I need to be careful while disabling the screen for writing the new text, if the displayed image will be affected in some way. But I guess this is the subject of another thread if some problem occurs because I haven't made that part yet ^^;;


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 5:09 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1765
One more thing that you should keep in mind: Once all the colors are black, you still need to disable rendering, so that you can write to the PPU outside of vblank.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Sat Sep 01, 2018 2:21 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
Or you can keep rendering on at all times, even during screen transitions, and keep using the NMI handler for VRAM updates. That may seem inefficient, but if you already have a full VRAM update system in place, you might as well use it all the time, even when the screen is blank, and save some time by not writing new update functions.

Even if you draw the background one column or row per frame, making use of your existing scrolling engine's functions, it'll take significantly less than 1 second to redraw the entire background. In most cases, that's perfectly appropriate.

There are cases when you'd want lightning fast VRAM updates though, like in a multi-screen action game with no scrolling... if you're running and jumping through different screens, you'll want the switch to happen as quickly as possible, or the experience might be frustrating to the players.


Top
 Profile  
 
PostPosted: Sat Sep 01, 2018 2:27 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2124
Location: Fukuoka, Japan
Right now the current place where screens are updated during fade is for the story itself. When text is faded out, you may need to update the text or fade the background then update both.

Since my engine allows to change at any time the NMI with a custom routine, I could update the NMI for that specific state or even update many time during the state when different rendering is necessary. I will try at first to do it without such code and just in C with some code in a library, neslib like. If there is some artifact then I will just figure out something in the NMI and update during vblank.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 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 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