Does anyone have detailed information on how Golden Sun handles wall glancing? Is it a tile based lookup to a collision type? And does anyone know how I could get detailed information on what parts of maps allow pathing (I'm talking specifically about towns/dungeons etc... not the world map)?
I really don't want theories, I'd like to know exactly how they handle it. I'd also like to figure out exactly where they allow a character to go on a map so that I can recreate that map with the same pathing abilities.
If I'm correct, I think you're talking about how there are several rooms in a map, and if you go in one of the rooms, the camera is "locked" into that one, right? If this is what you are talking about, I think the data for it is in one of the seven files a map would have... Where one of these files would be decompressed probably around 0202E000,... which contains about 4 small tables of data.
Likely the last table.
---
Not sure if this is used in all cases, but if it isn't, I can maybe see it being in Map Code. (02008000-0200FFFF.)
For glancing I'm talking about this:
Only holding UP key:
(http://i.stack.imgur.com/oC5rS.gif)
(http://i.stack.imgur.com/HK12j.gif)
Where and how is this data stored? What method does Golden Sun use for this?
And for pathing I mean does Golden Sun use some type of collision layer? How does it determine where on a map a character can run around in? Here being an example mockup layer of magenta on Vale's town center:
(http://i.imgur.com/SQgfDLg.png)
Looks like you are talking about collision data...
It's with-in the tiledata that is decompressed to 02010000. (Edit: At least for GS1, but there's some related stuff in GS2 as well.)
(@Compression: The game actually separates the data first... so that the first and second byte of each tile is in one group, and the other two in their own separate groups. (3 groups) ; I think they did that for better compression, the first section is reformatted using (Was it 0FFF?) for incrementing tiles, anyway.)
QuoteThat makes it easy. All map data contains header information, and 7 compressed files, that would make the treasure coordinates one of the 7 files.
1) Tile table (Arranges the 8x8 tiles in the tileset into 16x16 tiles, and applies palettes to them)
2) Heightmap tile table (Defines the 16x16 tiles that will be used in the heightmap)
3) Tile data for the map
4) Heightmap data for the map
5) Tile animation data (Stuff like water)
6) Tile layer visual effects (Sun rays in Madra)
7) Coordinates
*Edited #7 from where I quoted this from.
Anyway, Files 2, 3, and 4 are the ones of interest.
File 1 = 02020000
File 2 =
File 3 = 02010000
File 4 =
File 5 =
File 6 =
File 7 = 0202E000
Quote from: From my Hacking Documentation02008000 = Map Code
Initialization
Some Entrances
Exit Init
NPC Init
Event Init
Special Entrances? (For Z-coords) (May need to double check.)
Copy tiles/etc? (More research needed)
02010000 = Tilemap (Including graphics, event indexes, heightmap, etc.)(32-bit a tile)
000007FF = Graphic tile
00000800 = Unused? (MSB of graphic tile in GS1)
00FF0000 = Event Connecter? (For doors as well.) (FF=Wall, FE=Gap for hopping?)
FF000000 = GS1: Height data; GS2: Special tilescript flags.
20000000 = Slope down.
40000000 = Climbable (Ladder/Vine) (Use same value on tile above or below to activate.)
80000000 = Hop. (Can hop from this tile.)
02020000 = Tile data (Mini-tiles) (F000=Palette; 0C00=Flips; 03FF=Tile)
02024000 = Heightmap tilemap.
02028000 = Animation Tileset
0202C000 = Heightmap tile table (Defines the 16x16 tiles that will be used in the heightmap)
0202D000 = Tile animation data (Stuff like water)
0202DE00 = Tile layer visual effects (Sun rays in Madra)
0202E000 = Coord Data
Three relative addresses to Entrances data and later.
Treasure locations
Entrances
Copy Tiles (Each entry is a Storybook Flag & 6 bytes for "from x/y", "to x/y", "w/h")
Map boundaries
EDIT: No wait, it might be that height data is in that 02010000 tile data only in GS1, and GS2 separates it somewhere else... oops. (Which would be at 02024000.) , but still GS2 does have some collision-related data there... with the climbable/hop/etc. stuff.
--
I've posted this just in case the Heightmap has this x/y by pixel data, unfortunately, I haven't checked recently, so I dunno, but I plan to check soon.
Are you just exporting the map data from the editor and then using a tool to uncompress it? What tool are you using?
Also, is there a resource that maps values from the decompressed collision data to specific types of events? I.e. value 0x2 = deflect character SW?
Actually, I looking at VisualBoyAdvance's memory viewer, which can be found under Tools... I keep forgetting that's not common knowledge, oops.
My guess is that you'd use Event Connectors in the tile data to do stuff like that. You would need to go into the Map Code file to set up what the "Event Connector" does...
I appreciate the responses, but at this point it seems like I'd just have to figure out how to interpret the hex data. I'm trying to avoid reinventing the wheel.
Do you know how I can interpret this data specifically for Golden Sun?
Sure I can go look at those offsets you mentioned but I'd really like to not have to reverse engineer this game, especially if someone has already done the parts that I want to look at.
(http://i.imgur.com/NfbUHt8.jpg)
Any other tips or resources?
Quote02010000 = Tilemap (Including graphics, event indexes, heightmap, etc.)(32-bit a tile)
000007FF = Graphic tile
00000800 = Unused? (MSB of graphic tile in GS1)
00FF0000 = Event Connecter? (For doors as well.) (FF=Wall, FE=Gap for hopping?)
FF000000 = GS1: Height data; GS2: Special tilescript flags.
20000000 = Slope down.
40000000 = Climbable (Ladder/Vine) (Use same value on tile above or below to activate.)
80000000 = Hop. (Can hop from this tile.)
Most of the data on the left, from the second row down... is me just labeling the
bits (in hex format) that apply to the description on the right.
A byte (00) is 8-bits.
Hex representation on left, bit representation on right.
01 = 0000.0001
02 = 0000.0010
04 = 0000.0100
08 = 0000.1000
10 = 0001.0000
20 = 0010.0000
40 = 0100.0000
80 = 1000.0000
Anyway, a tile is 4 bytes long. Unless I'm mistaken, I think rows were 0x200 bytes apart for all maps regardless of actual size.
As for other programs you could use, well, there's a debugger called SDL-H that I like to use for understanding data, but that requires knowledge of assembly code. (Not recommended for novices.)
I understand hex, I don't understand the underlying value representation. For example, you said:
Quote02010000 = Tilemap (Including graphics, event indexes, heightmap, etc.)(32-bit a tile)
So if I go to that offset I can see this:
(http://i.imgur.com/4lAFP0z.jpg)
Example row (so 4 tiles):
02010090 | 00000015 00000015 0000001A 0000001BWhat do these values tell me?
00000015 = ? Is this a reference to a specific palette tile? I.e. for the 40th tile, draw a grass tile? I'm looking for information on what those values mean.
00000015 =
0015 = A 16x16 Graphics tile (It's an index to the 8x8 tile listing at 02020000, and those are indexes toward the data in Video RAM...) ; You have to play-test in order to find the tile you want, I guess.
The event connector is 00. (Likely means no event.)
And no tile flags are used (00)
Ok, that makes sense. I'm assuming there is no way to click a tile on the game in VBA and have it give me those offset values hey?
Not that I know of? But you could probably skim for event connectors near eventful places if you wanted to try to find the tiles you want to edit on the map faster, maybe. ; I forgot to also mention that sticking this data back into the ROM itself may be the hard part for you... So you could use the Save button to save a dump if you don't want to lose anything. I don't think there's currently any public programs to compress this data, but I'm sure I could develop one.. one day, if I ever get motivated enough. (I've been procrastinating for what seems like ~years... I guess.)
Atrius's editor does compress and insert Map Code back into the ROM, though.
I probably should mention that there are three layers... Most large maps usually separate them by 0x5000, but I don't think all of them do.
02010000 = Layer 1 (With player collision data)
02015000 = Layer 2 (Forget if there's used collision data here...?)
0201A000 = Layer 3 (With object collision data. Like when you move a pillar or something.)
And yeah, those three layers include the graphic layers on maps, too.
I know pretty much exactly how it works.
The collision data for maps is a height map, the game calculates coordinates in 3 dimensions. Each value is a word (4 bytes) in size and contains a shape value, and 1 to 3 height values depending on shape. There are separate values for special/event tiles.
As the player moves there are 5 points on an arc in the directions he's moving that are checked against the environment's height map. These points are at a distance depending on the player's sprite's collision diameter (normally 16px, so the arc has an 8px radius from the player's actual X, Y coordinates) at the angles 0°, 22.5°, -22.5°, 45°, and -45° relative to the direction the player wants to move. If the height of any of the 5 locations on this arc checked is greater than 8px higher, or greater than 12px lower a collision occurs. After the environment is checked the game checks for collisions with NPCs, this collision check is a simple distance check using the collision radius of the player and NPC's sprites. If the distance between the player and an NPC is less than the sum of their sprite's collision radius's a collision occurs. If a collision occurs with the environment or an NPC the game will attempt to move the player +22.5°, -22.5°, +45°, and -45° degrees, in that order, relative to the direction the player originally wanted to move until a direction is found where no collision occurs. If a collision with an NPC occurs at directions +22.5°, or -22.5° relative to where the player wanted to move the checks at +45° and -45° are skipped to prevent the player from sliding around NPCs they might want to interact with. If a collision occurs in every direction checked the player cannot move.
So when checking for collisions agains the environment imagine an arc with 5 points in front of the player. Position the player where they should move to and these 5 points are (by default) 8 pixels from their center at 0°, -22.5°, +22.5°, -45°, and +45° relative to the direction they moved. If no collision with the environment is detected, the game then checks for collisions with NPCs from this location.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/GS_Collision1.png)
If a collision occurs where the player was supposed to move, the process is repeated at locations 2 through 5 in order (angles -22.5°, +22.5°, -45° then +45° relative to the player's desired direction) until a collision-free location is found.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/GS_Collision2.png)
Like I said collisions with NPCs are based on distance from the NPC. The sprite data in the Golden Sun includes a value for collision diameter, most character sprites have a collision diameter of 16 pixels (including the player). You have to add their collision radii (Radiuses?) together to get the distance between them that a collision will occur at, so for most characters this will be a distance of 16 pixels (16/2 + 16/2 = 8 + 8 = 16). If the player encountered a larger character with a collision diameter of 32 pixels the distance a collision would occur at changes to 24 pixels (16/2 + 32/2 = 8 + 16 = 24) Collisions with NPCs are checked from the same locations as arcs for environments checks are immediately after an environment collision check, and again if an NPC collision occurs at position 2 or 3 then positions 4 and 5 will be skipped. Rephrased, the player will not be slid into positions 4 or 5 around an NPC they might want to interact with.
It's kind of confusing, I know, and I've been deprived of sleep for over 20 hours now so I probably didn't word it as well as I could have. Let me know if you have any questions.
EDIT:
I made a mistake in the above explanation, the game also attempts deflection at +67.5 and -67.5 degrees as well.
Good job, Atrius! I don't think I knew that, but it should help in my research!
I assume these are the related functions? (Some bits of info inside the functions may have been provided by both me and Salanewt.)
[spoiler]0802632C = Data Script 23 - Hover
08026362 = Hover running speed
08026368 = Hover initial running speed/end traction
0802636E = Hover running animation
08026374 = Hover walking speed
0802637A = Hover initial walking speed
080267BC = Data Script 24 - Slippery Ground
080267EC = Slippery running speed
080267F4 = Slippery initial running speed (lower traction means that it takes longer to reach full speed)
080267FA = Slippery running animation
08026802 = Slippery walking speed
0802680A = Slippery initial walking speed (lower traction means that it takes longer to reach full speed)
08026DD0 = Sets psynergy to use on map. (At least for shortcuts.)
08026E60 = Related to button controls and menus?
08026F80
08026FC8 = (BL in Data Script 19)?
08027064 = Data Script 19 - Normal movement - Gives you the ability to move your character.
080270A6 = Running speed
080270AE = Initial running speed (starts at this before changing to normal value)
080270B2 = Running animation
080270BA = Walking speed
080270C2 = Initial walking speed (starts at this before changing to normal value)
0802726E = Debug mode: Walk through walls
080276A2 = Pushing NPCs animation (not used in all instances, such as with pushing psynergy obstacles)
080276C2 = Idle animation (not moving)
080276C8 = Idle animation when party leader has 0 HP
080279B0 = Data Script 1A - Overworld movement
080279DE = Running speed
080279E4 = Initial running speed
080279EA = Running animation
080279F0 = Walking speed
080279F6 = Initial walking speed
08027A50 = Debug mode: Walk through walls (There's also a Flag 0x163 check. (Can be used instead of the L button, if necessary.)
08027E0C = Data Script 25 - Calls 08026E60 - No movement. Access to menus/psynergy shortcuts.
08027E20 = Data Script 1F - Overworld thing; walk through everything, objects are solid
08027E38 = Debug mode: L button check that doesn't seem to do anything special?
08027FAA = Debug mode: Walk through walls
08028534 = Data Script 20 - Ship mode
08028608 = Debug mode: L button check
08028AAC = Data Script 21 - Hover Ship mode
08028B96 = Debug mode: L button check
080290F4 = Data Script 1B - Climbing wall
0802910A = Debug mode (Nothing special?)
08029110 = Idle climbing animation (when not moving)
0802914C = Climbing right animation
08029156 = Climbing left animation
0802915E = Climbing up/down animation
0802920E = Hitting wall/dead end animation
08029262 = Animation before climbing up/hitting ground
080292FC = Data Script 1C - Climbing rope
08029570 = Data Script 1D - Walking rope
08029810 = Unused? Loads a value from 02000474
08029838
080298C0 = Data Script 1E - Sand
080299A2 = Debug mode (Nothing special?)
08029C94 = Debug mode: L button check
0802A124 = Data Script 22 - Sand (World Map)
0802A1BC = Debug mode: L button check[/spoiler]
Speaking of... once, I learned that sprites that are located higher than the ground during Map Loading... float like the platforms on top of the Lighthouses.
Wow Atrius, thank-you for such a detailed answer. I do have a couple questions for you:
- Is the height map used for determining whether a given position a map is valid? I.e. if you run straight into a cliff is it the fact that the height map can't deflect you that causes you to not be able to move into the cliff? Or does a separate layer determine this?
- Is every height map tile an 8x8 tile with a given value? You said greater than 8 less than 12 results in a collision, does that mean for every relevant height map tile the following is true: "It is an 8x8 tile with a value of either 9 or -13?"
- Can you go into more detail on the shapes you mentioned for each tile? And how they relate to the different height values? I'm think these shapes are right-angle triangles?
For example, in the given image would the game have something like this, where those tiles have a height value of 9?
(http://i.imgur.com/aNJghBm.png)
And trying to understand your first drawing in relation to the game, if say, Felix were moving South, would it look like this? Where the black circle is his collision radius and the magenta circle is his 5 point arc deflector?
(http://i.imgur.com/rKm83CS.png)
For GS2:
02024000 = Heightmap tilemap. ; These hold indexes to below data..
0202C000 = Heightmap tile table (Defines the 16x16 tiles that will be used in the heightmap)
I think the latter is what actually defines how high a ledge is... (for each pixel.)
So... not height [indexes] of 8 and 12... but height [pixels] of 8 and 12.
I'm not sure what you're thinking with the "5 point arc deflector"
It's all part of collision detection, it's just that there are only 5 points on the edge of the circle that are tested against the height map, while the entire circle is used for NPC collisions.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/GS_Collision2.png)
Looking at this diagram again, the player was trying to move up/right to position 1. The red points on the arc are where the height map will be tested for collision, and if you draw the full circle that the arc is part of you get the collision radius for NPCs. If a collision occurs between the environment or NPCs at position 1, the game tries again position 2. If a collision occurs at position 2, position 3 is tested and so on.
Now for your questions:
QuoteIs the height map used for determining whether a given position a map is valid? I.e. if you run straight into a cliff is it the fact that the height map can't deflect you that causes you to not be able to move into the cliff? Or does a separate layer determine this?
Yes, the height map is what is used to detect collisions against the map. If the difference in height in the direction the player wants to move is too great then deflection will occur, if deflection is not possible the player is unable to move.
QuoteIs every height map tile an 8x8 tile with a given value? You said greater than 8 less than 12 results in a collision, does that mean for every relevant height map tile the following is true: "It is an 8x8 tile with a value of either 9 or -13?"
Height map tiles are 16x16. The values of these tiles have a range of -1024 to 1016 (-128 to 127 multiplied by 8, they can only be a multiple of 8). Golden Sun's engine calculates movement in 3 dimensions, you can literally think that the ground has differing height to it instead of just being a 2D collision map. That is what the height map is.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/HeightmapExample.png)
Here's where things get fun. For tiles above 0 the black tiles show how the height map data is actually stored, while the pink tiles show how it appears in game. Now, if this were any normal RPG you could imagine left/right as the x-axis, and up/down as the y-axis. As the player walked up the stairs their Y position would increase since they're moving up on the screen as well. That
is not how Golden Sun works, in Golden Sun as you walk up those stairs
your position on the y-axis remains the same. According to your X, and Y coordinates you're now standing on the black tiles. This is where the z-axis, and the height map come in. Visually the Z-axis overlaps the Y-axis, but it exists as it's own dimension in the game's code. When I say that a collision occurs at 8 pixels higher, or 12 pixels lower these pixels are visually represented on the y-axis in-game, but by z-axis in code.
QuoteCan you go into more detail on the shapes you mentioned for each tile? And how they relate to the different height values? I'm think these shapes are right-angle triangles?
Looking at the above picture, the stairs are a great example. They have a sloped shape to them, so they transition from one height value on one side to a different height value on the other side. If you look at the diagonal edge of the cliff it also has a special shape, the 16x16 tile is split into two triangles at different heights.
I can't find my notes on the different shapes right now, but as I recall they varied quite a bit. They say how the 16x16 tiles are split, or sloped. Some are split into triangles, some into rectangles, e.t.c. A single height map tile can have up to three different height values depending on the shape.
I've been looking at this again. While I understand how it works, I want to be able to see the actual data in Golden Sun. Can someone walk me through finding the height data for the tiles that Atrius shows the picture?
Where in the memory am I actually going to see a height tile that shows it going from 0-16?
This is what I'm doing currently:
Step 1 - I'm clicking a tile of interest - purple highlight (that according to Atrius should be in that height map of 0-16):
(http://i.imgur.com/dfizNjX.png)
So I can see that it is tile #728.
Step 2 - I can identify that tile in the tile viewer.
(http://i.imgur.com/wUJ28Db.png)
Step 3 - I can identify the reference to that tile in memory at offset 0x02013E78 (I'm not even sure if this is correct):
(http://i.imgur.com/ov1n3G3.png)
Step 4 - Getting the height map data for that tile?
This is where I'm stuck.
---
TLDR: How do I go from a tile of interest to it's height map?
02D8 is for GRAPHIC tile.... (Basically an index to 0x02020000.... which is a list of 8x8 tiles in groups of 4 ... Think: 0x02020000 + (8 * [0x02010000 + (mapTile * 4)]) ...)
GS1 and GS2 have the height data stored in a slightly different way.... See bolded sections.
Quote02010000 = Tilemap (Including graphics, event indexes, heightmap, etc.)(32-bit a tile)
000007FF = Graphic tile (11-bit in GS2; 12-bit in GS1)
00000800 = Unused in GS2? (MSB of graphic tile in GS1)
00FF0000 = Event Connecter? (For doors as well.) (FF=Wall, FE=Gap for hopping?)
FF000000 = GS1: Height data; GS2: Special tilescript flags.
01000000 = ? (Not sure if used or not?)
02000000 = ? (Seen used in Jupiter Lighthouse near Hover pads/slopes. No idea what it could be.)
04000000 = Determines whether to use the first or second encounters index.
08000000 = Hit/damage inducing.
10000000 = ? (Not sure if used or not?)
20000000 = Slope down.
40000000 = Climbable (Ladder/Vine) (Use same value on tile above or below to activate.)
80000000 = Hop. (Can hop from this tile.)
02020000 = Tile data (Mini-tiles) (F000=Palette; 0C00=Flips; 03FF=Tile)
02024000 = Heightmap tilemap. (GS2 only)
02028000 = Animation Tileset
0202C000 = Heightmap tile table (Defines the 16x16 tiles that will be used in the heightmap)
0202D000 = Tile animation data (Stuff like water)
0202DE00 = Tile layer visual effects (Sun rays in Madra)
I would explain how this works, but I think I would need to do a bit of research first.
Basically...
FF000000 = GS1: Height data / 02024000 = Heightmap tilemap. (GS2 only)
should hold indexes to 0202C000 = Heightmap tile table
So that data should be researched.
0202C000 = Heightmap tile table (32-bit/entry)
0000FF00 = Height, it seems
FFFF00FF = Unknowns
00000000 = Has been used for ground.
00000200 = Has been used for walls. (Just raised ground.)
0002020A = Has been used for Left wall.
00000409 = Has been used for Right wall. (House)
00060801 = Has been used for |\ staircase (Left tile for Daila)
00040601 = Has been used for |\ staircase (Right tile for Daila)
00020001 = Has been used for /| staircase (Left tile for Daila)
00040201 = Has been used for /| staircase (Right tile for Daila)
00040004 = Has been used for \| wall.
For the sake of this, let's only talk GS1. I'm just trying to figure out GS1's height map data.
I currently have Issac sitting in Imil.
(http://i.imgur.com/E6jIf1c.png)
Going to your tile map offset 0x02010000 I see this:
(http://i.imgur.com/M8TY2NE.png)
This is how I'm reading it based on your replies:
00FF0000
- 00 = Height tile 0?
- FF = Door event connector?
- 0000 = Tile index 0?
The beginning of that data is pretty boring so if I scroll down a bit I see this:
(http://i.imgur.com/RPckERB.png)
So starting at 0x02011640:
0100A0BE
- 01 = you said: "? (Not sure if used or not?)"
- 00 = no events?
- A0BE = Tile index 41150... what? Or is it 0xBE = tile index 190 and 0xA0 = some tile flags?
Skipping to 0x02011654:
060000C2
- 06 = is this height map tile index 6?
- 00 = no events?
- 00C2 = Tile index 194?
Going to your collision data offset 0x0202C000 I see this:
(http://i.imgur.com/fIbSqzc.png)
00000000: No data
00000400: Height = 4 * 8 = 32 pixels?
00080407: Height = 4 * 8 = 32 pixels? What is the other data?
It looks like there are only 23 collision tiles, is that correct?
I want to be able to "see" the collision data that is surrounding him.
QuoteFor the sake of this, let's only talk GS1. I'm just trying to figure out GS1's height map data.
Well, that's the only difference I've noticed with height stuff from GS1 and GS2 so far... so everything else /might/ be the same.(?)
Quote00FF0000
- 00 = Height tile 0?
- FF = Door event connector?
- 0000 = Tile index 0?
For the most part, correct. (But one should remember that the graphic tile index is not 16-bit, but 12-bit for GS1. - To the beginner, 12-bit would be three hex characters. (4-bits per hex character))
QuoteSo starting at 0x02011640:
0100A0BE
- 01 = you said: "? (Not sure if used or not?)"
Um, no, that was for GS2, not GS1... So if you're going GS1, ignore where I label the 8 flags. (AKA: 1-bit values. ; 01/02/04/08/10/20/40/80 represent where those bits are.)
Quote- 00 = no events?
- A0BE = Tile index 41150... what? Or is it 0xBE = tile index 190 and 0xA0 = some tile flags?
The A might be related to tile priority(?), but might need to double check some time.
Quote00000000: No data
00000400: Height = 4 * 8 = 32 pixels?
00080407: Height = 4 * 8 = 32 pixels? What is the other data?
It looks like there are only 23 collision tiles, is that correct?
I want to be able to "see" the collision data that is surrounding him.
Unfortunately, this happens to be one of the things I haven't done much research with.... But yes, there are 23 unique collision tiles.. (You can tell if you zero out the data and reload the room that the data after the last tile doesn't change, so it gives itself away.)
Think: 0x0202C000 + ([0x02010000 + (mapTile * 4) + 3] * 4)
^ One should write a LUA script to show that data on the screen. (The tile you are on, and the 8 surrounding tiles.)
Edit: It's coming to me....
0202C000 = Heightmap tile table (32-bit/entry)
0000000F = Tile type (There are only 16 tile types; each having their own function to calculate height.)
000000F0 = Unused? (Or unknown.)
0000FF00 = Arg 1
00FF0000 = Arg 2
FF000000 = Arg 3
Tile types:
0 = Flat ground ... height is Arg 1
1 = Left/Right stairs (Arg 1 and Arg 2 used - Basically a linear function.)
2 = Up/Down stairs (Arg 1 and Arg 2 used - Basically a linear function.)
3
4 = \| slanted wall
5 =
6
7 = Pillar? (Based on data at 0802EDC4) (Not an index to Arg 1/Arg2/Arg3, but... (value * (Arg 2 - Arg 1))
8 = Left half of tile's height is Arg 1, right half is Arg 2.
9 = Top half of tile's height is Arg 1, bottom half is Arg 2.
A = Based on data at 0802EEC4 [X<<4 + Y] Note: Both X and Y should be 0x0 to 0xF of tile. ; And table is index to which of Arg 1, Arg 2, or Arg 3.
B = Based on data at 0802EEC4 [X<<4 - Y + 0xF]
C = Based on data at 0802EEC4 [Y<<4 + X]
D = Based on data at 0802EEC4 [Y<<4 - X + 0xF]
E = Bottom half = Arg 3 ; Top left corner = Arg 1 ; Top right corner = Arg 2
F = Top half = Arg 1 ; Bottom left corner = Arg 2 ; Bottom right corner = Arg 3
A to D may be for slanted walls.... Basically where the slant could fit in a rectangular 8x16 box or something... Interesting way of doing it, I must say...
Still looking at this stuff. I think I understand how the height map roughly works in Golden Sun, but I'm a little confused as to how the data is stored for something like a bridge:
(http://i.imgur.com/kdMBY2g.png)
Mainly since you can go under the bridge and over the bridge, how does Golden Sun handle this situation? I'm trying to imagine what the height map looks like for this particular section.
Oohh! Thanks for bringing this up!
A quick look up of GS2... Looking at Yallam.... You know how there are three graphic layers? Well, there are also three heightmap layers as well.
1st layer = Original PC heightmap
2nd layer = Secondary PC heightmap when needed (B/c of bridges)
3rd layer = For objects (pillars/crates/etc.) you can move... (Although, it might be possible that the NPC data selects which heightmap to use... Not sure???)
And with that... More data becoming known?
00003000 = (Only researched for GS2 so far.) 2-bit value that somehow tells which heightmap to switch to? (Used before you get to the bridge itself.)
0000C000 = Might have to do with priority somehow?
FF000000 = GS1: Height data; GS2: Special tilescript flags.
01000000 = (GS2) PC has access to two 2 height layers... bridges and stuff... ? (Maybe????) Actual purpose currently unknown. (Seems to be used at the bridge, but not necessarily at tiles that change heightmaps.)
020322EC = Felix RAM data...(If looking at GS1, you can still look at Isaac's RAM data by following the pointer at 02030014.... Yes, there are 8 pointers for each of the PCs there... in both games. Pointers after that are for the rest of the NPCs.)
0203230E = Felix's current heightmap index. (0-2... not sure if it is ever 2.)
That's mostly what I've seen so far... there may be a few questionable things, though... (Like that 01000000 flag)... Maybe I should look into this further.... (And I may check GS1 out later... the point with why I do GS2 first, usually... is because so much has already been documented on a lot of stuff.)
Interesting finds Fox. Any ideas on how the game is changing those heightmap indexes? I'm thinking there could be a couple
possible ways:
- Height map index is determined by your z-coordinate
- Height map index is determined by specific tiles
Any thoughts?
QuoteHeight map index is determined by specific tiles
That one is correct. I'll give a visual. Do note those numbers colored in visual are 2-bit, not 4-bit... in-case coloring them like that makes it seem so...
Basically...
0 = Does nothing?
1 = Changes height layer index to 0
2 = Changes height layer index to 1
3 = Changes height layer index to 2
Hey Fox, this is an odd request but can you tell me everything you know about the collision data for the highlighted tile (the pot):
(http://i.imgur.com/PeN02bP.png)
I have been assuming that it was just a 16x16 collision tile with a single height map value of 16.
QuoteI have been assuming that it was just a 16x16 collision tile with a single height map value of 16.
Basically, it is like a mini-pillar. (Using type 0x7.) (And not limited to jars, so the two things directly above are also using the pillar type.)
Ah ha! I figured my assumption was wrong. I'm guessing that when it's a pillar type it uses NPC style collision detection. Meaning that it uses a circle with probably a radius of 8 there. You can actually see it if you attempt to go in between the objects.
Thanks for finding that out.
As far as GS2 is concerned with the pillar-type tile... (It is probably the same in GS1 as well.) A radius number isn't used, the tile is literally mapped out.
(http://i900.photobucket.com/albums/ac208/charleysdrpepper/gs2pillartype_zpskevti9k0.png)
(^GS2 addresses)
Oh, and you are welcome!
That is very interesting because I think it goes against what Atrius said about the collision system where it tries to deflect at +22.5°, -22.5°, +45°, -45°. If the characters 8px radius circle is directly underneath that tile according to those angles it shouldn't be possible to glance, but in the game it does.
Hmm? I dunno? Unless there's some misunderstanding somewhere?
-Pillar tiles use the 16x16 table to define which pixels are at which height.
-PCs/NPCs/Objects .... using a radius/arc thing to determine where to walk.... perhaps I need to check the documentation and document some things if I've forgotten anything.
It was my mistake, the game also attempts deflection at +67.5 and -67.5 degrees as well.