Language…
20 users online: akawo, Alex No,  AmperSam, CharlieUltra, DanMario24YT, deadworld2009,  DeppySlide, edgar, Green, Hammerer, Heitor Porfirio, JezJitzu,  MarioFanGamer, Metal-Yoshi94, MistaX88, Nayfal, Pink Gold Peach,  Telinc1, timeisart, Tulip Time Scholarship Games - Guests: 288 - Bots: 446
Users: 64,795 (2,370 active)
Latest user: mathew

New Level Editor (Very much a WIP)

  • Pages:
  • 1
  • 2
Hello World! o/

Thanks for stopping by!

I've been hacking SM64 for a week now, and I feel confident enough in my progress to announce and show off the level editor I've started working on during that time. Mostly, I wanted to brag ;)


Goal:
To make content-development for Super Mario 64 as fast and easy as that of any modern game.
[That means minimal iteration time; the time it takes for you to change something in your level and see the results in an emulator should be negligible.]


Progress:
-I can already import 0x39 objects, geometry and collision data from Bob-omb Battlefield!
pic of editor

-To demonstrate that I understand the format and can write it out as well, I also wrote a utility that would shrink the y-value of every vertex / position of all of the geometry and most of the objects in BOB, flattening the level:
Flat BOB level
-When you press "Make and Run," a batch file runs n64split's make and launches Project64 if make succeeds.


