Correct, you would still have to wait for them to be generated. Even on very fast hardware this takes time and it would take an age to render a PGR4 track. Maybe on Cell2 but not this generation.It's a lot more than slightly more. I don't recall what's public domain but if you follow places like Beyond3D you get a pretty good picture from the cross-platform devs. Several are on record as saying the 360 has a ton more memory to work with, plus the Unified nature of the architecture allows you to be flexible with what you have.

It's something Sony work hard on but an area they will always be playing catch up in. MS make operating systems for computer hardware for a living!

Obviously you missed my method and point.

Point: Consoles are about compromise in design (i.e. where the power is). This isn't Xbox 360 versus PS3, but, "All consoles make compromises and argueing that because 1 game hits a limit that a limitation was the incorrect decision is hasty if not considered in the context of all design decisions, limitations, and market factors".

Method: Take your example, word for word, and demonstrate in a different scenario (different game, different performance vector) that your criticism can be completely flip flopped.

The other point was your point was very tunnel vision oriented to the issues and a lot of your statements are inaccurate.If you call over 50MB -- 10% -- slightly more. But it is more than just the OS. The Xbox 360 has eDRAM for back buffers, so the framebuffer is tiled to system memory for output. Your 720p image on the front buffer side is about 3.5MB. On the PS3 a 720p framebuffer is over 30MB, and 1080p (and 1080i at times) is over 60MB.

Now we are creeping in the territory of 80MB difference. So 15% isn't too bad, right? Considering you may have a couple hundred MBs in functional code and sound the percentage rises. So 80MB for OS, 30MB for the framebuffer, 100MBs for audio, 50MB for game related code, that leaves you about 260MB for graphic assets (various geometry and texture formats). On the Xbox 360 you are looking at 340MB -- that is a 30% difference in resources allocated for graphical assets.

Hence more than one multiplatform developer has bitched about the memory situation on the PS3. That and the split memory pools, that take more management, have performance gotchas and limitations, and more bandwidth restrictions to mitigate and balance.And have the 8 VS on RSX sit idle and do nothing?

And use your SPEs for graphic tasks instead of running game code?

Sounds like a lose-lose situation. You are leaving performant silicon on RSX idle and using the CPU for core graphic tasks when they are needed to do the stuff that makes games fun, engaging, and deep.RSX could always access R (20GB/s read, 15GB/s write over FlexIO). It isn't overly complicated and a lot of games have done it since launch. The problem is there are some performance issues. e.g. R has 25GB/s of bandwidth and with RSX you can texture (read) from R at 20GB/s (15.5GB/s realworld). Wow, 15.5GB/s of additional graphic bandwidth in addition to the 20GB/s of system memory... but here is a gotcha: In addition to only accessing 15 of the 25GB/s of system bandwidth, texturing from R also incurrs a latency penalty, i.e. it can slow you down.

Oh, and you just sucked up the majority of your system memory bandwidth (and footprint) from CELL."only memory limtiation" is pretty inaccurate as I have shown. You have limitations to bandwidth, footprint, and resource management (split memory pools).

So, lets return to my point:

"All consoles make compromises and argueing that because 1 game hits a limit that a limitation was the incorrect decision is hasty if not considered in the context of all design decisions, limitations, and market factors".

By your reasoning, that no HD optical media was a poor design and market decision because a game has hit a store limition, the same logical conclusion can be drawn that the PS3 has been limited in many, many games in regards to system memory.

If no HD optical was a mistake in the Xbox 360, then memory limitations in the PS3 was a mistake by Sony.

The issue isn't so clear now, is it?Wrong. As mentioned before, a game like GTA will be using more dynamic lighting and shadowing solutions due to its use of dynamic day cycle. This means less precomputed solutions (static shadow maps, light maps, maybe even fewer prebaked texture passes like AO maps, etc).

Further, GTA:SA was under 1.5GB. Sandbox games do not tend to be huge, contrary to popular opinion.

