You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Render resolutions of 6th gen consoles - PS2 couldn't render more than 224 lines? *spawn
- Thread starter sheathx013
- Start date
davis.anthony
Veteran
When looking back in retrospect one design decision I'd make with the PS2 is to either give 8 or 16 MB of edram instead of 4.
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
Namco System 256 apparently had 8MB of eDRAM.
It did, but it also had double the main RAM at 64MB.
davis.anthony
Veteran
Oh, that's interesting. Did they increase EE clock speed aswell?
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".When looking back in retrospect one design decision I'd make with the PS2 is to either give 8 or 16 MB of edram instead of 4. I'm sure they could have designed it given the graphics chip in gscube has 32.
Maybe ditch VUO for another VU1.
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.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.
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
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.
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.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.
davis.anthony
Veteran
The stuff I mentioned, takes up very little data. The code is the same for many instances of the same transform or hit detection.
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.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.
4 KB is plenty for procedural code, a simple instanced model, a light frustum or rough culling volumes.
Similar threads
- Replies
- 32
- Views
- 9K
- Replies
- 19
- Views
- 6K
- Replies
- 98
- Views
- 34K
- Replies
- 224
- Views
- 30K