Why VGA_StartResize() has 50 ms delay? \ VOGONS

Why VGA_StartResize() has 50 ms delay?

Topic actions

Post a reply

First post, by jaclfh

Posted on 2020-07-08, 16:38

jaclfh Offline

Rank Newbie

Rank: Newbie
Posts: 9
Joined: 2008-12-16, 20:30

Hi,

Why does VGA_StartResize(Bitu delay) in SVN have 50 ms delay by default?

Apparently, when an application sets a mode such as 13h ("mov ax,13h", "int 10h") and int 10h returns the mode has actually not been setup yet even though an application will think it is. This delay seems to be why the demo No! by Nooon runs too slow. The demo seems to measure FPS for the mode (12h and 13h) and then sets up PIT timer based on that, but since it measured the wrong FPS, the animation ends up running with half the correct speed.

The following patch fixes No! (but may break some other stuff?).

1--- include/vga.h~	2020-04-25 23:05:04.000000000 +0300
2+++ include/vga.h	2020-07-08 18:57:34.186746462 +0300
3@@ -417,7 +417,7 @@
4 void VGA_SetMode(VGAModes mode);
5 void VGA_DetermineMode(void);
6 void VGA_SetupHandlers(void);
7-void VGA_StartResize(Bitu delay=50);
8+void VGA_StartResize(Bitu delay=0);
9 void VGA_SetupDrawing(Bitu val);
10 void VGA_CheckScanLength(void);
11 void VGA_ChangedBank(void);

Reply 1 of 1, by ripsaw8080

Posted on 2020-07-08, 18:42

ripsaw8080 Offline

Rank DOSBox Author

Rank: DOSBox Author
Posts: 5034
Joined: 2006-04-25, 23:24

AFAIK, the main reason for the delay is to allow for the display to be "tweaked", as in tweaking mode 13h into Mode X, with only one resize after all register tweaks are done rather than resizing for each one. See the conditions in vga_crtc.cpp where VGA_StartResize() is called. Without the delay, you get to watch the screen resize several times while Mode X is being set up.

It is a known issue that the delay can cause timing problems for those programs that measure display timing soon after setting or tweaking a mode, but there are actually very few games that do that. FYI, the delay only applies to the video hardware aspect, not to the video BIOS aspect of mode changes. The ideal way to fix the issue would be to de-couple updating the emulated video hardware display timing from window resizing, if you're looking for a programming challenge.

I don't know how 50ms was chosen, but have at times thought it was more than necessary, perhaps erring on the side of caution. However, I do know that any changes made there would require a lot of testing.

Go to top of page Go to top of page

Back to DOSBox Development

Main menu

Common searches