Topic: Chillyfeez's Shadow Party Hack V 2.0

[chillyfeez]

Aha, I see...

Code: [Select]

Bit-Plane 0:        Bit-Plane 1:      Bit-Plane 2:       Bit-Plane 3:
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   0 0 0 0 0 0 0 0
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   1 1 1 1 1 1 1 1
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   0 0 0 0 0 0 0 0
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   1 1 1 1 1 1 1 1
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   0 0 0 0 0 0 0 0
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   1 1 1 1 1 1 1 1
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   0 0 0 0 0 0 0 0
0 1 0 1 0 1 0 1   0 0 1 1 0 0 1 1   0 0 0 0 1 1 1 1   1 1 1 1 1 1 1 1


Code: [Select]

55-33-55-33-55-33-55-33-55-33-55-33-55-33-55
0F-00-0F-FF-0F-00-0F-FF-00-0F-FF-0F-00-0F-FF

And I've actually watched the 3BPP->4BPP conversion happen for a tile, byte by byte, in Geiger's. At the time I wondered why it made sense to insert 00s in between each of the last 8 bytes, but now I get it.
3BPP uses 3 bit planes. All of the information for the fourth bit plane used by a 4BPP tile would be stored in bytes 11, 13, 15, 17, 19, 1B, 1D and 1F.

Well, that means I can pretty much abandon all hope of editing tiles on the fly in hex (not really that important, anyway) because the unpacking and re-packing of bits is way too complicated for my very human brain to do with any efficiency.

I guess this somehow makes the data easier or faster for the SNES to interpret? You don't have to explain why or how that is - it's probably deeper than I need to go.

[Squall]

Excellent work, m8!!! I'm proud of you!!!
Both task completed!

That was the hardest part - hard to explain, hard to code, and hard to understand.

I guess this somehow makes the data easier or faster for the SNES to interpret? You don't have to explain why or how that is - it's probably deeper than I need to go.

My speculation is - hardware. Usually by doing this weird for us things, they organize memory ... like a Bit-Plane in one memory chip. Then you can assign different processors to work on different chip memory simultaneously without interfering (internal multitasking).

The other possibilities is to have separate bus to each chip which will multiply the access to VRAM. For example if each bus is 8 bit and we have 4 banks with separate bus connection - that is effectively 32 bit bus (you can read 32bits in one bus tact).
That's exactly what contemporary video cards do - multiple cores for multitasking and wide bus to guarantee fast access to the VRAM. In the past GTX modifications had better performance, not because they have more cores or frequency, but wide bus, because the bus is quite a bottleneck for the performance.

Anyway we have only 2 things left: Sprites and Palettes. Both should be familiar to you so I'm only going to write SNES specifics. After that we may talk a little bit of DMA/HDMA and if you want finish the 2 ??? - Clipping & Scrolling of layers :)

[Squall]

IV. Palette
1. What is a Palette?
Our next abstraction is a Palette. Think of an artist painting a picture - although the picture may contain millions colors, while painting the artist take only couple of colors on a palette (tray/board) to draw specific areas of the picture. The same way, when the PPU draw a Tile, it uses a selection of colors named a Palette.

The number of colors in a Palette is tightly connected with the Layer BPP:
 - If a Layer is 4bpp, then the Palette contain 2^4 = 16 colors with indexes 0..15.
 - If a Layer is 2bpp, then the Palette contain 2^2 = 4 colors with indexes 0..3
 - How many colors we have in 8bpp?

2. Color (Palette Entry)
In each Palette entry 0 is a special - it is used for transparency. All colors are 16 bit in the format: 0BBBBBGGGGGRRRRR.
That is 5 bits for each component - Red/Green/Blue. In specialized books you will see this abbreviated as 5-5-5.

3. Palette memory
PPU contain dedicated memory of 512 bytes for Palettes, abbreviated as CGRAM. That memory can hold 256 colors. Depending of the Layer's BPP that memory is used differently:
- in 8bpp - we have 1 Palette containing 256 colors, entries: $00..$FF
- in 4bpp - we have 8 Palettes, occupying entries: $00..$7F
- in 2bpp (Mode 0) we have 8 Palettes for each layer: $00..$1F (BG1), $20..$3F (BG2), $40..$5F (BG3) and $60..7F (BG4)
* Sprites use 8 Palettes, occupying entries: $80..$FF

4. PPU Registers:

Code: [Select]

$2121: Address for accessing CGRAM (1b/W). This register selects the  word location (byte address * 2)
$2122: Data write to CGRAM (1b/W)
$213B: Data read from CGRAM (1b/R)
[i]*Since read/write return only 1 bite, you need 2 consecutive operations to get the whole color (16bits)[/i]


[chillyfeez]

3. Palette memory
PPU contain dedicated memory of 512 bytes for Palettes, abbreviated as CGRAM. That memory can hold 256 colors. Depending of the Layer's BPP that memory is used differently:
- in 8bpp - we have 1 Palette containing 256 colors, entries: $00..$FF
- in 4bpp - we have 8 Palettes, occupying entries: $00..$7F
- in 2bpp (Mode 0) we have 8 Palettes for each layer: $00..$1F (BG1), $20..$3F (BG2), $40..$5F (BG3) and $60..7F (BG4)
* Sprites use 8 Palettes, occupying entries: $80..$FF

Uh-oh... This is going to be a problem for this project.
In FFIV, every character portrait and every PC battle sprite has a dedicated palette. So to use every palette I was planning to use, that would be a minimum of 16 palettes (11 portraits + 5 battle sprites). That means that hardware limitations will definitely prevent me from using the method I had originally intended for this project.

So now I have to rethink how this is all going to work.

