Programming Questions

[Jason777]

I guess I'll just post here when I have trouble that after researching thoroughly I can't solve on my own (which will be pretty rare). Anyways, the question I pose today that has me kind of puzzled is this...

 

Is there any efficient way of detecting free space in the OoT Debug ROM? I have the idea that doing a thorough search of all the tables within the ROM and recording/comparing offsets would help tremendously but what if someone places custom code at a certain offset? No file table will have a reference to said code's offset.

 

Code snippets are appreciated no matter what language they may be in!

 

EDIT:

Well, you actually could find references to the custom code by disassembling certain parts of the ROM and searching for bits of code that made jumps DMARomToRAM or wrote to the special DMA registers. But the again, that's going above and beyond.

[Wooffadog]

ive also got a question. I understand that hex digits go from 0-F but all i can do is edit text, how did you guys learn how to progress from that, what more can i learn about hex editing and how? etc

[Jason777]

Everything has its own value representation in text, decimal, hexidecimal, octal, or binary; in just depends on which side of the hex editor you're looking at. Most files within the ROM follow a particular format (scene, map, object, JFIF, cutscene, text strings, etc) and some are just RAW code (actors, functions, routines, etc). To understand what certain bits, bytes, halfwords, words, or doublewords do in a "formatted" file, you could do yourself a great favor and take a look at the Z64 Wiki : http://wiki.spinout1...title=Main_Page

[Guest sakura]

I guess I'll just post here when I have trouble that after researching thoroughly I can't solve on my own (which will be pretty rare). Anyways, the question I pose today that has me kind of puzzled is this...

 

Is there any efficient way of detecting free space in the OoT Debug ROM? I have the idea that doing a thorough search of all the tables within the ROM and recording/comparing offsets would help tremendously but what if someone places custom code at a certain offset? No file table will have a reference to said code's offset.

 

Code snippets are appreciated no matter what language they may be in!

 

EDIT:

Well, you actually could find references to the custom code by disassembling certain parts of the ROM and searching for bits of code that made jumps DMARomToRAM or wrote to the special DMA registers. But the again, that's going above and beyond.

 

Maybe I'm not entirely sure what you're looking for, mind elaborating on the end result you're hoping to achieve? There's around 12MB of free space at the end of the ROM that you can use.

[Jason777]

I'm mainly just looking for a way to accurately find free space without worrying about overwriting something. Of course, in unmodified ROMs, there's a load of free space (e.g. 0x35CE040) and most programs happen to utilize that information and insert files at that offset by default without checking if there's some data their already.

 

Basically, I'm writing a program that makes some changes to a map file which increases the size of the map. The change in the file size obviously calls for the file to be moved to free space and have its file pointers fixed. I could just ask the user to input an offset for the map to be inserted at and that would take care of the problem, but for nonexperienced users I would like to create a function which searches for the first occurence of free space to insert the map at.

[Guest sakura]

Oh okay. If you're working with an unmodified ROM to start off, the easiest way is to just read the file table and then put it after the last offset pointed to. You can have your own program then update the file and scene tables, so that you can do the same thing reliably again if they're inserting another map.

[Jason777]

Alright, I have another question! I'm a little confused on how mesh type 1 is structured and I wish to have support for all three mesh types in the program I am writing. Anybody care to explain how it works?

[DeathBasket]

http://wiki.spinout182.com/w/Maps_and_Scenes#Mesh_Header

 

It would look something like 01nn0000 xxxxxxxx yyyyyyyy ...

nn would be the number of display lists to load and xxxxxxxx is the location of the display lists in the map file. yyyyyyyy is the location of the jpeg image in the map's file, I can't remember what the data following this does though, but according to the wiki it is 0x14 bytes long. I can't remember if I have notes on it somewhere...

[Jason777]

I'm starting to think that that doesn't apply to all mesh type 1 entries... take the Temple of Time day scene for example, here's its mesh header along with the data it points to :

 

0xA0 : 01 02 00 00 03 00 00 E8 02 00 00 00 03 00 00 B0
0xB0 : 00 82 00 00 03 00 7A F0 00 00 00 00 00 00 00 00
0xC0 : 01 40 00 F0 00 02 00 00 00 00 00 00 00 82 01 00
0xD0 : 03 02 D2 F0 00 00 00 00 00 00 00 00 01 40 00 F0
0xE0 : 00 02 00 00 00 00 00 00 03 00 7A E0 00 00 00 00

From what I can see with the information this is provided in the Wiki...

Type : 01

Number of Entries : 02

Start of Entries : 0x030000E8

JFIF Image : 0x02000000

 

Now that obviously isn't right. However, if we look down the data a bit, we find the true offset of the JFIF image : 0x03007AF0

^ Checked with this page : http://wiki.spinout1...FIF_Backgrounds

 

Start of Temple of Time (day) map in ROM : 0x032DF000
Temple of Time (day) JFIF image in ROM : 0x032E6AF0

  0x032E6AF0
- 0x032DF000
------------
  0x00007AF0

[DeathBasket]

Well I would guess that the word at 0xA8 gives the number of jpeg images, the word at 0xAC is where their entries are. Each entry looks to be 0x1C bytes long, they point to the images and maybe determine when each one should be loaded.

Could you check this out for the back alley maps?

[Jason777]

Well I would guess that the word at 0xA8 gives the number of jpeg images, the word at 0xAC is where their entries are. Each entry looks to be 0x1C bytes long, they point to the images and maybe determine when each one should be loaded.

