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

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

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?
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

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

Post by FrankenGraphics »

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.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

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.
FrankenGraphics wrote: ...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.
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.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

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

Post by FrankenGraphics »

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

Code: Select all

.byte -4, -8, $00, 0 
.byte -4,  0, $01, 1 | VFLIP
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

Code: Select all

.byte -8, $00, 0, -4
.byte  0, $01, 1 | VFLIP, -4
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.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

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.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

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

Post by thefox »

FrankenGraphics wrote:This is what i know about the .msb file format:
...
Here's my take: viewtopic.php?p=133350#p133350
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

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

Post by Kasumi »

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.)
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

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.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

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

Post by FrankenGraphics »

Banshaku wrote: The OAM format seems un-natural when you are used to structure things by group.
It just struck me... One dumb trick to eat the cake and have it too would be to output it like so:

Code: Select all

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

Code: Select all

.byte -8, $00, 0
.byte -4
.byte  0, $01, 1 | VFLIP
.byte -4
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.

kasumi wrote:It's the two origin bytes
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)
Last edited by FrankenGraphics on Sat Aug 18, 2018 4:37 am, edited 1 time in total.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

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

Post by Kasumi »

FrankenGraphics wrote:The editor GUI has no direct origin control (and at a few times i've whished it had, except preferably not global).
It does, that's how you accidentally changed it once! Control+Click inside the grid.
Image
Metasprites are flipped relative to it when you click HFlip and VFlip.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

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

Post by FrankenGraphics »

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.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

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.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

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

Post by FrankenGraphics »

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.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku »

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 ^^;;
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

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