For example Kirby's Adventure is 512kb PRG + 256kb CHR so you'd expect a very huge game, but no it's for example smaller than SMB3 which is "only" 256kb PRG + 128kb CHR.
I think it'd be cool to build up some algorithm which could measure the ROM efficiency of a game, taking in consideration the amount of levels, size of levels, amount of tileset, amount of musical tracks etc...
Any ideas ?
Also, I doubt anyone would spend a lot of time working on this, because it doesn't really bring any sort of advantage. Game A uses ROM more efficiently than game B, so what? There's nothing useful you can do with that information. I'm pretty sure people would rather spend their time working on things that actually contribute to the development of new games.
I have learned a lot by looking at the data formats for SMB1, Zelda 1 and Metroid. Mainly I learned that those sorts of extreme application-specific data compression just isn't worth it for my projects. I am not trying to squeeze onto a 32 KB ROM chip or an FDS disk. I still use compression, but it's not as insane as Zelda 1's.
If you've played a game (meaning you know how long it is) and you've looked at the sizes of its ROMs, it should be obvious whether it's using the space efficiently or not, enough for one to decide if a game is worth studying or not. I fail to see any significant advantages a tool that analyzes games could provide.
SMB1 on the other hand uses every byte of it's ROM, and even stores some data (such as the title screen layout) in CHR-ROM and reads it via the PPU.
I was speaking about some formula that would involve one person analyzing a NES game, the number of levels it have and the size of the levels, the amount of graphics it uses, and the amount of different songs, and produce some "magical number" out of those number.
Then this number divided by the ROM size would become the efficiency factor. Of course this involve exploring the game completely and it time consuming so I'd never have plans to do this alorithm for all games, just some well known games.
Maybe if entiere PRG banks in the game are unused this should be taken in account but otherwise this would just be an indication of how efficient the game is, nothing more. (so if the game don't use all it's ROM it will just loose some points of efficiency which is perfectly logical because the developers could have added levels to fit all the ROM).
About Zelda this is a bad exemple as the original was a FDS game. I suspect that FDS ports don't use efficiently their ROM. This "test" could confirm or reject this hypothesis...
The test would really be something simple like :
N = a*#of levels*size of level + b*#of tunes + c*#of graphics
efficiency = N / Rom size
Of course the constants and units to measure actually the amount of levels/graphics would be complicated
Kirby also has a lot more unique graphics than SMB3, and possibly less scrolling constraints (e.g. no 2-screen-tall level limit) that impact how it can compress levels. SMB1 is efficient, but it's also very repetitive and constrained.Bregalad wrote:For example Kirby's Adventure is 512kb PRG + 256kb CHR so you'd expect a very huge game, but no it's for example smaller than SMB3 which is "only" 256kb PRG + 128kb CHR.
Because they probably compressed the data in the same way that the FDS version did. An FDS game doesn't have access to all its data at once; it has to spin up the tape every time it wants to load a different set of files, and sometimes it even has to prompt the user to switch banks ("SET SIDE B"). And there weren't any ROM chips between 512 Kbit and 1 Mbit.qbradq wrote:I agree on the tool part, however you can't just look at the size of the ROM image either. For instance, Zelda 1 is a 128 KB ROM, but much of that space is unused. This blew me away when I read it. I thought surely a game with a compression scheme as painful as Zelda 1 needed every last byte in the ROM, otherwise why would they compress the data like that?
And lack of ROM efficiency alone isn't enough to call its developers incompetent. Failing to fill the space to an even power of two with extra levels could just mean the level designers didn't have enough time to implement and properly balance a longer game. (See Ending Fatigue and Xen Syndrome.)
FDS uses a Mitsumi Quick Disk mechanism. Quick Disk is a tape that rewinds quickly.
In my tests (running APACK on NES games for my GBA flash cartridge), Codemasters's games are the biggest 256k games, especially Cosmic Spacehead.
Code: Select all
rom size -------- fun
If the game has 0 fun (just for the sake of argument; this is not actually possible), then the ratio will be infinity, which means the chances of you caring about the game are 0, so the rom size won't matter.
If the game has a measure of 907.18 smiles per runthrough (commonly referred to as a ton of fun), then the ratio will usually be very low (almost 0), and chances are, you'll play it no matter what the rom size is.
Cool. Then I can encrypt in-game text and CHR data with a stream cipher, and I can look all efficient while tracing prototype leakers.Dwedit wrote:Compressing the file is often an easy way to tell how efficient the game data is stored.
That's because Codemasters were also Codecmasters.In my tests (running APACK on NES games for my GBA flash cartridge), Codemasters's games are the biggest 256k games, especially Cosmic Spacehead.