The easy option would be to eliminate the battle sprites from the picture entirely, then use a gray palette for "inactive" characters, only using the proper palettes for characters currently in the party. This is not my favorite option. I think it would look cheap.

So looking through the documentation. It looks like Mode 1 uses one 4-color BG and two 16-color BGs... how are the palettes allocated in Mode 1?
I assume sprites get 8 palettes regardless of mode? Would that mean, then, that in Mode 1 there are eight 4-color palettes for BG3 and six 16-color palettes shared by BG1 and BG2?
That still wouldn't be ideal - I'd still have to gray-out the portraits of inactive characters, but I could bring back the battle sprites (they could be a BG). Then, what I could do is have the active party's portraits in color, as well as the highlighted inactive character's portrait (all other portraits would share a grayscale palette)...

[Squall]

So looking through the documentation. It looks like Mode 1 uses one 4-color BG and two 16-color BGs... how are the palettes allocated in Mode 1?
I assume sprites get 8 palettes regardless of mode? Would that mean, then, that in Mode 1 there are eight 4-color palettes for BG3 and six 16-color palettes shared by BG1 and BG2?

Excellent observations, m8!
You actually answered to to your question :) and shared a good observation (something that I should had mention it): all 4bpp Layers share same pool of palettes.
Yes because of BG3 we loose 2 Palettes in Mode 1. Keep in mind that each BG could be turned off, so we can use all 8 Palettes.

Uh-oh... This is going to be a problem for this project.
In FFIV, every character portrait and every PC battle sprite has a dedicated palette. So to use every palette I was planning to use, that would be a minimum of 16 palettes (11 portraits + 5 battle sprites). That means that hardware limitations will definitely prevent me from using the method I had originally intended for this project.

Let me ask you something:
- What is the max number of colors for BG3 in Mode1?
- What is the max number of colors for BG1 in Mode1 with BG3 on?
- What is the max number of colors for BG1 in Mode1 with BG3 off?

Lets think globally:
We will have 14 different Palettes (6 from BG and 8 from Sprites). That may net you 210 different colors on the screen. That is close to VGA in PC. That is many times more colorful then 90% of all games for SNES.
Of course we can't use both Sprite & BG palettes from one Tile. Lets take the BGs - 6 palettes with max 90 colors. Lets say we use only BGs for the whole PHS. You have 90 colors and 6 palettes. You don't have to limit 1 portrait with 1 palette. You may use all 6 palettes from each portrait. Remember the limitation is a Pal for a Tile, but a portrait composed by 3x3 or 4x4 (not sure what you will use) may use all 6!!! Imagine how cool a portrait will look in 4x4 tiles (64x64 pixels) with 90 colors

[chillyfeez]

I think you might be misunderstanding my intentions for this project...
I'm not creating any new images or palettes for the PHS. The portraits I'll be using are the same portraits from the menu ("push X") screen. The portraits are already locked into a dedicated palette for each.
One of the primary goals of this hack is that it can easily be used as a base for other hackers' projects, so I want to avoid creating original content.

[Squall]

My goal is by knowing how things work, to give you (as an artist) the freedom to create. If you want to restrict yourself ... OK :D

[chillyfeez]

Oh, I know, and I do appreciate that, but I am necessarily restricted by the particular scope of this project.
That doesn't mean that I won't eventually have a creative application for what you're teaching me here, but I don't need all of it for this project.
Still, I'm using the tools you're providing here to formulate a workable plan for the project as originally conceived.

[chillyfeez]

Hello, dear readers.
Quick status update. There isn't much to show, since there is a lot of coding to do for what will end up being just one (dynamic) screen.
Here is the visible portion I have so far:


The window on the left will display the portraits of the characters currently in the party (except Cecil, as he will not be swappable). The small window to the right of that will display the name of the character the finger cursor is pointing at. The large window on the right will display the portraits of the available characters not currently in the party. Due to palette limitations, those portraits will be displayed in black and white until pointed to by the finger. The small space in between the windows towards the top will show the battle sprites of the current party (including Cecil).

There's a lot to do, and the going is slow, but this is really happening!

[Swordmaster]

To quote Alucard from Castlevania: Symphony of the Night, "I'm interested in this."

[Squall]

Sorry chillyfeez, just for the sake of completion: SNES PPU Tutorial

[chillyfeez]

Cool, Squall, good to have the whole thing in one place.

I haven't had a whole lot of time to work on the project lately. I got a couple of hours in today, but it was all background stuff - literally and figuratively.

A couple of days ago I took out the routines that draw the battle character graphics into the Namingway screen as sprites, because in this mod they'll actually be part of a BG screen. Then I wrote the first part of the routine that will load the battle character tiles into VRAM. But today I realized that the same routine I removed also draws the battle character images in the Load Saved Game screen, so today was spent reworking those changes so that the sprites still load there, but not in my PHS screen.

Anyway, blah-blah-blah, right? I'll keep you guys updated as I make progress when there is progress worth mentioning.

[Gedankenschild]

The 3bpp to 4bpp explanation was interesting to read. I kinda knew it already but couldn't have explained it myself with the right terminology. Lots of good info here.

Did you consider using overworld sprites for the selection screen, chillyfeez? That would only require 3 (or is it 4?) palettes due to the sharing.

[chillyfeez]

It's 4, and I did consider it for that reason, but in the end I think those images are too small relative to the screen.
I'm pretty sure the plan I've got will work, and it should look pretty cool once I've got it all working.
Is Squall's tutorial responsible for the better understanding you spoke about on RHDN?

[thepatirckinator]

I'm sure that Cecil cannot be replaced like other 2D Releases of Final Fantasy IV.