dosbox doesn't care about the codecs of your os.

Thanks for that clarification, Qbix! 😀

Even tried reinstalling the games from the CD's and I still get that issue.

Is there a way to overcome that issue? I can only think of different output methods (which i think I've tried in the past) and maybe some core/cycle issue...

Does anyone else had this issues and/or found any solution?

well I recall that some cutscene problems were fixed by using a slightly different timing with respect to the vertical retrace. But this is tricky business as a there a lot of different systems games use to sync themselves to it.

well I recall that some cutscene problems were fixed by using a slightly different timing with respect to the vertical retrace.

Hmm... So by playing with different cycle numbers one might find a fix? Will try it later today after work.

But this is tricky business as a there a lot of different systems games use to sync themselves to it.

Despite having a fixed resolution and refresh rate in DOSBox as my desktop (800x600 @100 Hz), I've noticed also some "screen tearing" while playing in a few games (Desert Strike comes to mind). Can this issue be related to game needing to run at a specific number of cycles/speed? If so, I'll gladly do any tests in order to aid (even if only very slightly) in DOSBox improvements.

In the case of Death Rally (registered CD version 1.1), you can eliminate the strange flickering of the FMVs by running RALLY.EXE with a /W parameter. That parameter is for running in a Windows DOS shell, so I don't know what other effects it might have, but it seems to work OK in DosBOX 0.7x. For the issue with the FMVs, I suspect it alters how the VGA palette is manipulated.

That's great, ripsaw8080! Thanks for the tip! 😎

Will give the feedback later today.

I was aware of that option, but thought it would only be used for running the game directly in Windows... Always learning! 😉

It may ultimately be a system speed issue. I also use core=dynamic, cycles=max for DR; and the /W parameter may just give it the extra speed it needs to work better. I tried disabling sound, and that also stops the flickering even without the parameter. It's not so nice without sound, so I tried using GUS sound instead of SB, and that also stops the flickering without the parameter. With the SB16 sound, either 8-bit DMA channel 1 or 16-bit DMA channel 5, it flickers a lot without the parameter and just a little bit here and there with it. So it may just come down to speed.

I've come to the same conclusion, for now.... No matter what sound settings, cycles and using /w switch, the flickering varies in intensity, but never totally dissapears. It can be set to run nearly flawlessly, but there's still some room for (hope) future improvements. Still, maybe with other builds the outcome is different, who knows... Real life time is my main enemy now 🙁 However, I shall be persistent and try to squash the bug ( or hurt him as much as I can 😁 )