Kuribo64
Views: 19,851,280 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
03-28-24 03:59 PM
Guest:

0 users reading Editor development | 2 bots

Main - General SM64DS hacking - Editor development Hide post layouts | New reply

Pages: 1 2 3 4 5 6 7 8 9 ... 27 28 29 30 31
Skelux
Posted on 03-30-13 08:29 AM Link | #18819
Posted by Fiachra
Posted by Skelux
Are you certain of these addresses? I tried each of them In my arm9.bin and all would either do nothing or freeze the game. I uploaded it, I was pretty sure It's an EUR copy: http://www.mediafire.com/?9neoxfj6nnc9019

I'm pretty sure it's right, I was able to modify it. I'm not on my computer right now so I can't check that arm9 unfortunately. Is it definitely the patched one? If you open it in a hex editor you can find the table by searching for: 03 20 ff 03 20 off
(1st 2 entries). Copying 08 23 3b to the 2nd entry will change castle grounds to JRB music for example. I haven't figured out what the individual bytes do yet.


Found it at 0x7176B. I have no idea what ROM version I have, but anyhow, I'll get back to work.

Fiachra
Posted on 03-30-13 08:40 AM Link | #18820
I got the EUR address looking at ROM in disassembler. Forgot to subtract 0x4000 for arm9.bin. I think the rest are for arm9.bin so add 0x02004000 to get their ROM address. I'll update the list later when I'm on the computer.

Fiachra
Posted on 04-01-13 06:26 PM Link | #19005
I've managed to patch the game to store and read the music data from the individual level overlays and have added the ability to change their values via the Level Settings dialogues. I'm on holidays at the minute so I'll commit the code when I get back next week. Wanted to say in case anyone else started working on doing it.

Skelux
Posted on 04-03-13 04:32 AM (rev. 2 of 04-03-13 04:32 AM) Link | #19086
It seems that sequences 0x13 to 0x47 are loaded into memory during the game, I cannot get any mini game or vs mode tunes to play. I'm unsure what the first two bytes are for, but I found that some sequences are able to share them.

eg:
Sunshine Isle - 24 35 44
Peach Note - 24 35 46
Ending - 24 35 48

Within that range, I am having trouble getting the credits music (staffroll) or rabbit (usagi) music to play.

Fiachra
Posted on 04-06-13 03:20 PM (rev. 2 of 04-06-13 04:02 PM) Link | #19256
Have committed code:

-Music data stored in and loaded from level overlays.
-Added option to copy CLPS data from another level, no more need to worry about levels having correct collision types.
-Fixed problem with some punctuation characters in text editor.
-Added editing 'Type 14' objects, just for completeness.

Arisotura
Posted on 04-06-13 03:27 PM Link | #19258
Just curious, how did you modify the ROM patching?

ROM patching was designed to be backwards compatible without requiring external patches, ie added patching is added in a Patch_v4() function or so, and the patch version is incremented...

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

Fiachra
Posted on 04-06-13 04:02 PM (rev. 2 of 04-06-13 04:53 PM) Link | #19264
Ok, have fixed that.

Edit:
If you were asking how the game is patched:

Originally, the game used this for loading the first byte:

Multiply the level id by 3 and use that as an offset
point R2 to music table address (stored as a dword nearby)
load byte into register found at above table + calculated offset

The second and third bytes were similar but loaded and

I got the locations at which the music table, music table + 1 and music table + 2 addresses were stored and replaced them all with the address the overlays are loaded into memory at + the offset of the first music byte (lvl_start + 0x7C), which very handily is the same for all the new overlays.
I replaced the offset calculations with offset 0 for byte 1 (0x7C), offset 1 for byte 2 (0x7D) and offset 2 for byte 3 (0x7E).

Arisotura
Posted on 04-06-13 04:55 PM Link | #19269
Sounds perfect :)

I should definitely try this out. Have any of you managed to change those bytes without just breaking all sound?

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

Fiachra
Posted on 04-06-13 05:18 PM Link | #19270
Posted by Mega-Mario
Have any of you managed to change those bytes without just breaking all sound?