Could you check this out for the back alley maps?

 

Your assumptions seem to make a lot of sense when applied to the data that is present. Here's the Back Alley's (day) mesh header :

0xB0  : 01 02 00 00 03 00 01 14 03 00 00 00 03 00 00 C0
0xC0  : 00 82 00 00 03 00 01 20 00 00 00 00 00 00 00 00
0xD0  : 01 40 00 F0 00 02 00 00 00 00 00 00 00 82 01 00
0xE0  : 03 02 59 20 00 00 00 00 00 00 00 00 01 40 00 F0
0xF0  : 00 02 00 00 00 00 00 00 00 82 02 00 03 04 B1 20
0x100 : 00 00 00 00 00 00 00 00 01 40 00 F0 00 02 00 00
0x110 : 00 00 00 00 03 07 56 88 00 00 00 00 00 00 00 00

Applying your logic to define the above data...

Type : 01
Entries : 0x02
Start of Entries : 0x114
-- Display List 0 Offset : 0x75688
-- Display List 1 (unused) Offset : NULL

Number of JFIF Images : 0x03
Start of JFIF 'Settings' Entries : 0xC0
-- JFIF 0 Offset : 0x120
-- JFIF 1 Offset : 0x25920
-- JFIF 2 Offset : 0x4B120

^^ The offsets line up perfectly with the offsets of the JFIF backgrounds page.

It seems you're on to something good, DeathBasket.

[DeathBasket]

It seems the jpeg image 'settings' folllow a format something like this then:

 

0082xx00 <- x is image number?

yyyyyyyy <- image pointer

 

00000000 <- constants from here?

00000000

014000F0 <- image dimensions? 320x240 is the size of all jpeg backgrounds in OoT

00020000 <- scale? is OoT run in 640x480 resolution?

00000000

 

Other maps will need to be checked out before this can be confirmed though. Numbers after the image's pointer could well be where it is to be drawn on the screen (top left at 0,0 and bottom right at 320,240) but I don't have any way of testing anything at the moment.

[Jason777]

I'll try replacing a JFIF with an image of different dimensions at a later time to see if there any noticeable changes.

[DeathBasket]

I'm wondering if you've made any progress on this? I understand you're probably busy, what with school/college and things starting and whatever, I'm just curious because I haven't got everything set up to test things out myself.

[Jason777]

I'm wondering if you've made any progress on this? I understand you're probably busy, what with school/college and things starting and whatever, I'm just curious because I haven't got everything set up to test things out myself.

 

You're dead on when you say that I've been busy with school. I have Fridays off, though, so I plan on experimenting then. Not to mention the tool I've been writing should be making its first public release on Friday if I continue work on it tomorrow

[DeathBasket]

Well after a quick test it seems most of the data following the image pointer is ignored. What I labelled as image dimensions actually sets how much of the screen the image takes up (see screenshot below) and what I thought might be the scale of the image actually seems to be the image type or something, changing it really messes with what gets displayed. Everything else does not seem to change anything when modified.

 

 

 

[SoulofDeity]

perhaps its the color encoding, a simple change from RGB to CMYK, HSV, or YUV might give those results.

[SanguinettiMods]

 

 

 

OFF TOPIC:

Is that my patch?

[Jason777]

I have one thing to ask of the members of this community... I am looking for the flag within the arrow actor that tells whether or not to shoot the arrow. If you don't know what I'm talking about, think of it as whenever you let go of the bow string, the arrow fires. The problem is that if you just spawn a regular arrow actor it doesn't fire and floats in mid-air.

 

Also, just a quick question: How would I "kill" an actor? I know that actors work in doubly-linked lists but would killing an actor through unconventional means (screwing with the actor panel in the RAM) automatically fix the pointers to the "next" and "previous" actor?

[Guest sakura]

Sorry that I don't know the specific offset for it, but there's a game engine function you call to clean up an actor properly after it's no longer needed.

[Jason777]

It looks like I'll have to try and find it myself again :/ Honestly, I can comprehend and understand a lot of things about hacking but I just can't seem to understand how to "search" for currently unknown values or RAM addresses... which sucks because it's a necessary skill to make hacks in ASM, C, or GS. The only hacks I've made were ones which utilized RAM address documenation that was already available to me.

[spinout]

Also, just a quick question: How would I "kill" an actor? I know that actors work in doubly-linked lists but would killing an actor through unconventional means (screwing with the actor panel in the RAM) automatically fix the pointers to the "next" and "previous" actor?

 

void kill(RamActor * actor)

{

actor->ActorDraw=0; /* Actor drawing code executed if non-zero */

actor->ActorMain=0; /* Actor AI code executed if non-zero */

}

Seems to work fine. The game figures out that it's no longer needed.

 

Of course, you could always do:

actor->next->previous = actor->previous;

actor->previous->next = actor->next;

[Jason777]

That's the way I was thinking of doing it.. It just seemed too straightfoward. Anyhow, thanks spinout (like always).

 

Does anyone have any ideas or methods to which they think I would be able to find the "shoot arrow" flag? Originally, I was thinking of monitoring the player controller to see what runs directly after the C-button is let go in the arrow actor. However, there doesn't seem to be any references to the controller RAM address in the arrow actor or the ovl_en_player actor after the arrow is spawned.. Any suggestions?