OpenBor Game Pak File Size

[Airwalk16]

Can anyone explain to me why these Openbor Pak games are so ENORMOUS in size, when the graphics are the same as something you'd have on like Super Nintendo? Compared to a Super Nintendo game, such a BattleToads, the OpenBor games are easily 300MB, some as large as a Gigabyte. When Battletoads is 1.05MB.
What's going on here?!

 

[Kratus]

When Battletoads is 1.05MB

@Airwalk16

OpenBOR engine (and other modern engines too, like Unity) work differently from native 8/16 bits games in its original consoles. One of the main reasons for the pak size is the fact that in the OpenBOR the music/sound/video are all played using media files such as .ogg/.wav/.webm.

As an example, a Mega Drive plays music using sound cards with built in synthesisers, which play music on-the-fly using built in instruments. Considering that a single .ogg music can have 1mb, an entire game like SORX with two playlists exceeds 300mb easily.

YM2612: The chip that powered music on the Mega Drive - Yamaha - Music - Australia

au.yamaha.com

Using SORX as an example again, if I remove all media and mix only code/sprites, the size decreases from around 360mb to around 25mb (even considering SOR1/2/3 plus many new sprites).

 

[O Ilusionista]

Compared to a Super Nintendo game, such a BattleToads, the OpenBor games are easily 300MB, some as large as a Gigabyte. When Battletoads is 1.05MB.
What's going on here?!

As @Kratus explained, things works very differently from the original systems and modern engines.
For example, the original games worked using sprite tiles, while we don't use them (and don't need to).
Plus, music codes for the sound chips are way, way smaller than the rendered music file.

But you can't compare two different systems like that, as it won't make sense.

As an Example, the Sega Genesis Arcade Classics contains 3 arcade games and the rom is 101,09 kb.
But this is way bigger than the game files combined - Arcade Centipede is 8,38 kb only.

 

[DCurrent]

@Airwalk16,

Same as others have said. Old school games were optimized to an absurd degree, written specifically by and for the hardware they ran on, with tedious restrictions, bottlenecks, and other frustrations developers had to work around. Images were stored as indexed tiles they had to very carefully arrange not just in memory, but artistically as well to squeeze every last literal bit out of the assets.

Developers were just a different breed then. Now, those sorts of optimizations are not only unnecessary, they are also a detriment. Human time is too expensive, and so are developmental tools. Obviously you don't want to waste resources just because you can, but there's no practical gain now in tiled assets or chiptune music. In fact, it would actually cost you MORE resources to do either since modern hardware doesn't include onboard tile decompression or synthesizers.

So why would you bother with tiles when it just costs you time, limits your graphical capability and eats up CPU cycles? Store the asset trimmed and compressed (which OpenBOR does for you), then go on with life. Same for music. You want an old school chiptune? Well you could try and write a software emulator for the chiptune, but good luck ever getting it to sound consistent across any hardware, and say goodbye to a good 10% or so of your CPU time. Or, you could just record the chiptune in production and play it back.

-------

This all said, a lot of OpenBOR creators DO get a little flippant with their projects. They'll leave a lot of unused assets lying around (in some cases, many times over what's in the actual game) or pay no attention what so ever to music trimming and sound size. One common mistaken is not knowing how to set loops, so they'll just pack in a huge music file with several loops baked into the track.

Another size multiplier is adding massive .gif animations for cut scenes. These are common in really old games before the engine supported webm movies.

DC

 

[Airwalk16]

I see. It still seems like such a waste to have them be so enormous. I'd think the engine or something could have some kind of way to compress them further than just a zip file. I dunno. I'd be way more in to openbor if a 300 game set didn't take up 50 gigs of my space.

 

[Kratus]

I'd be way more in to openbor if a 300 game set didn't take up 50 gigs of my space.

I understand, but in this case I think that the problem is how the OpenBOR games are treated.

In fact, OpenBOR is not like an emulator, where you have tons of games with an "uniform" size running with an unique executable. Instead, it's an engine where every game must be treated separately like a PC game.

So, looking from the "PC game" point of view, SORX (365mb) look small if compared with SOR4 (6gb), even smaller if compared with AAA games with 100gb+
It would be equally weird if we ask for smaller Unity 3D games with an "uniform" size in order to put all of them into a unique small pack.