Planned Progress Coming Very Soon:
-Parse a level's .s file, allowing any level to be edited
-Implement textures
-Allow editing of level vertices and object positions (way easier than you'd think!)
-This is a big one: Hack SM64 to allow arbitrary level loading! I want to be able to skip the logo, intro, file select, and castle and just jump straight into a level of my choosing. This will really speed things up! (Maybe somebody has already done this or knows something about how to do it?)


Methodology:
-Being developed as a Unity Editor script, may transition to a stand-alone app later in life. I predict I'll get some hate for this decision but it lets me leverage Unity's 3d editor and interface, and that alone saves me SO much time it's not even funny.
-Uses queueRAM's n64split project. At this point, it doesn't need to (it would actually be faster to use an extended ROM) but I'm really excited about this project and the long-term potential using it will offer.
-Will be open source (I'll post the source up soon). I'm normally not a big open-source guy, but for SM64 hacking projects, it really makes sense and I wish more hackers would release the source for their tools. In fact, I was able to better understand some of the level format because xdaniel released the source to his MariOZMAV level viewer.


Motivation:
I looked up the process one has to go through to make custom SM64 levels, and it seems HORRENDOUS. Am I wrong? It seems like for the past 7 years, TT64 has been serving a dual-role as the community's savior and oppressor, since it's the ONLY thing you can use to place objects in levels, and it doesn't even support making new levels. So a bunch of other programs get tacked onto it, making a level designer's workflow slow and tedious. Also, and this is just my humble opinion, its interface really is a turn-off. (I have actually avoided using TT64 for that reason. I haven't even tried it. True story.)

Now don't get that twisted. I'm overflowing with respect for VL-Tone; the information he's shared is CRUCIAL for me and other SM64 hackers, and I really appreciate him! I just want to see an alternative to TT64, so I'm making my own. Also, anyone who can make a decent SM64 level has the patience of a saint, and tons of respect from me as well!


Conclusion:
What do you guys think so far? I guess it's pretty early to comment :P. I think this project is going to move fast, but we'll just have to see!

What features do you want to see in a SM64 editor? What annoys you about TT64 and what features seem conspicuously absent from it?

Thanks for reading! :D
-Jedi
Can't blame you for avoiding TT64, your editor should have everything TT64 does, but enhanced. I.e better rendering and maybe not crashing 26 times in 1 minute. But you should put it out of unity3D. Please finish this, it's obvious no other SM64 level editor will ever get released.
There's nothing wrong with using unity. It's faster and can be compiled to a lot of computers that toad's tool and the level importer can only dream of being able to run on.
Team CornersoftYoutube
Some people can't download 1.4GB to edit levels, it'll be much more better as a standalone exe.
Hey guys! Thanks a lot for the feedback and attention! It really helps!

Mr. GreenThunder, Luigixhero and Kazeshin, nice meeting you all. #w{=)} Kazeshin, thanks especially for your excellent ideas! I just discovered your major hack thread today and was blown away!

Originally posted by Kazeshin

- the ability to create/edit geo layouts. this has been huge work for me in the past. i needed about 1 hour for something like my spikey piranha plant, because i've always had to adjust values->test->adjust values->test,... for every single bodypart.

Originally posted by Mr. GreenThunder
...maybe not crashing 26 times in 1 minute

I want to hold this community close in my arms and whisper, "I know you've been hurt before baby, but you don't deserve that. It makes me cry to think how TT64 treated you."


Originally posted by Mr. GreenThunder
your editor should have everything TT64 does, but enhanced. I.e better rendering

Yeah, pretty sure I can do that #ab{8-)}
Can anyone point me to an up-to-date feature list of TT64? I looked at the video that's here but it doesn't seem to demonstrate much more than placing objects around. I can do that now! #w{=P}

As for the rendering, I think it should be fairly trivial to emulate Fast3D in a shader (or several). I plan to render the models in-place, to scale too. Hopefully using queueRAM's build system will help with that. Once it's more advanced, it should allow for using original models like assets and building them into the game, instead of having to virtually emulate the game and discover models in a kind of backward-fashion. (Virtually emulate... Did I just coin a phrase there?)

Originally posted by Kazeshin
- vertex editing! its a huge pain to edit every vertex manually in hex, with a graphical representation, this would be way easier. we mainly need it for RGBAs.

See below and thanks for the feedback; now RGBA editing will be coming soon #ab{8-)}
Originally posted by Kazeshin

- the ability to read out from RAM that is not loaded by levelscript commands. My MOP patches and also many things in my major hack use a DMAcopy instead of the levelscripts, because it gives me more control of where everything is and enables globally loadad data more easily.

Sounds tricky but I think I'm up for it; I'll have to think on it. It seems like to make a really good SM64 editor, you'd end up bordering on also implementing an N64 emulator. Hmmmm.....
Originally posted by Kazeshin

- i know you want to work with the romsplitter, but for already existing hacks, or those that use my MOP, i think it would be nice if there was a functionality to move data and repoint all levelscript loading commands that referred to that data.

That's an excellent point! I don't know how I'm going to handle compatibility for existing hacks but I'll be thinking about it. One thing I'll say is that it should be pretty easy to implement a level importer so you can use the same Blender / SketchUp / Anything-Really level files that you use with another importer, like Skelux's.

I haven't come across your MOP tool yet Kazeshin, it's a bit embarrassing but I've not been hacking SM64 that long so I'm a bit ignorant of the scene. Not even my Google knows! Do you have a link?
Originally posted by Kazeshin

- the ability to move display lists around in RAMbanks, doing it manually takes aout 6 hours and even with my cheap tool for that, it often takes about an hour. (for something like bowser)

If I'm understanding you right, this should be very doable.



As for the issue of Unity, I agree with Mr. GreenThunder and Luigixhero ;). Unity is fine. Also, some people will be turned off by the download size and for them I plan to make a stand-alone version later.

However, such a version will never hold a candle to the in-editor variation, for the simple fact that I don't want to recreate Unity! It's also likely that 90%+ of the work for an out-of-Unity editor would go toward the out-of-Unity part, so you can understand why such an editor is not a priority for me right now.

Using Unity's editor offers so many advantages I can't even list them, because even I don't know what all of them are! I know 1.5g is daunting, but I think most users will come around once they see the awesome power of the Dark si... I mean, of Unity.

Let me give you a small example. I just found out I can save and load the levels I edit. When I say I found out, I don't mean I just got done testing a feature I thought of and implemented, I mean I just got done testing a feature I never thought of but was already implemented. And I haven't even mentioned the fact that you can use OTHER editor scripts - ones written with and without SM64 editing in mind.

Here's another thing I did but hadn't mentioned before that was made possible by Unity: Since I already had the collision data all nicely formatted into meshes, it took about five minutes to add into my parser the ability to turn that data into Unity collision meshes. This let me pop a first-person character controller in there and play around in the level from a first-person perspective. When doing this, I had a weird feeling, like what I was doing was way too easy and slightly sacrilegious.




Now, one legitimate concern is for Linux users, because there's no native Unity EDITOR for Linux, last time I checked. Linux users: You should know that this script ought to work with a pretty old version of Unity (IDK how old) and such a version will probably run under WINE. I would like to help if I can so please speak up as to what works or doesn't. (I mean, when I release it, obviously)

Originally posted by Mr. GreenThunder
Some people can't download 1.4GB to edit levels, it'll be much more better as a standalone exe.

Can't, or probably won't? I bet plenty of people will be turned off by the download size simply because they don't want to wait for the download, but it's still a pretty low bar of entry for what is presently the uber-tedious world of ROM-hacking.

If anyone really CAN'T download Unity though, PM me and we'll see if it's possible for me to mail you a DVD-R.

I hope that settles the issue of Unity for a while, and I don't mean to pick on Mr. GreenThunder, he was absolutely right that using Unity will turn some people off to this project, and I'm spending so much time talking about it because, like I said, I predict it will be a sore point for some. For them, there's TT64 or the source :P

Originally posted by Jedi

-Allow editing of level vertices and object positions (way easier than you'd think!)

What did I mean by "Way easier than you'd think?" I mean it's done :P

I decided I'd implement this feature next since it made my thing a bona-fide level editor. For the screenshot below, I took the rings of coins and their 5 hidden goals from the island in the sky, and moved them to the beginning of the level. Then, I lowered the geometry (collision and visual) of the hill that the applicable star spawns on, making for a nice and easy little path up to that star. xD

Easiest Star evar?


Since I felt like that "hack" was actually a little too easy, I also arranged the trees in the level like so:

That was one happy gardener!


Here's my revised, immediate-ToDo / Features Coming Soon list:
-Clean up source a bit, remove hardcoded paths and release the sucker! (Releasing the editor means releasing the source; the editor IS the source!)
-Add RGBA editing to geometry verts
-Add instant-updating of meshes as you move the verts (Right now you have to build and reimport to see proper meshes)
-Implement textures
-Spread the love around to some other forums (and touch base with queueRAM)
-Parse a level's .s file, allowing any level to be edited
-Still want badly: Hack SM64 to allow arbitrary level loading! I want to be able to skip the logo, intro, file select, and castle and just jump straight into a level of my choosing. This will really speed things up! (Maybe somebody has already done this or knows something about how to do it?)
holy hell, this looks nice, hope to se more :P
Your layout has been removed.
There really needs to be a faster way to test any inserted custom music...
I hope that your big-shot editor will rake down TT64! #smw{:TUP:}

I've had enough of TT64's crashing after I moved one or two objects and the load time is horrible whether be custom levels (only those who hold 20k polygons in the counter) that are imported

I'm not fond of Unity, but seeing it being compatible for SM64 is worth trying for fun. Try cramming all stuff TT64 has and hasn't currently like I want it have a built-in importer well advanced than Skelux's (with the scrolling, tweaks and skybox settings, as well as the misc stuff to improve the faulty functionality the separate hacking tools have). Grant us our wish!
SUPER CRASH TIME YEAH!
Not bad at all! I think that this is coming together nicely!
Congratulations! You have just met BroDute's number 1 fangirl.


  Oh my f***ing god can this be the long-awaited RGBA Vertex editor I have waited for long years? Just omg you just came of nowhere and show this to us, my respect, sir.

    See my hack development here!: Super Mario and the missing memories.
Originally posted by Jedi
I've been hacking SM64 for a week now, and I feel confident enough in my progress to announce and show off the level editor I've started working on during that time. Mostly, I wanted to brag ;)

That's impressive progress for only hacking for a week! I look forward to seeing your continued progress.

Originally posted by Jedi
I want to be able to skip the logo, intro, file select, and castle and just jump straight into a level of my choosing. This will really speed things up! (Maybe somebody has already done this or knows something about how to do it?)

This can all be done by the SM64 Level Importer, so it is known. Finding the info in the ROM might require a little decoding some of the patches in the Data/Tweaks/ directory of the level importer. I have converted some of these to n64split file patches.
To skip the title screen:
269ECC: 01 10 00 14 00 26 9E A0 00 26 A3 A0 14 00 00 78
skip title n64split patch
To skip the mario screen:
269F4C: 01 10 00 14 00 26 9E A0 00 26 A3 A0 14 00 02 0C
269FD8: 01 10 00 14 00 26 9E A0 00 26 A3 A0 14 00 02 0C
skip mario n64split patch
To skip the main menu:
26A0C8: 01 10 00 15 00 2A BC A0 00 2A C6 B0 15 00 00 00
skip main menu n64split patch
The level importer also allows setting the start level, but I don't know off hand where that is. You can play around with the "Set Start Level" in the "ROM Settings tab" and look at the binary diffs.

Edit: I looked into it. The level importer actually implements this as an assembly hack in the procedure at 8024BD5C which is called by level command 11. You can also accomplish this by setting the level command 13 in the 'game over' level scripts to the desired starting level ID. For example, for BOB (id 0x09):
.word 0x13040009

Originally posted by Jedi
-Uses queueRAM's n64split project. At this point, it doesn't need to (it would actually be faster to use an extended ROM) but I'm really excited about this project and the long-term potential using it will offer.
-Will be open source (I'll post the source up soon). I'm normally not a big open-source guy, but for SM64 hacking projects, it really makes sense and I wish more hackers would release the source for their tools. In fact, I was able to better understand some of the level format because xdaniel released the source to his MariOZMAV level viewer.

Awesome, I'm excited to hear that you have found use for n64split. I am still actively working on it so there will be some changes coming as I only have about 60% of the ROM decoded. I am willing to take suggestions from you if there is something that would make it easier to use in your level editor.

Originally posted by Jedi
As for the rendering, I think it should be fairly trivial to emulate Fast3D in a shader (or several). I plan to render the models in-place, to scale too. Hopefully using queueRAM's build system will help with that. Once it's more advanced, it should allow for using original models like assets and building them into the game, instead of having to virtually emulate the game and discover models in a kind of backward-fashion. (Virtually emulate... Did I just coin a phrase there?)

Fast3D is probably the least decoded part of the SM64 ROM. I have derived my fast3d tool from cpuHacka101's notes, but I still do not incorporate this into n64split since there are so many undeciphered Fast3D commands. I agree that ideally the build system would help with the conversion from editable assets to N64 ROM though.

Originally posted by Jedi
Originally posted by Kazeshin
- the ability to read out from RAM that is not loaded by levelscript commands. My MOP patches and also many things in my major hack use a DMAcopy instead of the levelscripts, because it gives me more control of where everything is and enables globally loadad data more easily.

Sounds tricky but I think I'm up for it; I'll have to think on it. It seems like to make a really good SM64 editor, you'd end up bordering on also implementing an N64 emulator. Hmmmm.....

This sounds useful, but I'm thinking this is more of a patch than a level editor function.

Originally posted by Jedi
Originally posted by Kazeshin
- i know you want to work with the romsplitter, but for already existing hacks, or those that use my MOP, i think it would be nice if there was a functionality to move data and repoint all levelscript loading commands that referred to that data.

That's an excellent point! I don't know how I'm going to handle compatibility for existing hacks but I'll be thinking about it. One thing I'll say is that it should be pretty easy to implement a level importer so you can use the same Blender / SketchUp / Anything-Really level files that you use with another importer, like Skelux's.

I don't know of anyone using the ROM splitter for a hack yet and it really isn't ready for general consumption just yet. However, we can work together on making the tools work better with each other and n64split working on extended ROMs.

Originally posted by Jedi
Now, one legitimate concern is for Linux users, because there's no native Unity EDITOR for Linux, last time I checked. Linux users: You should know that this script ought to work with a pretty old version of Unity (IDK how old) and such a version will probably run under WINE. I would like to help if I can so please speak up as to what works or doesn't. (I mean, when I release it, obviously)

I haven't encountered too many other Linux users in the SM64 hacking community. Wine has worked fine for me for TT64, Level Importer, and Nemu64. I think us Linux users are used to being on our own to get tools to work.

Originally posted by Jedi
-Spread the love around to some other forums (and touch base with queueRAM)

Hi. You can PM here, on origami64, or find me on #origami64
Hello World! It's time for another post! In fact, it's past-time! This is a long one too, so start some coffee and settle in.

The enthusiasm on this thread is so cool! It really helps to motivate me and keep me making progress with this editor.

Let me kick it with some progress:

As promised, I started work on a vertex RGBA editor. Right now, I can read the vertex colors from level 1, and wrote a very simple shader to show those colors.

Below is what Bob-Omb Battlefield looks like with colored vertices and no textures or lighting. The coloring seems a bit strange in places but I think it's kinda pretty...

Pretty Level 1 vertex colors


Yesterday, I implemented two features that I like a lot. The first allows for the collision and geometry meshes (that is to say, the visual representations of each within Unity) to be updated in real time as you move vertices around.

Also, as the editor imports vertices into Unity, it will make any new, overlapping vertices children of the current vertex occupying that space. It also makes the children slightly smaller so you can't select a child by accident. This means that if there are many [geometry and collision] meshes sharing the same physical point in space (as happens quite a lot), you can select that point and move it around, and all of the triangles connected to that point will follow, regardless of how many vertices the meshes actually needed to represent that point in space.

These two features come together to make editing vertices simple and intuitive! I was playing around with them earlier:

Can I just move the Island in the Sky to beat Koopa the Quick?...

HAHAHA it worked!

Now for some replies:

Darkspire17 and Amazee-Dayzee; nice to meet you! Thanks for the encouragement!!



Kazeshin, your MOP patch looks awesome! Assuming I'm capable, support for adding more objects in the game is a given. How that's implemented within the editor & build system remains to be seen. I have quite a ways to go before I will come close to your level of hacking wizardry! However, my intution tells me that when this project is close to complete, you will not need such a patch to put new/more objects in the game. If I'm wrong, and even if I'm not, your patch seems like an easy way to implement adding more objects. I'm going to do more research as I go...



Originally posted by Mariocrash

I've had enough of TT64's crashing after I moved one or two objects and the load time is horrible whether be custom levels (only those who hold 20k polygons in the counter) that are imported

Nice to meet you, Mariocrash! I won't lie to you and say that it will be instant, or that my editor or Unity will never crash (Save often!) but it should almost never crash without some reason. I'm actually keeping track and Unity has crashed 7 times on me in total since I've started this project. I'm pretty sure I know the cause of each crash and have fixed all but one (which is next on my TODO).

Wow, 20k poly's seems like a lot to me! I looked it up and, indeed, Skelux's importer has support for 20k polygons. Is that meant to be for emulator-only hacks or can the N64 actually handle such levels? BOB only has 2166:
Early speed test

I've made no effort to optimize this thing for speed yet, and it might even get slower as I develop more components to represent the game data. For the in-game levels, I think a few seconds is acceptable (I'm not thrilled), but if you assume 10x polygons = 1/10 speed, importing a 20k-poly level would take about 23 seconds! If you're modelling in another app like SketchUp or Blender, that's pretty horrible! An extra 23 seconds added to each development iteration is abysmal. I'll try and take a look at what is slowing it down so much after the first release.

One thing that's nice is once you have modelled your level, you shouldn't need to import it any more since you can save and load levels as Unity scenes once they're imported, and that process is pretty much instant.



Nice to meet you, Kaisaan Siddiqui! I don't know anything about custom music yet but I'm going to learn because I really like the way you think!

I want to know every aspect of what makes editing this game painful and time-consuming, so I can nip them in the bud!



Originally posted by Mariohacker14
Oh my f***ing god can this be the long-awaited RGBA Vertex editor I have waited for long years? Just omg you just came of nowhere and show this to us, my respect, sir.

Nice to meet you Mariohacker14! The more I learn about this process, the more confident I feel in saying, "Yes. This is that editor." Thanks for the respect my good Sir. :)

I can definitely let you edit the RGBA of each vertex, but I think I can do you one or two better...

Hey, I was just thinking...
Remember that pretty image I put at the beginning of the post? Notice anything about it? It seems like there might some kind of pattern to these colors...


What I'm getting at is probably very old news to 99% of you (At some point I'm going to catch up on that 100+ page SM64 hacking thread), but I had fun discovering it anyway:

