nesst, import metasprite data in asm/c format possible?

since I converted my old data to C array with at first the same format that neslib was using, the data is very similar to what nesst is creating. I want to change the origin of my sprites and the tool would be the one that make the most sense, if I could find a way to import the data.

I looked in the menu and there is an option to export in either asm/c but import doesn't seems possible. So my guess is there isn't one then?

Yeah, that assumption is right. It sounds like a typical job for a py script to convert text to a .msb binary file.

This is what i know about the .msb file format:
-Most of my files seem to start with a header (if that's what it is) of $40 $40, though one starts with $40 $38. I'm not sure what that is about.
-Metasprites can contain up to 64 sprites, 4 bytes data each, ordered like so:
Ypos, TileID, attributes, Xpos. In other words same sequence as raw OAM, but with offset position values. Interestingly, this is not the order NESST exports metatile data as asm or c text btw, which is a little backwards imo.
-Ypos and Xpos are relative to center position (which btw is $40,$40, striking similarity to the usual two first bytes in a file) and can be offset from -64 to +191. The visual representation bugs out at +64 though, so the practical range is -64 to 63.
-Each metasprite is padded to a page start +2, ie addr 0x000002, 0x000102 and so on.
-The padding is filled with $FF in case there aren't enough sprite entries. I'd assume a repeat of four $FF:s tell NESST to ignore these entries from being interpreted as sprite entries, or maybe it just looks at the value of Attribute to tell. Position values can be $FF, at least, and you can still use tileID $FF.



...but if you can wait a bit, i know Lukasz and M-tee are working on a more dedicated metasprite editor. I'm not clear on what the exact feature set will land, but i was invited to come with ideas and suggestions and assembly text imports was one of them. I'm sure they'll chime in on the details whenever it is ready to go into the wild.

For the format, my original data was following OAM based one but since I started to switch some code to C and started with neslib, I adapted my data to the same one in neslib. The only reason that the data is different is maybe it makes it easier to update x/y by hands since they are now the 2 first values for a row. In OAM format, it's a lot easier to make mistake unintentionally.



I will be interested at a later stage but for now the meta sprite data is only for the main actor so I guess for testing different origins (right now it is located in top/left position), I think it will be faster to just remake the data manually. If the msb file was just some xml/json etc, that would have been quite convenient. My old map editor file format was all text based for that reason: if someday, someone wants to parse the data, they can with any scripting language they like.

I think the main reason for NESST organizing sprite data like that is because it is a bit more readable in a text editor.

let's say we have a metasprite consisting of 2 sprites for simplicitys' sake.

shiru's order:
xpos, ypos, tileID, attribute

so, we've maybe got something like


That makes for even columns, since the OR appendage on the palette with all the attribute constants gets last in line.

in raw oam format, we've got
ypos, tileID, attribute, xpos

so that would be


Which, well, you can read it, but it takes time to make out what it is.

On the other hand, both ease of editing and ease of reading is what the editor is for. Once exported it shouldn't be touched again and the editor ought to be the canonical source for edits, IMO. Text edits not represented in the editor project file is messy to keep track of and you'd risk overwriting manual changes if you need to go back to the editor. Personally, the only time i'd go about editing in a text file with such data is to make a quick, temporary a/b check.

So with that in mind, i'd prefer if the output of the editor was directly digestible for the PPU. that's what the output is for - again IMO. Everyones' got their own workflow.

As it is, text exports always need to be edited or processed to comply to the PPU directly.

Even though I didn't have an editor ready yet for that (never had the chance to make it that far), my format was originally OAM based and done by hand. The OAM format seems un-natural when you are used to structure things by group. The new format made it easier to read and edit for the time being. I may go back to older format later but for now that is not an important detail.

As for editor, I agree, once edited it should never be touched again by again because it's make the project harder to manage.

Here's my take: viewtopic.php?p=133350#p133350

I can confirm thefox's findings. It's the two origin bytes followed by an entire OAM page for each metasprite. (Since each metasprite could be 64 sprites.)

I see. So maybe I could wip something fast to import the data. Since the data is in C, I could even make a quick c program that just write the data from the array, that's one idea too.

Thank you for the confirming the format, I may give it a go.

It just struck me... One dumb trick to eat the cake and have it too would be to output it like so:

Same example, OAM formatted, but pairing y and x vertically with the help of a line break:

The staggered structuring of the text and the spacing between entries actually makes it easier to make any single position, tileID, palette or other attribute from a larger table, at least for me, but someone coming from outside to have a look would probably wonder what the fuss was all about.



On the topic of editor vs manual editing.
One thing you actually can't edit with nesst is the priority attribute bit. So if you want to store that with your metasprite, manual editing is warranted.



Thanks for the clarification, kasumi & thefox. I wonder what i did to change the origin in one of my msb files The editor GUI has no direct origin control (and at a few times i've whished it had, except preferably not global).

(edited for a spelling mistake)

It does, that's how you accidentally changed it once! Control+Click inside the grid.

Metasprites are flipped relative to it when you click HFlip and VFlip.

oh, nice! That's pretty nifty. I guess i must have missed that one from the readme. And also embarrassingly missed that the y origin was one snap off in the visual representation.

Regarding the priority bit, I think this is not something I would put in my metasprite directly (I don't have a use case for it that way). Instead, if I enter a zone that affect the entity on screen, the metasprite data is updated at runtime before putting in OAM buffer.

The way i see it... the utility of putting it into the metasprite data from the get-go will of course vary from case to case, game for game. You wouldn't normally want that for your actors in an action platformer*, for example. Except if they're meant to for example gradually pop up, like the piranha plant in SMB. That's a case where the easiest solution is to deprioritize the metasprite directly in data. There are other use cases. Some i can think of on the top of my head: Maybe a meta is intended to be used as a sprite mask (very limited utility but still a thing). Maybe the floor in a slanted topdowner is always colour 0 and it makes sense to keep the lowest sprite(s) of every actors' meta de-prioritized so it can "hide" behind south walls but always show on top of north walls. Maybe it makes sense for some things to keep deprioritization as the original state, which you can temporarily toggle to the other at some point. Or what about a moon, cloud or sun or other decorational detail supposed to be behind the background? In this case, it is much simpler to let it be deprioritized in data directly than to write and circumstantially call a routine that deprioritizes it.

Basically, if you can get away with it elegantly and it makes for simpler handling with fewer branches, one might as well take the free ticket. A rule-of-thumbs could be that a routine is best suited for a general and somewhat recurring feature. Data encoding often seems best for specific exceptions - far-away decorations, piranha plants and masks being such. I don't actually know which method SMB uses, but anyway.



Imo, ideally editors shouldn't obstruct or obfuscate simple techniques like this arbitrarily. Some users might not even become fully aware that there is in fact a priority bit that you can use to your advantage, if it isn't even represented in the field-associated tools you use.

*Edit: Oh, one other example. Ingame, Metroid actually keeps all actor sprites deprioritized, except the HUD. Again i don't know if it runs a procedure or not, but i'd just hardtype that into the metasprite data.

I didn't meant to say that there was no use-case, I just meant in my current tests with my sample data I didn't saw a case that needed it

I think nesst must have been made with the requirements of Shiru's games at the time so those possibilities were not developed. The source code is included and maybe it would be possible to add but it's in borland c++ or something and I don't have the license for that ^^;;

What Borland-specific libraries does it use, which would preclude building it with MinGW-w64 or the without charge edition of Visual Studio?

All the GUI layout is in some Borland specific file format. (i.e. half the program)

The Borland compiler is actually free, but you have to manually request it and get approval from some support representative to download it. (Takes a bit of waiting.)

There's probably some converter you could find out there to turn it from that borland format into something other compilers could use, but so far it hasn't been worth enough of my time to go down that hole and find out.

Rainwarrior was faster than me to answer about it. I wasn't aware that it was now free.

In the app, there is a lot of interesting tools for small tasks like nametable but the part that interest me the most is the meta sprite editor for my current task. Making a simple one in .net could be fast (or wait for the one that FrankenGraphics mentioned) but since I don't need to edit attributes I should just focus on importing my data. If Im successful creating the msb file then I will share my results.

Sorry for the double post. The information from thefox is accurate. I was able to take my C based data, make a quick c program and convert it to the format nesst expected.

Now that I can use my own data, I will start testing different origins and check how can I re-export to my current array format. I don't think you can name the metasprite so I could re-export them to the same array but I guess this is one compromise I will have to do.

I will check what I should do from now on based on the tool.

Thank you for the information, that will save me some time!