What cycles setting are you using? If you are using max cycles, that is not a specific amount; rather, DOSBox tries to guess the amount needed. Also keep in mind that DOSBox uses internal callback code for BIOS functions, not code that executes on the emulated CPU as on a real system, and that internal code appears to execute almost instantaneously according to any timekeeping within the emulation, which complicates benchmarking against real systems.

ripsaw8080 wrote on 2021-02-08, 12:54:

What cycles setting are you using? If you are using max cycles, that is not a specific amount; rather, DOSBox tries to guess the amount needed. Also keep in mind that DOSBox uses internal callback code for BIOS functions, not code that executes on the emulated CPU as on a real system, and that internal code appears to execute almost instantaneously according to any timekeeping within the emulation, which complicates benchmarking against real systems.

No. That's not the point. I was testing it by using default settings (I guess it is 3000 cycles).
My point is the specific behaviour of DOSBOX .... it starts with high speed and is slowing down 2-3 secs later significantly.
I am using DOSBOX on a Ryzen 7 3700X system with NVMe SSDs...

Just test it by yourself and you will see what I mean.
The program behaves totally different in PCem for example. It runs continuosly with the same speed, not slowing down while running.

Peter z80.eu wrote on 2021-02-08, 12:58:

it starts with high speed and is slowing down 2-3 secs later significantly.

If you're referring to the appearance of animation in the colored blocks, that remains consistent for me throughout the ~5 second running time of your program, there is no slowing down here.

Do you see the slowing down you refer to in SVN as well as 0.74-3?

I tested with default settings, which includes output=surface; and also with default settings except for output=opengl. Maybe try different output methods at your place.

I want to emphasize my earlier point about the internal callback code. It is so fast within the emulation that it could, depending on host factors like the display and drivers, create apparent patterns that aren't really there. I see this using your program when using much more than 3000 cycles, where there appear to be shifting bands of the blocks, but that's just patterns evolving from the rapidly changing image and the way DOSBox renders.

BTW, loading a video BIOS in DOSBox will create a more level playing field against real systems. For example, loading the IBM VGA BIOS with 3000 cycles results in 36 loops in your program vs. 175 with the internal callbacks... no small difference. To load a video BIOS you need a debug version of 0.74(-3) or SVN.

May be it's related with the sizing / the size of the DOSBOX Window - I'm using one almost twice sized (compared to the unscaled size). Or in other words, my DOSBOX window is resized to a bigger size than the default offers.

I guess these parameters may influence it, too (settings come from dosbox-0.74-3.conf):
fullscreen=false
fulldouble=false
fullresolution=original
windowresolution=1280x960
output=ddraw

I tried output=ddraw and see no difference. Different window sizes, scaler settings, and fullscreen also appear the same. Actually, I usually use windowresolution=1280x960 with output=opengl and aspect=true (scaler=normal2x in 0.74, but scaler=none and glshader=sharp in SVN).

You seem to be experiencing something that is not necessarily typical of DOSBox users. Maybe try capturing a video of your program with DOSBox and watching it in a media player to see the difference.

I hope someone else can also reproduce the strange behaviour, but yes, I can try to capture it (hopefully capturing will not influence it) and publish it on Youtube.

I've tried to capture it, see https://youtu.be/hsuNpOgipDg - in reality (without capture, without youtube), the slowing effect and the end can be recognized a bit better.

Peter z80.eu wrote on 2021-02-08, 12:58:

No. That's not the point. I was testing it by using default settings (I guess it is 3000 cycles).

The video clearly shows you are using max cycles, and my point about that remains.

That was correct, I looked into the .conf file, and there was indeed max, but set to 5000 shows still the mentioned slowing down effect. Set to 4000 makes it less visible, using 3000 it is almost invisible.
So what is the exact explanation if cycles > 4000 are used ? Why is this so "parameter cycle" dependant, but other emulators like PCem does not show this effect ?

1) Have you tried with output=opengl?
2) What refresh rate is your monitor running at?

If the emulated screen is being updated at 70Hz but your physical screen only refreshes at 60Hz, you'll get bad performance. Usually this is mitigated because DOSBox performs "lazy" screen updating, redrawing only when the content actually changes. OpenGL can also help because it attempts to disable vsync (not always successfully).

I see no relationship between the Windows monitor refresh rate and the emulated screen, because even the captured screen (with only 30 frames/sec) shows the effect. But anyway, my monitor is set to 75Hz.
I can try OpenGL instead of DDraw, but I choosed DDraw, because in the past, I was not able to change the size of the DOSBOX window smoothly with the OpenGL setting.

opengl looks a bit more blurry/blurred but shows the same effect. The only parameter which influences it drastically is "cycles", as mentioned before. Setting it below 4000-5000 will stop the slowdown, if set to max it has also the most slowing down effect. I will try to accept it, also because if I know that I should not set cycles to max, no unwanted effect will occur again.

I tried the benchmark and I noticed no slowdown. I tried various cycles and everything looked fine. I'm using Linux and also Ryzen 7 3700X.

What power plan are you using? Is there any difference if you use High Performance ?

No power plan, DOSBOX is running with Windows 10 Pro on a Desktop PC (always max. CPU performance). Although I appreciate Linux too, I didn't tried it here (but I will try it with a Life CD for sure).