øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;sa=messages;u=65e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index663d-2.htmllayedslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=65e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index663d-2.html.zxaÙg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ@P/V³OKtext/htmlISO-8859-1gzip@øÕV³ÿÿÿÿÿÿÿÿÑHTue, 10 Mar 2020 18:32:24 GMT0ó°° ®0®P®€§²ð®`Ùg^ÿÿÿÿÿÿÿÿ&V³ Show Posts - Vehek

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Vehek

Pages: 1 2 3 4 5
1
It's been a long time since I worked on this, but I'll try.

I didn't keep direct notes, but reviewing the scripts I used, it looks like each block of 0x80 bytes defines a set of corners, as in one corner of each 16x16 tile. Top left, top right, bottom left, bottom right.
Quote
Is this read differently from the graphics for, say, the ship/airship tileset?
Very different. Those are planar graphics, where the bits are spread across bytes. Here, the bits are consecutive in one byte. Each nybble (4 bits) is one pixel.

Then two bytes per tile for the palette assignment table?
It's one palette byte for each 8x8 tile. You can't palette-swap mode7 tiles with map data. By the time they're sent to VRAM, they've already been assigned colors on the pixel level.

avalanche also looked into this in the past, and wrote about it in the FF4kster thread.
This probably deserves a longer tech post, but the crux is that each 8x8 graphics tile is stored in the special 4 bpp format and has 1 byte in this "palette pointers" section that you just add (or 'or', either way) to each pixel's value.  That's the final color index for each pixel, which happens to be effectively only 6-bit color index because those bytes only have certain values.  And that matches with the fact that the palettes for each world have 64 entries in them.

2
Quote
The assembly must do some crazy stuff to get this ready for the PPU...
Overworld is Mode7. Mode7 uses 8bpp tiles with no bitplanes. All it has to do is split up the nibbles and combine them with palette assignment data (ff4.txt called this the "World Map Tile Palette Pointers").

3
Why does everyone consider the world map tiles a mystery? I guess nobody paid proper attention to what I said about them last year in the overworld data thread. They're 4BPP, but not the type you're probably familiar with. In Tile Molester it's "4BPP linear, reverse-order", and other tile viewers may call it "GBA 4BPP".
Edit:
Tile Layer Pro calls the format simply "GBA".

4
Do you know of a program that is capable of editing world map tiles? Tile Layer doesn't seem to be able to view them properly.
I haven't checked Tile Layer yet, but are you using the correct tile encoding, since it's not in 4BPP SNES? The tile format is called 4BPP GBA in YY-CHR.
Or if you meant the assembled tiles, I don't have a good method for viewing them. The tileset images were made by having a program use the tile assembly data to write out the tile graphics to a file, which I then viewed in a tile viewer.

Quote
Obviously there are quite a few unused tiles in the Underworld and Moon tilesets (and one in the Overworld). It would be great to be able to change the graphics of these tiles and actually put them to use.
I wouldn't say there are really that many available. Keep in mind that each 16x16 tile is made up of 4 8x8 tiles. There are very few unused 8x8 tiles, if any. Except for the moon, which doesn't have a full set of 256 8x8 tiles. While it's possible to turn those unused 16x16 tiles into new combinations of the 8x8 tiles, there probably aren't enough unused 8x8 tiles to insert many new graphics into.

Let's see...

  • There are no spare 8x8 tiles in the overworld
  • There are maybe 4 spare blank 8x8 tiles in the underworld.
Haven't yet accounted for some of the used blank 8x8 tiles maybe being leftover and not really needing to be used instead of other blank tiles.

5
Here are some generated tilesets for the world maps.

6
These are unheadered offsets.
0A0000: Overworld tile assembly data
0A0200: Underworld tile assembly data
0A0400: Lunar tile assembly data

0A0600: Palette assignment data (overworld)
0A0700: Palette assignment data (underworld)
0A0800: Palette assignment data (lunar)

0A0900: Palette Data (Overworld)
0A0980: Palette Data (Underworld)
0A0A00: Palette Data (Lunar)


0E8000: Overworld subtile graphics
0EA000: Underworld subtile graphics
0EC000: Lunar subtile graphics
(4bpp linear reversed, combined with palette assignment data to make 8bpp subtiles)

7
Game Modification Station / Re: FF6 Overworld sprite pointers
« on: June 19, 2013, 09:48:20 PM »
Was that really what Edrin was asking? I don't see what PC slots have to do with this. I thought Edrin was expanding sprite sheets to player character-completeness.

The sprite pointers in towns and the overworld are split up. The lower 16-bit offsets are at 0xD0F2 while the bank byte and another value are at 0xD23C.

I don't know where this routine is used, but it's the only one in the disassembly that labels what these particular offsets are.
Code: [Select]
C0/69A3: BFF3D0C0 LDA $C0D0F3,X (Loads pointer to Map character graphcis)
C0/69A7: 852B    STA $2B
C0/69A9: 852E    STA $2E
C0/69AB: 8531    STA $31
C0/69AD: 8534    STA $34
C0/69AF: BF3CD2C0 LDA $C0D23C,X (Bank pointers and Number of Bytes to Copy per Tile for Map Char Gfx)
C0/69B3: 852C    STA $2C
C0/69B5: 852F    STA $2F
C0/69B7: 8532    STA $32
C0/69B9: 8535    STA $35

The routine for the behind-view sprite used when riding a chocobo is in bank $EE. It does not access a pointer table, instead calculating an address based on the assumption that all sheets are 0x16A0 bytes long.

Code: (Novalia's Disassembly: Overworld chocobo rider sprite) [Select]
EE/8943: ADFB11  LDA $11FB      (Sprite number for map character)
EE/8946: 8D0242  STA $4202      (Save as multiplicand)
EE/8949: A9A0    LDA #$A0
EE/894B: 8D0342  STA $4203      (Set multiplier to 160)
EE/894E: EA      NOP
EE/894F: EA      NOP
EE/8950: EA      NOP
EE/8951: AE1642  LDX $4216      (Product)
EE/8954: 866A    STX $6A        (Save the address temporarily)
EE/8956: A916    LDA #$16
EE/8958: 8D0342  STA $4203      (Set multiplier to 22)
EE/895B: EA      NOP
EE/895C: EA      NOP
EE/895D: EA      NOP
EE/895E: AD1642  LDA $4216      (Load low byte of product)
EE/8961: 18      CLC            (Clear Carry for addition)
EE/8962: 656B    ADC $6B        (Add middle byte of address)
EE/8964: 856B    STA $6B        (Save updated address)
EE/8966: AD1742  LDA $4217      (Load high byte of product)
EE/8969: 656C    ADC $6C        (Add to high byte of address)
EE/896B: 856C    STA $6C        (Save updated address)
EE/896D: 18      CLC            (Clear Carry for addition)
EE/896E: A56A    LDA $6A        (Low byte of address)
EE/8970: 6980    ADC #$80       (Add 128)
EE/8972: 856A    STA $6A        (Save changes)
EE/8974: A56B    LDA $6B        (Middle byte of address)
EE/8976: 6901    ADC #$01       (Add one, or two if an overflow occurred)
EE/8978: 856B    STA $6B        (Save changes)
EE/897A: A56C    LDA $6C        (High byte of address)
EE/897C: 69D5    ADC #$D5       (Add #$D5, or #$D6 if an overflow occurred)
EE/897E: 856C    STA $6C        (Save changes; D5/0180+X)

8
Gaming Discussion / Re: How to break FF6
« on: July 14, 2012, 12:10:16 AM »
I believe the airship bug is very old news around here. Well, at least, the experts around here should know of it, since they were at Mnrogar's back when it was first revealed.

9
"copies the character names to memory".... hmm this could be why one only sees a garbled mess if you assign a character any name past anna's, its just copying junk or nothing at all....? nah thats just a guess...
The game normally only copying the first 14 names isn't the only problem. Have you noticed that the "Name, Battle Commands, Equip able hands." values don't necessarily correspond to the order of the names? The game uses tables to determine which name it should load.

Code: (Menu) [Select]
$01/83B4 BF 57 84 01 LDA $018457,x
$01/83B8 0A          ASL A
$01/83B9 85 45       STA $45    [$00:0145]
$01/83BB 0A          ASL A
$01/83BC 65 45       ADC $45    [$00:0145]
(...)
$01/83CE BD 00 15    LDA $1500,x

Code: (Battle) [Select]
$02/A67E BD 00 20    LDA $2000,x
$02/A681 3A          DEC A
$02/A682 29 3F       AND #$3F
$02/A684 AA          TAX
$02/A685 BF 3F FB 16 LDA $16FB3F,x
$02/A689 85 26       STA $26    [$00:0026]
$02/A68B A9 06       LDA #$06
$02/A68D 85 00       STA $00    [$00:0000]
$02/A68F 85 28       STA $28    [$00:0028]
$02/A691 20 60 85    JSR $8560  [$02:8560]
These tables could be considered to be 1-based arrays. Both have data/code following them, so they have to be moved in order to extend them.

I tried moving the first table elsewhere so I could add more values. Even with the extra values, I only got two additional names working. The range of memory after that was overwritten with other data, making the names there vanish.

10
There's more than one place where it does this for some reason, but when a new game is started, it copies the character names to memory.
Code: (New-game names) [Select]
$01/9B36 A9 53 00    LDA #$0053
$01/9B39 A2 10 A7    LDX #$A710
$01/9B3C A0 00 15    LDY #$1500
$01/9B3F 54 7E 0F    MVN 7E 0F
The 0x0053 is how many bytes to copy. In a headered ROM, this code's at offset 9D36.

11
SPC - Hard Core / Re: Live a Live
« on: June 04, 2011, 04:45:13 PM »
Well, in the ROM I'm using, the pointers there match your "Pointers to something part 2".

On a different note, back when I read Japanese RS3 documents, IIRC, they believed that LAL indeed uses the RS2 version of the engine, but without the weird tempo difference.

12
SPC - Hard Core / Re: Live a Live
« on: June 04, 2011, 03:07:44 AM »
Are you sure you've got the right data there? My quick research says the SPC pointers are at 0x3426C. Maybe you're looking at the BRR data.

Here's a list I've generated.
Code: [Select]
0x00: silence
0x01: Prelude To The Demon King
0x02: Difficult Fight
0x03: Sound Of Shinobi
0x04: Wanderer
0x05: Killing Field!
0x06: The Wilds
0x07: Under the Fake
0x08: Unseen Syndrome
0x09: Native Life
0x0A: Wait For Truth
0x0B: A Painful Death At The Hands Of A Psycho
0x0C: Martial Arts Masters
0x0D: The Bird Flies In the Sky, The Fish Swims In the River
0x0E: War In China
0x0F: unknown
0x10: Knock You Down!
0x11: unknown
0x12: unknown
0x13: unknown
0x14: The Ancient Master Descends From the Mountains
0x15: Nice Weather Ain't It!
0x16: Kiss of Jealousy
0x17: Secret Mission
0x18: Go Go Buriki King!!
0x19: Wings That Don't Reach
0x1A: Journey To The Mountain Of The Demon King
0x1B: The Demon King Odio
0x1C: Pure Odio
0x1D: unknown
0x1E: unknown
0x1F: unknown
0x20: unknown
0x21: unknown
0x22: unknown
0x23: unknown
0x24: unknown
0x25: Select-A-Live
0x26: unknown
0x27: unknown
0x28: unknown
0x29: unknown
0x2A: unknown
0x2B: Megalomania
0x2C: unknown
0x2D: unknown
0x2E: unknown
0x2F: unknown
0x30: unknown
0x31: unknown
0x32: unknown
0x33: Ultimate Strength - Victory Road
0x34: Live-A-Live
0x35: Cry-A-Live
0x36: Warm-A-Live
0x37: City of Hopelessness
0x38: Sancho de Los Panchos
0x39: unknown
0x3A: unknown
0x3B: Sacrificial Feast
0x3C: Silent Labyrinth
0x3D: Armageddon
0x3E: unknown
0x3F: Captain of the Shooting Stars!
0x40: unknown
0x41: unknown
0x42: unknown
0x43: unknown
0x44: Live Over Again
0x45: Live For Live
0x46: unknown
0x47: unknown
0x48: unknown
0x49: Captain Square
0x4A: unknown
0x4B: Illusion...
0x4C: Versus!
0x4D: unknown
The facts that I can match sequence data in an SPC to sequence and that people make SPC collections help me generate lists like this quickly.

13
Final Fantasy IV Research & Development / Re: Who Appears in Scenes
« on: May 22, 2011, 07:11:26 PM »
Phoenix posted the kind of information you want before, over here.

14
Game Modification Station / Re: Increasing Esper Name length to 12 Letters
« on: December 08, 2010, 11:48:15 PM »
0A is the ASL opcode, not a value.
ASL mulitplies by 2. Can you figure it out now?

15
Final Fantasy V Research & Development / Re: FFV Sprite editing
« on: November 11, 2010, 06:45:47 PM »
Two weeks ago, I was investigating FF5's compression, so I have some information in case you don't have it already. Bartz+Boco are part of a compressed block starting at 031E84. The stuff Jorgur messed with that affected position is part of a packet at 031D49.
The main compression routine is in bank $C3. (However, this routine isn't used for Bartz+Boco. A variant from a compressed block of routines is used instead.)
The compression is similar to FF6's, with at least two major differences:
  • The first two bytes are the decompressed size in FF5, not the compressed size. So, the decompression routine ends when it's written that many bytes
  • (This is very badly worded.) In the second byte to of a compressed/repeat-data-block, the bit-positions of the amount to copy and the bits for the offset are switched compared to FF6. That is, the upper 3 bits are the offset, the lower 5 bits after adding 3 to the number tell how many bytes to copy.

Pages: 1 2 3 4 5