Let's say we isolate the R, G, and B channels from the vertices and just look at each component individually. Then, if we line the image up with some choice axies, we start to notice....
My God, it's full of normals!

These colors aren't colors at all; they're normals! Like I said, probably old news to most of you but I thought it was pretty cool.

And, not that anyone asked (I guess because modelling programs already do this), but the editor will have no trouble recalculating normals with the the press of a button, or letting you tweak a normal with a graphical representation.



At some point yesterday, my understanding of this vertex-coloring situation gelled quite suddenly, and I realized what some of you guys have actually been doing in the past to edit vertex colors, and to accomplish some of the tinting I'd seen in custom levels on youTube prior, and I actually got very close to dropping to my knees and crying. That's no exaggeration. I think it goes without saying, but you shouldn't have to do that! When I said some of you have the patience of saints, that really doesn't come close to describing the situation, does it?

After doing some more research today, I came across this super-helpful video by cpuHacka101. I particularly enjoyed when he said, "How do you find each triangle? You... you hate yourself, that's how you do it! You have to find each triangle yourself. It's so annoying. I hate this part, that's why we need someone to program this! ... This is why I really wish we had a program. I cry myself to sleep over this."

LOL. Okay, I feel like I really understand the problem now. You're all going to love me! :D

I can already tell that editing vertex colors brings with it an obviously-necessary feature: for a given display list, we need the ability to detect and change when the RGB component is evaluated as such, and when it's an encoded normal (and, I suspect, whether the normal is pointed into or out of the tri - toward or away from the light - hence cpuHacka's "bright" and "dark" designation in his Fast3D notes). Apparently, we also need to make each affected display list restore the previous mode at the end of the list (and I hope there's room at the end of each list for this in the original game and/or the build system can handle new display list commands. I'll worry about that later).

