[BG] Tell me how stupid I am...

[Frostmork]

...nothing would currently make me happier I believe.


So, I know this "problem" have been up lots of times already, but I can't for the life of me get the damned background color on the start menu to change.

So it's the first time I've even thought about modding a game and like usually I get dug down to my ears with things. So I made all the sprites I wanted to and got so far as to realize I need reshacker. So I got that as well and made new images there as well. So all is fine and dandy but then I was getting bugged on the title so I quickly realized I needed to "go hex" to get what I wanted. Said and done, I got hex workshop and managed to figure that out, sort of. So I got the credits to go away and managed to change the name as well, jubilations! But then I wanted my otherwise green colored game to not have a blue background and I'm almost at the point right now where I'd rather re-color all the sprites to get this right.
I tried to find the color in Photoshop at first but that one doesn't seem entirely accurate and thus I couldn't find the color in Hex Workshop. Tried paint but with no luck. So I tried to get the suggested tool (FarbH) from here but due to possible virus attacks I couldn't get that tool (OfC.). So I got another one and it told me the background color was: 10206C
Great! So I searched for that.
Didn't find anything.
So I found some threads here saying it was simply: Start screen address: 000271aa and the value should be 6c2010.
My row 000271aa has: 75F72B. So a bit annoyed I tried to change it to 121212 anyways to see if it maybe was that one. NOPE. Nothing happened. When I restarted Hex Workshop again the lines were back to 75F72B again. So Ive tried all sorts of hex colors at any line that seems even the faintest bit of similar to a color hex and after five hours on the same page I've come to the conclusion that things aren't going so well...

So after being dead on stuck at trying to get the bloody color to change I've decided to check here for help and see if anyone have any idea on what I manage to screw up on such a tiny operation on such a level that nothing works, I'd be extremely grateful, and no, having a blue background is not an option, it'll ruin the whole game! (I'm sure of it!)

Simoneon edited this post 03-29-2016 02:50 PM because:

you're not stupid, you're beautiful :3

[YinYin]

Some colours in there are in BGR format rather than RGB.

[Silverthorn]

Start Address: 270ca, Hex value: 6c 20 10 [BGR]
Change to a value of your choice, for illustratory purposes, I chose 00 00 ff.

Basically, grab a hex-editor of your choice and search for the hex-value "6c2010" or, in general, the color you'd like to edit. Some are encoded as RGB, some as BGR. The loading screen is an embedded image. Some years ago I actually listed up pretty much every solid color there was in LF2, viewable in this thread. Note that the offsets (first number) are for 1.9c, iirc, so they'll most likely be something else for 2.0(a). They however should give you an idea about the different color-values and in which format they're specified

Ramond edited this post 03-23-2016 08:45 AM because:

Chickie Bear is back

[Frostmork]

That thread was giving me a 404 yesterday, seems to work just fine today though.

And now it works! I never got that you should use BGR, I was typing in my desired color in hex a couple of hundred times... I still find it odd that I did search for 6c2010 yesterday as well and edited it out and nothing happened. Oh well, it works all fine today for some reason, the wonders of sleep I guess? And yea now that the thread is alive and well again so I can reference to that!

It does feel a wee bit more effective to wake up and get stuff done compared to spending hours upon hours getting nowhere tho.
It's almost like the program was rejecting me yesterday knowing "Hey, ya really shouldn't be doing that right now..."

I also just realized that I /really/ should've taken note of every adress as I was passing by as I decided to go with black on quite a few places, and "000000" is /really/ easy to find. Oh well, some other day perhaps.

[A-Man]

I hope I'm not going off topic (even though the title doesn't really suggest a topic; instead it seems to be more of an inquiry about the person's behavior), but the body of the post implies this is about LF2's color format. So I will ask here.

Why did Mr. Marti/Starsky go with BGR anyway? Was there an advantage or a limitation/convention (related to Big Endean vs Little Endean) with such color format back then? Why are there only *some* colors that are represented that way in the exe?

[NightmareX1337]

Why did Mr. Marti/Starsky go with BGR anyway? Was there an advantage or a limitation/convention (related to Big Endean vs Little Endean) with such color format back then? Why are there only *some* colors that are represented that way in the exe?

As far as I know, x86 processors use little-endian, this some times result in reverse byte order when an union like the following is used:

C++-Code: union Pixel { struct Color { char a; char r; char g; char b; } color; int px; };

When used without caution, above struct may result in different behavior between little and big endian systems (and even between different APIs which treat them differently; and even between GPU and CPU). When you write pixel.r = 255; you can easily mess up things because you don't know if you are assigning to Red or Green part that graphics API actually thinks.
I myself encountered this kind of problem too. I was putting blue vertex colors into memory and they were coming out rendered red :D
So, here I'm guessing that DirectDraw equivalent of glClearColor() accepts BGR format (probably for performance reasons).

[someone can correct me if I'm wrong]

[Frostmork]

He made it to mess with people, that's how programmers gets their kicks, I'm quite sure of it. It would be heavenly if they would've gone for a config file to put colors and image references in but I'm sure they're going to forums like these and searching for posts like this and laughing.
I would've done that.

[Boop]

Why did Mr. Marti/Starsky go with BGR anyway? Was there an advantage or a limitation/convention (related to Big Endean vs Little Endean) with such color format back then? Why are there only *some* colors that are represented that way in the exe?

As far as I know, x86 processors use little-endian, this some times result in reverse byte order when an union like the following is used:

[someone can correct me if I'm wrong]

You are correct about the endianness, the rest of your post goes on and over complicates it IMO. I don't see how structs come into play here. The compiler makes sure everything is right for you (unless you rely on undefined behaviour).

Marti most likely didn't know or care about what the compiler would spew out as long as the result was correct. He would just write the color he wanted and pass it as an arg.

In assembly it would become:
push color

When it is assembled, because x86 is little endian, the color becomes "reversed".

If you edit colors in a dissambler (like ollydbg) you don't have to worry about it .

[A-Man]

When it is assembled, because x86 is little endian, the color becomes "reversed".

If you edit colors in a dissambler (like ollydbg) you don't have to worry about it .

Oh, I was very puzzled because I do remember modifying the exe colors with ollydbg, after picking the color with paint and searching "push 0xRRGGBB" and changing occurrences of that. This explains why I never came across this BGR stuff.