Excel-Based SMB3 (Possibly Extensible...) Map Editor

[segaloco]

Just wanted to share a new project I'm very slowly tinkering on. This won't be moving very fast since I don't even have Excel on my daily driver, but for times I'm working on a bit more robust of a desktop, I wanted to have at least one map editor in my pocket.

So the idea is there is an Excel sheet with two tabs, one for the main map editing and one for the tile bank being used. First, the tile bank is just a simple table of numeric IDs, symbolic names, and a visual tile those IDs relate to:

Screenshot 2025-09-29 at 10.18.05.png

Then the map editing tab makes use of this data and a numeric table to create a visual of the map being edited:

Screenshot 2025-09-29 at 10.21.18.png

Right now it would be a lot of manual maintenance, for instance I haven't figured out yet how to take a series of tiles and import those as the graphics for the editor. That could probably be macro/VBA-ified, but I'm working this up on a Mac computer and it turns out Excel's VBA is incredibly hobbled on macOS...

In any case, this is not meant to be an end-all-be-all tool, rather, just a simple lightweight mechanism. There will also be a button on the map screen to export the current map. I'm going to have a few different export options:

- Binary - Excel won't literally create the BLOB, but I'll have it spit out the CLI printf statements to generate a BLOB, this can simply be incbin'd into something that has the right mappings.

- Symbolic - This will instead spit the data out as the symbolic names as ".byte" directives, ready to include in a project as text. Naturally I'll be targeting my own disassembly but hopefully the implementation will be simple enough that other symbolic directives could easily be slipped in.

In the long run I want to doll it up with some macros for things like importing the metatile information from some other format, maybe from files from my disassembly, maybe some middleware like a script that strips info out of a ROM then transforms it for import into Excel, really depends. What this *won't* target any time soon is editing ROMs in situ. That said, it probably wouldn't be to hard to build a bigger toolkit that does the necessary extracts and transforms on either side of a ROM to extract, do the map editing, then slip it back in. Maps are *generally* fixed size compared with courses, although you do have some maps that have multiple X-axis pages. I haven't quite figured out how I want to represent that scenario in this editor yet, but one step at a time.

Anywho, nothing material to share yet, I'm still building up the basic macro structure and a proof of concept full map edit for World 01 (I'm going to try and edit it to the "beta" version on TCRF as a first experiment).

The fancy features I'd try but probably have to save for a more focused application is I'm also trying to centralize the "special" tile behaviors in maps. For instance, the "START" tile specifically has to be at (32, y) where y is some variable number per world but every world map expects the character start position to be at x 32. In my disassembly, I setup macros to dynamically calculate the Y value from where it physically is in the map defintion, and to assert on the X value matching the others (currently they all must match 32 exactly, in the future I'm going to switch it so they just have to be the same 16-clamped value, then you can move them all without once editing the placement routine.

So that's all for now, just wanted to spin this one up as a separate thread since this is work that dovetails with my SMB3 work but is not a direct factor in the disassembly work.

Finally, if anyone knows of other Excel-based approaches like this, I'd love to see how others have done this sort of thing. Also if there is a spreadsheet-like application like this that would be a better platform-neutral investment for this (that isn't Google Sheets, not making a big G account), I'm all ears, really I just want to shunt the concern of manipulating grid-based data to a spreadsheet program for this version of the tool. When I feel like doing some graphical work I may consider a more native application, but the goal here is learning, not producing a super sophisticated end-all-be-all solution, especially for a decades old video game.

[creaothceann]

it turns out Excel's VBA is incredibly hobbled on macOS...

There's also LibreOffice. (I don't use it myself though)

[segaloco]

Good point, I should see how this stuff works Libre Calc...then I could use it on my own machines more often. Frankly I personally plan on doing any hacks by simply doing the work on graph paper and typing up the differences, just seemed like a neat opportunity to experiment with building a simple map editor. Theoretically if I play my cards right I may be able to finagle a partial level editor using the same constructs. I'm not going there any time soon though, the courses are actually the last thing I'm documenting in SMB3 after I get all the other bits done.

[tepples]

I'm assuming that "VBA" support here doesn't refer to ability to edit Super Mario Advance 4 and integrate with VisualBoyAdvance.

[segaloco]

Nah, "Visual Basic for Applications", the VB subset in Excel for scripting. I wanted to just write some VB to do the tile import from the filesystem but yeah for instance the generic file browser does not seem to have been ported to launch Apple's file picker instead.

[Dwedit]

