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

[rokdcasbah]

i just ran the demo again and tried to see scrolling in the noise, but i couldn't pick it out, it just happens too quickly for me. but keep in mind that i have a mk1, so the wacky timing on the interlace muddies things up, and on top of the whole thing are some faint scrolling diagonal bands of course, i could play with the timings some more but generally i just leave it since it's good enough for me to enjoy...

 

[Micket]

There is NO way to ever notice the repetition of that huge array
320*240-65535 = 11265 = 35*320+65
65532/(320*240) = 4369/5120
You got a offset of 35 lines and 65 pixels for each repetition, and the sequence wont restart until after 5120 frames, ~85 seconds.

You could easily cut that down to a much smaller array, maybe.. 5000, worth a try
Repeats every 15 rows and 200 pixels and the sequence starts over after 384 frames, 6.4 seconds. Or even better, 4999
That wont repeat until after 76800 frames. (same for any numbers that arent divideable by a factor, 2 3 or 5)
Just choose a good size and you wont have problem with repeating noise
After all, 320*240*1.5 is pretty big, but repeats every other frame

 

[A_SN]

There is NO way to ever notice the repetition of that huge array
320*240-65535 = 11265 = 35*320+65
65532/(320*240) = 4369/5120
You got a offset of 35 lines and 65 pixels for each repetition, and the sequence wont restart until after 5120 frames, ~85 seconds.

You could easily cut that down to a much smaller array, maybe.. 5000, worth a try
Repeats every 15 rows and 200 pixels and the sequence starts over after 384 frames, 6.4 seconds. Or even better, 4999
That wont repeat until after 76800 frames. (same for any numbers that arent divideable by a factor, 2 3 or 5)
Just choose a good size and you wont have problem with repeating noise
After all, 320*240*1.5 is pretty big, but repeats every other frame

You forgot something, as I said, there's one byte per color layer, which means that in a 65,535 element array there's only enough for 21,845 pixels

21845 = 68*320 + 85

Sounds even better.. I wonder if the size of the array has any influence on the performance, I guess not..

 

[Micket]

Doh!
Yeah, still the best size has as few factors 2,3 and 5 as possible (since 240*320*3 = 2^10 * 5^2 * 3^2)
As long as you stay away from that as much as possible (worst beeing no other factors, and no more than each factor in 240*320*3) it should take ages for the pattern to repeat.
65537 sounds like a good choice maybe?
Given the color offset as well, the same random number wont match the same color channel until 3 iterations.

For safety, we say we dont want to have the pattern repeat more than.. 5 times on one frame, so we want at least random numbers for 320*240/5 pixels, and choosing one without a factor 3 lets ignore the color channels, as we wont notice repetitions that doesn't match the same color => we want at least 15360 with no factor 3
15359 happens to be a prime (and is close enough)


but you should probably ignore me. 65535 works. screw suboptimizations, i just like math

 

[A_SN]

Doh!
Yeah, still the best size has as few factors 2,3 and 5 as possible (since 240*320*3 = 2^10 * 5^2 * 3^2)
As long as you stay away from that as much as possible (worst beeing no other factors, and no more than each factor in 240*320*3) it should take ages for the pattern to repeat.
65537 sounds like a good choice maybe?
Given the color offset as well, the same random number wont match the same color channel until 3 iterations.

For safety, we say we dont want to have the pattern repeat more than.. 5 times on one frame, so we want at least random numbers for 320*240/5 pixels, and choosing one without a factor 3 lets ignore the color channels, as we wont notice repetitions that doesn't match the same color => we want at least 15360 with no factor 3
15359 happens to be a prime (and is close enough)


but you should probably ignore me. 65535 works. screw suboptimizations, i just like math

I think you're wrong about giving importance to avoiding prime factors, because here we don't care about how often it will repeat itselves but we care about how much it moves. In order to find the best number we first need to know what kind of offset we want from a frame to another, although I agree with you that the pattern shouldn't repeat itselves more than 5 times a frame.

65537 isn't a multiple of 3 and even then 65538 or anything close wouldn't make a real difference. 15359 isn't good because it means that your noise will seem to move by 5 pixels rightwards from frame to frame, it would look aweful actually (I tried btw and I can confirm, looks like some kind of transparent film is scrolling through). With 21845 (65536/3) it means it moves down by 33 pixels and right (or left? dunno) by 20 pixels from frame to frame, so I guess that's why it doesn't look bad, but I guess it gives us a clue as to how to make it better.

But I just tested with a uniform image and you can see noise scrolling, it's not fully obvious but it's there. I think there's a double problem here, because if the noise is too small, then it limits your choices. For example, in our case, on one frame our noise repeats itselves on an offset of 68,85 (down,right). That means that the frame-to-frame offset must be somewhere between 0,0 and 68,85, which means that no matter what it'll look like it's scrolling by at most 34,42, and even that's if you don't pay attention to the next frame because then there would only be an offset of 0,2 between the first and the third frame.

