Digital Foundry tech analysis channel at Eurogamer

[Shifty Geezer]

I think you've missed the detail again! You can have a 1 bit mask if you want it. If you want true alpha, you'll need another data source that stores the alpha data. That you have one buffer of LogLUV colour, and a second buffer of 8bit alpha values, and when alpha blending you read in both sources.

If you think about alpha, it's no different to the colour channels in requirements. If you want a range of greens in your object, you need to store a range of values in a green component. Or if you want a range of hues, you need to store a range of values for hue. The number of bits determines the range you have available. Too many are wasted, too few would cause colour banding. Alpha is likewise a range of transparencies. Too few bits, and you can only express a banded range of blends. If you consider a smoke trail, each smoke particle needs a gradual fade from opaque in the centre to transparent at the edges. If you need a range of values to express the image, then you need a range of data somewhere. 8 integer bits works well as a range, and fit very nicely the regular 32 bit formats of yesteryear. With programmable shaders we can try cleverer system (although hardware blending wants 8 integer bits), but you're still going to need several bits of data. In a 32 bit word, if you give up some of those bits for alpha, they'll be lost to the other components of your pixel data. Thus you'll need extra bits from somwhere, which requires another buffer.

 

[Crossbar]

You can do whatever you want with data! It only *has* to be converted to RGB for the GPU to render it, because that aspect is hardwired in, or whereh LogLUV fails like alpha blending.

Sure I asked because I wanted to know for what kind of work you could skip the two transformation phases which may steal time from more useful work.

Perhaps the hardwired functions of the GPU are so heavily geared towards RGB that you always want to transform to RGB? Perhaps post-processing on SPUs is more flexible towards different data formats? Are there any benefits at all to keep the LogLUV representation through any type of data processing or is it a pure storage format?

 

[liolio]

I think you've missed the detail again! You can have a 1 bit mask if you want it. If you want true alpha, you'll need another data source that stores the alpha data. That you have one buffer of LogLUV colour, and a second buffer of 8bit alpha values, and when alpha blending you read in both sources.

If you think about alpha, it's no different to the colour channels in requirements. If you want a range of greens in your object, you need to store a range of values in a green component. Or if you want a range of hues, you need to store a range of values for hue. The number of bits determines the range you have available. Too many are wasted, too few would cause colour banding. Alpha is likewise a range of transparencies. Too few bits, and you can only express a banded range of blends. If you consider a smoke trail, each smoke particle needs a gradual fade from opaque in the centre to transparent at the edges. If you need a range of values to express the image, then you need a range of data somewhere. 8 integer bits works well as a range, and fit very nicely the regular 32 bit formats of yesteryear. With programmable shaders we can try cleverer system (although hardware blending wants 8 integer bits), but you're still going to need several bits of data. In a 32 bit word, if you give up some of those bits for alpha, they'll be lost to the other components of your pixel data. Thus you'll need extra bits from somewhere, which requires another buffer.

So if 1 bit is used it could be used as a hint (opaque/transparent) if opaque you could avoid to check alpha value (wherever it is stored). That's it?

I think I may not understand how FP10 work in the 360 for instance (I'm scared that I'm going a bit out of topic between).
In the FP10 format it's R 10 bits G 10 bits B10 bits Alpha 2 bits right?
Then 2 only allow for very few values (4). So it's right to say that if FP10 is consider as "free" you indeed trade better "lightning" for worse transparencies? So its use is limited to case where few transparent objects, right?
So I'm right to think that if FP10 support alpha blending then before blending the data get translated into standard RGBA2 format, thus whereas alpha channel allows 256 values only four will be in used, right?

If you have no alpha channel where it should be and you have render transparent object then things get costly. So in fact it's right to say that neither Nao32 and FP10 are good choices if you have quiet some transparent objects too render? But in case you have few transparency it might be worse it. In the cases where FP10 makes my proposal could make sense, no? (between it's not a refutal of your post I just trying to make sure I understand this time )

To take concrete example, using FP10 could be ok for a game where the only transparent object are some glasses here and there. That still let particles, usually while using Nao32/FP10 devs render particles in ldr in a different buffer?

 

[Shifty Geezer]

Sure I asked because I wanted to know for what kind of work you could skip the two transformation phases which may steal time from more useful work.

Perhaps the hardwired functions of the GPU are so heavily geared towards RGB that you always want to transform to RGB?

Do you mean for certain calculations? You need RGB to end with on the backbuffer for output to the frontbuffer. You also need RGB to interpolate two colours as in alpha. Otherwise you can do whatever you want in terms of averaging, shifting, brightening and the glut of shader operations in LUV space.

Perhaps post-processing on SPUs is more flexible towards different data formats? Are there any benefits at all to keep the LogLUV representation through any type of data processing...

Yes, it preserves accurate brightness and hue information! That's the key benefit IMO. RGB can suffer from colour posterization in areas of high intensity. LUV doesn't have that, brightening to white more naturally.

 

[Shifty Geezer]

So if 1 bit is used it could be used as a hint (opaque/transparent) if opaque you could avoid to check alpha value (wherever it is stored). That's it?

Yes. When drawing a leaf for example, the surface is a rectangle and the GPU would draw a rectanlge. The leafy shape is defined by a texture, with the quad not drawn where the texture alpha says 'don't draw this bit of the quad'. This is achieved with a 1 bit mask.

I don't know what the added range of 2 bit alpha provides. It's not enough to use as an alpha blend, but Ithink it benefits alhpa to coverage. I'm not really the right person to ask though!

And yeah, seeing the topic title, this is OT.

 