But for now, this is an intervention. This behavior isn't healthy and I know it isn't making you happy. No more hex-editing vertex colors! OK? :P



Last but most definitely not least, queueuRAM, it's ESPECIALLY nice to finally meet you! Haha, you found me before I could reach out to you, but I'll be in touch with you directly as soon as I get a chance. Your build system was such an inspiration, thinking about the possibilities it could open up if it's finished and integrated into an editor that was made for the task, is what really inspired me to get this project off the ground!

Thanks so much for getting back to me about skipping the level intro! I haven't had a chance to really look at it yet, but I'm psyched!

Originally posted by queueRAM

Awesome, I'm excited to hear that you have found use for n64split. I am still actively working on it so there will be some changes coming as I only have about 60% of the ROM decoded. I am willing to take suggestions from you if there is something that would make it easier to use in your level editor.
Oh, I understand! I got that from the 0.2a version number :P. Still, it's been more-than functional enough to help me get the ball rolling, so I really appreciate it! I'll give you some feedback soon.

Well, one thing real quick: I notice that make skips .bin files if they're older than what was compiled into the previous .MIO0, even if I delete the .MIO0. Can you make it so it will recompile anytime the files are different, not just if there's a newer version? It's really helpful to be able to roll back to a known-good copy of something when you're hacking it!


