GP2X What Rgba Format Do You Use (non-sdl)?

[A_SN]

For those who don't use SDL for graphics on the GP2X, how do you deal with alpha layers, or which option according to you is the best?

EDIT : argh wtf it was supposed to have a poll plus I posted it twice. Here's the poll's options anyways :

1). RGBA8888 in a word and convert to RGB565 at every frame
2). RGBA5658 (or less for the alpha layer) in a word
3). RGB565 in a short and keep your alpha layer in separate arrays
4). Other

 

[refractor]

1). RGBA8888 in a word and convert to RGB565 at every frame

That one. Everything else is 565 except alpha stuff which is 24+8 bit (avoids some unsightly banding issues).

 

[A_SN]

1). RGBA8888 in a word and convert to RGB565 at every frame

That one. Everything else is 565 except alpha stuff which is 24+8 bit (avoids some unsightly banding issues).

Banding issues? What's that?

 

[refractor]

Banding issues? What's that?

Have a look at the first two balloons here:

http://www.websiteoptimization.com/speed/tweak/dithering/

Alpha-blending suffers from the same kind of banding if accuracy isn't good. In small doses (i.e. a single sprite) then people probably won't notice. If you use it for something much larger (e.g. fog) then it banding makes it look atrocious.

 

[A_SN]

Banding issues? What's that?

Have a look at the first two balloons here:

http://www.websiteoptimization.com/speed/tweak/dithering/

Alpha-blending suffers from the same kind of banding if accuracy isn't good. In small doses (i.e. a single sprite) then people probably won't notice. If you use it for something much larger (e.g. fog) then it banding makes it look atrocious.

Oh yeah well, for stuff like kind of large gradients I'll use dynamic random dithering, but it hardly has anything to do with our problem (since we're limited to RGB565 in the end no matter what) but it seemed to me like you said there was a difference between using RGBA8888 -> RGB565 and RGBA5658 -> RGB565, right?

 

[Blah]

Dynamic random dithering? No, you want Floyd-Steinberg dithering. Theres a filter for Photoshop (and thus other editors which are compatible with Photoshop plugins) that will dither to RGB565. The source code is available, so you could repurpose the filter for use in your program. The results are very good.

 

[A_SN]

Dynamic random dithering? No, you want Floyd-Steinberg dithering.

No I don't lol, trust me I know what I want way better than you do ;-). Do you even know what I mean by dynamic random dithering? First of all, my dithering wouldn't be performed on my sprites or anything, but rather live inside my game, otherwise it couldn't be dynamic, which makes me think that no matter what I'll have to keep some stuff in RGB888 to some point.

Anyways, the idea is the following, let's take a single channel example, say my channel is in 8-bits, and I only can display it in 5-bits, so I take its value, add a random number to it between 0 and 16 (if I didn't make any mistake), I add it to the 8-bit value, then shift down to 5-bits, and I do this for every frame. Therefore, if the three last bits of your 8-bit value (that would otherwise be discarded) amount to let's say 10, that means that, in average, 37.5% of the time the 5-bit value would be the closest lower one (with respect to the 8-bit value) and 62.5% of the time it would be the closest upper one.

