+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  SD2 R.E. - Actual Dev Environment Encoding of Mode7 Over World.
Pages: [1]
Author Topic: SD2 R.E. - Actual Dev Environment Encoding of Mode7 Over World.  (Read 2 times)
jargon
Guest
« on: September 02, 2008, 10:48:00 am »

I have been attacking the SD2 (SoM) over world again.

My goal is to figure out the original formatting the over world was in while the Square/(Enix?) development team was working on the game.

This time it took 8 continuous hours roughly of processing to breakdown the raw image dump.

Apparently, the SD2 mode7 over world appears to use a 96 color palette with 4x2 tiles; Plus I still have yet to take 4 way mirroring into account.

This will take a couple more weeks of additional processing before I am done with my analysis though.

 :banghead:
MathOnNapkins
Guest
« Reply #1 on: September 02, 2008, 02:39:39 pm »

Why can't you just look at the data in the rom and draw conclusions from that? It sounds like you're doing a lot of unnecessary work. 2 weeks of processing? What in the world are you doing?
Nightcrawler
Guest
« Reply #2 on: September 02, 2008, 08:14:51 pm »

Why don't you just make a savestate while on the overworld and open up VSNES? That would probably let you discover a large amount of information very quickly. That's what I would do. That program is a great time saver when trying to figure out how a screen is put together. The only thing it can't handle is certain HDMA effects for obvious reasons. Mode7 should be covered and covered well though.
jargon
Guest
« Reply #3 on: September 05, 2008, 11:42:45 am »

Quote from: Nightcrawler on September 02, 2008, 08:14:51 pm
Why don't you just make a savestate while on the overworld and open up VSNES? That would probably let you discover a large amount of information very quickly. That's what I would do. That program is a great time saver when trying to figure out how a screen is put together. The only thing it can't handle is certain HDMA effects for obvious reasons. Mode7 should be covered and covered well though.
apparently i wasn't very clear in what exactly i was doing sorry.

i am taking someone else's PNG dump of the sd2/som mode7 overworld and tearing it into unique tiles, palette, etc. ripping as 4x4's in order to later make 2x2 combos of 4x4's in order to verify the accuracy of their dump.

reason i am using 4x4's is objects like trees, waves, cannons, houses, bridges, mountain, grassland, are all in 4x4 sections embedded within a set of 8x8 tiles.

reason i am ripping as 4x4's from the dump they already made is so i can compare 4x4 sections (unique objects with unique color rotation) in order to verify whether the entire mode 7 dump was made using the same frame of animation for the whole overworld or not, and if not, create a new dump from it where it shows each 8x8 cell with the correct palette per frame timing info.
Nightcrawler
Guest
« Reply #4 on: September 08, 2008, 01:27:55 pm »

I don't know what you're talking about... You have some severe misconceptions.

1. Mode 7 graphics utilize a full 256 color palette. One byte per pixel like a bitmap file. Each tile pixel can use any of the 256 colors.
2. All tiles are 8x8 in size, including the trees, houses, etc. Objects that APPEAR smaller than 8x8 are typically centered in the tile with grass filling the rest. I've looked at the game. That's how the graphics are stored and that's how the screen is constructed.
3. Frames? Frames should have nothing to do with it. The map is a static image. The perspective is manipulated by the Mode 7 registers, but the map is static.
4. The screen (technically background layer) is constructed with a 128x128 grid of 8x8 tiles. It's 1024x1024 pixels in size.

During the development, artists would either draw the full image outright OR construct it via tiles the entire over world image resulting in one 1024x1024 canvas image via a custom tool developed by the development team. Artists would never work with anything less than an 8x8 tile. Any object appearing smaller than 8x8 as still drawn in an 8x8 square and the surrounding pixels were filled to blend with the background or surrounding tiles.

I'm telling you, open a savestate in VRAM and look for yourself. That's how they are. Once you see the tiles in the memory viewer, you'll understand.
creaothceann
Guest
« Reply #5 on: September 09, 2008, 05:31:52 am »

re: 3

SoM animates some tiles though (not just palette changes).
Nightcrawler
Guest
« Reply #6 on: September 09, 2008, 08:04:26 am »

Quote from: creaothceann on September 09, 2008, 05:31:52 am
re: 3

SoM animates some tiles though (not just palette changes).

Such as?
Deathlike2
Guest
« Reply #7 on: September 09, 2008, 09:39:35 am »

Quote from: Nightcrawler on September 09, 2008, 08:04:26 am
Quote from: creaothceann on September 09, 2008, 05:31:52 am
re: 3

SoM animates some tiles though (not just palette changes).

Such as?

I think he means the water, ice (to reflect the trees in the region around the Ice Palace), and some of the mushrooms (around Mantango).
Nightcrawler
Guest
« Reply #8 on: September 09, 2008, 11:47:52 am »

Ah, in that case, it looks as though there are 4 frames of animation for those tiles. All are preloaded into VRAM and show up in VSNES as far as I can tell. Snow, mushrooms, water, and tree animation seem to all be there.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC