File sizes

[NachtIntellect]

Hi everyone, so there is a project I am working and in terms of file size it might be probably a little more than what this forum is used to and I know large file sizes are normally frowned upon as some people here either don't have much bandwidth or don't have the data to download certain large files. So I thought what I'd do is give you guys a compressed version which lowers the quality quite a bit of audio and then maybe split it into packs with their being an option to download the high quality audio, basically you would only need 2 of these packs 1 being the core files includes all the code for base monsters, has the basic voices and so on, originally I plan to have each pack being 10-15 MB's so that way it can be played and enjoyed by all.

But I have to ask, what size do you all think is the limit to what you would normally download? Please let me know, I want to make sure you guys with the low-end bandwidth or data all get a chance to play my project should you choose to.

[Redneckerz]

If it is your dream game Eternally Eternity Blitz, i would first focus on getting the content ready and worry about size later.

Judging from your post you are concerned about audio. I assume you want to use .ogg or .mp3's for the soundtrack and/or the voices?

Or, you could commit yourself to use a midi soundtrack as an alternative for the .ogg pack, since that can be included in a low-bandwidth download, and make the ogg soundtrack an optional download. Or you could opt to ship the low-bandwidth version without soundtrack, but that might turn into a point of criticism from those who will play your mod.

[MFG38]

Thankfully my own Internet doesn't have any arbitrary bandwidth limits or other such caps I know of, so I'm not too concerned about .wad and .pk3 files that are even 100MB+ in size.

Either way, I second Redneckerz's post above, in particular the idea of a MIDI "main" soundtrack and an optional OGG one available as a separate download.

[NachtIntellect]

If it is your dream game Eternally Eternity Blitz, i would first focus on getting the content ready and worry about size later.

Judging from your post you are concerned about audio. I assume you want to use .ogg or .mp3's for the soundtrack and/or the voices?

Or, you could commit yourself to use a midi soundtrack as an alternative for the .ogg pack, since that can be included in a low-bandwidth download, and make the ogg soundtrack an optional download. Or you could opt to ship the low-bandwidth version without soundtrack, but that might turn into a point of criticism from those who will play your mod.

I've made all the sound files ogg, the music is made in MIDI. WW suggested seeing if Speex would work which would help with the compression. But yeah as far as I know some people on the forums have bandwidth problems and was the whole reason for changing over to imgur as spoilers didn't stop the images from loading.

[Redneckerz]

I've made all the sound files ogg, the music is made in MIDI. WW suggested seeing if Speex would work which would help with the compression. But yeah as far as I know some people on the forums have bandwidth problems and was the whole reason for changing over to imgur as spoilers didn't stop the images from loading.

Good, so its your fault.

Joking aside, i would then consider making the ogg an optional download. Speex could be used, but perhaps its an idea to convert them over to a lower bitrate stream and re-code from there? In the old times voices were used as .VOC files.

Whilst i reckon that's old and buried, perhaps its an idea? Or maybe look into how other games go with this idea?

[leileilol]

There's also the old idgames/ guidelines where 50MB is the max ever, and there's been many, MANY cases of pwads of a few not impressive levels with their size 'impressively' padded up with commercial MP3s. Some see a large filesize as a reflection of quality/"marchitecture".

Another thing to watch out for are MD3s. There have been a few gzdoom wads that have a few thousandspolies lotsofframes MD3s that ended up in the hundred megs. MD3 is not an efficient format....somethinggrumbleIQMetc


my 'no thanks' begins in the upper hundredmegs+gigabytes since it usually smells like a mess. I don't care how ridiculously fast 2019 internet is or how much storage can be had for less, this is instinct/expectation

[Matt]

Pretty much what leilei said, though my own personal cutoff point starts materializing at 100MB just because of the new digit.

(I really dislike the feel of any headphones and I live in a tiny apartment so good speakers aren't a real non-asshole option, so I do a lot of playing without audio and lots of voice and music are going to be a waste for me usually)

[Kinsie]

Stand-alone games should probably focus on being fun and/or entertaining to play before they stress about shaving off kilobytes.

[NachtIntellect]

There's also the old idgames/ guidelines where 50MB is the max ever, and there's been many, MANY cases of pwads of a few not impressive levels with their size 'impressively' padded up with commercial MP3s. Some see a large filesize as a reflection of quality/"marchitecture".

Another thing to watch out for are MD3s. There have been a few gzdoom wads that have a few thousandspolies lotsofframes MD3s that ended up in the hundred megs. MD3 is not an efficient format....somethinggrumbleIQMetc


my 'no thanks' begins in the upper hundredmegs+gigabytes since it usually smells like a mess. I don't care how ridiculously fast 2019 internet is or how much storage can be had for less, this is instinct/expectation

Pretty much what leilei said, though my own personal cutoff point starts materializing at 100MB just because of the new digit.

(I really dislike the feel of any headphones and I live in a tiny apartment so good speakers aren't a real non-asshole option, so I do a lot of playing without audio and lots of voice and music are going to be a waste for me usually)

Thank you very much for that both of you, look I am going to do absolutely everything I can so you don't have to download it at a large filesize. But in the end if it does somehow end up at 50 MB's I think the packs would be the better option to avoid the yikes factor.

[SanyaWaffles]

When a former animator on my team was pushing for full fledged 24/25FPS animated cutscenes for DD2 the immediate concerns was the fact the filesize would be offputting to my target audience.

I know that DD1 and DD2 are both niche projects but I still want them to be accessible to the Doom community.

It is a standalone project that doesn't use Doom2.wad at all but I frankly am not going to subject people to gigabytes of cutscenes when people aren't even playing the game for that... especially knowing historically people don't want that.

My philosophy: focus on gameplay and the asthetics you want to go for, but worry about prettying it up second, then worry about size last - but keep in mind your audience as well.

For me I follow what Kinsie says: I want the project to be fun and entertaining and balanced before worrying about size, but there's also obvious things I can do to keep size low.

Music is what makes up most of the size as neither of my projects use MIDI music. I use OGG Vorbis for both sounds and music to try to balance compression with being not sounding awful. I also try to trim the full soundtrack down to what is looped as per my musician's notes for each track. I used to use FLACs but the size was too much for the project.

I use Slade in conjunction with PNG optimization tools for manipulating PNG sprites and graphics. People say recoloring sprites is unreliable when you do that, but I've never had that problem personally.

[Graf Zahl]

People say recoloring sprites is unreliable when you do that, but I've never had that problem personally.

It is unreliable when you got the same color multiple times in a palette. In such cases the palette index something will end up is random, especially when the source palette is not a perfect match for the image. If you need translations you may be better off using Doom patch format - normally that wouldn't increase final file size.

[leileilol]

My techniques (for OA3) for preventing bloat:

- using skeletal formats and other non-big-data-stream formats (tracker music, NO .roq cutscenes, NO ogg/mp3/wav/flac/opus music etc)
- An engine function that logs all the files loaded so non-essential accidental copies, unused redundant leftovers don't get in packing. Infozip/7zip would make a pk3 out of that log
- Mass swizzling/encoding assets at pak building time. Most of the texture art is 512x512+ so it'd be pretty fine to JPG or DDS them, the loss doesn't matter for non-pixel-precise things. WAVs becoming OGGs too etc.
- Mapping carefully. it's easy to make a bsp with a big aas when you don't clip carefully.
- Atlasing frequent item textures together to one square image texture (i.e. ammo boxes)
- Packing without compression, so a better compression format for distribution would have more advantage and the lessened load times when it's for playing time.

So far, the largest (not latest) internal OA3 build (after swizzling etc) is 69mb and the largest lossless uncut form packed is 176mb. Sure beats 400+mb...

[SanyaWaffles]

People say recoloring sprites is unreliable when you do that, but I've never had that problem personally.

It is unreliable when you got the same color multiple times in a palette. In such cases the palette index something will end up is random, especially when the source palette is not a perfect match for the image. If you need translations you may be better off using Doom patch format - normally that wouldn't increase final file size.

Ah, that explains that. I use a custom palette that as far as I can tell doesn't have duplicate entries, so for me it wouldn't be a problem.

[ravage]

People say recoloring sprites is unreliable when you do that, but I've never had that problem personally.

It is unreliable when you got the same color multiple times in a palette. In such cases the palette index something will end up is random, especially when the source palette is not a perfect match for the image. If you need translations you may be better off using Doom patch format - normally that wouldn't increase final file size.

I've found that converting to a paletted png will retain the palette and actually be smaller than doom format. Most of the time.

[Graf Zahl]

But it normally won't be smaller if you compress it again.