The result is a fine little animated noise (16 out of 256 isn't much, or 8 out of 256 for green) and if you got a good framerate it'll look like 24-bit color to you, except with this fine little noise that hardly looks bad.

I plan on using that on stuff like smooth gradiented sprites and also when I'll have a background colour that will very slowly get darker in order to make the transition look completely smooth step-less. So fuck Flyod-Steinberg, although my method has a cost, there's no way anything else could look as nice. In other words there's no better way to make 16-bit color looks as much as 24-bit color than random dynamic dithering.

Anyways, back on topic, I think I'll have to use a mix of RGBA5658 and RGBA8888, I wish more people answered to it tho, I would have liked to hear how other people do it.

 

[Micket]

Alpha blending over already dithered (to RGBA565) images might also work. They'll produce some banding, but it's original dither will probably hide it quite well.

But why the floyd-steinberg hate? It often looks quite nice. But then of course if you really want that animated effect (which indeed might look cool, you better show us when youre done) then of course the randomized method is the only choice.

Anyway, since you seem to aim for the highest quality of color, i'd say go for RGBA8888. Although there are probably not many pixels that will differ (and if so, very little) even with RGBA5658.
Perhaps a few tests and comparisons is the best way to decide.

 

[rokdcasbah]

But why the floyd-steinberg hate?

why indeed?



actually my guess is because for smooth gradients you don't want to use anything that has a chance of developing artifacts (thus defeating the purpose of dither). you can get away with a simpler dither on a more complicated image, but even a random dither can have artifacts on something like a smooth gradient, it's just one of those things you need to tweak a lot. not sure what the "dynamic" is about but i'm guessing it means that the dither is intelligent as to the range of values it uses, rather than applying the same scale of random noise everywhere...using less noise where the image bands less, and so on.

i'm interested in seeing how you acheive your dithering, a_sn (tech demo maybe??) as dsp stuff is right up my alley. good luck though.

 

[A_SN]

But why the floyd-steinberg hate?

why indeed?



actually my guess is because for smooth gradients you don't want to use anything that has a chance of developing artifacts (thus defeating the purpose of dither). you can get away with a simpler dither on a more complicated image, but even a random dither can have artifacts on something like a smooth gradient, it's just one of those things you need to tweak a lot. not sure what the "dynamic" is about but i'm guessing it means that the dither is intelligent as to the range of values it uses, rather than applying the same scale of random noise everywhere...using less noise where the image bands less, and so on.

i'm interested in seeing how you acheive your dithering, a_sn (tech demo maybe??) as dsp stuff is right up my alley. good luck though.

Haha I don't really hate the floyd-steinberg dithering, I'm just saying I can use something better . Random dithering does create artifacts (noise, or grain if you prefer), but dynamic (by dynamic understand animated) random dithering has these artifacts changing all the time.

If you know some about DSP you'll understand this : since these random artifacts change and are defined in a stochastic manner, and that our eyes perform some averaging of this noise through time (when you see something at 60 FPS (or even more), your eyes mix some frames together, and that's simiilar to averaging, in the same way as Mario Kart Super Circuit fakes half transparency, by turning an image on and off at 60 FPS so it looks semi-transparent to us), the averaging reduces the noise and this average matches closely to the original color values that we could not display with our reduced color depth.

Anyways, a tech demo? Like, a GP2X program showing many pictures made of gradients (or even pure gradients) first being displayed without any dithering in RGB565 mode and then being displayed using my dynamic random dithering? (shouldn't I use another word than dynamic to say animated? sounds good since it's the opposite of static but still it seems to cause confusion). I could totally do that, pretty quickly, actually what will take most of the time will be to find pictures that would fit the job. If you got some pictures that look like aweful in RGB565 and real nice in RGB888 don't hesitate to show me

Anyway, since you seem to aim for the highest quality of color, i'd say go for RGBA8888. Although there are probably not many pixels that will differ (and if so, very little) even with RGBA5658.
Perhaps a few tests and comparisons is the best way to decide.

Well I started using RGBA8888, but I faced performance issues when converting the whole RGB888 screen to the RGB565 framebuffer (even when optimized to the death in ASM that part took 10 ms at every frame), so I decided to change the way I'd do it but I wasn't sure what to move on to. But I agree with you, tests will be needed, right now I think I'm going to mainly try to do most things in RGBA5658.

EDIT : Weirdly enough what I call "dynamic random dithering" seems to be poorly documented, and the term itselves is unknown to google, and I have been unable to find any use of an alternative term to describe this, anyways, I found this page (look at 2. Random Dithering to the people) that backs my claims about the use in video games of a random dithering that changes over time in order to look smooth.

 

[A_SN]

Done. Let me know what you guys think about the results of that technique.

 

[Blah]

I can see that dynamic random dithering could be effective for animated sequences, but for still images I think the filter I mentioned works better for still images because there is no wavyness for the user to notice.

 

[A_SN]

I can see that dynamic random dithering could be effective for animated sequences, but for still images I think the filter I mentioned works better for still images because there is no wavyness for the user to notice.

Undoubtfully, the point was here to prove the use in a video game.

 

[rokdcasbah]

sweet. unfortunately i can't test it until i'm off work.

i don't know why i used the word "artifacts" before. what i meant to say was that floyd-steinberg had a higher chance of creating additive error than a random filter (which, if i remember correctly, still has some chance of doing that depending on the pseudorandom algorithm and the size of the image). which could be just as bad as not dithering.

actually what i was hoping for was something to see the dynamic quality, like some sort of animation. but i guess that no matter what, since you're starting with thousands of colors, the effect is going to be very subtle.

i'll probably have to edit this post once i get home and actually run the thing

 

[A_SN]

sweet. unfortunately i can't test it until i'm off work.

i don't know why i used the word "artifacts" before. what i meant to say was that floyd-steinberg had a higher chance of creating additive error than a random filter (which, if i remember correctly, still has some chance of doing that depending on the pseudorandom algorithm and the size of the image). which could be just as bad as not dithering.

actually what i was hoping for was something to see the dynamic quality, like some sort of animation. but i guess that no matter what, since you're starting with thousands of colors, the effect is going to be very subtle.

i'll probably have to edit this post once i get home and actually run the thing

Well I don't find the effect to be too subtle, it shouldn't be any less subtle, but I'll let you judge that by yourself

what do you mean by "additive error"?

 

[rokdcasbah]

sweet. unfortunately i can't test it until i'm off work.

i don't know why i used the word "artifacts" before. what i meant to say was that floyd-steinberg had a higher chance of creating additive error than a random filter (which, if i remember correctly, still has some chance of doing that depending on the pseudorandom algorithm and the size of the image). which could be just as bad as not dithering.

actually what i was hoping for was something to see the dynamic quality, like some sort of animation. but i guess that no matter what, since you're starting with thousands of colors, the effect is going to be very subtle.

i'll probably have to edit this post once i get home and actually run the thing

Well I don't find the effect to be too subtle, it shouldn't be any less subtle, but I'll let you judge that by yourself

what do you mean by "additive error"?

sorry. when i said subtle, i didn't mean that the effect was being scaled back, i just meant that you have enough colors to start with that it's probably never going to look terrible. if you were dithering down to indexed color, things might get a little hairier.

as to additive error, i'm just dumb is all. i meant to say accumulating. it's possible that using the wrong dither algorithm could create repeating moire-like patterns.

when i said dsp was up my alley, i didn't mean that i knew what the hell i was talking about
i just find it really interesting. i do know a bit about audio dsp, and at the moment i'm reading whatever i can find on image applications. my eventual goal is to create a half-decent, fast, heightfield renderer for the gp2x, as well as a library of visual effects that i can use in a game to make it look snazzy. not too long ago i ported an sdl voxel demo, runs ok. but i want to do everything myself.

 

[Micket]

I just checked it out. Looks quite nice. Used wisely it could really help the atmosphere in a game.
But still, floyd-steinberg wouldn't have looked bad either. The framerate isn't fast enough to eliminate the noise, so (putting speed issues aside, floyd-steinberg might very well be way to slow to use at 60Hz with lots of other stuff going on as well) it's a question to wether or not you want the effect.

 

[rixed]

4) other : YUV ;-)

more colors, and better lighting shades (for 3D stuff).

 

[rokdcasbah]

the demo looks pretty awesome. on some of the images you actually get increased detail when the filter kicks in. the images do seem to get brighter across the board, though...is that a side effect of the dither or just the removal of banding in dark areas?

rixed: yuv does sound interesting...just guessing but my first thought was that, if you were only using white light, you'd only have to calculate one new value for each pixel rather than 3.

but then you'd have to deal with going back to rgb, or writing some funky code to send your yuv data straight to the screen, right?

can't wait to see what this is going to be used for.

 

[A_SN]

the demo looks pretty awesome. on some of the images you actually get increased detail when the filter kicks in. the images do seem to get brighter across the board, though...is that a side effect of the dither or just the removal of banding in dark areas?

rixed: yuv does sound interesting...just guessing but my first thought was that, if you were only using white light, you'd only have to calculate one new value for each pixel rather than 3.

but then you'd have to deal with going back to rgb, or writing some funky code to send your yuv data straight to the screen, right?

can't wait to see what this is going to be used for.

The images seem to get brighter because they do get brighter, or rather they get as bright as they should be. Since to go from RGB888 to RGB565 we simply get rid of the last bits of each color layer, which implies that all the lower bits that range from 0 to 15 included (or 7 in the case of green) are brought down to 0, it means that in average the undithered image is 8,4,8 (RGB, each value out of 255) darker than it should be. The dithered image is just right. If we wanted the undithered image to have the proper brightness, we should add 8,4,8 to it, which means we would round the 24-bit values to the closest 16-bit value instead of truncating as we do (but we truncate for the sake of performance I guess)

By the way, on the lower right corner of the screen on bright images we can notice a flickering, I write straight to /dev/fb0 in ASM and I made sure I wasn't writing out of bounds, but still you can see those few pixels flickering, would anyone know what this is due to?

And to rixed, same questions as rokdcasbah asked, I don't think I'll bother with YUV tho.

By the way, in case you guys didn't notice I'm not actually using a random number generator in real-time for my dithering but I make an array full of (currently 65,535) random bytes (one for each color layer) that I use over and over again, because using a random generator in real time was too damn slow. Depending on the array length it can look like the noise is scrolling, I was wondering if it was any appearent in my demo?