(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
11-01-24 12:14 AM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - Zelda64 Mapdata info? New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 09-21-06 09:33 AM Link | Quote
Hello everyone

with the help of cooliscool´s zelda edit i was able to find the leveldata off some maps in zelda64... after a while i found the Vertex data off map 117 and was able to edit the vertexdata.



I´ve found out that the layout off the vertex data is something like this:

"FE0D 0000 FE07 0000 0000 0000 007F 00FF"

The first three byte-paars are the x-y-z loacation off the vertex..
I don´t know what the next four byte-paars do, but the last byte-paar
cotrols the lightning of the vertex.

but i still have many questions about he mapdata:

1. I´m somewhat confused about the vertex data they dont seem to be in a linear order?
2. I´m only able to edit the vertex data but not to edit the collisonsdata, where is the collisionsdata stored?
3.Can anybody give me some info about the mapdatas header?
4.What are the unknown four byte-pars doing?

ok that´s all for know, i would be very pleased if anyone can/wants answer my questions.

Uschghost
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6465 days
Last view: 6465 days
Posted on 09-21-06 05:50 PM Link | Quote
Seems similar to Mario Kart's polygon format which I believe is based on a standardized format.

typedef struct {
short XPos;
short YPos;
short ZPos;
short TextureCoordS;
short TextureCoordT;
unsigned char RedTint;
unsigned char GreenTint;
unsigned char BlueTint;
char Unknown3;
} MK64PolygonData;


Hit detection probably works similar to Wind Waker; I've seen people render the collision maps of that game for beta levels with no actual polygon data. Unfortunately Mario Kart doesn't appear to work anything like that (not sure how it does work), so I can't help you there.
Yoronosuku

Toss Tortoise


 





Since: 11-17-05
From: Massachusetts is my new home..

Last post: 6465 days
Last view: 6465 days
Skype
Posted on 09-21-06 06:04 PM Link | Quote
Y'know the game was heavily modified of SM64's engine right? Is it a possibility that it uses a similar or identical hit detection to that of Mario's then?
Guy Perfect









Since: 11-18-05

Last post: 6467 days
Last view: 6465 days
Posted on 09-21-06 06:46 PM Link | Quote
I appologize for going off on a tangent, but... HyperHacker, I betcha your Unknown3 element is the color Alpha channel.
cooliscool

Octorok








Since: 05-21-06
From: USA

Last post: 6565 days
Last view: 6469 days
Posted on 09-21-06 09:27 PM Link | Quote

2. I´m only able to edit the vertex data but not to edit the collisonsdata, where is the collisionsdata stored?


Collision data is stored in a seperate "scene file" which follows directly before the room's room file (in the Debug ROM.. in normal OoT ROMs, the scene and room files are stored in a single Yaz0 block). The first byte of the room's scene file is either 18 or 15, usually 150x. If it's 18, a few bytes after it there will be 2 bytes: 150x. The scene file will contain a pointer to the room file's ROM location, so you can use it to make sure you're at the right spot. HyperHacker is right, you can render OoT's collision without the room file loaded at all.


3.Can anybody give me some info about the mapdatas header?


Sure - here's 117's as an example:



The header can be any length, with a few exceptions which I'll note later.

The first word, 18000000, just denotes this as a map file. Can also be 16000000. The word 12000000 denotes data after it being environmental variables. +C after 12000000 is environment lighting (4 bytes, one word).

Any data after the word "14000000" is actor data (variable size, usually contains actor group with the number and variable somewhere else, not even in the header depending on appearance and repitition in the level. The actor group is defined once, and if the actor is repeated in the level, the number is defined as many times as necessary. Variable is always +E bytes after the actor group), as can be seen by Zelda Edit's source code. If there is no such word, the room doesn't have any actors. The 12 (4x3) bytes after the actor number (find this with ZE), are the actor's X-Y-Z locations in that order. They're stored as 16-bit signed integers, so use that for conversion of the hex data.

Most importantly, anything with "0300" as the first two bytes, the proceeding two are difference offsets which locate critical data in the room file. The last two (or one, depending on how many seperate sets of vertices there are in said room) "0300xxxx"s are locations of the room's model data in the file (origin plus whatever the last two bytes are), and that's the limitation: if you add bytes to to the room file at all, you must recalculate these values based on how many bytes you added. Say you added a new "14000000 + actor data" to the header to add a new actor: you would add that many bytes to every 0300xxxx value in the room file, not just the header. Yikes! Fortunately, it would only take a few lines of code to have a program do this for you.

Also, note how that room file is at 02D03000. Search that in the hex editor, and it'll take you to the main data pointer list. Handy!

In RAM, the word at 80223D14 holds the location in ROM of the currently loaded room, proceeded by a word which contains the room file's location in RAM.

Hope that made sense. If it didn't, or you need more info, let me know and I'll be glad to help.

Also, this info holds true for Majora's Mask. Nothing was changed between the two in the form of room/scene data loading. Obviously, though, room data in Majora's Mask is compressed, and the game won't read uncompressed rooms correctly. I'll touch on MM hacking later.

That reminds me of something.. http://youtube.com/watch?v=JwWzsxFMUv4


(edited by cooliscool on 09-21-06 08:28 PM)
(edited by cooliscool on 09-21-06 08:29 PM)
(edited by cooliscool on 09-21-06 08:35 PM)
(edited by cooliscool on 09-21-06 08:39 PM)
(edited by cooliscool on 09-21-06 08:41 PM)
(edited by cooliscool on 09-21-06 08:42 PM)
(edited by cooliscool on 09-21-06 08:43 PM)
(edited by cooliscool on 09-21-06 08:44 PM)
(edited by cooliscool on 09-21-06 08:47 PM)
(edited by cooliscool on 09-21-06 08:51 PM)
(edited by cooliscool on 09-21-06 08:53 PM)
(edited by cooliscool on 09-21-06 08:59 PM)
(edited by cooliscool on 09-21-06 09:26 PM)
(edited by cooliscool on 09-21-06 09:27 PM)
(edited by cooliscool on 09-21-06 09:27 PM)
(edited by cooliscool on 09-21-06 09:28 PM)
(edited by cooliscool on 09-21-06 09:30 PM)
(edited by cooliscool on 09-21-06 09:30 PM)
(edited by cooliscool on 09-21-06 09:35 PM)
(edited by cooliscool on 09-21-06 09:37 PM)
(edited by cooliscool on 09-21-06 09:47 PM)
(edited by cooliscool on 09-21-06 11:55 PM)
(edited by cooliscool on 09-21-06 11:56 PM)
(edited by cooliscool on 09-21-06 11:58 PM)
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6465 days
Last view: 6465 days
Posted on 09-22-06 01:23 AM Link | Quote
Originally posted by Guy Perfect
I appologize for going off on a tangent, but... HyperHacker, I betcha your Unknown3 element is the color Alpha channel.

That's what I'd have thought, but it's always zero. (Or 0xFF, I can't remember... either way it's always a specific value, and changing it doesn't seem to do anything.) I think it's just padding.
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 09-22-06 08:38 AM Link | Quote
thx cooliscool, your informations really helped me^^

