L.A. Noire - Not so exclusive? PS3/PC? Too big for DVD9?

[shams]

iclim4 said:

... 

Mono audio? even ps1 titles had stereo sound. i would hate it if they went mono, i dont really care about 7.1 or 5.1 though, but i think mono is way to low a quality for sound.

also, correct me if im wrong, but doesnt compression make your processor work extra hard and if you compress it enough, it would take a really long time for a processor to uncompress the data which would actually add more load times, frame rate drops and other issues.

 

@Mono audio:

It really depends on the sound. If you think about it, most "in-game" sounds are all point sounds - generated from a single point in 3D. The CPU is then used to dynamically work out the stereo, panning, etc (more complex for 7.1, etc) - based on either the camera position, or the position of the player. But the original sound data itself is all mono. I was doing this back on the PS1 - its not a very hard thing to do.

The exception I guess is for things like FMV cutscenes. 

So its not about more space at all - its about better code to generate dynamic sound.

 

@Compression:

Yes - you do work your CPU harder. But in most cases, CPU is *almost* idle when loading. Its pointless to have your IO at 100% utilisation and CPU at 5%. Not smart.

...

Even when streaming - the biggest factors are average seek time, and data read rates. The better the read rates, the less time it takes to load something - meaning less popup, and the faster you can "navigate" through a city that uses streaming (directly affects the top speed you can drive at for example).

Compression can effectively increase your read rate by a factor of 3..10x (depending what you are streaming).

And whereas code can be optimised (including decompression algorithms - rewritten in assembler, etc) - drive read rate is basically fixed. Its not something you can tweak.

(seek times can be tweaked, by reorganising the location that certain data blocks reside on the disc itself - but thats a different issue). 

There are other issues as well - including drive noise, drive wear (the more you read, the more you wear the drive out), etc. 

Another more technical issue is this: depending on exactly how the loading occurs, it will require CPU usage anyway (i.e. it could use DMA access, syncronised reading from the bus, coping blocks from a drive memory buffer, etc..).

So its sort of odd - but in some cases its possible that reading/decompressing data can actually take less CPU. This has actually been the case in some of my projects in the past. And as CPU cycles are much faster than IO cycles - you can cut down on loading times by 80%-90% in some cases.

(hope that helps... :>)