Originally posted by queueRAM
Fast3D is probably the least decoded part of the SM64 ROM. I have derived my fast3d tool from cpuHacka101's notes, but I still do not incorporate this into n64split since there are so many undeciphered Fast3D commands. I agree that ideally the build system would help with the conversion from editable assets to N64 ROM though.
Cool, I hope you didn't think I was putting pressure on you there :P.

Since I'm just now getting into it, it's nice to know there's still some genuine hacking left for the rest of us to do with this game! ;)

CpuHacka101's the man! But it may interest you to look at the source to xdaniel's MariOZMAV - it seems he's got his hands on way more info into how Fast3D works, including what looks like a very complete list of operand #define's. Most of them are lacking any explanations, but you can guess at what they do. I sort of get the impression these #define's fell off a truck that was leaving SGI, but I'm glad they did! ;)

Originally posted by queueRAM

I don't know of anyone using the ROM splitter for a hack yet and it really isn't ready for general consumption just yet. However, we can work together on making the tools work better with each other and n64split working on extended ROMs.
After thinking about this issue for a while, I've come to the same conclusion, so I'm glad you said that. A ROM file, extended or compressed, should be treated as the universal format for the game. And when I say extended, I mean the kind of extended that the build system produces, the kind that works on hardware. (It does work on real hardware, right?)

