PSP probable Pixel Format: 24 bits RGBA=5:R, 5:G, 5:B, 8:A ?

[Panajev2001a]

- 24bit Full Color: RGBA"

This was from the "Specs" available on the net...

Uhm... I "think" know what they are doing... pretty clever, considering this is a handheld... I suspect they will have single cycle multi-texturing to reduce low precision artifacts related to the dithering you would have to do with lots of multiple rendering passes while multi-texturing.

Still it is more than possible that on chip they can do 32 bits RGBA color calculations and that would be dithered to 24 bits RGBA when rendering to the back buffer.

Their pixel format seems to be this:

8 bits for the alpha channel ( finally... you do not know the liberation that using polygons with texture mapped sprites on them [doing 2D with 3D technology] will be for some coders... no more limits on blending... sprites being easily alpha blended with each other [GBA does not do Hardware blending between sprites... the Saturn did not do it either and that is why you had lakc of real transparencies in most aturn games] ).

5 bits for Red

5 bits for Green

5 bits for Blue

Yes, it adds up to 15 bits for color, they just would not use the 16th bit ( bit #15 ) like the GBA does... but in addition to the 15 bits RGB mode the GBA uses ( not for sprites, those are 8 bits palletized ones, but for Bitmapped Backgrounds ) we have 8 bits for an alpha channel

YEAH

I mean.. ahem...

 

[akira888]

Although I could easily be wrong, I believe NGCube has a 6:6:6:6 format for its main color mode. That to me seems more "balanced" than 5:5:5:8, but then again on the LCD they are using perhaps that's all the dynamic color range they might need, so they might go with that.

 

[marconelly!]

Pana, on such a tiny LCD screen you don't really have to worry much about color banding/artifacting. I mean, MGS2 uses 24 bit color buffer, has multitexturing, *no dithering* and you only can see color banding in the extreme low contrast gradient situations. Again, I don't think dithering would be a good idea on an LCD screen (because no color bleeding = you can easily see dither patterns) but that depends on resolution / screen size (basically the pixel size)

 

[Panajev2001a]

I think that on an LCD 15 bits RGB would look pretty good to me, especially if on-chip they can use higher precision ( the GS uses internal 32 bits precision regardless of the back-buffer precision ).

The good thing about this ( I think they will allow several pixel formats and R:6 G:6 B:6 A:6 might also be available ) is that you have a full-precision alpha channel whcih could make it easier to port software from PlayStation 2, given the software uses it

 

[Panajev2001a]

Pana, on such a tiny LCD screen you don't really have to worry much about color banding/artifacting. I mean, MGS2 uses 24 bit color buffer, has multitexturing, *no dithering* and you only can see color banding in the extreme low contrast gradient situations. Again, I don't think dithering would be a good idea on an LCD screen (because no color bleeding = you can easily see dither patterns) but that depends on resolution / screen size (basically the pixel size)

Still internally the GS does 32 bits calculations and that helps... if the PSP does that too they HAVE to do dithering to produce the back-buffer output...

24 bits back-buffer AND 24 bits on chip calculations might produce quite of artifacts unless they do allow single cycle multi-texturing via loop-back and I see no indication in their specs they want to go the multi-pass rendering route...

32 bits internal == 24 bits color + 8 bits alpha

24 bits internal == 15-18 bits color + 6-8 bits alpha

That does make a difference... will it be very visible ? Maybe not...

Hopefully not, color banding can look pretty ugly... especially when you are using lots of fill-rate doing lots of alpha-blending and multi-texturing in your scene...

I'd rather have a better balance between dither patterns and color banding rather than not wanting dither patterns at all and say hello to color banding...

Plus it is not like you are dithering from 24 bits color to 8 bits color

I understand the fact that a CRT will have more color bleeding that hides the dithering and why on my fiancee and I TV ( the Samsung HDTV ) a lot of games ( especially PSOne games ) seem more dithered than usual ( comparing it to what happened on our older TV )

 

[Fafalada]

Calculations on chip aren't "pixel format" Pana
On that note, as far as actual pixel format goes I expect selectable 8:8:8/6:6:6:6, depending on application needs.

Anyway even in regards to internal precision of rasterizer I see no reason to give precedence to alpha precision at expense of degraded color. I am too lazy to work it out in my head (or run an actual test) but off the top of my head I would argue that your format would almost always look worse then 6:6:6:6.
Besides, I'm willing to bet it's 32bit internal anyhow. 8)

 

[Panajev2001a]

Calculations on chip aren't "pixel format" Pana

Sorry, I am allowd one brain fart per day

On that note, as far as actual pixel format goes I expect selectable 8:8:8/6:6:6:6, depending on application needs.

Anyway even in regards to internal precision of rasterizer I see no reason to give precedence to alpha precision at expense of degraded color. I am too lazy to work it out in my head (or run an actual test) but off the top of my head I would argue that your format would almost always look worse then 6:6:6:6.
Besides, I'm willing to bet it's 32bit internal anyhow. 8)

You mean 8:8:8 without ANY alpha channel in the back-buffer ?
I am not really sure that it would be ideal for most 3D games, but it is also 3 A.M. and I should not speak or write right now

I think you do make sense with R:6 G:6 B:6 A:6 as we only lose two bits in the alpha channel ( we still have it, good for applications that se the alpha-channel for transparencies or other tricks ), but we gain 3 bits over-all for color precision ( yes the math works... I was thinking about 15 bits color like the GBA does in modes 3 and 5 and it does not look that bad )...

