It is currently Tue Oct 15, 2019 10:37 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Fri May 27, 2011 9:50 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7744
Location: Chexbres, VD, Switzerland
It's a known fact the size of ROM is not a very reliable way to measure how big is a game, because some games use memory with more efficiency than others.

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 ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 9:51 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
That's ultimately subjective, but a good start would be to map the ROM using FCEUX's ROM Mapper utility. You have to play through the whole game pretty much, but it will tell you which bytes are code, which are data and which are not used.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 10:08 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11416
Location: Rio de Janeiro - Brazil
This would be a very difficult thing to automate, since each game has its own architecture. There's no easy way to tell how much of the ROM is dedicated to levels, or even how many levels there are.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 10:55 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
Learning how other games made use of their data is helpful to designing new software.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 12:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11416
Location: Rio de Janeiro - Brazil
Sure, I'm all for studying the solutions used in existing games, I just don't see the need for a tool that analyzes ROMs automatically, mainly because it would be overly complicated and probably not very accurate.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 12:40 pm 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
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?

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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 12:50 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7744
Location: Chexbres, VD, Switzerland
What tool are you talking about ? I never talked about a tool !

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

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 1:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21634
Location: NE Indiana, USA (NTSC)
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.

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.

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?

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[1] 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.

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.)


[1]FDS uses a Mitsumi Quick Disk mechanism. Quick Disk is a tape that rewinds quickly.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 4:15 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4222
Compressing the file is often an easy way to tell how efficient the game data is stored.

In my tests (running APACK on NES games for my GBA flash cartridge), Codemasters's games are the biggest 256k games, especially Cosmic Spacehead.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 4:30 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3737
Location: Indianapolis
I'm sure everyone's seen it before, but at the end of the Programming M.C. Kids article, there are data statistics for size and compression.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 5:07 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1272
I think programming efficiency should be measured as a ratio between rom size and fun. This would need to be expressed as the equation:

Code:
rom size
--------
  fun


Any of the standard measurements for fun (smiles per minute, satisfaction per achievement per minute, etc) would be acceptable.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 27, 2011 7:19 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21634
Location: NE Indiana, USA (NTSC)
Dwedit wrote:
Compressing the file is often an easy way to tell how efficient the game data is stored.

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.

Quote:
In my tests (running APACK on NES games for my GBA flash cartridge), Codemasters's games are the biggest 256k games, especially Cosmic Spacehead.

That's because Codemasters were also Codecmasters.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group