I will try to edit the collisiondata as sonn i´ve enough time for....

In your official thread about zelda edit i´ve seen that you have ported zelda edits source to c#. would you like to send me the c# source via e-mail, because i´ve never used VB but im familiar with c/c++, and it don´t looks like you have hosted the c# sourcecode on your site.

my e-mail adresse: zero-one01@web.de
Thanks in advance

Edit:
ok... i´ve had enough time right now^^.... but im somewhat confused......

I edited one vertex in room 117 (at 0x02D03490) from "FD13000006D6" to "FD1300AA06D6" (this are only the x-y-z coordinates from the vertex). I thought that the colisionsdata has the same layout as the vertex data so i searched for "FD13000006D6" befor the roomdata, and i found it (at 0x02D021DC). but when i edit "FD13000006D6" to "FD1300AA06D6" link still walks through the little hill -.-"


So cooliscool can you give me an example how to edit the colisionsdata so that link will walk up the hill?


(edited by uschghost on 09-22-06 08:27 AM)
cooliscool

Octorok








Since: 05-21-06
From: USA

Last post: 6565 days
Last view: 6469 days
Posted on 09-22-06 05:15 PM Link | Quote
For sure. Let me port the latest version to C# (0.8.8, now supports adding to the "quick add" actor list), and I'll gladly upload it.

Should have it done later on tonight (EST).

As far as the collision, I'll have to study it some. I haven't really dealt with editing it, rather just mapping things out.

Edit: 117's collision data begins at 02D00170. It doesn't correlate to vertex values in any way though, nor their locations.. hrm.


(edited by cooliscool on 09-22-06 04:40 PM)
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 09-23-06 08:31 PM Link | Quote
what the.....
The collisionsdata realy confused me
it seems that the collisionsdata is stored something like this:

