Lcd Colour Correcting Daemon For Mkii's

Do you like it?

  • Yes

    Votes: 0 0.0%
  • I can't see what it does, looks just the same as before to me

    Votes: 0 0.0%
  • No

    Votes: 0 0.0%

  • Total voters
    0

Alex. said:
Why not use SDL_image? SDL ain't poison you know :p
Nah, I've used SDL_image before and had issues with it, mainly had issues with it working on a platform and not on another and such, and then i'm not comfortable with SDL.
 
Last edited by a moderator:
Alex. said:
A_SN, I gave it a try some more, and I came to the conclusion that your calibration could stand to be a bit more saturated. Not as much as the MK2 default, but a bit nonetheless. Right now it's too close to looking washed out. Besides, a bit more saturation will lower the gap between graphics that look best on MK2 and their change after calibration :)
Yeah, I noticed this too. It looks more grey-ish, like my Phat DS compared to a lite DS.

I voted "No" on the poll, but the concept is a great idea. Perhaps you should add a command line interface, too.
(I'd like to add it, myself, but I can't seem to figure out how do do that... :( Oh well. :) )
 
Last edited by a moderator:
It seems a lot of users find this useful, so I could actually look into integrating it in gmenu2x if there is demand for such a feature.
I have a MKI though and I am happy with it so I wouldn't directly benefit from this :p
I would also have to look into having this coexist with the gamma settings (or removing them)
 
Ryo said:
It seems a lot of users find this useful, so I could actually look into integrating it in gmenu2x if there is demand for such a feature.
I have a MKI though and I am happy with it so I wouldn't directly benefit from this :p
I would also have to look into having this coexist with the gamma settings (or removing them)
But before we could integrate it to gmenu2x or anything else we'd have to find a way to tell MKI's from MKII's. Would you know how?
 
Last edited by a moderator:
A_SN said:
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...
This is a great accessory.

Heh, the context switch probably takes more time than this does; but I always think code should be as optimised as possible B)

I personally would prefer not to have a process running in background doing this - why do the values have to keep being re-applied?
Is something else changing them back to the defaults ie what else accesses these registers? If so, can that be disabled or is it a hardware 'feature'?
Note, I have no idea what memregs16[0x295C] points to.
 
Last edited by a moderator:
kevcal said:
I personally would prefer not to have a process running in background doing this - why do the values have to keep being re-applied?
Is something else changing them back to the defaults ie what else accesses these registers? If so, can that be disabled or is it a hardware 'feature'?
Note, I have no idea what memregs16[0x295C] points to.
gmenu2x and gpfce change these values, and some others probably do too, so if you run these it ruins the fix, that's why it keeps being re-applied. I could make a check to see if things have been changed instead of systematically writing over and over again, but that wouldn't be much more efficient, would it?
 
Last edited by a moderator:
Fair enough - yeah wasn't advocating that - just wondered why it needed to keep 'doing it'. :)
Looking at this stuff makes me realise I ought to digest the MP2520F(?) databook.
 
Ryo said:
It seems a lot of users find this useful, so I could actually look into integrating it in gmenu2x if there is demand for such a feature.
I have a MKI though and I am happy with it so I wouldn't directly benefit from this :p
I would also have to look into having this coexist with the gamma settings (or removing them)
Yes, I think it would fit nicely in Gmenu2X. Because the MKII Fix is not in every app useful, a per game enabling/disabling would be the best. The Colour Correction option should be put in the Link settings. :)
 
Last edited by a moderator:
Cruel said:
Thanks! Its much better now, especially in dark games. :rolleyes:
Cool thing, i wonder if i can insert this in autorun somehow?
Of course, just call it from an autorun script.
 
Last edited by a moderator:
A_SN said:
Cruel said:
Thanks! Its much better now, especially in dark games. :rolleyes:
Cool thing, i wonder if i can insert this in autorun somehow?
Of course, just call it from an autorun script.


Not working here. If I run the autorun.gpu from the menu, it runs just fine. Unfortunately, it doesn't run on startup - and yes, I do have autorun enabled and the script is named correctly, and is in the root of the SD card :(

D.
 
Last edited by a moderator:
Dunny said:
A_SN said:
Cruel said:
Thanks! Its much better now, especially in dark games. :rolleyes:
Cool thing, i wonder if i can insert this in autorun somehow?
Of course, just call it from an autorun script.


Not working here. If I run the autorun.gpu from the menu, it runs just fine. Unfortunately, it doesn't run on startup - and yes, I do have autorun enabled and the script is named correctly, and is in the root of the SD card :(

D.


Well, well I'll release officially a finished version of it, it'll come with an installing script which will add some command for it to run somewhere in some file in /etc, so no autorun will be involved.

EDIT : It has been brought to my attention that you can do such a thing by editing /root/startup.sh
 
Last edited by a moderator:
Back
Top