/cog/ - Traditional & Video Gaming

>>432088
Physical ROM chips cost an arm and a leg back in the day, so publishers urged (or straight up contractually obligated) coders to get games done to a certain smaller size. Almost always this meant leaving out tons of content because it wouldn't fit the cartridge. 16-bit Ultimate Mortal Kombat 3 was missing Sheeva and the announcer voices because of this, for example.

Romhackers bumping that up to impossible levels is either to get around that limit, or to make games have impossible amount of content or voice samples. Or they are simply using the extra space to get around Colecovision tier limited hardware.

That's just my theory though! I don't follow the rom hack scene.

>>432094
Why? Several of those games are 32k which was a perfectly legitimate ROM size many games used back then.

>>432118
>>432094
it does take less time to finish a smaller game though. you can fill a 16k ROM a lot faster than a 256k one.

SG 1000 Longplay [43] Bomb Jack

Bomb Jack for the SG-1000. They needed 32k for this? The game logic seems simple enough that 16k should have worked. I bet though that the background graphics aren't compressed and it's just raw data because screen switches are almost instantaneous, there's no pause to de-pack anything.

>>432123
>>432094
>>432088
There was one SG-1000 game that used 128k ROM (Loretta no Shouzou: Sherlock Holmes) so technically it did exist.

>>432141
that's true although they marketed it as a Mark III game iirc

>>432088
is that like all the Genesis homebrews that use 32 mbit ROMs?

>>432207
Yes. I'd like to see them try making a 4 mbit game like the early Genesis titles where you have to recycle tiles and whatnot.

>>432123
it's probably 16k of code and the rest of the ROM is uncompressed tiles

Congo Bongo (SG-1000)

Congo Bongo. It pauses between screens so there's definitely some decompressing going on there.

>>432217
Every home system port of this game was horrible.