0000 0000 0003 00005 0006 0007 0000 7FFF
ofcourse i could be totaly wrong

it also seems that the above part is standing for a hole triangle face.
I have this tought because when i change the second bytepaar (0000 in this case) to
0013 link sinks in one of the triangles like this:

and when i set the second bytepaar too high(0030) link just fells to his doom.

but i have no idea what this bytes do, except for the second bytepaar wich seems to have something to do with the "collisions-triangles" y value

but for today im alll set with fidelling around in my hexeditor...
and my dream to make my own zelda maps (with collision ) still has to wait.


(edited by uschghost on 09-23-06 07:34 PM)
(edited by uschghost on 09-23-06 07:34 PM)
(edited by uschghost on 09-23-06 07:37 PM)
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6465 days
Last view: 6465 days
Posted on 09-23-06 11:35 PM Link | Quote
I imagine they'd only use one large polygon (maybe 2 or 3 given the different types of ground) for the entire level there, since it's just a big square.
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 09-24-06 08:58 AM Link | Quote
No they dont use just two big triangles for the hole map.

As i mentioned above, the change in the collisionsdata i made, only effects the triangle in the above picture. Link walks normaly on all other triangles....

Edit:
I´ve made some new findings in the collisionsdata^^

At first I was totaly wrong about the collisionsdata Layout but now it´s looks defenietly something like this:
0002 0003 0004 0001 0000 7FFF 0000 0000

the first byte-paar is realy interesting, it seems to store the behavoir off the coolisios-triangle. for example if the first 3 nibbles are set to zero it acts like a normalground and the last nibble (2 in that case) controls wich sound you hear when link walks over it:
1=Grass
2=water
3=dusty
4=stone
5=wood
6=organic
7=sand
8=stone
(this are my own interpretations off the "walk sound")

But the first byte-paar can do much more if it´s set to "0010" it acts like lava/magmar
and hurts link:


And if I set it to "0020" link will walk across the triangle like he is walking throug a gate and will then teleportet to zoras kingdomO_o"
Or when it´s set to "1000" link gets warped inside the deku tree when he walks over the collisionstriangle.
But i´m still not sure wich syntax the firstbyte-paar follows.

The next three byte-paars semm to have something todo with the collisions-triangles location(but i´m totaly not sure for that)

And I dont know what the other bytes do except for the last byte-paar wich is the byte-paar i mentioned bevor that when i set it for example to "001A" for example
the triangles y-position goes down circa half of links size.....

whatever... i still have to learn alot about the map/collisionsdata and any help is welcome^^



(edited by uschghost on 09-24-06 04:07 PM)
(edited by uschghost on 09-24-06 04:08 PM)
cooliscool

Octorok








Since: 05-21-06
From: USA

Last post: 6565 days
Last view: 6469 days
Posted on 09-27-06 11:16 PM Link | Quote
FYI uschghost - I've almost finished the complete port to C#. The first port was of an old version, and I had to nearly completely redo the app. Been busy, but I've been doing it on and off - when it's finished I'll let you know. Easier to understand to you C guys, but still uses some .NET conventions.

Here is the currently finished code. That's ZE in its entirety, now I have to migrate that code to a new C# project to make new designer files.. so it won't run, but you can use that code for reference.


(edited by cooliscool on 09-27-06 10:17 PM)
(edited by cooliscool on 09-27-06 10:18 PM)
(edited by cooliscool on 09-27-06 10:20 PM)
(edited by cooliscool on 09-27-06 10:21 PM)
(edited by cooliscool on 09-27-06 10:21 PM)
(edited by cooliscool on 09-27-06 10:28 PM)
(edited by cooliscool on 09-27-06 10:28 PM)
(edited by cooliscool on 09-27-06 10:29 PM)
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 09-28-06 08:21 AM Link | Quote
Thanky you very much cooliscool for the source^^
I´ll look forward to the finifhed source and will look up in the source this night...

currently i´m trying to render the maps of oot...
to do that i isolate the pure vertex data of a map into a seperate file and load them into
an opengl window..... (here is map nr.117, wich isnt that spectaculear but the vertexdata of 117 is very easy to isolate)

unfourtainly i´m only able to show the vertexes nor to render the
triangles... because i don´t know how to find out wich triangle belongs to wich vertex.

