non-working nb file PROBLEM SOLVED
sure mate. the padding will defo be different as you certainly use a different bmp picture. i am very astonished that my padding is so close to your padding even.
The other difference is, if you didnt forget to type it in your post, the "-s" argument, which defines the Smartphone format.
did u use that when creating your nbh?
and on the other hand: my bitmap works for sure. it did work in the first attempt when i created the nbh with the rom tool. it only doesnt work anymore since i involved the nbimg nbh function. since i created an nbh with that and flashed that one i cannot flash a custom splash anymore. only the stock one works.
weird isnt it?
I tested nbimg last night again with some combinations of arguments. while doing so i noticed that suddenly the conversion of the bmp to the nb does not work anymore. the very same bmp i used with the first go.
i then fetched that bmp from a backup location on a different disk because i thought maybe it got corrupted.
same stuff. parameters set as in my guide on the first go, bitmap corrupted when i converse it backwards now. always the rightmost 20 pixels are swithched over to the left side of the bmp. really weird as i did exactly the same steps as first time. and i did it about a hundred times, i also tried various other arguments, i tried to create the nbh with nbimg etc....
Reason for corruption: Signature.
Reason for bad flash ((no new splash installable after flash, white screen): wrong padding size.
NBIMG can add a smartphone signature if -s
is set. if this is not set it does not set no signature but it sets a "HTC Splashscreen signature".
Assuming the LEO is a smartphone, i set this argument. when i did the first go, i obviously forgot (yes, for real!) to set that option but i did not forget to set it when i tried it again afterwards (i wasn't drunk anymore).
when i looked at the two different nbh-files (the working one i did when i made my first attempt and the new one i did today) with a hex-compare-tool (UltraCompare) i found the reason for the mentioned pixelswitch right away. The Smartphone Signature is added right at the beginning of the nbh. The HTC Splashscreen Signature is located at the very bottom.
Seing this, i noticed that the actual data shifted by the size of the signature, which means the offset of the picture data is wrong when using the -s
argument. until then, i didn't notice the filesize difference yet.
So i redid the nbh file today without the smartphone signature, did a hash-check and was horrified to still see different hashes. so i compared them again with UltraCompare and found - nothing of any use.
Only then i checked the filesize and guess what?! the HTC Splashscreen Signature is exactly two bytes longer!!!
So this is why everyone else used 18400 for padding when i used 18402 for the shorter Smartphone Signature (obviously when doing this first i not only forgot the -s
argument but also got the padding wrong, i presume i copied the commandline from this thread instead of creating my own. I think i was very drunk then).
This brings me to one more question: why was i thinking that i need to calculate my padding value myself when it seems to be the same for everyone?
Does NBIMG reduce the bitmap-size to a standard-value when converting it? It looks like.
That would imply that we don't need to make such a big fuss about the padding value.
I re-did the guide. Please do not use version 1.1 as it contains the wrong commandline. Version 1.2 contains correct info now.