So you have put forth a conslusion, DVD9 limitations holding back the scale of GTAIV, and haven't done anything at all to substantiate this position. The current crop of sandbox games with realtime day cycles indicate this hasn't been an issue.Not totally. Games use what is present. A lot of games have, "If HDD present, then cache; if no HDD, no cache". Users without HDDs get longer load times. The Xbox worked in a similar way.All games have compromises. 1 game out of 200+ hit this specific limitation, so it is now a significant issue?

What of all the other design and performance issues that crop more often?

Where is the priority? Why? How does this affect cost and reasonable market penetration?Like almost all current games :|

It is statements like this that resulted in my tongue and cheek response. Truly the reverse is true, "There will always be a few games that cannot fit on DVD9..." in which case you can either span disks, cache to the HDD, or in a few cases the user will get reduced asset quality (sound, textures, mech complexity) or the developer will need to impliment unique solutions that are system specific like procedural generation.

Making a big deal out of a rare occurance -- when far more weightier issues affects many [most!] games -- and looks at the issue very narrowly (i.e. HD optical not available, limited production in 2006, HUGE expense) seems like special pleading.

See, you are good for something Inflatable ;) You can be my bulletpoint man! :P

Interestingly, there are always all kinds of tradeoffs based on design. There are cases where the PS3 memory architecture could be an advantage. But then again there are cases where DVD9 can be an advantage.

Getting bent out of shape because a developer had to mitigate a limitation isn't really a big deal unless it becomes a significant bottleneck to design and is a recurring issue without remedy.

Consoles are a lot about exploiting what you have and making the most of it and leveraging the closed design and absolute consistant performance threshholds to your advantage.

This seems like a pretty stable discussion so far, let's not rock the boat :P

Yes and No. You could generate them on demand, over and over again, and depending on the limitations of the hardware they could be done possibly with the quad or pixel you are working on or could be generated and written to memory and then called [and then destroyed]. OR you could just do them at "level load time" and start your procedural generation application and generate your procedural textures and store them into memory.

There are a lot of ways you can do procedural textures--everything from the artist design stages for generating base content to later be altered and packaged down to runtime on demand.Nope.

Displacement mapping is the technique of using textures to generate geometry (of which a tesselation unit is very helpful in doing single pass displacement).

Parallax mapping, or as Epic calls it virtual displacement mapping, is pixel shading intensive, not vertex. It is essentially a progression of bump mapping; in Parallax Mapping the effect is create "parallax" ie the sense of depth through the forground and background shifting independantly based upon the point of view and angle of the observer. There is no geometry created -- hence POM fails when you get flush with the real geometry (e.g. a brick wall using POM for the grouting looks real until you get flush, in whichc ase all the depth is lost and you see a flat wall). POM doesn't require a tesselation unit either; see RSX's use of parallax mapping in games like Motorstorm.

You have no clue what you are talking about.Both of these statements are incorrect and your followup obfuscates your original statements with even more foggy information.

Parallax Mapping is not pixel shader light / vertex shader heavy, and it doesn't require a tesselation unit.Unified shaders is hardware resource model to adapting [essentially] math units [shaders] for a broader range of computations; current shader models still make clear distinctions between pixel shader code, vertex shader code, and geometry shader code.

Unified shaders is a hardware implimentation that has not obscured the distinction between vertex and pixel processing (or ROP processing either) in the way you are suggesting.

Virtex shading deals with vertices (geometry) and pixel shading deals with pixels. Vertex shaders can use textures (vertex shading, R2VB) to augment real geometry; pixel shaders can use textures (various bump maps like normals and parallax maps) to augment pixels to appear to represent geometry -- hence drawing flush to geometry with a parallax map will clearly show the geometry hasn't been altered.

Edit: Wiki is your friend (as it seems you don't believe me).

http://en.wikipedia.org/wiki/Displacement_mappinghttp://en.wikipedia.org/wiki/Parallax_mapping

Yup, beautiful! I'd say that's good enough, when it comes to different lighting conditions, although I would have preferred to see the difference extend to night and day. Still, stunning visuals!