Visual Basic for Applications was much cooler around 2000, because Visual Basic itself was a standalone commercial product. With regular Visual Basic, you could write Windows programs that used Forms and had Buttons to click on and all that.
But with Visual Basic for Applications, you got something pretty close to a full version of Visual Basic secretly hiding inside of every copy of Word or Excel. You just had to put a button in the document, then it would open a UserForm, and from there the rest was just like writing a regular Visual Basic program.

[segaloco]

Well and that was the idea, a short-cut to a grid-based editor since Excel with VBA is VB with a grid-based presentation surface baked in pretty much. That is, on Windows. Back to the drawing board I guess. I might still tinker out something just to say I did it but I'm starting to think a more portable option is in order.

What I'm considering now is this:

One can setup I believe ed or vi using pipes to simply dump the contents of the current file into a pipe, I think. If not, I would finagle some way to have a terminal text editing session sitting at the beginning of a pipe and that pipe can then just spit out the full contents of the buffer each time.

On the receiving end of the pipe is something much like my metatile display cruncher pipeline, the one that builds the metatile view map up from a CHR bank and optional palette assignment. At the terminal end would then be a viewer like ImageMagick "display" or something else light-weight. Said tool would ideally be in a "watch"-like mode in which each save of a new png stream down the pipe reloads the image.

The end result, with a bit more pipelineing in between to assemble on save and commit updated tile assignments to the binary data feeding the pipeline, would be a text-based map editor with a visual feedback window. This wouldn't be as sophisticated as the Excel-based approach, because the latter I would've eventually wanted to explore drag-and-drop editing. Still, this would allow a real-time feedback window on an active map being edited while not requiring any X or other GUI development. Really this is all I would need in my own world, I prefer to use typing as all my editing actions since then I don't have to mess with a mouse. Couple this with an editor with tab completions and editing a map via keyboard from symbolic constants becomes *very* fast.

Anywho, yeah I didn't anticipate when I built out my little proof of concept the VBA situation would be as particular as it is, but I should've expected something that entrenched would fall apart once you get to the OS-specific edges of things. Hopefully the pipeline I've just described would alleviate much of that in that it is dependent on three interchangeable parts:

- The input mechanism: For me, I want this to be a persistent vi or other editor session in which saves send a file down a pipeline or otherwise trigger a shell script on it. This will allow for text-based editing of the level without mouse interaction. Since this is just attempting to attach a save to a trigger to supply a file to a pipeline, the trigger part could be omitted and this be supplanted by providing arbitrary files offline. In other words, the input interface is insulated from the display transform logic, so it can be swapped out at will.

- The display pipeline: This is all the part I'm writing myself, the various pivots and transforms to take whatever input data is provided and map it into an image for display. One tip of this is binary data as a result of the assemble and snip triggered by the input mechanism. The other tip is whatever image format is produced, in my case currently png. This tip could be any common display format, including uncompressed, although I went with png for ubiquity at this point. The tile-to-image converter is just the last stage in a pipeline after a bunch of other transform operations so it can be swapped out without the map, nametable, metatile, etc. transforms caring.

- The presentation mechanism: For me, I want to use ImageMagick "display" perhaps with a visual refresh mechanism if one isn't available through their tooling. This would result in a secondary borderless window in which an edit and a save (or really just a dump of input data on the front of the pipeline) results in a new image on the other end, which then is presented in the "display" window. Keeping with the theme of portability, this is a pipeline extremity, and the important part is the image produced at the end of the display pipeline. Similarly to how the display pipeline can produce different image formats (either directly or by conversion of the "native" output format), the presentation mechanism could be anything that can display the image, be it an image preview tool, an editor, or heck, another pipeline that performs further graphical transforms "as an image" after all the information about the original formats has been effectively discarded by the pipeline operation.

The end result is a core graphics pipeline that uses the system native format generated from some symbolic input at the front end and some ubiquitous portable image format on the other end.

Of course, using my graphics pipeline, this should also be extensible to other games since it's still just the vague concepts of maps of metatiles which are maps of CHR IDs in a nametable-type row-based grid of given dimensions. Since I made all these dimensions configurable in my tools rather than fixed to the 2C02 specifications, I can just provide different values for different map sizes, metatile sizes, row/column majority, packing formats, whatever.

Anywho, when I get all of this a little more figured out I'll certainly share a status update. Dunno if I'll focus more on the Excel or more on the feedback viewer but the latter is starting to sound like I already have 99% of the pieces built up from various other projects.