Now that I think about it, I should try to handle an extended file natively within my editor as much as possible, and only invoke the build system when something that needs it changes, because no matter how optimized, a build system will never be as fast as only updating the relevant binary data in a pre-existing file.

By working with extended ROM's natively, changes made to the game by this or any other editor can be picked up by future version of this or any other editor (in theory), even if the internal format used to represent the projects changes drastically from one version of the editor to the next - and it probably will. I'll be very happy to work with you on getting our tools cooperating! I will take a peak at the n64split source soon too, and see if there's any way I can help you with coding it (if you wouldn't mind).

As for the kind of extended ROM that TT64 utilizes, the one with misaligned data and several bogus MIO0 headers that won't work on real hardware - let's call it a "Shitty ROM," just for sake of clarity - I think the easiest way to handle those is to convert them to proper extended ROM's. That's doable, right? (I bet it's been done and I just don't know that it has, like the level-select hack)

Thanks again for the awesomeness that is n64split, queueRAM! No clue when I'll get a chance but I'll definitely be in touch again soon!


Immediate goal:
Release a minimal, functional vertex & object editor that can operate on levels from the original Super Mario 64, and start receiving feedback.

Tentative, optimistic deadline:
One week from this post

Next immediate goal (for now):
Add ability to operate on extended, hacked ROM's.


