Over the past few weeks, a terrible issue has appeared, and it's been quite noticeable.
It's caused my Stringy Things project to get stuck, as well as creating multiple issues in lots of other places.

The problem is as follows..

Not all devices are the same!!!

-=-=-

I knew from the start that image based data would be quirky, and so I initially set myself a /8 reduction on all values.
I naturally assumed that dividing everything by 8 would give "less awesome" devices the ability to keep up.
My assumption has been proven spectacularly wrong.

The Issue

Monkey, for various unknown reasons, does not allow your program to access pixel data of images that are currently loaded into memory.
I'm not 100% sure why this is, but I'm guessing it's to do with the complexity of achieving the same result on so many different targets.

It does, however, allow you to draw the image to the screen, then grab that data, and access it nice and easily. This works on ALL targets, even HTML, which is fantastic.

Except when it isn't...

Some devices are running in 16-bit colour mode. This is causing an ever so slight shift in the colours.
To test this thoroughly, I devised a simple but effective "Colour Swatch" test program.
The resulting image is a joy!


Oooh, look at all those pretty colours!!
On the left, every 32-bit colour, one by one. Everything from 0,0,0 up to 255,255,255, and a bunch of different colour variations along the way.
On the right, a checklist of "readability", with each dot representing whether or not the device is giving back the expected colour.

As you can see in the feedback above, everything on a Windows 32-bit colour screen is perfect, and all readings come back exactly as expected.

.. But then we switch Windows to 16-bit mode, and..


Hmm..
That's not a good sign.

If you zoom in close, you can see the issue. Windows is dithering the colours, and it's causing all kinds of chaotic behaviour.
Checkerboarding, and odd unexpected colours aren't what I'm after, and they're causing untold issues when reading the data back.

And not only is Windows an issue.
Socoder regular @Spinal_Cord has been helping test this, on his Android device, which is giving similar image-data issues.
He tested the same program, and alarmingly got the following result..



Now, that might look more or less similar (except for the fact that his version does orange) but there's a rather significant difference in the results.
Not only is his Android device reducing the colours, and dithering them, it's also leaving gaps with no accurate colour feedback, at all!!
Take a look at the Green segment. There's a giant pile of unbroken white area, where no correct colours are being fed back to the device.

ARGH!!

I've spent most of the past few days battling with this.
I've tried "proper" 32 to 16 bit colour conversions, I've tried "accurate" divisions of numbers, and I've tried "trial and error" guesswork. Nothing seems to be working.
Nothing is fixing this issue on ALL targets. And these are only the targets I'm testing with!! God knows how much more complex this issue might become.

My image-loader is falling apart at the seams, and it's taking a whole host of things with it.
Karl's Tiny Adventure is probably completely knackered at this point, as is Stringy Things' WordList, and my Music Engine is no doubt just as bad.

It feels like everything I've managed to get working over the past two months is suddenly deteriorating at an alarming rate, and all because I can't simply access a bunch of numbers!
grrr!!

I'm going to keep tweaking, and hopefully I can come up with some sort of solution to this whole mess.
It's not looking good