Author
|
Topic: SNES color math (sprite palette 0-3) (Read 1 times)
|
FinS
Guest
|
 |
« on: August 14, 2011, 06:15:03 pm » |
|
I've read in a few documents that sprite palettes 0 through 3 cannot participate in color math. I need to figure out a way to do it anyway and I have found an example in a game where it seems to happen. I wonder if anyone can look at this and give me an idea of how it might work.  I tested this in Vsnes. In this screenshot the mage is being hit with an inferno attack, the mage is using sprite palette 3 and the paladin in front of him is using sprite palette 1, both at priority 2. They both look like they are participating in color math with the inferno which is in BG2 using palette 3 priority 1. The code sent to the color math register $2130 is #2202, so $2130 would receive bits "0000 0010" and $2131 would receive "0010 0010" which according to documentation translates to 'add subscreen', 'enable color math with BG2 and backdrop', 'add colors'. This also makes it seem as though there is a color math operation involving sprite palettes 1 and 3. I forgot to mention that this is in mode 1.... could be important. correction: "0010 0010" sent to $2131 would translate to 'enable color math with BG2 and backdrop'
August 14, 2011, 08:07:38 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Does backdrop mean everything that would normally appear on the screen, including sprites utilizing lower palettes, which would explain why it is possible to do color math on them? |
|
|
|
« Last Edit: August 14, 2011, 08:07:39 pm by FinS »
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #1 on: August 15, 2011, 01:23:06 pm » |
|
I think I see what's going on here. By "not participate in color math", it means cannot be affected by color math when on the main screen. I'm going to assume that BG2 is disabled on the sub screen, as you'd probably not want to add it to itself. The main screen image is probably just BG2 and the backdrop. The backdrop you can think of as a sort of empty default window. That is, what would be displayed on screen in the absence of any tiles (i.e. all tiles are transparent). The color you see as the backdrop is the first color in CGRAM. The backdrop is only on the main screen, but it doesn't necessarily have to participate in color math. In your example, however, it is clearly participating. Notice that color math affects the *visible* pixel on the main screen. With this setup, every top most or "visible" pixel is either from the BG2 inferno or from the backdrop. So I think it is configured like this, and you can check registers $212c / $212d to confirm:
main screen ($212c):
BG2
sub screen ($212d):
BG1
OBJ (sprites)
To help understand what's going on, imagine that BG1 and the sprites are not there, and you've just got your BG2 inferno on the main screen. Presumably the background is completely black in this scene. If you set $212d to zero, you'd probably see something just like that. What happens in the end though, is that BG1 and the OBJ layer get added to the inferno, even though it would appear to be the other way around. As long as the player can't tell the difference, who cares?
|
|
|
|
|
FinS
Guest
|
|
« Reply #2 on: August 15, 2011, 05:22:38 pm » |
|
You're correct!
$212c is #06
BG2
BG3 (BG3 is just that small window with the word "INFERNO")
$212d is #11
BG1
OBJ
And I just noticed Geiger's debugger will print that out under the "what's used" button, but I have to be careful because he uses different background numbers.
I think I get it now but let me try to rephrase it to make sure:
Sprites(0-3) must be on the sub screen in order to participate in color math since they cannot do it directly or on the main screen. I'm guessing the 2nd bit of $2130 is set to indicate the sub screen is used as the backdrop in this instance so the equation must be between the backdrop and a layer in the main screen.
|
|
|
|
« Last Edit: August 15, 2011, 05:30:40 pm by FinS »
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #3 on: August 16, 2011, 12:25:52 pm » |
|
I think you get the gist of it, but I must be cautious in agreeing to the whole thing. I'm guessing the 2nd bit of $2130 is set to indicate the sub screen is used as the backdrop in this instance so the equation must be between the backdrop and a layer in the main screen. This is the portion I wanted to correct a bit. The main screen is what is always displayed regardless of anything. Of course, its elements, and those of the subscreen, can be disabled. The subscreen's only purpose* is to manipulate the mainscreen when the appropriate setting in $2130 is enabled (the 's' bit). However, it is invisible for all intents and purposes otherwise. * The subscreen is also used for hi-res, but I'm ignoring that here. |
|
|
|
|
FinS
Guest
|
|
« Reply #4 on: August 16, 2011, 04:31:19 pm » |
|
Yeah, $2133 is set to zero at the beginning of the scene but you were probably able to tell that hi-res was disabled somehow. Thanks MON, you've made it more clear to me. I should have remembered the backdrop is the first color of the palette, which is {0,0,0} in this case, so I guess it would be transparent unless it was the only thing left to show. Maybe I could think of it like a film between the main screen and subscreen that I can only see where the other 2 are empty. I just found the data for some of the registers in ram so I can edit that and it should give me a decent understanding of the process.
August 16, 2011, 09:06:29 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Here's what I've got so far.  The sparklies(bg2) were moved to main screen, and bg1 and obj moved to sub screen. I need them to only cover the blue sprites but at least the trick I've learned here is working. Just have to figure out another puzzle. |
|
|
|
« Last Edit: August 16, 2011, 09:06:29 pm by FinS »
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #5 on: August 19, 2011, 04:55:11 pm » |
|
I think you'll have a real tough time doing that so long as the sprites are using palettes 0 through 3. One common technique is to temporarily swap palettes to allow certain sprites to participate in color math. That is, swap palette numbers and actual palette color data with the sprites that do not need to undergo color math. In some games and situations that would probably not be feasible, but it looks to me like it is in this situation. What game is that btw, Ogre Battle? It looks familiar but I've never played Ogre Battle or Tactics Ogre so I wouldn't recognize it right off the bat.
|
|
|
|
|
FinS
Guest
|
|
« Reply #6 on: August 19, 2011, 06:12:43 pm » |
|
It is the first Ogre Battle game. Actually it's episode 5 but I can't say whatever happened to episodes 1 through 4. They could be on paper somewhere or maybe they've already been forgotten about.
I think the palette swap idea would work and that's actually what it already does normally except it doesn't make use of the palettes it swapped from, therefore it had this 1 wasted palette that I've been trying to free up. It's the reason you see only 2 types of enemies on the other side. Everything in the game says you should be able to add another enemy except the last palette needs to be freed up for it.
|
|
|
|
|
|