Thanks for reading! :D
-Jedi
Originally posted by Jedi
Assuming I'm capable, support for adding more objects in the game is a given. How that's implemented within the editor & build system remains to be seen.

I'm hoping to provide the functionality to support adding arbitrary objects using the build system and convert Kaze's MOP into a source patch for n64split someday. I too have a lot to learn before making that a reality though.


Originally posted by Jedi
Well, one thing real quick: I notice that make skips .bin files if they're older than what was compiled into the previous .MIO0, even if I delete the .MIO0. Can you make it so it will recompile anytime the files are different, not just if there's a newer version? It's really helpful to be able to roll back to a known-good copy of something when you're hacking it!

This issue was confusing me when I was testing the Windows build of n64split. It's due to the nature of Makefiles and NTFS. On Linux (at least with ext4), if you rename a file, it's modification date is updated so programs like 'make' can know something is changed and file need to be rebuilt. Windows keeps the same timestamp, so 'make' sees the older timestamp and thinks it doesn't need to rebuild. The workaround is to always rebuild. However, my MIO0 compression tool is really slow and inefficient at the moment so I'd rather avoid that until I can spend the time to optimize it. That's near the end of my 322 item TODO list though (not even joking).


Originally posted by Jedi
CpuHacka101's the man! But it may interest you to look at the source to xdaniel's MariOZMAV - it seems he's got his hands on way more info into how Fast3D works, including what looks like a very complete list of operand #define's. Most of them are lacking any explanations, but you can guess at what they do. I sort of get the impression these #define's fell off a truck that was leaving SGI, but I'm glad they did! ;)

Yeah, I've looked at MariOZMAV and have seen a couple versions of SGI's header files for F3D, but those aren't very clear or descriptive. With enough time studying them, I think we can make some headway into decoding the F3D unknown though. This too is further down my TODO list.

Originally posted by Jedi
And when I say extended, I mean the kind of extended that the build system produces, the kind that works on hardware. (It does work on real hardware, right?)

The build system generates ROMs that are hardware compatible. I only have it extend it to 12MB as a temporary workaround for convenience with some things in the linker and some inefficiencies with my MIO0 compressor. It will be 8MB again when I get those worked out. Let's keep the terminology consistent and refer to 'extended ROMs' as ones that have been extended with Mario 64 ROM Extender (either 24 or 64MB). I don't really have a name for the build system ROMs, but "split ROMs" or "rebuilt ROMs" might work.

Originally posted by Jedi
By working with extended ROM's natively, changes made to the game by this or any other editor can be picked up by future version of this or any other editor (in theory), even if the internal format used to represent the projects changes drastically from one version of the editor to the next - and it probably will. I'll be very happy to work with you on getting our tools cooperating! I will take a peak at the n64split source soon too, and see if there's any way I can help you with coding it (if you wouldn't mind).

