Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Nobun]

Hi Elecbyte. I am Nobun from Mugenation Team. Even if I have no more time to spend with mugen I will be happy if I can be usefull in some manner. I am very happy of Elecbyte come backs.

Now I go to the point

---------------------
Sff v2
---------------------

Perhaps (like old formats.txt) a text file that explains the structure of sff v2 (and fnt lv2) should be nice to allow manipulation, extractions, alternate creation etc of Sff done.
Also, there some thing that are not clear to me:

1) Sffv2 will support PNG and also RGB images if I understood well. Ok no problem about PNG (easyer to use than PCX) but about RGB. If an image is a true-color one I think that the "palette system" (based on act file loaded into the sff v2) will not work, so a 32 bit images should be ALWAYS the same and will not change if you choose different palettes to you character. is it right? if it is so the base-images (poses of char so you need to color it with the color choosed by the player) should be always 256-color with shared colors?
Is it possible to have a SFF v2 with RGB images with different palettes? If yes how must be builded the sff v2?

2)
[Pal section]

You said that you can use different group, itemno other than 1,1 to 1,6 and use other values for other issues, for example: projectiles etc (fine xD)
1 - However, in [Sprite] section there is a way that allow me to say that a picture will use, for example, palette 2,1? Do I have to use

Code: [Select]

[option]
sprite.usepal = 2,1

1.B - If I use 2,1 - for example - for a projectile and I defined also a 2,2 palette: what happens if I choose second pal? (main pictures will use 1,2 pal and the projectile? will use 2,1 or 2,2?)

-----------------

Sorry for all those questions. But I also would like to test deeply RC1 and search if there are problems on the management of  sff v2

###############

font

I didn't understand how works fnt v2

[Frederika Bernkastel~]

1) palettized images normally only go up to 256 colors, anything more and the palettes become huge (what do you think about a 2gbs palette file ?)

2) form my understanding, the remappal sctrl is not very imnportant. every sprite belongs to a certain group,no palette, based of the sff, you can specify those in the sff2 , in the sff1 shared spirtes default to 1,1 ; then using in code remappal you can choose a palette group,no to apply a palette to it; you can read the palno choosen by the player as a trigger or you can just randomize the palette completely.

[Cyanide]

The format of sffv2 (at least it's creation) is explained in the docs folder. Font is as well. Gives you a sample file to look at and if you like, pull out and alter.

[Frederika Bernkastel~]

yeah, but he want the file format, so he can open them ina hex editor and know what he is looking at not viceversa. personally I would love if the short ints for the sprite group and no are increased to full 32 bit ints.

[tunglashor]

Yeah, there are lots of things they could improve from the old format, I hope they have.  I thought it was strange the way linked images were linked not to a particular [group,sprite], but to a specific location in the list.  That was a terrible choice.  I think there were only 16 bits for that (the index of the source sprite) as well.

The main thing I hope they do (but they probably won't) is tighten up on what Mugen will accept as a valid SFF file.  Some of the tools out there generate SFFs that deviate badly from the spec, but Mugen accepts them.  That means that all tools have to be able to accept them, which means coding around the mistakes of others, with nothing to guide you.  Not fun!

[Nobun]

I thought it was strange the way linked images were linked not to a particular [group,sprite], but to a specific location in the list.  That was a terrible choice.  I think there were only 16 bits for that (the index of the source sprite) as well.

I don't agree with you at this point. The choice is easy to explain. In C, C++ When you load an array of datas (array, vector, etc) you call all elements by index. Groupno, Imageno is a combination thinked for an easyer and better organization of images for the user of the program. But, INTO THE ENGINE, to avoid to vaste space in memory, the better choice is to associate a couple of grp,img into a single index.

For example assume I have a
std::vector < IMAGE * > image

when I call a single image I call, for example
image[10]

so using index of images for linked image is a choose right becouse it is thinked to a better and quicker image localization from MEMORY. Or I think this is the reason.

However it is only a little opinion.

---

Hoping that Elecbyte will solve my initial doubts (about binary format, Federika understood well my question  )

[tunglashor]

By that logic you'd code your .air file based on the index of the sprites in the list, instead of by groupno/imageno.  Whatever data structures the engine uses internally, there's obviously some method for looking up a sprite based on its groupno/imageno, or else how would it play animations?  So, there's no reason not to use the same method for looking up the linked sprite.

A sprite's unique identifier in the SFF is its groupno/imageno, so that's how you should link to it.  Using the index just means you're FORCED to maintain an array of the order of the sprites as well as whatever other data structures you're using.  Of course, my reasons for wanting this are selfish - it would remove an annoying complication of coding tools that manage SFF files - but it makes sense either way.  And allowing only 16 bits for the index of the source sprite means it's only possible to link to the first 65535 sprites in the list (unless my math is off  )  Probably not a problem in practice, admittedly - not yet anyway.

[Nobun]

Eh Eh... my assumption is basicly based on the way that dynamic allocation of memory works on C / C++
(using std::vector or malloc )
For example if I define an array like
Image[9001][100]
(to allow to have a 2d array that can contain up to 9000 in group - to allow avatars - and 100 images for a group)
I allocate memory space for 9001 * 100 images so I am using memory for 9,001,100 images but I am really using A LOT less - with an incredible vaste of memory).
Usually, when you don't know how many elements you need to store in memory, you use a dinamic allocation that allocate the memory you really use depending of how many elements you must store.
example
IMAGE * image = (IMAGE *) malloc (800 * sizeof (IMAGE)); //Allocating space for 800 images
image[401]; //call image ID 401
So if I want to call an image that is for example 9000,1 I have to see other infos (using "if" and matching the ID from groupno, imageno infos)

Yes it is obliouvsly my assumption, basicly (my example is very bad and not efficient), but it is complex to explain what I meant exactly (if you know how std::vector, malloc works, if you know how other container class works you probably understand what I am trying to say but I am not able to explain well becouse I am not a good english-speaker)

However I understood your point and you can be right. 

[tunglashor]

Actually I think your English is good - I understood everything you said, at least!

I know what you're saying regarding malloc etc, however I don't think we need to go as low-level as that.  It's evident that Mugen has a mechanism for associating individual sprites with their groupNo and imageNo, and however that's done, the same mechanism could be used for link references consisting of a groupNo/imageNo.

Anyway, sorry to drag out a minor point.  Nice to have the discussion though  

[Nobun]

You don't need to be sorry 
A discussion is never useless, mainly if it concerns programming. As a programmer for fun (more or less a noob one), I like discussing those things becouse I can learn things I don't know or I can see new points-of-view I never considered.
From my side it was a very pleasure to discuss with you 
I hope I didn't annoy you too much

--------

Backing to the point of original question (things that only Elecbyte knows deeply and not explained in documentations) I hope to have a detailed answer of my questions I wrote in my first message of discussion. I will only explain better the "palette" question becouse it can be not totally clear:

- Assume I define those palettes: 1,1; 1,2; 1,3; 1,4; 1,5; 1,6; 2,1; 2,2; 2,3; 2,4; 2,5; 2,6
- Assume that in txt to create sffv2 I used, for example a code like that

Code: [Select]

[Option]
sprite.usepal = 1,1   
sprite.removecolors = -1

[Sprite]
   0, 0, stand00.png,  18,105
   0, 1, stand01.png,  18,104
   0, 2, stand02.png,  18,104
 
[Option]
sprite.usepal = 2,1   
sprite.removecolors = -1

[Sprite]
   2120, 0, proj00.png,  18,18
   2120, 1, proj01.png,  18,18
   2120, 2, proj02.png,  18,18

- Assume that, when playing the char with this SFF, I choosed color 3 (pressing "c").

While we are sure that images 0,x will be colored as 1,3.... what about 2120,x? the will be colored as 2,1 or 2,3?

-------

The other question I did before, as Federika understood well, is also about if you will also release the infos about binary structure of sffv2 (like you did in past for sffv1).... and the same question for fonts lv2

NOW ADDING OTHER QUESTIONS:

1 - actually sffv2 seems able to load both pcx and png (also becouse SDL_image is able to manage those formats I assume). However: will the pcx support become deprecated? I am asking becouse I am evaluating to develop a sffv1 to sffv2 coversor so I'd like

2 - in ALL your examples you putted ALL individual images (usepal = -1) BEFORE the shared ones. It is always suggested to put individual images BEFORE shared ones?

[serio]

While we are sure that images 0,x will be colored as 1,3.... what about 2120,x? the will be colored as 2,1 or 2,3?

2,1
to use 2,3 you'll have to add a remappal with source=2,1 and dest=2,palno

the remappal in state 5900 is only for sprites with palette 1,1 so 2,1 are unaffected by it.

[Nobun]

Thank a lot, serio!
Now only 3 questions remained unsolved (Sffv2 binary format explaination, if PCX support will be to consider deprecated, and if you have to put always "individual" images [usepal = -1] before "shared" ones [usepal = 1,1] like in example or if you can put at any point without worries)

[serio]

and if you have to put always "individual" images [usepal = -1] before "shared" ones [usepal = 1,1] like in example or if you can put at any point without worries)

