I should also add that those were figures for one particular project. The other one has its proof-of-concept levels being enormous with really huge draw distances and very few occluded polys (lots of wide-open area), loads of full-screen effects, and so one... and we stick around 40 fps on that one -- 40 on the 360, that is. PC is lucky to get 30, and they don't have a PS3 build yet.
Either GeForce 7800 cards or ATI X1900s... doesn't make much difference because we're mainly CPU-limited (occasionally bandwidth-limited) on the PC for that particular project. Animation and physics sims are among the big hogs of CPU time in these gigantic levels, and no, we don't use any middleware.As a point of reference, what GPU is that using? And is it an issue of capability or optimisation?
Either GeForce 7800 cards or ATI X1900s... doesn't make much difference because we're mainly CPU-limited (occasionally bandwidth-limited) on the PC for that particular project. Animation and physics sims are among the big hogs of CPU time in these gigantic levels, and no, we don't use any middleware.
I guess the question then becomes which CPU? And if dual core, are you using both cores either partually or fully?
Also, how do you think a quad core would effect things? Is it even possible to leverage 4 x86 cores for that kind of project?
I figure it's worth echoing what ERP said prior to anything else, but to answer your questions... It again seems to be the case with any CPU. We're not really multithreading anything on the PC, and even the extent of work we have in that respect on 360 is pretty localized to things like audio, physics, and AI. So on the PC we have hell whether it's a dual-core A64 or a single-core P4. Bear in mind that neither of these projects are likely to be out until mid-2008. In a funny way, in spite of having a very incomplete codebase for the PS3, there are already enough SPE-directed tasks to give it something of an edge over the state of code on other platforms -- even though the only SPE code we have at the moment are the really obvious candidates.I guess the question then becomes which CPU? And if dual core, are you using both cores either partually or fully?
Also, how do you think a quad core would effect things? Is it even possible to leverage 4 x86 cores for that kind of project?
The reason you end up CPU limited on PC but not on console has little to do with the raw speed of the CPU, it's largely to do with the API overhead.
ShootMyMonkey said:
Can't say I've bothered to try or even look up anybody's examples. The only DX10 tests I've even seen were all running on the reference rasterizer, so it was more than a miracle if anything ran at better than 5 fps.Does anything change to a significant degree with Vista, SMM?
I figure it's worth echoing what ERP said prior to anything else, but to answer your questions... It again seems to be the case with any CPU. We're not really multithreading anything on the PC, and even the extent of work we have in that respect on 360 is pretty localized to things like audio, physics, and AI. So on the PC we have hell whether it's a dual-core A64 or a single-core P4. Bear in mind that neither of these projects are likely to be out until mid-2008. In a funny way, in spite of having a very incomplete codebase for the PS3, there are already enough SPE-directed tasks to give it something of an edge over the state of code on other platforms -- even though the only SPE code we have at the moment are the really obvious candidates.
Assuming that we can ultimately get around to making more cores fly on the 360 and PS3, and we follow in kind on the PC, you can theoretically see a benefit over 4 or 6 or 8 cores, but I can't say it'll be terrific or horrific... We'll cross that bridge when we come to it.
Though there are definitely cases where raw CPU power just for our end of the code is a problem on the PC but not on the consoles, but they come down mainly to just throwing a lot of activity into a scene.
Does anything change to a significant degree with Vista, SMM?
To understand you correctly, does that mean a ~28.1MB backbuffer (720p 4xMSAA 32bit and Z) is then resolved to ~3.5MB frontbuffer (or smaller for 24bit?) that is used as the framebuffer displayed on screen?
How much memory would a 720p 4xMSAA and Z take in terms of backbuffer and frontbuffer on Xenos? I imagine this would need to be heavily tiled?
Yeah, I also get the impression that because of the typical distance between the camera and the characters, which save for a few exceptions aren't that huge, it gives the impression of being high-poly since the on-screen spatial density of verts is high.But...R&C, to me, looks like it's a "relatively" average poly game. There's other things they do to make the game look very pretty, but a high vertex count, in my opinion, is not one of them, nor does it have to be for that type of game.
Don't want to be anal..but what's the difference between giving the impression of being high poly and being high poly for real? It seems like the latter is considered to be smarter/cooler..when it should be the other way around.Yeah, I also get the impression that because of the typical distance between the camera and the characters, which save for a few exceptions aren't that huge, it gives the impression of being high-poly since the on-screen spatial density of verts is high.