D vs. C#

[Nathan Reed]

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