Extremely large executables?

Started by
5 comments, last by 21st Century Moose 11 years, 10 months ago
Hey everyone, I've noticed that many AAA games have extremely large executables, up to 60-120 mb. I was wondering if the codebase is so large that it actually takes that much (seems extremely large?), or is it because of embedded resources (why not use external ones that are loaded?), or is it part of DRM?

Cheers!
Advertisement
If you're really interested, grab one of the many PE format viewers/analyzer and have a look.

I suspect it's due to embedded resources, because code itself isn't very big, once you've stripped the debug info.

DRM shouldn't change the size of the executable at all, besides the code/keys/signatures that might need to be added, but these are tiny.

Why resources are embedded rather than loaded "externally" can have a lot of reasons. Maybe something should be hidden from plain sight, or it might speed up start up (since the executable gets the benefits of prefetching on Windows), or it's just convenient.

There's also a thing called "fat executable", where multiple versions of the same executable are embedded within one file, to conveniently (for the user) ship multiple versions (i.e. 32 and 64 Bit Versions, SSE higher vs. SSE lesser,...). Mac OS uses that a lot, not sure about Windows.

Why does it matter to you?
Thanks for a quick reply.

I'm just curious, being a newbie at game programming there are many concepts that are very different from other programming. I was just wondering what causes those huge file sizes, if it is something I can apply to my own projects.
A good chunk of it's embedded resources, but for a fair number of games there's legitimately enough code to crank out 20-30MB of that executable easily.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]


Thanks for a quick reply.

I'm just curious, being a newbie at game programming there are many concepts that are very different from other programming. I was just wondering what causes those huge file sizes, if it is something I can apply to my own projects.


I think the size of the executable is the last thing you should worry about! ;)

Also, know that there are things like UPX (http://upx.sourceforge.net/) that can dramatically shrink the perceived size of executables.
Some people use it, some people don't.
Some people prefer DLLs, some people link everything statically.
Some people use a lot of templates, some people prefer uhm, whatever the opposite to that is called.
Some people like embedded resources, some don't.
And so on....

Ultimately, it's a matter of taste!

Hey everyone, I've noticed that many AAA games have extremely large executables, up to 60-120 mb. I was wondering if the codebase is so large that it actually takes that much (seems extremely large?), or is it because of embedded resources (why not use external ones that are loaded?), or is it part of DRM?

For us a good chunk of it is comprehensive libraries.

Our corporate networking libraries add about 8 MB to the executable. But that 8MB includes all the NAT punchthrough stuff, lobby stuff, P2P or partial mesh networking infrastructure, dynamic reconnect and host migration, mixed reliable/delta UDP, VoIP, encrypted billing access, and much more.

They are one of the biggest benefits of corporate packages.

The downside is that you get an 8MB networking package that few people on the team really understand. The good side is that you get an 8MB networking package that does everything from nat puchthrough to behind-your-back reconnect to practically wiping your nose after you sneeze, and you get it all for no additional cost.


This is true for all the different corporate libraries. The physics library adds another several megabytes; it is more than just crunching numbers, it includes visualizers and debuggers and logging and many other tools that are available in final builds. Repeat again for comprehensive rendering libraries, comprehensive animation libraries, comprehensive audio libraries, comprehensive movie libraries, and other major systems. The size adds up quickly, but the benefits at creating immense games quickly also add up in everyone's favor.
Another huge advantage of static linking is that you get all of your userbase on a known, common version of your libraries. If you've linked with version 1.0 of libfoo, and have run a comprehensive series of tests with it, then you want to be certain that is the version that everybody is using. You don't want to release and find out that it crashes for the 40% of users who have other versions...

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

This topic is closed to new replies.

Advertisement