D vs. C#

[Bruce Adams]

Nathan Reed Wrote:

> Bruce Adams wrote:
> > Bill Baxter Wrote:
> > 
> >> Bruce Adams wrote:
> >>> An interpreter itself is relatively small. I can only assume that a
> >>> lot of the bloat is down to bad coding. If you look at games these
> >>> days they weigh in at a ridiculous 4Gb install. No amount of
> >>> uncompressed data for performance gain excuses that. 
> >> It's not the code that makes modern games eat up 4Gb of space, it's the 
> >> textures, animations, 3D models, audio, video cut scenes, etc.  The code 
> >> is a pretty small part of that.
> >>
> >> --bb
> > 
> > That's partly my point. A lot of that could be achieved programmatically or with better compression. You get map and model files (effectively data structures representing maps and model) that are huge and hugely inefficient with it, describing low level details with little or no abstraction. E.g. a pyramid might made of points rather than recognising a pyramid as an abstraction. Some bright sparks have decided to use XML as their data format. Its only a little bigger and only takes a little extra time to parse. This costs little on a modern machine but can hardly be considered compact and efficient.
> > 
> 
> Map and model file formats for most modern games that I know of *do* 
> provide a way to factor out common geometry elements, so you only store 
> one copy of the geometry for a streetlight (say) rather than repeating 
> it for every streetlight in the game world.  Even so, a modern game 
> involves a hell of a lot of content.  That's just the way it is.
> 
> I'm not sure how compressed that data is on the hard drive.  It's 
> possible that they could shrink the data significantly with more 
> attention to compression.  However, that probably adversely impacts 
> level loading times which are already long enough (I was playing the 
> latest installment of Half-Life the other day, and seeing approx. 20-30 
> second load times).  Despite your opinion about uncompressed data for 
> performance's sake, a lot of gamers *would* rather the game take up 4GB 
> of space than add to the load times.
> 
> Thanks,
> Nathan Reed

Don't get hung up on the geometry example. My example generator is broken. It is my contention that both the performance and compactness can be improved given the time and effort.
I imagine it varies a lot from shop to shop but typically from what I hear they are working to tight deadlines with poor processes. Hopefully they still at least use the rule "get it right, then get it fast" but they miss off the "then get small" at the end.
The huge install sizes and huge patches to supposedly "complete" games are one result of this. Battlefield 2 is painful slow to load each tiny level and yet still has a 4Gb install.
Its almost a part of the package now. If someone realised a game that only needed a CD and not a DVD a lot of people would (wrongly) assume it was less feature rich than the DVD version. 
Take a look at a good shareware game and you see more of the full craft at work parly because download sizes are restrictive (though less so than they were).