Note that your (2) change in first post (Background color) seems to affect what the application takes for transparency color in the bmp images!
This list is a gem... absolutely great! I have almost all the odball colored stuff corrected now... looks very slick. How on earth did you figure out what is what? Are you peeking in assembly code?
I'm now hunting the white colors. I've got well over 400 possibilities here, so it could take some time.
That said, I've stumbled across the button transparency color: 0x56AC2
The color at that location defines the button bitmap transparency.
A large number of color locations have been added to the first post. I have also changed the descriptions for some of the existing locations in an attempt to standardize them.
2002 Mitsubishi Galant
Progress: 90% [-▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓- ->
Souund Blaster Audigy2 NX
OPUS ITX PC Case
There are 2 texts I am still trying to change the color...
1) The address of the current destination (not the 'Current Destination' text, but the actual address that is below it.
2) The text that says: "Continue to Final Destination?" as well as the address that appears right below it.
I hope you can find those 2!!
First, let me say that quoting my entire post is overkill to the extreme, plus doubles the image requests to my web server. At least edit your post to remove the images from my quotes. Thanks.
Now.. I use WinHex as my hex editor, but that's just personal preference. You can use any hex editor that you are comfortable with. Xvi32 is free and decent, but I prefer the way WinHex separates each row into two blocks of 8 bytes. I also like the "Position Manager" which is like xvi32's bookmarks, only more manageable.
I also know that with 32bit software, colors are usually stored as 8 byte DWORDs, normally in RGBA format. So if I want to find the color "blue", I just start searching for values that appear as "00 00 FF 00". Looking for yellow? How about "FF FF 00 00"?
Once I've found a possible color location, I replace it with something recognizable. For iGuidance, I haven't seen any bright purple, so I replace it with "FF 00 FF 00". Then I save the changes, start up iGuidance and hunt through the menus and screens for any purple. It's really a very tedious process.
Yesterday, I finally gave in and downloaded AutoIt. I built a quick and dirty script to hit up a limited set of menus that seem to contain all (or at least most) of the GUI elements. As the script hits up each menu, I have it scan the screen for purple pixels, then stop when it finds any.
Unfortunately for me, I found that there are a crapload of possible "white" color value locations. Most of the valid ones seem to start with a push to stack instruction (0x68) but there are 383 of those locations alone. So searching for "68 FF FF FF 00" reduces the hunt from 1305 locations with "FF FF FF 00" alone. Of course, the problem is that at least some of the remaining 922 locations without a preceding 0x68 also contain colors that are displayed in the GUI.
So lately I've been cheating a bit. If you can call it cheating anyway. I disassembled iGuidanceUMPC using IDA Pro. I've already got a decent sized list of valid color locations, so I can see that some patterns have emerged. Like, damned near all of the color values related to the "Current Destination" screens are located between 0x2AEC1 and 0x30DD0.
So now I can jump to 0x1AA3E in IDA, since it's the last known color location before the "Current Destination" stuff. Then I hunt through the assembly code for anything that looks like a static DWORD value from there until 0x32CF8 (the first known location after the current-dest stuff).
Still, it's all a very tedious process.
The daytime-street-name color discovery was almost accidental. I changed the nighttime value to "FF FF FF 00" and discovered the daytime color became a nasty purple. I took a screenshot to determine the actual shade of purple was "5F 00 5F".
So I figured that the location had to be near the nighttime value and started looking. I found the "60 00 5F 00" value in the hex almost immediately and figured it's probably close enough considering that the street-name text is anti-aliased. I changed the value and the daytime color changed as well, but not to what I had expected.
So then I had look up the 80x86 opcode instructions and discovered the values were being added. I should have disassembled in IDA at that point, because it's a lot more obvious in assembly.