Its limit was available VRAM. An old discussion here with all the old devs.
And it used the same principle as PS2:
I know bugger all about the ps2 but we had palletized textures on the pc but they were 256 colour palletized you sure it wasnt the same on ps2 16 seems a little low
Of course. This line of discussion came from someone asserting that DC could render GA at a higher res than PS2 though, not the other way around. Given DC can run GTA better than PS2 res, what res was PS2? Was it only 480x224 because that was the highest resolution the hardware could manage? No, turns out PS2 can handle higher resolution rendering. Okay, so GTA could be any resolution and 480x224 is not the target for DC to know it can surpass PS2 GTA rendering. Does that mean DC cannot surpass PS2? No, we'll have to wait and see.
16 colour CLUT, but you could layer textures in passes. Sometimes people struggle to understand just how different PS2 was!
0 fps. It's not drawing 240 unique lines every 60th of a second, but 480 lines every 30th. Ergo, it's rendering '480p30'. Or whatever res it is, it's 'xxxp30', not 'xxxi60'. If looking at a 60 Hz game, then 480i60 is half the render res of 480p60, but the moment you get to 30 fps output, there's no difference, rendering 640x480 pixels in one frame, one 30th of a second.Actually we don't need evidence it can render above 640x448 internally because the claim was that it could only do 448 interlaced or 224 lines progressive. So just a game with an internal frame buffer of 640x448 would disprove this claim. There's quite a few games that do this including Soul Calibur 2, Shadow the Hedgehog, Sonic Unleashed, etc. Assuming PCSX2's "Take screenshot at internal rendering resolution" option is accurate.
Yeah, I already used that one on the following post with BG: DA. If anyone has GTA on PCSX2, we can get a render target.
Again assuming this is accurate, it's 640x448 in game, 640x480 during the opening logo screens:
Coming back to this comment, are you saying rendering in pieces and putting them together isn't how other 3D hardware works?
I dont think I've ever read about another renderer that puts polygons on top of polygons, or renders multiple frame buffers and combines them for one frame in a game.
XB360 rendered in tiles, two for 720p and three for 1080p. Furthermore, PVR in DC is a tile based deferred renderer meaning it takes the notion of rendering the scene piece-by-piece to a whole other level!
That's a whole frame immediate renderer. XB360 was a tiled immediate renderer, very good at that but not so great at deferred rendering. There are lots of alternative approaches. Current tech is kind of a mix between PS2 and OXB et al. You can render in one pass geometry with multiple materials and lighting, but then you renderer multiple buffers and combine them. Indeed GPUs were evolved to allow multiple render targets, not just a 'back buffer'. PS2's use of overdraw is unique as having limited rendering per triangle and using massive overdraw to solve rendering features, but it's just one member of a spectrum of hardware solutions.
Correct. For what it's worth Soul Calibur 2 renders at a resolution of 640x448 at 60fps.
What?
What? It's tile based rendering, not upscaling. At 720p XB360 renders 1280x720 pixels per frame.
Those discussions basically started here on B3D with pixel counting. Leadbetter had perfect video capture tech which could record uncompressed output, and he engaged the board to develop a methodology to count pixels and determine internal render resolutions (and count individual frames to establish framerate) - thus Digital Foundry was born. Upscaling and later reconstruction techniques allowed devs to get more complexity per pixel at a reduction in visual fidelity, and pixel counting allowed us to see what tradeoffs were happening.
There's nothing particularly special about tile based rendering (or even multipass rendering) on other platforms and it produces exactly the same results with a nominal overhead over rendering to a single buffer when triangles overlap the edges. Tile-based rendering doesn't reduce the number pixels or upscale or soften the image, it doesn't add lag, and it doesn't compromise the output in any way. It's just an alternative approach, rendering pixels to make use of very-fast-but-expensive-so-smaller-pool DRAM for situations where that's advantageous.
That's essentially how Xenos works, right? The EDRAM is, essentially, just like the tile buffer in that it has lots of bandwidth and writing into that super fast buffer, then transferring the finished result into off chip memory before output. And it didn't require any special programming, unless I'm totally understanding what happens if you exceed the EDRAM's capacity. The main difference is that Xenos has enough EDRAM to potentially render the scene in 1 tile.
