Did you ever see correct colors in your build?
The behavior is inconsistent, it may be some uninitialized variable somewhere. I am getting colors every time I run in CVS with only SVGA patch applied but I find it really hard to believe that my patch fixes bug in CVS and then some other patch reverts it exactly where it was.

I'm wondering why my clean cvs build without patches makes the colors strange. - !!! I meant I didn't apply any patches !!!
Can it be related to build environment?
Gulikoza's build also seems to be made in MinGW/MSYS. (I use that compiler.)

I am using VS.NET 2003 (a.k.a. VC7.1). I was not able to reproduce the issue in local builds. Now we start getting somewhere. There is a possibility of misgenerated code in MinGW but I would expect that to be somewhat more dramatic. Uninitialized variable is far more likely.

yes. an uninitialized variable might be the case.
(or as experience teaches us...... vs.net creating broken code.)

It could be a compiler issue. We had similar things happen with Exult as well. Some things worked in the gcc build and not in the MS compiler built and also the other way round. Worth checking.

Hmm..I didn't realize I sparked a manhunt. 😅 I wish you guys luck if you try to track this bugger down. As I said it works in 0.63 😢

Got it. My local build was missing one change that was in CVS, and it was the change that caused it:

2005-05-02 23:18 harekiet

* src/hardware/vga_dac.cpp: Some bizarre vga dac behaviour fixes
star control 2

Reverting this change fixes Wari but presumably breaks Star Control 2. Not good. The change looks really odd, I don't believe the hardware is supposed to work this way. I will have to dig out my copy of SC2 and check what's going on.

EDIT: Found the original thread: Star Control 2 palette problem
The change itself is three lines. The first line (in write_p3c7) makes sense in the connection to that described undocumented behavior, as odd as it is. The other two lines are less clear (moving read_index in write_p3c9 and write_index in read_p3c9). Removing them fixes Wari. I would not be surprised if only the first line is actually needed for SC2.

Brilliant! Good work my friend. 😎 I hope there is an easy solution to get both games working (even though I'm not familiar with star control)

Digged out my copy of SC2 (from Segasoft Sci-Fi Collection, not cracked) and played with it. Looks like I am right and only the first line of that change is needed -- SC2 seems to work fine after removing the other two, and Wari also works correctly in that case.
Relevant patch has been submitted to Sourceforge (patch #1255540).

EDIT: Looks like ykhwong's build has already been updated with this patch. That was really fast! Can anybody with a copy of SC2 verify that it is indeed still working properly?

well I recall it happened after playing a while (a few minutes at least)
Then the screen would suddenly get a wrong pallet

commited fix for wari.
overkill is broken since 0.58 I think

Ok. I'll just wait patiently for ykhwong's build 😀

EDIT - That was fast! 😳 Good work all.

Did not take long to find the problem with Overkill. In vga_memory.cpp the data sent to VGA_GFX_16_WriteHandler gets rotated according to vga.config.data_rotate. If you scroll up to ModeOperation and read comments you will see that this rotation is to be applied only in write mode 0 (which is correct). As implemented it is always rotated. Moving offending line from write handler to ModeOperation just under that comment fixes Overkill. I will do a little more testing and submit a patch to Sourceforge.

EDIT: The patch is on Sourceforge (#1256405). Overkill was indeed broken since 0.58 because data_rotate was implemented around that time.

Thanks vasyl, you rock!

And thanks in advance to Qbix for committing it to CVS 😉

Amazing 🤣 Two bugs killed in only what....2 days? This forum really does it's job!