[Crossbar]

Yes, it preserves accurate brightness and hue information! That's the key benefit IMO. RGB can suffer from colour posterization in areas of high intensity. LUV doesn't have that, brightening to white more naturally.

Thanks for the clarifications. Do these limitiations of the RGB get mitigated or totally eliminated if you choose an RGB representation with a better precision such as each channels get a 16 or even 32 bits fp representation? Or is this posterization effect inherent to the RGB format as such?

 

[grandmaster]

Our Crackdown feature gets top-billing on Eurogamer this weekend.

I like producing these original approaches to classic games. I also like the "gamebreaking" approach - setting up engine-stressing situations and seeing just how well the technology copes. Obviously a similar thing could be arranged for GTA IV, but if any one else has any other original approaches, let me know.

We're looking at Halo 3 at the moment. Assuming MS comes up with decent ODST material this week that should be a good decent feature for the next weekend EG slot.

 

[Scott_Arm]

...
I like producing these original approaches to classic games. I also like the "gamebreaking" approach - setting up engine-stressing situations and seeing just how well the technology copes. Obviously a similar thing could be arranged for GTA IV, but if any one else has any other original approaches, let me know...

GTA seems hard to stress because it will only allow x number of vehicles on screen at a time. I've tried to make car pile-ups, only to see cars disappear as new cars drive into the mix. Maybe there are other and better ways to stress the game, but blowing up a huge pile of cars seemed like the most fun.

 

[AlNom]

GTA seems hard to stress because it will only allow x number of vehicles on screen at a time. I've tried to make car pile-ups, only to see cars disappear as new cars drive into the mix. Maybe there are other and better ways to stress the game, but blowing up a huge pile of cars seemed like the most fun.

How about piling up fewer but larger vehicles?

 

[Scott_Arm]

How about piling up fewer but larger vehicles?

Never tried that. Maybe tomorrow

Oh, and the best weapon to use is the grenades because you can throw them really fast and make sure all the cars will explode at roughly the same time. It definitely hits the framerate.

The best place to do it is by jumping in the multiplayer lobby world because there aren't any police, so you don't have to worry about getting killed.

 

[Neb]

How about piling up fewer but larger vehicles?

There is a Youtube video of a person using cheat for 360 version to have lots of police cars stack up.. I mean lots and then blow them up. Will find the video if you want to see sub 5fps framerate!

 

[BadTB25]

Our Crackdown feature gets top-billing on Eurogamer this weekend.

I like producing these original approaches to classic games. I also like the "gamebreaking" approach - setting up engine-stressing situations and seeing just how well the technology copes. Obviously a similar thing could be arranged for GTA IV, but if any one else has any other original approaches, let me know.

We're looking at Halo 3 at the moment. Assuming MS comes up with decent ODST material this week that should be a good decent feature for the next weekend EG slot.

I really enjoyed your feature. The second video was really cool and although I have the game, I still haven't finished it.

Any chance of doing a Mass Effect analysis. The screen tearing in that game is pretty annoying. I'm really enjoying the game and I'm roughly 6-7 hours in.

 

[grandmaster]

Crackdown works by not generating any new cars once the "allowance" is in the game scene. Disappearing cars in order to allow new ones to appear sounds rather lame.

 

[Scott_Arm]

There is a Youtube video of a person using cheat for 360 version to have lots of police cars stack up.. I mean lots and then blow them up. Will find the video if you want to see sub 5fps framerate!

Maybe the single player game does not have the same car limit that the multiplayer "lobby" world has.

 

[woundingchaney]

Nothing much to say here other than the fact that I really appreciate the work you are doing with Digital Foundry.

 

[Tap In]

Crackdown works by not generating any new cars once the "allowance" is in the game scene. Disappearing cars in order to allow new ones to appear sounds rather lame.

thanks for the article. it explains why I always felt the lighting in Crackdown "made" the comic book style work.

Also were you able to determine a reason as to why this game can not be installed to the HDD on 360?

 

[liolio]

Last entry to the digital foundry is Dirt 2, good job at analysing the good job made by codemaster.
the game looks really good and the devs team seem to pull quiet some tricks nicely.

 

[grandmaster]

Thanks... a Halo 3/ODST feature is going today, which took aaaaaaaaaaaaaaaaaages to put together (mostly on the video side of things).

Next Saturday's slot is going to be occupied by a Burnout Paradise feature, and I'll be visiting Criterion on Monday.

So, you lot have got two days to let me know what sort of things you'd like to know about the game, its tech, how Criterion works etc.

Don't hold back, let me have all your questions and ideas

 

[holsty101]

The one thing I've been curious about in the past few years since EA brought Criterion is, the reported rational behind EA's purchase was to get their hands on a next gen Renderware engine to ease (and I guess give a certain amount of parity to) 360/ps3 development, maybe I'm wrong thinking this but it doesn't look like that's happened. IIRC there was a pretty big gap between EA's internal 360/ps3 games both pre & post Baradise release and I'd just like to know if they have anything to say on that topic.

 

[obonicus]

The one thing I've been curious about in the past few years since EA brought Criterion is, the reported rational behind EA's purchase was to get their hands on a next gen Renderware engine to ease (and I guess give a certain amount of parity to) 360/ps3 development, maybe I'm wrong thinking this but it doesn't look like that's happened. IIRC there was a pretty big gap between EA's internal 360/ps3 games both pre & post Baradise release and I'd just like to know if they have anything to say on that topic.

I think Riccitello talked about this, essentially saying that Renderware wasn't suitable for their next-gen products. This may have been in 2007, before Burnout Paradise.