QUOTE(xythen @ Jul 18 2007, 10:56 PM)
One thing I've found; when exiting gpfce (v0.4 r171, ie the newest version) it returns to the default settings at the gp2x menu, then after ~3 seconds the screen switches again to the new settings. It's actually quite a useful bug since it lets you see an obvious "before & after" transition, but it only seems to happen with this emulator (I tried picodrive and some gbax entries and nothing else seemed to do it).
I guess it means that gpfce changes the registers used by colourd to normal when exiting (maybe does it do it too when you start it?) which is why I made the daemon write the values again and again to the registers every 5 seconds. So yeah, it's a feature, not a bug
QUOTE(kevcal @ Jul 18 2007, 11:02 PM)
When this is considered an important add-on - I think it is - then maybe it can be run some other way - ie not a s a daemon but hhoked into open2x o/s possibly?
It could also be optimisedup a bit more if necessary (at the expense of a little memory). Actually probably straightfoward for someone to convert to assembler?
Well even if it is in open2x (and it will be) it'll still be a daemon
. why optimise it? what it does every 5 seconds seems to take about 1500 cycles, and if I'm not making any mistake at 200 MHz that'd be about 7.5 Ás. 0.0000075 seconds wasted every 5 seconds, does it sound like it requires optimization? Oh well that's if I compile it with -O2 tho, which I haven't done yet. I'll do it next time. Oh and actually I don't think there'd be much to optimize in assembly anyways, that's the kind of code gcc is great at optimizing. As for memory usage, it doesn't take much more than a hello world, besides a 768 B array...
QUOTE(fusion_power @ Jul 18 2007, 11:27 PM)
It happend with every application I tried, picodrive to I think. After exiting, Gmenu2x shows his standard Colours and then, the fix, well, fix it. But it's no problem, I can live with that.
Yes, because gmenu2x tries to apply its gamma setting. I guess I could "fix" more often than every 5 seconds then. I'll have to do some fiddlings with that
QUOTE(rokdcasbah @ Jul 19 2007, 04:53 AM)
the thing is, our eyes don't respond to light linearly. plus it differs among individuals, time of day, etc. that said, i understand your feeling completely. your work doesn't affect me on the user side (mk1), but i'm really hoping that everyone adopts this, and figured that if it was adjustable people wouldn't complain about it being too extreme, and i wouldn't have to worry about designing for two different gammas.
i won't pretend that's not selfish
in any case, it's great work and must have been an exacting process getting the test values, and it's of course appreciated.
ps. am i wrong about gph setting a bad default gamma correction? did they just not set any at all? in your code you have to change the register to turn on the gamma control, so i guess maybe they just used the screens as-is. still lame and still a problem for homebrew at least.
edit: i forgot something. actually, it does affect me as a user. because i want to crank up the chroma on mine. well, the source is in there, so i'd better get off my lazy butt.
While our eyes maybe not respond to light linearly, we expect to see stuff that's linear wrt real world stuff.
As for getting the test values, well it's based on an easy test actually. The only hard thing is that I didn't go that way in the first place, made another test that gave utterly bogus results.
And as for GPH, they just didn't turn colour correction on, and we can't blame them for that, although ideally they would have used that to calibrate their lcds.
Edited by A_SN, 19 July 2007 - 08:38 AM.