dunno if that one matters. i put the 1,1 palette ones before -1 and nothing bad happened. palettes work etc.

though it might be related to the color removing thing, i didn't try to use it yet so i don't know.

[O Ilusionista]

there are somethings I still don't get:

- Assume I define those palettes: 1,1; 1,2; 1,3; 1,4; 1,5; 1,6; 2,1; 2,2; 2,3; 2,4; 2,5; 2,6

why the first number had changed? this is like on the old where we press start to choose?

[Option]
sprite.usepal = 1,1   
sprite.removecolors = -1

[Sprite]
   0, 0, stand00.png,  18,105
   0, 1, stand01.png,  18,104
   0, 2, stand02.png,  18,104
 
[Option]
sprite.usepal = 2,1   
sprite.removecolors = -1

[Sprite]
   2120, 0, proj00.png,  18,18
   2120, 1, proj01.png,  18,18
   2120, 2, proj02.png,  18,18

We can have different pals based on groups?

[Nobun]

from sprmake2.htm

;Palettes
;Accepts .act as well as .pcx/.png files (the palette is extracted from the
;pcx or png).
;Character palettes should be numbered from 1,1 to 1,6. Extra palettes for
;projectiles, helpers, etc. may use any other number.
;Format:
;  group,itemno, fname, startcol,endcol

So I assume you can use other groupno, imageno for extra palettes.
And I assumed also you can use - for example - 2,1

Character palettes of char are reserved (1,1 to 1,6 so another question can be about pal 7-12 and the related cases of start+button if exists again in the new Mugen) and when you "mark" an image that should use a normal char palette you will start with [Option] and usepal = 1,1
Mugen will choose pal 1,3 for all sprites uses 1,1 in this def if you choose color 3 during game (pressing "c" instead of "a")

My question was about if the same mechanism can be applied to other groups (like 2 instead of 1) and serio explained that to apply the same mechanism to other groups (in this case group 2) you have to define a routine into the state 5900 of the char, or the images with palette 2,1 (in my example) will use always 2,1 regardless of the fact you choose another color for the char (so if you choose color 3 - in game - for the character, the character itself will use 1,3 but the projectile still use 2,1 and will not use 2,3 if you didn't change state 5900)

Hoping I was able to explain clearer the point. However nice to meet you, .o., I appreciate a lot your work with FF (hoping you added the feature I suggested )