PDA

View Full Version : 16 bit vs 8 bit colour loss


mdnchmr
Aug 22, 2013, 09:59 AM
Hello. Why am I losing colours in my tilesets running JJ2 in 16 bit mode?

My tilesets look as intended in 8 bit, but when I run the game in 16 bit I lose colour, as you can see here:

EDIT: WILL LINK ON A REPLY TO THIS POST. Apparently JCF is saying: You are only allowed to post URLs to other sites after you have made 2 posts or more

I`ve tried making two variations of the tileset I finished a few days ago. On the first, I`ve followed the default JJ2 palette. The second, I followed the default JJ2 palette as well BUT checked off the option in JCS for remapping.

I have also tried reducing colours on the tileset itself.

Both still result in the image above. 16 bit mode loses colours.

Especially noticeable on close gradients. The colours in question here are a gradual reduction of 1RGB value each palette slot. Example: "255 255 255 to 254 254 254 to 253 253 253 and so on.

I suspect the colour values are too similar and need more of a gap instead of only going down 1 increment, but thought I`d ask here first instead of revamping my project(yet again :r)

Thoughts? Ideas? Possible to fix from my side?

Thank you for reading.

mdnchmr
Aug 22, 2013, 10:00 AM
Post count +1

Link to example picture:
http://tinypic.com/r/w7gf2p/5

Obi1mcd
Aug 22, 2013, 10:26 AM
Hm. That's very interesting, I've never noticed that JJ2 does that before. Tried it out myself, and sure enough, same thing. I'm afraid I have no idea why it's doing that, though.

Torkell
Aug 22, 2013, 10:39 AM
I have a theory...

In 8-bit mode, JJ2 will be using paletted graphics. This gives you only 256 different colours, but the red green and blue values of those colours can each be chosen from the full 0-255 range. So you can do a complete gradient with no banding or artifacts.

In 16-bit mode, JJ2 will be using RGB graphics. However since it's only got 16 bits to play with it'll likely be using RGB565 - this gives a range of 0-32 for red and blue and 0-64 for green. The result is you can't represent a smooth gradient if you have more than 32 steps. Instead the colours will jump in discrete steps which gives the artifacts you saw.

You need at least 24-bit colour (or 32-bit, which in practice is 24-bit with padding) to get the full 0-255 range for each channel, but JJ2 doesn't support that. So unfortuantly your options are to use 8-bit mode or try and design your tileset such that you don't notice the aritfacts.

Violet CLM
Aug 22, 2013, 02:14 PM
Torkell is right. 16-bit mode has fewer possible colors overall but allows more unique colors to be on-screen at one time.

cooba
Aug 22, 2013, 02:17 PM
This thread is blowing my mind.

mdnchmr
Aug 22, 2013, 05:19 PM
Alrighty, those replies solve THAT mystery.

Thank you everyone. Unfortunate, but good to know for future design.

Love & Thunder
Aug 23, 2013, 09:09 AM
[...] You need at least 24-bit colour (or 32-bit, which in practice is 24-bit with padding) to get the full 0-255 range for each channel, but JJ2 doesn't support that. [...]
Torkell is right. 16-bit mode has fewer possible colors overall but allows more unique colors to be on-screen at one time.
Any chance of that being fixed in Plus, or would it be too complicated/unstable?

burnout92
Aug 23, 2013, 09:25 AM
Any chance of that being fixed in Plus, or would it be too complicated/unstable?

I think it's could be nice idea but the color loss is a color loss. I guess can't be fixable.

Violet CLM
Aug 23, 2013, 09:41 AM
It would mean recoding basically everything.

burnout92
Aug 23, 2013, 09:49 AM
Yeah... But we/you are then recode again the whole game...

Jerrythabest
Aug 23, 2013, 11:19 AM
Really interesting findings. I knew it was doing this (since I've seen and played with the code that does this) but I've never actually realised that it would cause this kind of artifacts! Changing it (i.e. to 24+ bits) would require rewriting pretty much all of the drawing code. We've got better things to do. :p

Torkell
Aug 23, 2013, 01:11 PM
Really interesting findings. I knew it was doing this (since I've seen and played with the code that does this) but I've never actually realised that it would cause this kind of artifacts! Changing it (i.e. to 24+ bits) would require rewriting pretty much all of the drawing code. We've got better things to do. :p
This is what comes of poking around with various console image formats - you end up playing with all sorts of weird encoding schemes :)

Interestingly there's some effects that only work well in indexed formats, like the colour cycling you get from touching the smoke rings (which is trivial to do with a palette but hard with any RGB format).