Zeldix Magic

An open source in-progress alternative to Hyrule Magic



CLICK HERE FOR THE ALPHA BINARY (WINDOWS)

Estimation of progress:
Monologue editor:


Address converter:


Hex Viewer:


Music editor:


Menu screen editor:


Credit text editor:


Graphics editor:


Overworld editor:


Enemy editor:


HELP WANTED:

• Music pointers
  
• How graphics are loaded into for the overworld
  

Github: https://github.com/trovsky/Zeldix-Magic
Documentation: http://alttp.run/hacking/index.php?title=Main_Page
Chat: https://discord.gg/jP5csBn

Notes for me:

https://stackoverflow.com/questions/21890168/wpf-usercontrol-property-change-not-updating
https://stackoverflow.com/questions/9413701/create-bitmap-from-binary-data/9413818
http://www.romhacking.net/utilities/1124/

Will it be open source? A public source repo would be a great resource. It would also provide an alternative to the sketchy download site.

qwertmodo: The project is now on github. Enjoy. https://github.com/corndoggers/fantastic-octo-chainsaw

Flóki wrote:Most likely would attract more people to the open nature of the project.
Good luck!

Thanks, the project is on github. But with Nintendo handing around a C&D to prism, I'd rather this be something between the community.

FYI: The project is in C# and was created with visual studio.

Well, ROM tools are like emulators, legal in and of themselves, so the public community driven approach is probably the best. The hacks made with those tools are what's more likely to receive a CnD/DMCA takedown.

Hi, if this project is still going after the new year i'll definately join you instead of making my own editor if you are looking for help !
i have 3 functions in c# you might find useful, decompress gfx, snestopc/pctosnes address http://pastebin.com/aYrTvqZA , i was planning on making my own "dungeon" editor.
also i'm not a fan of forums that's why it my first post, but i'm really active in the alttp discord

Good to see some new people involved into ALTTP modding which are actually able to code. I once wrote a series of documents for this very reason, since I know how the game works and know the code in hex, but still don't know programing languages to be able to program an editor myself:
http://www.bwass.org/bucket/Z3_Puzzs_Docs.zip

I would definitely recomend for you to team up:
Trovsky, superskuj, XaserLe, zarby
are the people I know, who have now all had an idea of a new editor (specially dungeon editor for starters).

Just a couple of quick notes, you need to add a .gitignore file to filter out the bin and obj folders (see here https://github.com/github/gitignore/blob/master/VisualStudio.gitignore ), and also I would rename your sln and csproj to something actually relevant instead of the default Application1 names.

Your idea is fantastic, HM really must be replaced by something better and most complete.  I just don't think C# is the correct choice for this project. The users will have trouble to run it in another operational system or even contribute to the project since it is a microsoft proprietary language.

C# is fine, it's been portable for years thanks to Mono, and now .NET Core. I personally use C++ more, but C# is a lot easier to work with.

qwertymodo wrote:C# is fine, it's been portable for years thanks to Mono, and now .NET Core. I personally use C++ more, but C# is a lot easier to work with.

I tried mono. The bare boned terminal environment didn't do it for me.

There are plenty of IDE's with Mono support, or VS Code with .NET Core.

This should be fun =]

I'm very much a novice programmer, so if I can't contribute much to the coding I'll at least be able to continue documenting the game and filling in the wiki.

I wish I could give some more info about what the others are working on, but I don't have anything specific right now.

So I guess your plan is to build a single application that contains all or most editing tasks within itself. Similar to HM but obviously superior. Do you have an overall design plan yet? I was working on some classes to format some game data (specifically dungeon data) into runtime objects, for the program to use then format back and restructure/repoint data in the rom upon saving. I can continue work on those if they'll be useful for you. We should also consider where to relocate expandable data, or rather how we should map the expanded banks, though that doesn't need to be committed to in the short term.

