Hacking Skinning problem, M3 Real, image crashing DS

[Hidekiadam]

Hihi

I have a skinning issue

The top desktop image should be 256x192x256colour uncompressed .bmp file aye?

This worked fine for my LCARS skin, however now I'm working on another and this image:

Conveniently available at http://www.pokenet.co.uk/misc/skins/top_desktop.bmp

is causing the DS to crash, I've recreated it three times and every time it displays fine but crashes immediately after loading

Feel free to try it, is this an issue with the 3.0 firmware or am I missing something, given the image was created in exactly the same way as the other images I can't see what could be doing it... (I've dropped it into a completely working skin to make sure it's no other files and it isn't)

Any help would be appreciated!

Thanks

 

[innercy]

Hihi

I have a skinning issue

The top desktop image should be 256x192x256colour uncompressed .bmp file aye?

This worked fine for my LCARS skin, however now I'm working on another and this image:

Conveniently available at http://www.pokenet.co.uk/misc/skins/top_desktop.bmp

is causing the DS to crash, I've recreated it three times and every time it displays fine but crashes immediately after loading

Feel free to try it, is this an issue with the 3.0 firmware or am I missing something, given the image was created in exactly the same way as the other images I can't see what could be doing it... (I've dropped it into a completely working skin to make sure it's no other files and it isn't)

Any help would be appreciated!

Thanks

try creating 24bit image... actual size is 147,512kbyte.. 256bitmap will cause problem.

 

[Hidekiadam]

Hihi

No, this is for the top desktop, which should be 256x192x256 colours, the bottom desktop is a truecolour bitmap, bear in mind I did do the lcars skin without shooting myself in the foot and checked the inbuild skins too :-)

As part of my playing I did try a 24 bit image but that was obviously wrong, didn't display correctly and still crashed, the current one does display correctly but crashes

Can somoene with an M3/G6 actually try this image to see what I mean? (or better yet, perhaps the developers who lurk here might want to check it out, it being a genuine bug and all! given it's likely a buffer overflow and could be potentially exploited to dump out all the stuff they don't want me to see you'd think they'd be falling over themselves to fix it)

Thanks ^^

 

[ridgecity]

do you mind if I mod it a lit bit to try to make it work?

 

[xJonny]

That's odd, I think it should be working unless I've forgotten something too

 

[Hidekiadam]

Hihi

If you can tell me how to make it work, sure, have you any idea what is causing this?

Hang on, I'll upload the truecolour version so you have a less mangled one to work with

http://www.pokenet.co.uk/misc/skins/top_desktop24.bmp

Note that it can be quite tricky to get it looking good in 256 colours, I used the PSP 7 feature to 'weight' particular areas so those colours get priority

Thanks ^^

 

[xJonny]

It's supposed to be an 8 bit 256x192 pixel bmp file.

And I think that's the only requirements it has to be.

 

[ridgecity]

the problem is in the window area where the rain drops are, the gradient from white to light blueish is too big, the top screen loads but doesn't leave any memory left for the botton screen and buttons to work.

I can't find the right combination to make it work, but you have make it have more contrasting colors and lower the brightness in the window area. the skinning doesn't like bright gradients...

is that your girlfriend?

 

[Hidekiadam]

Hihi

Well, yes, this I realise, and yet, it isn't working! lol

Posted the 24bit one because Ridgecity wanted to have a go at making it work and it'd be better to use as a starting point the image with all the colours in ;p

Posts merged

Hihi

the problem is in the window area where the rain drops are, the gradient from white to light blueish is too big, the top screen loads but doesn't leave any memory left for the botton screen and buttons to work.

I can't find the right combination to make it work, but you have make it have more contrasting colors and lower the brightness in the window area. the skinning doesn't like bright gradients...
Well, given it's a .bmp and all .bmp are the same size I can't see why it'd use that much memory, after all, 256x192 with one byte per pixel is only a paltry 48K of RAM needed, even with the 4MB limitation, that's nothing -.o

bear in mind all the loader does is load it and leave it on that screen, it doesn't really have to do anything else with it since the top screen isn't used at all, while I'm not saying that definitely isn't the reason, if it is there's been some very poor programming on the part of those who wrote the shell!
QUOTE(ridgecity @ Mar 3 2008, 09:00 PM) is that your girlfriend?

Sadly not

Deviantart girl from Latvia, one of her portraits

 

[ridgecity]

I've ran into this problem 1000 times, and I understand you, if this "invisible limit" wasn't on the skins I would probably have 20 more skins up here, but The only way I have found a workaround is leaving some parts black or dark blue and a very dark grey. I see it as "bright gradients are your enemy limit" and I think the limit is more of a how bright are the pixels rather than a size limit.

the picture is nice... I do wish these guys made the skinning part easier for us. but remember there are less than 20 M3 G6 REAL skinners probably in the whole world, when I started making skins I think there were like 3 skins and a couple were "wip" like that lawyer skin...

you could say we are the pioneers of skinning the REAL cards! lol!

 

[Hidekiadam]

Hihi

I've ran into this problem 1000 times, and I understand you, if this "invisible limit" wasn't on the skins I would probably have 20 more skins up here, but The only way I have found a workaround is leaving some parts black or dark blue and a very dark grey. I see it as "bright gradients are your enemy limit" and I think the limit is more of a how bright are the pixels rather than a size limit.

Hmm, oddness, I wonder if it's an overflow due to dodgy math with the palette entries

If it is I have a fair idea of how to fix it...

the trouble is most art packages will create a 256 colour image assuming a 24 bit palette is available and on the DS you get 15 bits, so perhaps if an entry is over 11111000 which would be the highest meaningful value on the DS (since the 3 least significant bits in the R, G, B entries would be ignored) it has problems, hrm...

Off to play and see if I can work it out, thanks ;p

Posts merged

Hihi

Yes, that was the problem, have a working solution now

In paint shop pro, go to adjust brightness/contrast and reduce the brightness by 10 and the contrast by 5, the difference isn't really visible but the crashing problem goes away!

Thanks for your help everyone!

(and to the M3 team, how about writing bmp decoding routines that actually work?)

 

[xJonny]

Ah, glad you have sorted it out, the solution may be of use to others in the future

 

[ridgecity]

Hihi

I've ran into this problem 1000 times, and I understand you, if this "invisible limit" wasn't on the skins I would probably have 20 more skins up here, but The only way I have found a workaround is leaving some parts black or dark blue and a very dark grey. I see it as "bright gradients are your enemy limit" and I think the limit is more of a how bright are the pixels rather than a size limit.

Hmm, oddness, I wonder if it's an overflow due to dodgy math with the palette entries

If it is I have a fair idea of how to fix it...

the trouble is most art packages will create a 256 colour image assuming a 24 bit palette is available and on the DS you get 15 bits, so perhaps if an entry is over 11111000 which would be the highest meaningful value on the DS (since the 3 least significant bits in the R, G, B entries would be ignored) it has problems, hrm...

Off to play and see if I can work it out, thanks ;p

Posts merged

Hihi

Yes, that was the problem, have a working solution now

In paint shop pro, go to adjust brightness/contrast and reduce the brightness by 10 and the contrast by 5, the difference isn't really visible but the crashing problem goes away!

Thanks for your help everyone!

(and to the M3 team, how about writing bmp decoding routines that actually work?)

can you explain it in simpler terms??

it doesn't work in photoshop...

Posts merged

what do you mean "if an entry is over 11111000 which would be the highest meaningful value on the DS"?

what is that

 

[Hidekiadam]

Hihi

Is there a way to adjust the brightness and contrast of a truecolour image in photoshop? I use Paint shop pro 7 so I don't really know...

If so, then start with 16.7 million colour image

Crop/resize to 256x192

Adjust brightness and contrast, drop the brightness by 10% and increase the contrast by 5%, those numbers might need adjusting on photoshop but I'm sure the option will be there

Reduce image to 15 bit colour with error diffusion if you can

Reduce image to 256 colours, optimised octree palette if possible, if there's an option to weight parts of the image like in PSP then select the face and tell it to give additional weight to those colours before reducing to 256

Save as uncompressed 8 bit .BMP, should work

 

[ridgecity]

mmmm... let me try...

 

[Hidekiadam]

Hihi

what do you mean "if an entry is over 11111000 which would be the highest meaningful value on the DS"?

what is that

Ahh, your 24 bit image, each pixel has 8 bits of R, G, B, likewise so do the palette entries in a 256 colour paletted image

The DS uses 5 bits for each of R, G, B, so throws away (or should) the three least significant bits

In binary your 24 bit entry would be like RRRRRRRRGGGGGGGGBBBBBBBB for the palette entry for each of the 256 colours (or each pixel in a 24 bit image)

Due to limitations on the DS, not all of this is used, it only actually sees, say RRRRRXXXGGGGGXXXBBBBBXXX where the bits marked with X are ignored

the DS actually I think uses 16 bit palette entries, sort of RRRRRGGGGGBBBBBA (or BBBBBGGGGGRRRRRA, not sure), so some conversion would be needed to get the 24 bit values down to 16 (15) bit, I suspect the problem occurs when the bitmap has an entry where one of the bytes in the palette is above 11111000 and overflows causing a crash, it's certainly a programming error on the part of the M3 team but can be avoided just by making the image slightly darker so no value is actually that high (which is what I tried and worked)

 

[ridgecity]

I'm not getting the "Reduce image to 15 bit colour with error diffusion if you can" after I do it it looks very pixelated...

how can i look for that over 11111000

 

[ridgecity]

I can't make it work in photoshop, so I'm downloading PSP trial, where's the reduce to 15bit option?

 

[ridgecity]

ok. I got your image working!!!! but how can I find if a value is going over that 11111000 limit? how can you check it?


photoshop couldn't make it work and Psp on the first try... stupid adobe... lol

 

[Hidekiadam]

Hihi

It probably does work in photoshop, somehow, the reduce to 15 bit isn't really needed, but since the DS display is 15 bit it might make the final image look a bit better, try with and without really, lol

As for how to find, I dunno, but in the adjust contrast/brightness tab, -10 brightness and +5 contrast definitely works, you might want to try -6 and +3 or something too, it's just a case of play with those numbers to get the smallest required change that doesn't cause it to crash

You can check the numbers with your ink dropper (?) tool.. (not sure if that's the right name, the one you use to 'pick up' a colour from the image) and it'll show you the colour value for whatever you're hovering over as three numbers 0-255 on each, as long as no number is above 247 (say 239 to be on the safe side if you want) then you should be okay, if you put a bright white pixel somewhere in the image (255/255/255) then you can just check that pixel to be sure you have the right values

I realise it's not ideal but it works, lol