Is there a maxiumum number of frames I can have in an .sff? Is there an amount that people have found to be unrunnable in Mugen, or difficult to play?

And since I'm probably going to throw in a good bit of sound too, has anyone had problems with running or playing chars over a total filesize?

I don't think theres any limits mugen itself regarding the amount of frames, but obviously you have to think of how much memory it use's, plus the amount happening on screen (plus sound effects). As this could effect pc's.

Its just guess work really (plus having beta testers :P) to see how far you can push it.

Taken from the Mugen docs, there is no limit besides the memory of your computer.

I've myself tested very high sprites and anims numbers and it worked.

Well, I don't think you can have more than 134,217,683 or so sprites in an SFF (and that many only if they're all duplicates, which would be rather useless). In fact, the limit may actually be more like half that, if Elecbyte was silly enough to treat the file offset numbers in the SFF subheaders as signed instead of unsigned, but I'm not about to check. :p
And, if you use duplicate sprite linking (-f in Sprmaker), you'd better not have any sprites linked to the 32,768th or higher sprite.

(I'd have to check the minimum size of a WAV file before I could tell you the limit on how many sounds you can put in a SND file, though.)

In other words, yeah, it really just depends on your system.

This post has been edited by Winane on Dec 10 2003, 08:30 PM

I'm not up to 1k frames yet, and I'll probably link to keep the number lower. I've got about 180 sounds, minimum size 380, max 380k, avg 33k. Does that get compressed in the final .snd?

If there's no max, have there been character sizes that have gotten a lot of complaints from users trying to play with them? I've got a semi-powerful system, not sure how this will perform on the average box.

This post has been edited by Enkephalin on Dec 10 2003, 08:22 PM

For the number of images, the SFF uses 4 bytes in the file header. That should be enough to store up to 2^32 = 4294967296 (Winane, the number is unsigned).

The group numbers are stored on 2 bytes, the same for the index.

That gives you: 65536 groups x 65536 images per group = 2^32 = 4294967296 images.

To give an idea: With that number of images, you can do a movie of 19884 hours long at 60fps

(((4294967296/60)/60)/60)

voila.
That should do it.

This post has been edited by Renzo on Dec 11 2003, 01:04 AM

Nope.
My calculation:
4 bytes in the subheaders for the file offset where next subfile is means a maximum size of 2^32 = 4294967296 bytes before the last sprite.
4294967296 bytes
-512 bytes for the main header = 4294966784
-899 bytes for the minimum size of an 8-bit PCX file (with just one pixel) = 4294965885
-0 bytes if all sprites are linked to the first one = 4294965885
/32 bytes per subheader = 134217683.90625
Rounded down to be safe = 134,217,683 sprites

(Or 67,108,819 sprites if the offset number is signed. How are you sure that it isn't?)

=P

Bah.

The only thing we are sure is you can put a LOT of sprites on it.

And about the unsigned or signed question, I know because I wrote a library to load SFFs in java

Actually, the bytes for the "file offset where the next subfile is stored" isn´t used properly in mugen. To calculate where It´s located the next sub-image, mugen uses "length of sub file in bytes", as I tested.

That issue almost break my will for programming because for almost a year I ignored why in the f***** my library crashed only when loading MSM´s SFFs.

It´s funny when you don´t comply with an specification, even if you defined that specification. That´s the case of mugen.

So, my calculations are not bad at all.

This post has been edited by Renzo on Dec 11 2003, 12:14 PM

I'm just lazy, and before I get starting making this thing happen, I'd like a guesstimate whether most player's machines can handle a swarm of 7-10 projectiles with 36 frames each, bouncing at walking pace across the screen, accompanied by a 20 second 860k sound effect, without the application crapping out completely.

What's your prognosis?

Um, Renzo, you got that backwards. Mugen ignores the subfile length, and only uses the next file offset. I'm quite sure of this. Haven't you noticed that MCM and Sprmaker calculate the subfile length differently? And yet, Mugen successfully loads SFFs created with either. :P

And, you didn't really answer my question about how you're sure Mugen treats the offset number as unsigned. :P


Enkephalin:
I've got a sytem with 1 GHz P3, 256 MB RAM, and a GeForce2 Go, and I'm pretty sure my system has never had trouble handling something like that. I wouldn't worry about it too much. But like LyonHrt suggested, just get some people with weak systems to test your stuff for you if you want to make sure you don't exceed many people's systems' capabilities.

Yes Winane, you are right. I checked again the code I wrote and I used offsets to calculate file sizes.

I´m sure about the unsigned values because in java , the unsigned types don´t exist and I had to write an entire routine only to convert the values from signed to unsigned. (explanation below)

When you read a int from the file, It´s interpreted as signed, but in the practice, the interpretation were wrong. I got negative group numbers and such results. That´s why I´m sure about that.

This post has been edited by Renzo on Dec 12 2003, 05:56 AM

Attached File ( Number of downloads: 4 )
 Sff.java

Actually, negative group and sprite numbers are allowed in Mugen. Once I have a spare moment, I'll test whether it also accepts numbers greater than 32767, but I have already tested negative numbers, and they work for sure.

Check out our modified formats.txt at http://nigaiden.skreel.org/index.php for more details about this stuff.

Now, how did you end up with a large enough value for the file offset to verify that it is indeed interpreted as unsigned? Did you actually make a 2,147,483,648+ byte SFF?

I expect to be soon, but right now I'm afraid I'm not yet familiar enough with Java to make any sense of the code you posted without the comments translated to English.

Now, I get your point about the unsigned/signed issue. To be honest, I wrote the code almost two years ago, and I can barely remember exactly when the problem came out.

Anyway is good to interchange comments about this stuff... and realize that I should study more the format.

Okay, I checked about signed vs. unsigned. I've updated formats.txt accordingly, and attached it to this post (see note #5).
So, Renzo, all that time you spent getting your program to interpret the numbers as unsigned instead of signed...

Attached File ( Number of downloads: 6 )
 formats.rar