Render resolutions of 6th gen consoles - PS2 couldn't render more than 224 lines? *spawn
- Thread starter sheathx013
- Start date
davis.anthony
Veteran
That would have actually been a poor idea, due to how it works architecturally it would be better to give it more main RAM.
davis.anthony
Veteran
It did, but it also had double the main RAM at 64MB.
davis.anthony
Veteran
No, clock speeds were at PS2 level, which would make sense if you ever planned to port games to PS2.
PS2 can render at and output at any reasonable resolution.
There’s is some constraints WRT the depth of the buffers matching, but not a huge deal.
The ca. 1 MB of space left over for textures is more than enough.
With ideal texture management the texture budget for a single frame, should never be over the frames size.
With a bit less than ideal (realistic) management with depth overdraw and loading some textures, that’s outside the view frustum, we should still be be well within what be the EE to GS bandwidth can handle.
1200 MBps / 60fps / let’s say half the bandwidth for geometry / and half the that number again for realistic redundancy = 5 MB.
So it would be very doable by that number alone to only use 32 bit textures uncompressed from main mem by the IPU per frame.
Problem was like simple origami, twofold:
- Developer resources. The above assumes geometry tailored to the GS, both baked in and dynamic.
That takes effort and learning/trial and error. And that effort doesn’t translate to multiplatform games.
The five year span of a generation wasn’t enough to warrant that.
It’s quite a different thing with the old 8 bit and 16 bit platforms that would have commercial lives of more that ten years often.
Kutaragi tried to continue the ideas with the PS3 but was halted for some reason.
- GS (and EE) doesn’t really have a good build in scheme for reducing the MIP levels with inclination of the texture. That means a lot of wasted effort with drawing invisible texels.
This has to be managed manually but tagging individual polygons/planes or objects once their angle to towards the camera starts to become sharply oblique.
Better LoD detail schemes in engines in general would have helped heaps on PS2.
There’s is some constraints WRT the depth of the buffers matching, but not a huge deal.
The ca. 1 MB of space left over for textures is more than enough.
With ideal texture management the texture budget for a single frame, should never be over the frames size.
With a bit less than ideal (realistic) management with depth overdraw and loading some textures, that’s outside the view frustum, we should still be be well within what be the EE to GS bandwidth can handle.
1200 MBps / 60fps / let’s say half the bandwidth for geometry / and half the that number again for realistic redundancy = 5 MB.
So it would be very doable by that number alone to only use 32 bit textures uncompressed from main mem by the IPU per frame.
Problem was like simple origami, twofold:
- Developer resources. The above assumes geometry tailored to the GS, both baked in and dynamic.
That takes effort and learning/trial and error. And that effort doesn’t translate to multiplatform games.
The five year span of a generation wasn’t enough to warrant that.
It’s quite a different thing with the old 8 bit and 16 bit platforms that would have commercial lives of more that ten years often.
Kutaragi tried to continue the ideas with the PS3 but was halted for some reason.
- GS (and EE) doesn’t really have a good build in scheme for reducing the MIP levels with inclination of the texture. That means a lot of wasted effort with drawing invisible texels.
This has to be managed manually but tagging individual polygons/planes or objects once their angle to towards the camera starts to become sharply oblique.
Better LoD detail schemes in engines in general would have helped heaps on PS2.
It would've been rad to have two vector units directly tied to the GS while keeping one properly tied up to the MIPS core. Being able to pre-feed VU0 into VU1 was probably unnecessary and would've been better positioned to assist the MIPS core in physics and "emotion synthesis".
davis.anthony
Veteran
What would have made a measurable difference for not a lot of messing around with the design would be to simply give VU0 the same 16Kb as VU1 has.
The 8Kb is has is too small and part of the reason why it saw very little use.
The 8Kb is has is too small and part of the reason why it saw very little use.
Last edited:
It’s good for procedural geometry, various kinds of culling, physics, simple modifier volumes, particles, inclination of geometry WRT camera to select appropriate MIP level etc.
It has indirect access to the 16 KB scratchpad too.
If it wasn’t used, I’d lay most blame on the devs. Their fear of the game and techniques not being transferable and their reluctance to try new stuff.
Perhaps VU1 was too good? It made using the VU0 feel redundant.
davis.anthony
Veteran
There were plenty of things developers wanted to do with it, they just couldn't get them in to it's small 8KB of memory.
The stuff I mentioned, takes up very little data. The code is the same for many instances of the same transform or hit detection.
davis.anthony
Veteran
There have numerous developers post in this very forum stating it didn't have enough memory to be useful.
The stuff I mentioned, takes up very little data. The code is the same for many instances of the same transform or hit detection.
4 KB is plenty for procedural code, a simple instanced model, a light frustum or rough culling volumes.
Would you even notice the difference of 448 lines compared to 480 lines on a CRT?
I mean it is basically the same image, but 16 pixels on top and bottom are left blank.
Which is only 6% less, so not a big deal.
And those 16 lines would perhaps not be seen due to TV overscan, I could imagine?
What do you think?
I mean it is basically the same image, but 16 pixels on top and bottom are left blank.
Which is only 6% less, so not a big deal.
And those 16 lines would perhaps not be seen due to TV overscan, I could imagine?
What do you think?
Definitely noticeable on a PAL tv as it changed the size of the black bars top and bottom, though without a proper PAL conversion a game made for NTSC would would still look squished.
PAL games used to run slower, have black bars top and bottom, and look a bit like someone was running old tv show stretched across a widescreen tv. First machine to get good PAL conversions was the Saturn, DC took it up a notch with some very good PAL conversions and a software selectable PAL 60 mode for quite a few games (and VGA support for many games, though the PAL conversion sometimes killed VGA support here in Europeland).
Yeah but that is a different story, is it? Those additional black bars would appear because the PAL video mode equivalent of those 448 lines would be 512 lines. But if you only use 448 lines out of those 512, you end up with only 448 lines out of the 576 lines of a PAL-TV and you would definitely see the bars.
But my guess was, that in NTSC-mode with 448 lines (or a properly done PAL-conversion with 512 actively used lines) the bars at least would be appear relatively small due to the CRT TV overscan hiding much, if not all of it.
Yeah that's the case. 448 lines NTSC (or PAL 60) does more or less cover the full vertical height of the tv.
Old consoles used the overscan time to send data to vram or to change things like the contents of the colour ram. If you can make the overscan areas visible you can sometimes see coloured pixels that are a side effect of changing things like the colour palette.
Ah OK!
I did not remember exactly to be honest, so I was just guessing.
Back then, I was too young to notice such things.
Legend has it that there is a digitalized image of Dan Forden hiding in the overscan area of some games, which could jump into the visible area at any minute and shout "toasty" or something...