But if your application were planning on not using the destination alpha in the back-buffer ( proposed 8:8:8 pixel format ), then why not using 5:5:5 and using those 8 bits to encode additional information, I do not know... we could use it for stencil operation ( storing the stencil information in the alpha channel ) ?

 

[Fafalada]

You mean 8:8:8 without ANY alpha channel in the back-buffer ?
I am not really sure that it would be ideal for most 3D games, but it is also 3 A.M. and I should not speak or write right now

Destination alpha (or alpha buffer) only gets major use doing complex shaders. I can still do multipass, transparencies and whatnot without ever touching destination alpha.

But if your application were planning on not using the destination alpha in the back-buffer ( proposed 8:8:8 pixel format ), then why not using 5:5:5 and using those 8 bits to encode additional information, I do not know... we could use it for stencil operation ( storing the stencil information in the alpha channel ) ?

Just means you have an application that uses destination alpha. And 6bits is more then enough for traditional stencil operations.

 

[Panajev2001a]

You mean 8:8:8 without ANY alpha channel in the back-buffer ?
I am not really sure that it would be ideal for most 3D games, but it is also 3 A.M. and I should not speak or write right now

Destination alpha (or alpha buffer) only gets major use doing complex shaders. I can still do multipass, transparencies and whatnot without ever touching destination alpha.

You are assuming the PSP's GPU will be flexible enough to do that...

I do believe it will have basic Register Combiners abilities ( yeah, DOT3 on the GPU ), but in the case it might be a bit more similar to the GS Rendering core ( not lilely, but still )... would not that be a problem as you would not have many long and complex shaders...

On PlayStation 2 you would feel really comfortable not having destination alpha in the back-buffer ?

Just a curiosity

Let's see if I get the answer: "yes, unless you need to do stencil perations or other things that do require the alpha channel"...

Correct ?

But if your application were planning on not using the destination alpha in the back-buffer ( proposed 8:8:8 pixel format ), then why not using 5:5:5 and using those 8 bits to encode additional information, I do not know... we could use it for stencil operation ( storing the stencil information in the alpha channel ) ?

Just means you have an application that uses destination alpha. And 6bits is more then enough for traditional stencil operations. [/quote]

Good to hear that... but can I expect a port of Silent Hill 3 then ?

 

[PC-Engine]

Good to hear that... but can I expect a port of Silent Hill 3 then ?

With 8MB of RAM?

 

[Panajev2001a]

12 MB... and I said a "port" and I did not mean a straight 100% port either

 

[PC-Engine]

12 MB... and I said a "port" and I did not mean a straight 100% port either

Also it's 8MB of main RAM and 2 MB of VRAM or 1/4 the amount of main RAM and 1/2 the amout of frame buffer memory of what SH3 on PS2 had access to

Also only 2.6 GFLOPS compared to 6.2 GFLOPS on PS2

 

[Fafalada]

On PlayStation 2 you would feel really comfortable not having destination alpha in the back-buffer ?

Your answer is close enough but to expand on it a little - Alpha buffer would probably be more usefull if GS supported better blend modes in the first place. As it is right now, I just don't need it particularly often - but it is good to have the choice (hence I argued switchable formats for FB).

Good to hear that... but can I expect a port of Silent Hill 3 then ?

You should ask Konami about that but on paper it sounds very possible indeed.

Also it's 8MB of main RAM and 2 MB of VRAM or half of what SH3 on PS2 had access to

And running at less then half the resolution too

 

[notAFanB]

yes it is effectively 8MB of RAM. oh and SH3 on a 4.5" screen? it loses some of it's attraction I think.

 

[PC-Engine]

And running at less then half the resolution too

Fillrate isn't going to be the problem porting SH3 to PSP

 

[Fafalada]

Fillrate isn't going to be the problem porting SH3 to PSP

Not what I argued either. But why would you use content(textures&geometry) that was optimized for resolution over 2x higher?

yes it is effectively 8MB of RAM. oh and SH3 on a 4.5" screen? it loses some of it's attraction I think.

But you could enjoy it in 7.1ch, oh yeah baby!

 

[PC-Engine]

Not what I argued either. But why would you use content(textures&geometry) that was optimized for resolution over 2x higher?

You wouldn't, but you still only have 1/4 of the main RAM of PS2 and less than 1/2 the GFLOPS.

 

[notAFanB]

Not what I argued either. But why would you use content(textures&geometry) that was optimized for resolution over 2x higher?

You wouldn't, but you still only have 1/4 of the main RAM of PS2 and less than 1/2 the GFLOPS.

just replace 'port' with 'remake' and you are good to go

 

[Panajev2001a]

You are not counting the PSPFLOPS of the Hardware Tesselator...

HOS == less memory needed for Vertex Data...

Textures would be smaller, frame-buffers will be smaller and we might not need models that are as detailed as SH 3 ones and cutting a bit on those, a bit on shadow volumes ( simplifying the extracted volume ) and all... and a port should theoretically be possible

 

[PC-Engine]

Not what I argued either. But why would you use content(textures&geometry) that was optimized for resolution over 2x higher?

You wouldn't, but you still only have 1/4 of the main RAM of PS2 and less than 1/2 the GFLOPS.

just replace 'port' with 'remake' and you are good to go

Yep, the remake would probably look more like RE:CV with realtime shadows for DC running on a 4.5" display which isn't bad and most people woudn't know the difference from SH3 on that little screen anyway.