I don't mind at all! The source is all there for anyone to see and use. Be ready for some changes to the file formats. I think 0.2a uses binary files for some of the geo layout data, but that's all being changed to assembly since I realized some of the geo layout commands had references to assembly procedures.

Originally posted by Jedi
As for the kind of extended ROM that TT64 utilizes, the one with misaligned data and several bogus MIO0 headers that won't work on real hardware - let's call it a "Shitty ROM," just for sake of clarity - I think the easiest way to handle those is to convert them to proper extended ROM's. That's doable, right? (I bet it's been done and I just don't know that it has, like the level-select hack)

I haven't worked with extended ROMs in n64split yet, but in theory it can be done. I need to redo my level command and geo layout parser so it can automatically walk the scripts instead of relying on guidance from a config file for them. On the TODO list!
Hi all!

Originally posted by queueRAM
That's near the end of my 322 item TODO list though (not even joking).

I don't doubt it! I'm not keeping count but I've gotta be at 30+ on mine already.

Originally posted by queueRAM
I only have it extend it to 12MB as a temporary workaround ... Let's keep the terminology consistent

Sorry about that; it was a total brain fart! Thanks for setting me straight.

Originally posted by Kazeshin
http://pastebin.com/HYvAJr9h
^this fixes the extended rom to have the mio0 data aligned properly.

I thought it had been done, thank you sir!

Thanks for the link to your site Kazeshin, there's some AMAZING work you've got there! I'll be spending a lot of time there.



Well, there's not much else going on.


...

Just some colored vertices and vertex editing. Probably nothing that would interest anyone here...


Fixing some messed up verts in the original game

Preeeetttty!

Woah, REALLY?


-Jedi
I love you
  I love you more than greeny, expect amazing level desings with this. I will credit you for them. >:D



Just omg...

    See my hack development here!: Super Mario and the missing memories.
That looks very neat. :)
Hi everyone! I was thinking I wouldn't make another post until it was time to release, but I'm still not quite there and I feel like I've gone way too long without an update.

Thanks for the encouragement and nice to meet you, UED! Thanks for the love Mr. GreenThunder and Mariohacker14!

I've been busy working on the editor, and getting a deeper technical-understanding of the game. The biggest feature that's been added since my last post is the ability to load any level from the game.

Adding that feature revealed that a lot of the shortcuts I was able to take to make castle grounds and bobomb battlefield work would not be adequate for most levels. I've been filling in the gaps in my own SM64 knowledge to parse levels better, bit by bit.

I think the easiest way to show this progression is with screenshots of how Bowser in the Sky has been supported by the editor. I've been tracking my progress as it gets it closer and closer to being right:









Lest you think I'm getting sidetracked "perfecting" support for the in-game levels: many of these improvements are also laying the groundwork for reading and writing custom levels in extended ROM's, so it's all good! #ab{8-)}


I'm trying to take care of all the stupid, annoying issues that I've encountered using the editor before I release it. I really hate explaining to users what doesn't work, or what doesn't work quite right. I'll have to do some of that just to get the thing out the door, but I want to minimize it.

I also don't want to get a ton of feedback telling me about issues I'm already aware of, or to have to write a ten-page manual explaining what doesn't work the way you'd expect it to. I'd very much prefer to FIX the major issues as they come up, rather than subject you to them.

Thanks for your patience! I really think you're going to like the results! #tb{^V^}
This looks promising. Hope it ends up doing everything Toad's Tool and Skelux's importer can plus more.

You seem to have gotten vertex colors/vertex rgba working. Those will give a lot more depth to levels, like being able to fake shadows and such.

I hope it will be able to import .obj or .dae files into the program, as I do all my modeling and texturing and vertex coloring in Blender.

I'd also like it if it would be possible to edit object banks and add any enemy/object you want in them. Like, for example, making an object bank with King Bob-Omb, Eyerock, Whomp King, etc. so one could make a boss rush level.

---
Holy crap that looks very awesome! Great job on it!
Congratulations! You have just met BroDute's number 1 fangirl.


  • Pages:
  • 1
  • 2