Not yet, I can only replace one completely with another :(

I wonder if there's maybe another table that specifies a range of sounds that can be loaded for each level. The first byte, for example seems linked to the level id - it increments for each level or group of similar levels. Eg. JRB and JRB Ship both use 08 and although BOB and WF both play the same music, they use 06 and 07 as the first byte.

Skelux
Posted on 04-08-13 02:23 AM (rev. 2 of 04-08-13 05:22 AM) Link | #19515
I'm still a little unfamiliar with ARM debugging, but using the messy No$gba debugger I was able to figure out a few things. Byte 1 is definitely related to the SWAR/s used in the level. Upon entering a new level, the game checks if this byte is equal to the first byte of the previous level you were in, and if not, runs through some functions. I haven't looked into byte 2 much yet, but it seems to have multiple purposes. During the game, you can find byte 1 at 0209B47C and byte 2 at 0208E428. I was able to play some minigame tunes and even the credits by finding the correct values this way, but these sequences seem to mess up sound effects. Below is my current list of working values.

Select Minigame: PLAYROOM: 27 05 05
JAZZ: 27 05 08
CASINO: 27 05 09
BOMB: 27 05 0B
CASINOM3: 27 05 0D
Title: 02 20 37
Inside Castle: SHIRO: 03 20 39
Water: WATER: 08 23 3B
Desert: MOTOS: 0C 29 3F
Final Bower: 22 33 43
Sunshine Isle: DOLPIC: 24 35 44
Peach Note: 24 35 46
Ending: ENDING: 24 35 48
Credits: STAFFROLL: 26 20 49
Wake Up: 06 21 4A
VSSHIRO: 2B 20 4B
VSATHRETIC: 2E 36 4C

Edit:
I started playing around with the intro. So far I have been able to disable the first part of the intro by NOPing 020FE314 after placing a breakpoint at 0202D2B8, though it causes some errors in the graphics. There are some interesting values at 0209F2D8 and nearby, changing this byte to 1 will make the game enter VS mode.

Fiachra
Posted on 04-08-13 07:56 AM Link | #19524
Very helpful. If you (or anyone) works it out I'll add a way to calculate the right values. I think byte 2 is related to sound effects somehow.

Disabling the intro is definitely something I want to add to the editor. I'll try looking into it as well. There's an AR code to do it, maybe that'll be helpful. I also want to allow changing starting level.

Fiachra
Posted on 04-12-13 10:39 AM (rev. 2 of 04-12-13 11:20 AM) Link | #19898
Rev. 43 (12/04/2013)

- Added support for editing paths.
- Improved model exporting for custom models (Kd values)
- Fixed rare bug with removing certain types of objects where minimap tile IDs were overwriting object parameters. (Probably what Skelux was referring to here)
- CLPS entry editing - add, remove, edit and change position of entries

Important note on paths:

Adding and removing existing nodes won't work but I have no idea why, especially after fixing bug mentioned.
You can edit nodes within existing paths and change their starting nodes and lengths.
Objects that use paths store the path ID in Parameter 4 (offset + 0xF).
When adding a new path, add the nodes first and then add the path and set the indices.

Also, discovered why Shifting Sand Land has so many collision types - they used a unique collsion type and path for every single slope!

Skelux
Posted on 04-12-13 01:27 PM Link | #19904
Damnit Fiachra, just after I finished figuring out how to edit the CLPS table for the most recent level haha.

Are you certain that there is an AR code to disable the peach/lakitu opening sequence, if that's what you mean? If there is, I could easily trace it back and remove the intro.

Also, I am having another issue with text editing. I find that after I edit a number of text strings, the entries at the back of the table start being overwritten, which effects saving and such. Any ideas on if this can be fixed?

Fiachra
Posted on 04-12-13 01:58 PM (rev. 2 of 04-12-13 04:50 PM) Link | #19906
Posted by Skelux
Damnit Fiachra, just after I finished figuring out how to edit the CLPS table for the most recent level haha.

Are you certain that there is an AR code to disable the peach/lakitu opening sequence, if that's what you mean? If there is, I could easily trace it back and remove the intro.

Also, I am having another issue with text editing. I find that after I edit a number of text strings, the entries at the back of the table start being overwritten, which effects saving and such. Any ideas on if this can be fixed?

:)

There's definitely an AR code, it's only for the US v1.1 version though:

Skip Intro
220960E8 000000FF

I've been meaning to fix the text editing one for a while but left it because I thought it only affected the last string and because it seems completely random. I'll start trying to fix it now.

Edit:
Fixed it (rev. 44). None of the strings should corrupt now. Also made it easier to work with - it'll save all changes at the end and you won't lose your place. Also, code is much neater.

Skelux
Posted on 04-13-13 02:47 AM (rev. 8 of 04-13-13 05:28 AM) Link | #19947
Great, I'll revert the dialog file and fix everything up.

The intro is eliminated.
EUR: ROM 0x13DF4 to 0x88
US: ROM 0x13CD0 to 0x88
US 1.1: ROM 0x13D48 to 0x88
JAP: ROM 0x13D48 to 0x88

Edit: I should also mention, r43 and beyond are not displaying object parameters correctly.
Edit 2: Hold on, this intro disable only works if there are no existing files. Looks like a couple of values will need to be changed, ill find it in a few minutes.
Edit 3: I corrupted my file and can't seem to recreate the problem where it still displays the intro. It may only occur with files created before the patch, I really don't know, I'll just have to test it again once the problem surfaces again.