Anything that can be moved should be configurable, or at least it should be able to load that data from anywhere, based on the pointers, rather than assuming a hard-coded location (at least anywhere that it's possible to do so).

Also, as an idea, it would be really cool to be able to save the project in patch form directly, along with multiple versions. Basically, the way I could see it working would create a project folder, similar to the way something like Temporal Flux does for Chrono Trigger. Then you could save project settings, decompressed data like the graphics, and other things all in that folder. Then, when you save, it would just save an ips/bps instead of the full ROM. Then you could have it save x number of previous versions and they would all get retained in that folder as well.

I added an export function to export the text as plaintext or hexadecimal. I'm currently looking into improving some dirty code in the Romio class to make the class more efficient.

qwertymodo wrote:There are plenty of IDE's with Mono support, or VS Code with .NET Core.

Can you recommend any specific IDE? If I can use my visual studio code that would be great. I'd rather not use Windows.

qwertymodo wrote:Anything that can be moved should be configurable, or at least it should be able to load that data from anywhere, based on the pointers, rather than assuming a hard-coded location (at least anywhere that it's possible to do so).

I agree with this.

superskuj wrote:This should be fun =]
I'm very much a novice programmer, so if I can't contribute much to the coding I'll at least be able to continue documenting the game and filling in the wiki.

Keep it up, documentation is important!

superskuj wrote:So I guess your plan is to build a single application that contains all or most editing tasks within itself. Similar to HM but obviously superior.

My goal is to pretty much copy Hyrule Magic.

superskuj wrote:I can continue work on those if they'll be useful for you.

I haven't looked the dungeons yet. I say that organizing dungeon data into a significant data format is useful.

qwertymodo wrote: Then you could have it save x number of previous versions and they would all get retained in that folder as well.

Having a backup directory of all saved ROMs sounds like doable task to me.

Anything that can be moved should be configurable, or at least it should be able to load that data from anywhere, based on the pointers, rather than assuming a hard-coded location (at least anywhere that it's possible to do so).

Yes, please do that, since this is the whole point of debugging. You can not edit ALTTP without this, as the original rom is packed up tight, not allowing changes by default. And thus one of the first steps is the editor to be able to autoexpand the rom to exactly 2MB and keep it at this size all the time (could also be 3MB or 4MB).

The main problem of Hyrule Magic is exactly this. The Rom gets bugged, since the program runs out of space and the program is also unable to expand the Rom to 2MB, it even shrinks it back to orthodox size after you manually expand it.

HM is also unable to read the pointers, as it assumes the data to be on certain locations. This is also resulting in bugs.

Imagine the editor would be able to actually read the pointers (specially for indoor data). Then such a program would be compatible even with the RT (room transfer) program, which is already alocating the indoor data optimally to the back of the rom. Such a program could in theory then also load and be able to edit Parallel Worlds, which has its own unique room data locations at around 118000.

Try Visual Studio Code (it's not the same as Visual Studio, and it's cross-platform) with .NET Core: https://code.visualstudio.com/Docs/languages/csharp

Fun fact: Hyrule magic allows monologues to be expanded in size but never bothers changing the pointers.

If anyone knows where the pointers for the monologues are that would be helpful.

qwertymodo wrote:Try Visual Studio Code (it's not the same as Visual Studio, and it's cross-platform) with .NET Core: https://code.visualstudio.com/Docs/languages/csharp

I did try that. It doesn't have the bells and whistles I was looking for. I don't think you can use .sln files from Visual Studio...?

I don't think monologues have pointers in ROM, they get generated at runtime. I just ran into that the other night trying to manually hex edit the PW script.

qwertymodo wrote:Anything that can be moved should be configurable, or at least it should be able to load that data from anywhere, based on the pointers, rather than assuming a hard-coded location (at least anywhere that it's possible to do so).

Yep and that's pretty easy to do. I have some code that does this in fact. I just need to clean it up and whatnot. I think the program should have default areas to put specific expanded data, and allow the user to set different ones if they have a need to. In fact the pointer tables can even be moved as long as the dungeon object/sprite/etc load routines aren't moved.

qwertymodo wrote:I don't think monologues have pointers in ROM, they get generated at runtime. I just ran into that the other night trying to manually hex edit the PW script.

Yeah that's accurate. Some table in RAM is populated with monologue pointers when the game is first loaded. If you want to relocate monologues I guess you just need to find the subroutine that does that and hope it uses a long address to find that data. In fact monologue data is divided between two banks anyway so at least relocating the second section should be easy. I'll take a look and see if I can find it

Monologue data starts at $0E0000(PC) or $1C8000(snes)

The byte at $0753EF (PC) is the bank($1C), and the two bytes at $0753F5-$0753F5 (PC) are the address ($00 $80)

That makes the little endian address $00801C (which converts to PC $0E0000), which is where the routine starts looking for monologue data, and uses some termination character to recognize the end of one monologue and to roll over to the next pointer.

It is luckily a long address so that should be all you need to relocate monologues

Ah right, there's obviously going to be a main pointer to the start of the table somewhere (possibly in more than one place), which you'd need to modify if you want to move the data, but the individual pointers to individual monologues are calculated at runtime based on the end markers and stored in a table in bank $7F.

Monologue data starts at $0E0000(PC) or $1C8000(snes)

The byte at $0753EF (PC) is the bank($1C), and the two bytes at $0753F5-$0753F5 (PC) are the address ($00 $80)

That makes the little endian address $00801C (which converts to PC $0E0000), which is where the routine starts looking for monologue data, and uses some termination character to recognize the end of one monologue and to roll over to the next pointer.

It is luckily a long address so that should be all you need to relocate monologues

Nice find, although monologues have 2 banks.


Main bank (bank A) is:
-starts at E0000, and the block data is 8000 (in hex) long.
-E0000 is 1C8000 is 00 80 1C

-global bank is 1C, which is loaded at 753EF, with A9 infront
-local bank is 00 80, which is loaded at 753F5, with A9 infront


Additional bank (bank B) is:
-starts at 75F40, and the block data is 14C0 (in hex) long.
-75F40 is 0EDF40 is 40 DF 0E

-global bank is 0E, which is loaded at 7543C, with A9 infront
-local bank is 40 DF, which is loaded at 75437, with A9 infront


Monologues then have no secondary pointers, since this one "separated" pointer is the only thing the game needs.

Once it loads the address, it reads letters in hex, untill it reaches 7F, which is end of monologue.

Note, first monologue is empty, thus 7F starts the string.

Bank A contains most monologues (first big part), while B contains what could not be fit into the 8000 data block. These monologue are at the end, and the barrier between the two should be that long Triforce monologue.