Are there any?

Ok, if this seems totally off the wall and not true that's great, but I've been browsing the forums recently and have come across various mutterings concerning file-size limits. As a PC user I haven't seen any particular file-size limits apart from the ability read the file in EVNEW. That said I haven't massively tested this.

So my question has a few possible scenarios:

1. There is a file-size limit for uploading to Ambrosia Plug-ins (If so what is this limit?)

2. There is a file-size limit for an individual rleD/rle8 resource

3. There is a limitation on the actual file-size usable on a Mac system (would obviously incur '2)' as you can't split a resource over two files)
   a ) Defined by the Mac OS
   b ) Defined by EV Nova.

Thanks for all your help

Answer:

According to Chamrin on IRC, the resource fork is limited to a certain size. So each individual file has a max size. Currently I think it's 15-16MB - remember seeing it somewhere. Which means my 122MB .rez file needs to be split up.

This post has been edited by philipw : 06 September 2008 - 05:12 AM

1. No hard limit (or at least none known). The problem is you can't see progress when uploading and they can sometimes silently fail part-way through (the only way to tell if it's still working is to watch your network activity). My advice would just be to try and see what happens. Files in excess of 20 MB have been successfully uploaded before.

2. Not sure, though shouldn't really be relevant. If you hit some sort of limit here then you probably shouldn't have a sprite that big anyway.

3. 16 MB limit defined by the file format used by Mac plug-ins (resource fork). So when creating plugs with EVNEW, make sure all files are under 16 MB or else Mac users will have big problems.

(edit) 122 MB?? Wow.

This post has been edited by Guy : 06 September 2008 - 05:18 AM

Also, you should have a pretty reasonable number of actual resources per file excluding size or strange things can happen- like mysterious corrupted resources or ones that just disappear. That was a problem for me when 'KFL Descs" had all of my descs and I could watch them disappear from the list! That behavior was peculiar to ResEdit and may not apply in real life: However, since ResEdit was Apples' approved tool I can only imagine the actual resource fork having similar limits, at least in classic.

And an individual rled can be quite huge- I can personally attest to a nearly 640 by 480 by 72 frame ship that was some eleven meg by itself, and one current ship which is 252 frames by 300*360 in size. I recall modesty_blaise making an explosion at one time or another that filled the whole screen.

Yeah, 16 MB (16,777,216 bytes, Guy?) is the limit to plug-in files on a Mac, but MC will start giving you dialogs about the file size being too big at 15 MB. Which is ironic, as I've found MC to be the best tool their is for splitting apart plug-ins. EVNEW is tedious at best.

@rmx256, on Sep 6 2008, 08:48 AM, said in EVN Filesize Limits:

Also, you should have a pretty reasonable number of actual resources per file excluding size or strange things can happen- like mysterious corrupted resources or ones that just disappear.

I'd just like to amplify this one, since it's less visible than the overall file size. There are all sorts of little limits that can hit you - there's even one on the number of resource names in one file - so it's best to err on the side of more files rather than fewer, and not to do it solely on the basis of file size.

Remember, when the resource fork format was created, the Macintosh's only storage device was a 400 K floppy drive, unless you were so rich that you could afford the 10 MB external hard drive. A 16 MB upper limit didn't seem all that big a deal.

I'm curious; what could you put in a 122 MB .rez file? Isn't that about the same size as all the Nova data files?

This post has been edited by JacaByte : 06 September 2008 - 11:57 AM

@jacabyte, on Sep 6 2008, 12:56 PM, said in EVN Filesize Limits:

I'm curious; what could you put in a 122 MB .rez file? Isn't that about the same size as all the Nova data files?

Not quite, but it's getting close. Especially given the question about RLE sizes, I suspect it's the result of the enormous sprites that seem to be becoming popular.

Didn't Pipey himself say that the maximum size he recommended for ships was 200x200? The number of frames a ship could have is debatable, but surely there's a limit to how large things can get and still look good, or before extra frames yield no noticeable increase in quality?

People do think that size matters. I try to limit myself to about 250. Anything more is ridiculous.

From looking at the data, the maximum number of frames, height, and width are all 32767 (or 65535), which is ridiculous. The only other limitation is that the whole thing must be less than 2147483647 (or 4294967295) bytes, although you'll run into the 16777215 issue first. It is not possible to directly map this size to a number of frames/height/width because everything is compressed. What editor you use may affect how much compression you get; EVNEW, for example, won't compress single-color runs. which are the only thing really left to the implementation, which generally means it isn't, for writing.

I use the large ships to balance all of the small ones I am not a size king. I have a vision of scale, you could say, that I aspired to when I was doing the graphics. Quite frankly I would love to redo many of my graphics but I am not worrying about that anymore. If I do this thing will NEVER get released.

Limitations of the resource fork

@nonconventionally-creative, on Sep 7 2008, 12:07 PM, said in EVN Filesize Limits:

EVNEW, for example, won't compress single-color runs.

Which is a good thing because Nova can't handle transparency on colour runs. MC doesn't compress them either.

@guy, on Sep 6 2008, 06:36 PM, said in EVN Filesize Limits:

Which is a good thing because Nova can't handle transparency on colour runs. MC doesn't compress them either.

I don't understand. DRAW_SINGLE isn't used to compress transparency, SKIP is. Or are you talking about extra sprite sets like engine/weapon glow and running lights?

Engine, weapon, light, shield glows, base transparency, ionisation, paint, murk, cloak...

Huh. You'd think that it wouldn't make any difference how the actual resource data was stored, since it has to be decompressed before it is used. I wonder it this'll be fixed for 1.1.

Getting Nova off of the resource fork system would be like taking beer away from a street bum. My wager is that it can't be done within the scope of the 1.1 update.

@jacabyte, on Sep 7 2008, 02:31 PM, said in EVN Filesize Limits:

My wager is that it can't be done within the scope of the 1.1 update.

...and probably wouldn't even be a good idea anyway. For a new game, a format not based on resources would make sense, but to make such a major change in a .1 update would create a huge disruption.

Huh? I wasn't talking about the resource fork, but the transparency failure. I was thinking that the buffered-drawing might fix that, or at least they'd fix it at the same time.