So I think I should make it much larger so that I get rid of this constraint, after all it would only impact the memory use and not the performance, right? So I think that it should be larger than a frame, let's say over 3 times larger than a frame (so that you can have 3 consecutive frames that wouldn't share a common bit of noise), and now, considering that we gotta worry about the in-between 3 frames offset as if it was the frame-to-frame offset, I think a vertical offset of between one third and a half of the screen's width would do it, and i'd say same for the horizontal offset, so that my offset would be 80-120,107-160 (not sure on how I'll choose the final values, if anyone has an idea..) but anyways that would mean that my array would have to be at most (320*240*3 + 120*320 + 160) * 3 = 788 kB large. Sounds affordable to me.

 

[rixed]

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.

Exactly. And you have more shade of lights than what you'd get from interpolating 16 bits RGB datas (which gave bad visual artifacts).

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?

There are no need to go back to RGB. The GP2X have a 32bits YUV mode.

 

[A_SN]

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.

Exactly. And you have more shade of lights than what you'd get from interpolating 16 bits RGB datas (which gave bad visual artifacts).

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?

There are no need to go back to RGB. The GP2X have a 32bits YUV mode.

Yeah but the LCD's still limited to 2^16 colors, right?

 

[Micket]

Well i'd be damned. Quite a few details i didnt think about. Yeah, i can't see a big array affecting the speed at all, thats why i told you to ignore me. I just can't help but to want to try lots of things all the time.
Seems like i overestimated the problem of the sequence starting over from pixel 1

About YUV, 32 bit. Which bits are used for what? The gp2x can't technically display more then 2^16 different color.

 

[Blah]

The LCD can handle up to 18bit IIRC.

 

[A_SN]

The LCD can handle up to 18bit IIRC.

Where you got that from? By the way the LCD's specs say it supports 24-bit color and can display 16.7 M colors. What's up with that? Why can't we actually display that many??

 

[rixed]

[Yeah but the LCD's still limited to 2^16 colors, right?

I don't know for sure, but in YUV mode you have 24 significant bits.
And, compared to the 16 bit mode, the YUV rendered pictures of gpu940
looks far better than the oldest version which used 16 bits RGB, when
lighting is enabled. So I would say that the LCD limitations are not the problem.

But perhaps the LCD can only handle 65636 colors, and that was my computation
of lighting on 16 bit RGB mode that was crapy ?

Honestly, I have no time to review the MMSP specs for now to find out.

 

[Micket]

The LCD isn't limited.
I was under the impression that there simple weren't enough pins connected, just the most significant bits of 888 to 565
Thus making it technically impossible to display anything but exactly the colors in RGB565

Thats giving me a real hard time believing that YUV-mode could ever produce a single color that RGB565 can't.

 

[rabidcow]

The YUV layers are 16 bits per pixel, but pairs of horizontal pixels share the same chroma giving you effectively 24 bits per pixel. It's a really bad choice if you need super sharp edges between two different colors on odd pixel boundaries. (though the YUV layers are behind the RGB layer, so it would make a fine background)

I think the intermediate RGB used to mix the layers together is 8 bit, but I don't have the MMSP data sheet handy...

 

[HenrikE]

I say, start with the most luxurious solution you can think of and see where it goes!

But also consider the interlace type effect of the screen (30Hz?), which might affect realtime dithering. To get 100% control of dithering over time, may I suggest a custom graphics converter? From 8888 to multiple pre-dithered 565 'animation frames' of the the sprites? 8888 takes twice the space already, so two dither animations would fit in the same space.

To do the alpha you might try a simple height x wid byte array, common for all the dither animations for that sprite. Not too much space extra and might give easier/faster alpha blend code?

 

[Blah]

What about dynamic dithering using Bresenham error correction? That would probably be very accurate, but also computationally expensive

 

[A_SN]

What about dynamic dithering using Bresenham error correction? That would probably be very accurate, but also computationally expensive

If by that you mean cumulate the difference between the value you want to display and the value that made it to the 16-bit color pixel than I think it's a bad idea. Imagine a grey background, made of 129,129,129 (R,G,B ). Basically, with your idea, every frame would be like 128 except every frame out of 16 frames which would be 144. So basically, if you imagine you have a screen refresh rate of 60 Hz, 4 times a second you'd have flash taking over the whole screen.

With dynamic random dithering, one frame out of 16 frames will be at 144 too, but it'll be distributed randomly, so that pixels won't flash at a regular interval and the screen won't change of intensity all at the same time. Basically if you wanted to improve your idea so that it wouldn't flash or anything, you'd end up with dynamic random dithering as I presented it

 

[Micket]

Just out of curiosity, why 16 frames and 144? The closest upper value should be 136 (or 132 for green) in RBG565. Still i agree with your argument.

Also, since this thread is back from the dead; Whats up with the YUV-comments in this thread.
I mean, in the end values must be sent to the LCD as RGB565, so RGB565 contains exactly every single possible color the LCD can display.

 

[A_SN]

Just out of curiosity, why 16 frames and 144? The closest upper value should be 136 (or 132 for green) in RBG565. Still i agree with your argument.

Also, since this thread is back from the dead; Whats up with the YUV-comments in this thread.
I mean, in the end values must be sent to the LCD as RGB565, so RGB565 contains exactly every single possible color the LCD can display.

Oh yeah, maybe did I miscalculate a few things in my comment. Anyways, yeah, we don't care about YUV for that very reason.

 

[rabidcow]

Also, since this thread is back from the dead; Whats up with the YUV-comments in this thread.
I mean, in the end values must be sent to the LCD as RGB565, so RGB565 contains exactly every single possible color the LCD can display.

If you want hardware layer composition, you have to use YUV for the lower layers. If we had documentation for the hardware JPEG/MPEG decoding stuff, that may even be useful (since they're natively in YUV). As it is, the cost is too high and the benefit too low.

 

[rokdcasbah]

The YUV layers are 16 bits per pixel, but pairs of horizontal pixels share the same chroma giving you effectively 24 bits per pixel.

i'm confused...do you mean that there's 16 bits for luma and 8+8 for chroma? Cause if there's 16 for everything, then wouldn't having a lower horiz resolution for chroma mean (effectively) less than 16 bits per pixel?