it would be nice if you can answer my following questions:
1. are ther bytes (maybe in the mapheader) wich stores the number of vertexes in the map?
2.can you give me some tips how to render the triangles?

this informations would realy help me.
as always: thx in advance^^

PS:I have to say that you are a very cool guy and i´ll be ever greatfull that you help me so much


(edited by uschghost on 09-28-06 07:42 AM)
cooliscool

Octorok








Since: 05-21-06
From: USA

Last post: 6565 days
Last view: 6469 days
Posted on 09-28-06 05:18 PM Link | Quote
What API/extension are you using to render those points? If you're using OGL, you can use "glVertex3f(x,y,z);" using "glBegin(GL_TRIANGLES)", and theoretically it should link them accordingly. If you aren't using OGL, I wouldn't know how to go about drawing triangles - OGL is all I've worked with.

may look like:


glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // clear color and depth buffers to avoid trailing
glBegin(GL_TRIANGLES); // starts an ogl instance in triangles mode as that's how these verts are stored (3 points), and runs the below instructions
{
glColor3f(r,g,b); // set a color for the below polygon
glVertex3f(x,y,z); // draw a triangle with these vertex points
}
glEnd(); // end the insance


Loop through that somewhere in your code, using the next vertex value in that glVertex3f.. so for example, glVertex3f(currentx,currenty,currentz), having that change on each loop to then next vert location in the file.

If you've tried that, don't take this as an insult. Just throwing out ideas.

As far as locations being stored in the room file, for the sake of the programmer's sanity I'm sure they're stored, it's just finding out where.


(edited by cooliscool on 09-28-06 04:18 PM)
(edited by cooliscool on 09-28-06 04:19 PM)
(edited by cooliscool on 09-28-06 04:19 PM)
(edited by cooliscool on 09-28-06 04:20 PM)
(edited by cooliscool on 09-28-06 04:24 PM)
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 09-28-06 06:53 PM Link | Quote
Yes i´m using Opengl too.
i have had the same idea as yours, but the vertexes of one triangle are not stored in line.
that means for eyample:
vertex1+vertex2+vertex3 are not building one triangle...
I have to find a way how to find out wich vertex belongs to wich triangle.
So far i´ve tryed a couple of algorythms to render the triangles, but it never shows a correct result...

Edit:
I´ve uploaded my mapvier for you so you can better understand what i mean.
get it here: http://home.arcor.de/uschghost/zvertex viewer.rar

just load the included zvertex file and you will see map 117
the red colored vertex is the currently selected.
the controls are the following:
left/right = select next/last vertex.

hold down space and
up/down/left/right = rotate scen

hold down shift and
p/down/left/right/+/- = translate scene

W/A/S/D/Q/Y/ = move vertex

if you go through the vertexes you will see....


(edited by uschghost on 09-28-06 05:54 PM)
(edited by uschghost on 09-28-06 06:18 PM)
cooliscool

Octorok








Since: 05-21-06
From: USA

Last post: 6565 days
Last view: 6469 days
Posted on 09-28-06 07:48 PM Link | Quote
Can you upload the source somewhere?
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 09-29-06 06:50 AM Link | Quote
Can you upload the source somewhere?

for sure, but the source isn´t that clean and the comments are in german...
but here itis: http://home.arcor.de/uschghost/zvertex viewer source.rar



(edited by uschghost on 09-29-06 06:53 AM)
cooliscool

Octorok








Since: 05-21-06
From: USA

Last post: 6565 days
Last view: 6469 days
Posted on 10-01-06 07:07 PM Link | Quote
Okay, it seems they're stored like this:

06xxxxxx and 05xxxxxx values are polygons. For example, 05010203 is a polygon with vertices 1, 2, and 3 on the vertex list.
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6465 days
Last view: 6465 days
Posted on 10-01-06 07:12 PM Link | Quote
Ah, and I bet 06 draws two polygons? Mario Kart had a similar system.
uschghost

Micro-Goomba








Since: 09-12-06
From: Germany, NRW

Last post: 6484 days
Last view: 6484 days
Posted on 10-02-06 10:10 AM Link | Quote
__________________________________________________________________________
Okay, it seems they're stored like this:

06xxxxxx and 05xxxxxx values are polygons. For example, 05010203 is a polygon with vertices 1, 2, and 3 on the vertex list.
__________________________________________________________________________

where exactly do you find this data? (example for 117 please?)
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - Zelda64 Mapdata info? |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.105 seconds; used 463.20 kB (max 594.70 kB)