Finally, after months of hard work, I'm glad to announce my mysterious (not on Discord) project, Mushroom Studio! Here is the current look of the application (It's still WIP):
What is Mushroom Studio?
Mushroom Studio is an open source tool whose aim is to become an Integrated Hacking Environment for SM64, a fully functional environment that will help the hacker to be more productive through the automation of many tasks, combined with the power of a user friendly interface. Even if at the first releases it will be able to do only some basic level editing operations, I'm willing to add many functionalities.
Special Thanks
I would like to thank queueRAM for creating n64split and helped me on various subjects concerning SM64 hacking. Also, I thank a lot many members of the SM64 hacking community, some of then inactive by years, who left exceptional hacking notes and guides, and some who responded to my questions about SM64.
I also thank the contributors of Helix Toolkit, even if it's difficult that they'll see this post.
Finally, I want to say a big thank to everyone is believing in this project, and is looking forward to it: You give me the force to keep me motivated succeed in a task where many failed.
FAQ Why the terrain of the level has those strange colors and has no textures?
Unfortunately, n64split v0.4a extracts from the ROM only the collision maps of the levels, coloring the various surfaces depends on their collision types. It is possible to get the visual maps from the raw ROM data, but it needs a good understanding of F3D commands that currently I don't have, so, for now, I stick with collision maps.
Why there are so few features? What were you doing all the time?
Adding a new feature to a hacking tool requires a lot of work: You have to study the subject; create a formalized model (an algorithm) to make the editing process possible; implement the model as code and use different inputs to test if the algorithm works properly. However, that does not explain the whole thing. When I said on the IRC channel that I was making a mysterious "hacking tool" (It was the second half of November), I've started doing my first serious WPF practices something like two weeks before. I hope that new features will take less time to implement since I'm now more confident with WPF (even if not 100%).
Does it run on Linux or Mac?
Unfortunately no, since WPF is windows only. However, if you really want to try this tool, you can install VirtualBox on Linux/Mac and run Windows on it (you can make a windows 10 iso through the media creation tool provided by Microsoft, for free).
Will it support extended ROMs?
Probably, even if not at the first release. Extended ROM support could be useful in the short term because it adds compatibility with other tools that work on extended and patched ROMs (e.g. Super Mario Editor). However, in the long term, since n64split has a huge pontential, it would be a huge step forward if we get rid of the concept of working on a built ROM, and we begin to think in terms of building a ROM based on a set of assets that we modify or add. Then, we won't need anymore extended ROMs, unless for retrocompatibility.
Will it support other N64 games?
I'm not planning to support other games, since the amount of work is already big focusing on SM64. However, the license lets you reuse and adapt the code of Mushroom Studio to support other games.
How can I contribute to the project?
The most helpful thing you can do is to play around with the program to see if any of its functionalities have bugs. Even if you can't use it now to effectively hack ROMs, you'll help me a lot if you can track down issues and show me if you like or not the design decisions I have made.
I also made a wiki for who wants to furtherly develop Mushroom Studio.
This is fantastic. I can see all of the work you've put into it already. It's gonna be so great not having to open TT64 as much! I'm not just hyped, I'm hyper hyped! (is that even a thing?)
Trello board is now public. Check it out at https://trello.com/mushroomstudio
This will give you an insight of planned features and current state of the project.
I am pleased to see the amount of progress you are making with Mushroom Studio. I know this takes a lot of effort to parse and understand all the data and significantly more work for rendering it and presenting a user interface to manipulate the data. By the way, have you seen Jedi's level editor he was making in Unity? It had similar goal of building a 3D editor on top of n64split, but using Unity for the user interface. Jedi is no longer working on it, but if you haven't seen it, it might be worth checking out how certain things were implemented.
I also wanted to let you know that I have some changes to n64split coming down the pipe and I would be more than happy to work with you if you have some ideas for improvement, especially if there is anything I can do to make things better for Mushroom Studio. I'm also seriously looking to switch from GNU assembler to armips which will allow me to handle some of the encoded strings and more easily package the assembler with n64split. The syntax shouldn't change much, if at all.
(26-01-2017, 04:27 PM)queueRAM Wrote: I am pleased to see the amount of progress you are making with Mushroom Studio. [...]
I've already looked at the source code of Jedi's editor. I found it useful to find the right string functions to get the data in the level commands. However, the source is not very well structured, so i figured out by myself most things, or I asked help for that.
I'm very happy to collaborate with you. n64split is an awesome tool, and has a great potential. I used it for gathering level objects and area collision maps only for now, but I want to use all of its potential in the future.
The thing that I most like in n64split is that you don't edit a preexisting rom, but you work on a set of assets that will be built into a rom. This concept is so simple and clean that if applied correctly, also eliminates the necessity of expanding a rom to fit more stuff in it. To get to this point however it is needed to track down all the references to other parts of the rom and label them. This is one of the most important things I care about, because it would be very nice to have, for example, variable length level scripts, so that it will be possible to add more objects into a scene.
About the adoption of armips, if it permits to decode more data in the rom, I'm totally in favor of it, even if GNU has the huge advantage of supporting C coding. I was thinking about adding C coding feature in Mushroom Studio in a distant future, but maybe I could figure it out without relying directly on n64split.
(27-01-2017, 02:06 PM)Fendoroid Wrote: The thing that I most like in n64split is that you don't edit a preexisting rom, but you work on a set of assets that will be built into a rom. This concept is so simple and clean that if applied correctly, also eliminates the necessity of expanding a rom to fit more stuff in it. To get to this point however it is needed to track down all the references to other parts of the rom and label them. This is one of the most important things I care about, because it would be very nice to have, for example, variable length level scripts, so that it will be possible to add more objects into a scene.
Yup, one of my big goals in the next release of n64split is to track down more of the data and use labels for all references, so that code and data can be moved around without issue.
(27-01-2017, 02:06 PM)Fendoroid Wrote:
About the adoption of armips, if it permits to decode more data in the rom, I'm totally in favor of it, even if GNU has the huge advantage of supporting C coding. I was thinking about adding C coding feature in Mushroom Studio in a distant future, but maybe I could figure it out without relying directly on n64split.
I was hesitant to switch assemblers because of the potential of using C coding as well. However, when I found out about the ".importobj" directive in armips that can link in ELF object files (e.g. gcc compiled .o files), I was sold on armips. I put together a simple "hello world" example in C to show what I mean armips_sm64_importobj_sm64.tar.gz. The asm file hooks into the ROM and calls the C code. The C code then calls an existing PrintXY() function (0x802D66C0). It's really a slick feature that I hope to use more in the future.
Nice! I watched to the example code, and the solution looks so straight and clean. Using it to attach object files to the sm64.s file shouldn't be too hard.
