does it happen with all cpu cores ?
(flag handling problem ?)

Yes, on all cpu cores, on all cores, etc...
No matter which option we put, always shows the graphic error (always talking about the build of emucr, which is what I use)

On irc, the problem has been identified. It will be fixed soon

How does breaking the OR operations into separate statements fix it? Does that mean other instances of multiple values ORed together in a single statement could be broken in VC?

The readHandler-functions have a side effect (templatch.d=...). With optimizations on VS swaps the two readHandler calls in readw(...) in VGA_UnchainedRead_Handler which results in the broken display.

Wouldn't it be in the VGA_ChainedEGA_Handler for this game? The readw() has two calls to readHandler() ORed together; but how are they "swapped" such that it makes a difference?

1    Bitu readw(PhysPt addr) {
2        addr = PAGING_GetPhysicalAddress(addr) & vgapages.mask;
3        addr += vga.svga.bank_read_full;
4        addr = CHECKED(addr);
5        return 
6            (readHandler(addr+0) << 0) |
7            (readHandler(addr+1) << 8);
8    }

The chained stuff is used for the 256 color VGA mode. For 16 color modes unchained is used.

MSVC executes readHandler(addr+1) first and then readHandler(addr+0) which causes the problem.

Doesn't gcc have some capability of warning if there's a (unintentional/harmful) dependency of sequence point evaluation?

1    case M_EGA:
2        if (vga.config.chained) 
3            newHandler = &vgaph.cega;
4        else
5            newHandler = &vgaph.uega;
6        break;

I put in some log messages here, and the unchained EGA handler is being activated for this game; and also on all the EGA side-scroller games from Id and Apogee that I've tried. Sorry, was unchained.

Why does changing the order of the readHandler calls make a difference? Same values and bitshifts get ORed together either way... unless you're saying the bitshifts are applied to the wrong values in spite of the parentheses that specifically state which shifts go with which values...

I/we didn't investigate further.

The difference is the last-latched value.

You guys are geniuses, i just downloaded the latest svn of dosbox from emucr (r3720) and the problem was fixed.

Million thanks for your time and cooperation 😉