It is currently Fri Nov 16, 2018 11:35 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Aug 16, 2018 8:56 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2046
Location: Fukuoka, Japan
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?


Top
 Profile  
 
PostPosted: Thu Aug 16, 2018 10:00 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Thu Aug 16, 2018 6:00 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2046
Location: Fukuoka, Japan
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.


Top
 Profile  
 
PostPosted: Thu Aug 16, 2018 7:04 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
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:
.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:
.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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Thu Aug 16, 2018 7:15 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2046
Location: Fukuoka, Japan
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.


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 2:39 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3136
Location: Tampere, Finland
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


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 3:13 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
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.)

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 3:19 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2046
Location: Fukuoka, Japan
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.


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 3:53 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
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:
yPos, tileID, attr,
xPos

Same example, OAM formatted, but pairing y and x vertically with the help of a line break:
Code:
.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)

_________________
http://www.frankengraphics.com - personal NES blog


Last edited by FrankenGraphics on Sat Aug 18, 2018 4:37 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 4:28 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
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.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 4:36 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 9:02 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2046
Location: Fukuoka, Japan
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.


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 9:53 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 8:29 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2046
Location: Fukuoka, Japan
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 ^^;;


Top
 Profile  
 
PostPosted: Sat Aug 18, 2018 8:38 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20773
Location: NE Indiana, USA (NTSC)
What Borland-specific libraries does it use, which would preclude building it with MinGW-w64 or the without charge edition of Visual Studio?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group