Edit 4: There is still an error with text editing. Rather than trying to explain, I'll just show you: http://www14.mediafire.com/convkey/d27d/2qno1b1ohac8qnl9g.jpg

Fiachra
Posted on 04-13-13 07:56 AM (rev. 3 of 04-13-13 08:40 AM) Link | #19981
Posted by Skelux
Great, I'll revert the dialog file and fix everything up.

The intro is eliminated.
EUR: ROM 0x13DF4 to 0x88
US: ROM 0x13CD0 to 0x88
US 1.1: ROM 0x13D48 to 0x88
JAP: ROM 0x13D48 to 0x88

Edit: I should also mention, r43 and beyond are not displaying object parameters correctly.
Edit 2: Hold on, this intro disable only works if there are no existing files. Looks like a couple of values will need to be changed, ill find it in a few minutes.
Edit 3: I corrupted my file and can't seem to recreate the problem where it still displays the intro. It may only occur with files created before the patch, I really don't know, I'll just have to test it again once the problem surfaces again.

Edit 4: There is still an error with text editing. Rather than trying to explain, I'll just show you: http://www14.mediafire.com/convkey/d27d/2qno1b1ohac8qnl9g.jp <br>g

Great, I'll get that added to the editor, I'll make it an option you can toggle on and off.

I changed the object parameters so you could edit the path ID more easily. Do other objects need this as 16 bits long? If so I'll change it back?

Sorry, I thought it was working, will try again.

Edit:
I think I found the problem, I wasn't calculating the difference in length between the new and old strings correctly. Try changing:
int lengthDif = txtEdit.Text.Length - m_StringLengths[selectedIndex];
(Second line in UpdateEntries())
To:
int lengthDif = EncodeString(txtEdit.Text).Count - m_StringLengths[selectedIndex];

Skelux
Posted on 04-14-13 04:30 AM (rev. 4 of 04-14-13 04:32 AM) Link | #20295
It worked, but I believe we have just discovered why it was necessary to cut off the end strings once you add too much text. It seems that anything above ~8000 bytes exceeds the allocated memory space, thus crashing my most complicated on entry because it overwrites some of level data (At least this is my assumption of what is happening).

Would it be possible to re-compress the dialog data, or shall I just simplify the level some more?

Fiachra
Posted on 04-14-13 07:43 AM (rev. 4 of 04-14-13 03:17 PM) Link | #20302
The code to compress is already there, it's used for the minimaps, it'll be very easy to add.

Add:
file.Compress()
before
file.SaveChanges()
in the writeData() method.

I'll also check if it makes a difference to the max poly count if you compress the model?
Edit:
It doesn't, but the option "Drop faces below ..." makes a huge difference - I was able to import an 8000 face model without crashing if I left it at the default 0.001. If I set it to 0 it crashed. Really wish I had realised that earlier, would have made importing Sunshine's models a lot easier.

Edit 2:

Rev. 45 14/04/2013

- Fixed Text Editor problem
- Added option to create, edit and apply own patches (including skipping the intro, thanks to Skelux). When you create a patch a note is made of the original data so you can easily undo it if you make a mistake. Patches are stored as an XML document, so it's easy to update etc.


[image]

Skelux
Posted on 04-15-13 03:45 AM (rev. 4 of 04-15-13 04:24 AM) Link | #20433
CCC still freezes even after compression, I forgot to consider that the game decompresses before copying to memory. Even with the file smaller though, CCC still freezes on entry if I replace the text. I'll have to experiment a bit to figure out the problem.

Edit: CCC really doesn't like this, I just edit one string in r45 and it starts freezing. Then, I open the file in r42, save one string (it deletes a bunch off the end of course) and it starts working again. Are you certain everything is being calculated correctly? Even so, it doesn't make sense that all other levels work.

Edit2: Removing half of the objects from the level fixes it, so it must be some sort of memory issue. The only problem is trying to cut back the level more, I had trouble simplifying it even as much as it is now. Would it be too difficult to make the text editor fully remove the original string rather than repointing to the end of the file (or whatever it is doing)?

Fiachra
Posted on 04-15-13 05:52 AM (rev. 2 of 04-15-13 06:14 AM) Link | #20442
It doesn't move text to the end, it checks if the new string is longer or shorter and if so shifts all following pointers and data forward or back and writes the new string at the original location, so it should be the same as r42.
I'll have a look at it, might be DAT1 size not being updated. What level does CCC replace?
Pages: 1 2 3 4 5 6 7 8 9 ... 27 28 29 30 31

Main - General SM64DS hacking - Editor development Hide post layouts | New reply

Page rendered in 0.067 seconds. (2048KB of memory used)
MySQL - queries: 28, rows: 236/236, time: 0.029 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.