Zeldix Magic

The project being open source is a response to Hyrule Magic not being so.

Correct choice.

I don't quite understand your premise, but the custom option doesn't change pointers, it reads at a location that the user inputs.

The premise is simple. ALTTP is packed up tight, that's why you have all those byte which simbolize repetitive words rather than letters. There's no need for that if the rom is expanded to 2MB. Such a conversation is simpler, since it does not use those bytes at all, so your txt file with character value will thus be shorter and simpler and the coversion easier.

I don't have the location of the pointers for the monologue so I decided to have an option to read at a specific location if a the user moved the monologue location for whatever reason.

But you do. They are written on the first page of this thread.
I also tested the repointing out and it works.

Main bank E0000 is 1C8000 is 00 80 1C.

at 753EF there is one value of the pointer-load which is global bank which is 1C, and at 753F5 there is 00 80.
So basically I tested like so, leave 00 80, but simply at 753EF rewrite 1C to 22. This moves the data to 110000.

Now you are (in theory) no longer limited to 8000, thus the editor will never give you "out of space", which is what it is currently doing if you add a letter into any monologue.

Second bank is at 75F40 is 0EDF40 is 40 DF 0E.

Again main bank byte is at 7543C, which is 0E.
And 40 DF is at 75437.

I tested this like so: changed 0E to 24, and 40 DF to 00 80.
Now second bank is repointer to 120000, which is 00 80 24.

I also examined the code, and you can not find any secondary pointers. Only the 7F which is simply put at each of the monologue's end independently. Which basically means if any monolougue changes the entire string is shifted. Theoretically you thus write what you want without space limitations. The program should know to switch to the next monologue automatically after each 7F.

After testing in game, it was actually loading the texts from new locations.

Dictionary encoding is really, really easy unless you're worried about getting the absolute, 100% smallest encoding possible.  Imagine the following string:

Code:

The cat in the hat

With the following dictionary:

Code:

an
as
at
ha
he
in
is
the

You just start at the beginning of the string

Code:

The cat in the hat
^

