

Of course, I know that there are people that have no such a good luck and never seethe game running properly. This happens to me keeping all other vriable things fixed: same pc, same DxWnd confguration, same game installation & setup, sometimes it is only necessary to make several consecutive runs to see all four behavior.

In this moment you can have four differen reactions:Ģ) the game shows a black screen and is working, provided you could immagine where to click with the mouse!ģ) the game shows a sceen moved sideways to the right (always of the same amount of space!) and keeps working with the same offset (see screenshots from 6 to 11) Most of the game problems are located in a specific instant, at the end of the intro movie (when you have one, with the CD mounted, if you use a RIP version probably there is no movie at all) and before the very forst game panel. That doesn't mean it's a desperate case, but for sure I can stop looking for defects in DxWnd logic about surfaces and palette handling. The simple truth could be that the game is bugged. The sad news is that I'm starting to believe that the game has no problems with DxWnd and perhaps not even with ddraw support. Let me start with a note of optimism about this damned game: the french and uk versions are so similar in their behavior that whenever I may fix one I'll probably fix them both. Ok, back to this "cold case" USM98 (or FM98 in its french version). It is not a great result so far, but in case you may have a better luck, here is some stuff. And when it doesn't work there are good chances that setting a SDL blitter the game could work.

The attached release seems to react a little better than before, it enforces the palette destruction on ddraw close event, and sometimes (sic!) it works. Since in both cases the screen is set in 8bpp palettized mode, DxWnd has to create a service palette to color the surfaces, but ddraw doesn't like events such as failing t close a palette after the belonging ddraw session or using a palette belonging to one session on a surface belonging to another session. In any case, the problems seem to depend on this fact: the game opens a ddraw session, does something and closes it, then reopens another ddraw session. So, I'm now used to say hooray because the game works and then getting frustrated by a following failure. This game has some weird behavior, it seems to react differently if you run it two times in a row, like if it depended on some dll loading time, caching or what the fuck.
