Latest screenshots from my WIP Mario Kart 64 level editor.
At present, it displays almost every level almost perfectly. The remaining visual glitches are mostly hardcoded things I have yet to track down, and one texture command Moo Moo Farm uses that I haven't decoded yet because who cares about Moo Moo Farm anyway.
Luigi Raceway is one notable exception.
Its textures seem to be in a very strange place indeed, devoid of any actual image data. Quite odd.
There is no actual ROM modification going on at present. You can click on polygons and they'll show up in the Polygon window. You can manually edit anything in these windows (but not add or remove) and it'll show up in the render. So basically all that's left is to be able to import models, drag things around, and save back to the ROM. You know, all the fun parts. Oh yeah, and I guess it should display Luigi Raceway correctly at some point too.
INFORMATION! *sprunge* Looks like something out of a Hollywood hacking scene... except these numbers actually mean things! :o You don't have to use dark widgets and stupid broken unreadable title bars, but you gotta admit it looks so much cooler that way.
The hex window is just for debugging; there won't be any hex editing involved here.
Menus, gotta have menus.
Can you spot the glitch in this render? Probably not unless you knew what to look at.
Polygon selection! Also Wario Stadium FTW.
Wireframe's always cool.
***BEGIN BORING TECHNOBABBLE***
Rena stands for Racetrack Editor, Navigator and Assembler and is totally not a backronym.
Rena takes a different approach to editing. It's designed to be very modular, flexible, and extensible.
Most first-party Nintendo games follow a similar design. There are no models. Everything is code. Each level is built from a few files - one containing all the texture graphics, one containing all the vertices, one containing all the display lists, and whatever else that game might need.
A display list is a series of commands for the graphic processor. This is a fairly simple system - all 8-byte sequential commands that map closely to OpenGL functions. Each frame, the game selects a single display list (which can then branch off and call others) to render the entire scene. Each list renders only a small portion so it's not wasting time rendering things you can't see on the other end of the level.
To convert between this command-based format and any traditional model-based format would be a slow and probably imprecise process - likely in the neighbourhood of O(N4). (In other words, coffee break.) Rena's approach is instead to edit in this native format, avoiding this lengthy process - though a model import function is high on the priority list. (Probably 10 times easier than implementing any actual editing functions, anyway. >.>)
Of course, N64 is a 3D game console from 1995, which means not a lot of processing power, which means a lot of design complexity to overcome that shortcoming. Those list commands can be pretty low-level, and nobody wants to deal with vertex caches and texture buffers and write 32 commands to draw a box. That's why Rena parses the game's low-level commands into a much simpler, higher-level, but still command-based format. In fact, all of the F3DEX microcode (i.e. the game's graphic commands) are summarized into six of Rena's commands, with a single parameter each.
Aside from the advantage of reducing complexity, this has a bonus side effect: we don't have to worry about microcode at all. Different games may be designed the same, but they tend to use different microcodes, which are incompatible. For example, Super Mario 64's vertex cache is half the size of Mario Kart 64's, which means if you wanted to port between the two, you'd have to hack around this limitation all the time. With Rena, you could simply import to the higher-level format, then export back out to any format you want. Not even necessarily an N64 format - maybe Gamecube, PS2, whatever. Writing a codec is dead simple.
Of course, first it needs to do the things it's designed to do, before I even think about branching off into other games. But damn that would be sweet.
5 comments:
Great job. Here is a question about this game : how is collision handled? i mean, did the game does some collision testing directly against map, or did it use some highly simplified model ?
That would means that the editor had also to change that simplified model if you want to be ale to test track you just created.
The game does use a separate collision model, but it generates the model at load-time by parsing certain display lists. So, editing the collision model is simple: just specify which groups of polygons should be added to it, and let the game do the hard work for you!
Wow, I'm impressed! Easily one of the best fan/community/hacking projects that has ever existed, I love Mario Kart 64.
Not sure if you're still working on this, would be happy if yes and understand if not, but I had to search very specifically to find this at all. I think it deserves more attention. :)
Anyway, good luck with whatever you're working on!
It's still something I'm working on, though I haven't done anything with it in a while. Will want to change the name, too...
I search every few months for any updates on the MK64 track editor, sadly no new information surfaces. I search youtube for any new custom tracks, Ive seen your video like half dozen times. So many fun memories playing this game with a group of friends. We are getting seriously bored playing the same levels. I really hope your able to finish the track editor one day, where everybody shares there track designs around, it would be like going back to 1997 when everything was still a surprise.
Post a Comment