Now you just loop through the entire dictionary using strcmp to see if there are any matches.  There are none (because of the capital letter.  So, add the letter to the encoded data array and move to the next letter

Code:

T
The cat in the hat
 ^

Loop through the dictionary.  You find a match.  Add the longest match into the dictionary.

Code:

T|he
The cat in the hat
   ^

No match (space)

Code:

T|he|
The cat in the hat
    ^

No match (c)

Code:

T|he| |c
The cat in the hat
     ^

Match (at)

Code:

T|he| |c|at
The cat in the hat
       ^

. . . etc, etc

Final result:

Code:

T|he| |c|at| |in| |the| |h|at

This does not always produce the absolute smallest/most optimal encoding.  The algorithm to do so is much more complicated, either recursive, or by sorting the dictionary by length and searching, either of which is going to be very slow in addition to the added complexity, so I personally wouldn't bother.  This algorithm is incredibly simple, and still works quite well.

Also, again, binaries should NOT be committed to the git repo, bundle them into a release instead. See my earlier link for setting up GitHub releases. I've done it myself, so I can't really judge, but I only did it for a one-off project that I never intended to really update (and still don't). For a repo with actual active development, you really just want to commit the source files. GitHub created the releases feature for a reason.

You're also missing the .sln/.vcxproj files, so it won't open natively in Visual Studio.

Puzzledude wrote:

I don't quite understand your premise, but the custom option doesn't change pointers, it reads at a location that the user inputs.

The premise is simple. ALTTP is packed up tight, that's why you have all those byte which simbolize repetitive words rather than letters. There's no need for that if the rom is expanded to 2MB. Such a conversation is simpler, since it does not use those bytes at all, so your txt file with character value will thus be shorter and simpler and the coversion easier.

I see. As of now, the monologue editing is fully coded for original ROMs with a DTE table. Are you suggesting I add support for ROMs that do not have a DTE table?

Puzzledude wrote:

I don't have the location of the pointers for the monologue so I decided to have an option to read at a specific location if a the user moved the monologue location for whatever reason.

But you do. They are written on the first page of this thread.
I also tested the repointing out and it works. ... [Snip]

Ah, I forgot about the post, sorry about that. From what I'm gathering from you, 0x75F40 is the PC address (PC as in computer, not program counter ) and 0x0EDF40 is the SNES address. 0E is the bank. So if I want to change where the game reads, you change these:

0x75437 (2 bytes) = 40 DF
0x7543C (1 byte ) = The bank


For the second bank, the PC address is 0xE0000 and the SNES address is 1C8000 (00 80 1C). So if I want to change where the game reads, you change these:


0x753F5 (2 bytes) = 00 80
0x753EF (1 byte ) = The bank


I'll change the program so it reads these values. I'll leave the searching option in though.

qwertymodo wrote:Also, again, binaries should NOT be committed to the git repo, bundle them into a release instead. See my earlier link for setting up GitHub releases. I've done it myself, so I can't really judge, but I only did it for a one-off project that I never intended to really update (and still don't). For a repo with actual active development, you really just want to commit the source files. GitHub created the releases feature for a reason.

I did it for SunGodPortal but it's gone now. If it isn't obvious already, I haven't used GitHub until this point. I've gotten used to the terminal program now, but working with other people's commits may pose another learning curve.

qwertymodo wrote:You're also missing the .sln/.vcxproj files, so it won't open natively in Visual Studio.

You previously suggested the files to be removed, so I did. I added them back in.

qwertymodo wrote:Dictionary encoding is really, really easy unless you're worried about getting the absolute, 100% smallest encoding possible.
[snip]

This does not always produce the absolute smallest/most optimal encoding. The algorithm to do so is much more complicated, either recursive, or by sorting the dictionary by length and searching, either of which is going to be very slow in addition to the added complexity, so I personally wouldn't bother. This algorithm is incredibly simple, and still works quite well.

I appreciate the post, however, I already implemented my own algorithm (it could be an already existing algorithm, I don't know) and the code can be seen on github in working form. You might not have known that considering the Visual Studio files weren't there.

As for the the recursive algorithm, I could look at it. I have experience with recursive algorithms before so I am familiar with them and also know that they aren't very fun to work with.

For everyone looking at the code, don't be afraid to pick out some code that's not so great that could be improved.

I see. As of now, the monologue editing is fully coded for original ROMs with a DTE table. Are you suggesting I add support for ROMs that do not have a DTE table?

There is no need if you already have this coded and it works, as qwerty described. I just though DTE was invented to save space, which (if repointed) is no longer needed. But like said, I never tested what happened if you exceed the 8000 data block. So no need to change things if they work.

Ah, I forgot about the post, sorry about that. From what I'm gathering from you, 0x75F40 is the PC address (PC as in computer, not program counter, Razz) and 0x0EDF40 is the SNES address. 0E is the bank. So if I want to change where the game reads, you change these:

0x75437 (2 bytes) = 40 DF
0x7543C (1 byte ) = The bank


For the second bank, the PC address is 0xE0000 and the SNES address is 1C8000 (00 80 1C). So if I want to change where the game reads, you change these:


0x753F5 (2 bytes) = 00 80
0x753E0 (1 byte ) = The bank

Yes, you only made one small mistake:
0x753E0 (1 byte ) = The bank

is actually
0x753EF (1 byte ) = The bank


I have to say superskuj found the first pointer and then because of this I could found the other one using the same strategy.

The good thing about is, that you can just choose a fixed repointing address. I can only suggest from 150000 to 200000, since from 100000 to 150000 is used for additional ASM hooks.

Trovsky wrote:I did it for SunGodPortal but it's gone now. If it isn't obvious already, I haven't used GitHub until this point. I've gotten used to the terminal program now, but working with other people's commits may pose another learning curve.

Sorry about my tone, I'm nursing a cold and dealing with way too many people around for the holidays (they're all great, I'm just an introvert in social interaction overload mode right now).  I was trying to be helpful, not judgmental.  You're absolutely right, git has quite the learning curve.  It's taken me quite awhile to get used to it myself.

You previously suggested the files to be removed, so I did. I added them back in.

I don't recall suggesting that, maybe it was when we were talking about alternatives to Visual Studio, like Mono or .NET Core?  In any case, if you're going to use VS, then you should include the project and solution files.  If you want to use something else, then you'd want to include whatever project metadata that alternative creates.  If I said anything to imply otherwise, my bad.

I appreciate the post, however, I already implemented my own algorithm (it could be an already existing algorithm, I don't know) and the code can be seen on github in working form. You might not have known that considering the Visual Studio files weren't there.

As for the the recursive algorithm, I could look at it. I have experience with recursive algorithms before so I am familiar with them and also know that they aren't very fun to work with.

Yeah, sorry I haven't gotten a chance to actually look at it yet.  Now that the project files are there, I'll definitely do that.  Don't bother with the recursive algorithm, it would be a lot of work for very little gain.

However, a cursory look over the code shows some things to look into

Code:

public bool writeToROM(string startingPosition, string size, List<byte>[] input, string copyFilePath)

Strings should never be used for sizes or offsets.  Use numeric, decimal values.

Code:

private string readBinaryFile(int startingPosition, int size, string typeOfReturn)

Again, strings are a bad fit here.  Use an enum.

I also wouldn't hard code the hex/dec/ASCII conversion into your file read routine.  I would just read the entire file into memory once on load, then any modifications should be done to that global memory buffer, and then the only time you need to touch the file again is when you save, just write out the whole buffer to file.

I'll probably fork your repo and actually commit some code, rather than just discussing it here.  I have my credits text code that could be modified to work here, so I already have at least that much I can contribute.  This looks to be a great project, and I'd love to contribute, so again, please excuse my tone if it's coming across as less than constructive.  Some of these issues are just much easier to catch as soon as possible rather than trying to course correct later once they've become more ingrained into the project.

qwertmodo I could sense a slight negative tone but at this time of year it's understandable, it's suicide season after all. Also, I understand you were trying to be constructive so it's all good.

You can definitely add your own code to the project. Make sure to create backups of your code in case I accidentally delete it or something along the lines of that.

qwertymodo wrote:
However, a cursory look over the code shows some things to look into

Code:

public bool writeToROM(string startingPosition, string size, List<byte>[] input, string copyFilePath)

Strings should never be used for sizes or offsets. Use numeric, decimal values.

Code:

private string readBinaryFile(int startingPosition, int size, string typeOfReturn)

Again, strings are a bad fit here. Use an enum.

I also wouldn't hard code the hex/dec/ASCII conversion into your file read routine. I would just read the entire file into memory once on load, then any modifications should be done to that global memory buffer, and then the only time you need to touch the file again is when you save, just write out the whole buffer to file.

I'll probably fork your repo and actually commit some code, rather than just discussing it here. I have my credits text code that could be modified to work here, so I already have at least that much I can contribute. This looks to be a great project, and I'd love to contribute, so again, please excuse my tone if it's coming across as less than constructive. Some of these issues are just much easier to catch as soon as possible rather than trying to course correct later once they've become more ingrained into the project.

I like the idea, go for it. And thanks.

Yeah, no suicide issues here, just irritated with too many people for my introverted self to handle

qwertymodo wrote:
I also wouldn't hard code the hex/dec/ASCII conversion into your file read routine. I would just read the entire file into memory once on load, then any modifications should be done to that global memory buffer, and then the only time you need to touch the file again is when you save, just write out the whole buffer to file.

It's important to note that I create a copy of the ROM into the resources folder and write modifications to that. Once the user wants to save the changes, the copy overwrites the target ROM. Can you give me an example of what you are thinking of? Would you still consider this information given my explanation.

I like to use the memorystream class for that, and filestream for reading/writing to the file itself. It's actually the only way I know so I couldn't tell you if there's a better way

Trovsky wrote:Can you give me an example of what you are thinking of? Would you still consider this information given my explanation.

When you open a new ROM file, get the size of the file and create a new byte array the same size as the file. Read the entire file into the array. All modifications such as text changes get written to the array. Nothing ever gets written to disk until you hit save, at which point you take the entire array and write it out to the output file. The entire ROM is only 1MB, and even expanded ROMs are only 2 or 4MB, so that's as big as the array would need to be. Just replace any of your ReadFromFile or WriteToFile functions with ReadFromBuffer/WriteToBuffer. Yes, I would still suggest this. It makes everything faster and eliminates unnecessary file I/O.

qwertymodo wrote:
When you open a new ROM file, get the size of the file and create a new byte array the same size as the file. Read the entire file into the array. All modifications such as text changes get written to the array. Nothing ever gets written to disk until you hit save, at which point you take the entire array and write it out to the output file. The entire ROM is only 1MB, and even expanded ROMs are only 2 or 4MB, so that's as big as the array would need to be. Just replace any of your ReadFromFile or WriteToFile functions with ReadFromBuffer/WriteToBuffer. Yes, I would still suggest this. It makes everything faster and eliminates unnecessary file I/O.

I'll respectively decline that proposition. Loading 1MB is too much to store in memory. Keep in mind that I don't have the best computer.

Trovsky wrote:Loading 1MB is too much to store in memory.

Uhh... if you can run Visual Studio, you can spare a single MB of RAM.  Just opening the IDE takes over 100, much less loading a project or building.  Seriously, once you start adding things like overworld and dungeon editing, you'll be using way more than that just to load the UI.  1MB is nothing.

Edit: Just running your program as-is takes ~12MB. So yeah, you're vastly overestimating the impact of 1MB.

Good point. Currently I am coding Romio so the byte array is inside the class. This is cleaning up a lot of bad code. I will rename this class monologueio and I will create a new class called Romeio that stores the ROM in an array. I plan to have the option to use my previous method of storing a temporary ROM that can be toggled on and off, when it's off the ROM is stored in an array. Why? I don't even know why.

Happy new years. The repo has been updated to make the program read and write from an array and write to a ROM once you save. Nothing huge for the lay user, but the improved code will pay off in the future. The improved code also cuts the reading time of the monologues in half. The program also reads the bank pointers and converts it from a SNES address to computer address.

Next feature to do: music!

The current documentation I've done can be found on the wiki by clicking here. Anyone have any useful documentation for the game's music? I'm confident in how the game stores the music notes and effects but not with the pointers, measure IDs, and how the game deals with loops. It doesn't help that Hyrule Magic is a total crash-fest with the music editor.

Sorry I've been a bit busy this season and I'll be out of town for a week starting soon, but when I'm back hopefully I'll be able to start contributing again =]

Update:
* Hex Viewer Added -- A quick hex viewer I made. Hope it's useful.
* Music proof-of-concept viewer added -- Lot's of work is ahead. Currently, the program can interpret notes, sound effects, and sound effect arguments.

superskuj wrote:Sorry I've been a bit busy this season and I'll be out of town for a week starting soon, but when I'm back hopefully I'll be able to start contributing again =]

No problem.

There are SPC track pointers at ROM address 0x0E1EF8 for song bank 1.  The table might actually start earlier, I don't remember, that's just the address that I modified...

Edit: This was Parallel Worlds, so it's possible that HM might have moved things around. Hard to say.

qwertymodo wrote:There are SPC track pointers at ROM address 0x0E1EF8 for song bank 1.  The table might actually start earlier, I don't remember, that's just the address that I modified...

Edit: This was Parallel Worlds, so it's possible that HM might have moved things around. Hard to say.

Are referring to the pointers for the sound channels? Yeah, it would be helpful to have the pointers for the unmodified ROM because that's what I'm working with. Basically, I need a better understanding of how everything is stored in the ROM. See the wiki for my notes: http://alttp.run/hacking/index.php?title=Music:Locations

The addresses may be slightly off because Hyrule Magic moves things around.

No, not for the sound channels, it was for the full songs.  2-byte pointers, 1 per song.  I used it to redirect some of the unused songs to act as duplicates of other tracks (e.g. track 15 became a duplicate of the light world overworld theme, then the MSU-1 track 15 is an alternate version of that theme with an intro fanfare), and all I had to do was copy the 2 bytes for the song I wanted to duplicate and paste them over the 2 bytes for the unused slot.

Looking at my code, my data table is 30 bytes long, starting at 0x0D1EF8, so that matches up with bank 1, which has 15 tracks.  I'll do a quick test and see if the address is the same for the original ROM.

Edit: Yep, same location. If you feel like testing it yourself, go to 0x0D1EF8, the first 2 bytes are D0 36. Overwrite the next 28 bytes with D0 36 D0 36 D0 36 etc, and every song will play the opening intro instead (well, every song in bank 1, I don't know where the pointer table for bank 2 is, I never bothered to track it down).

Thank you for the the explanation. Two other things I'm curious about, in Hyrule Magic there's values that range from 00 to 7F that are to the left of the notes and effects, what do these do? Also, can you shed light on how instrument samples are stored? I wish to have samples exported and imported as WAVs.