Why are graphics so slow, especially in high resolution, in DOS?

DOS specific questions.
Post Reply
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Why are graphics so slow, especially in high resolution, in DOS?

Post by xlucas »

Actually, I know half the answer to this question.
I had been making a few programs with FreeBasic that I compiled for GNU/Linux, Windows and DOS and worked very well on the three of them. So far, they had all been in 640x480. For a project I'm working on now, this is unacceptably tiny, so I used a window resolution of 1024x768 and full screen that size in DOS. I am careful to use ScreenLock and ScreenUnlock where I'm going to execute several graphics statements in a row. In GNU/Linux and Windows, everything goes perfectly well. In DOS, the program does work, but the mouse cursor jumps like there are very few frames per second. Depending on the part of the program (on how much I'm drawing in my loop, to be exact), this can be from a little uncomfortable to very annoying. Later, I noticed this really also happens with lower resolutions, only that the effect is tiny. Even ScreenLocking, I can't help it. It appears like FreeBasic is taking too long to copy the screen to the linear frame buffer, except that I can't see the sweeping.

Is there anything I can do about this? Why does this happen? I'd thought it would take the same amount of time to copy the same amount of memory regardless of the OS.
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by fxm »

In DOS, the mouse arrow does not react to mouse movements while the screen is locked.
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by xlucas »

You mean it would actually be better in DOS to just not use ScreenLock/ScreenUnlock? Uhm... I will try that, but in theory, that will cause the screen to be redrawn for every sentence, which will be slower :S
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by D.J.Peters »

May be your DOS/BIOS VESA driver is version 1.1 and is banked in blocks of 64KB not a real linear frame buffer !

Joshy
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by counting_pine »

Maybe instead of screenlock/screenunlock, you could do all your drawing in another frame, and use screencopy (instead of screenunlock) to update the visible frame.
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by xlucas »

@fxm: Undefining ScreenLock and ScreenUnlock and redirecting them to an empty function when compiling for DOS indeed prevents the mouse cursor from skipping frames. Of course, it's now producing other artifacts, since my code was relying on the screen not being painted until the process was finished. I can minimise the effect with some tricks, but there will still be some of it and of course, I'm aware that now the screen is being fully updated much more often, so I'm using more CPU. Anyway, what you said helped. Thanks.

@Joshy: I have to test that to make sure, but I'm pretty certain that my graphics do support VESA 3.0. Anyway, now you've made me contemplate this possibility. I'm going to call the interrupt function from DOS to see what it gives me back. Even if my card does support 3.0, if there are still some that do not, I must make sure the program will run well on those too. Thanks for the tip!

@Counting_Pine: That's a very, very good idea! I could use a default output screen other than the visible one, so I don't even need to modify all my graphical sentences. How come I didn't think about that? This is the solution I was looking for. Thanks!

Now... I'm still concerned about one thing: if I can see the mouse cursor skipping frames when I use ScreenLock/ScreenUnlock around just a couple of graphical sentences and it's clearly noticeable, then it means not only the mouse cursor, but everything is being drawn with a noticeable delay. This does not seem to happen in GNU/Linux or Windows. How is the redrawing of the screen triggered? Is it synced with the vertical retrace? Does the clock interrupt at its default (lowest) speed have anything to do with it in DOS? Because if it were so, then it would make sense that every ScreenUnlock would wait till next clock (up to on 18.2th of a second) and then, possibly, to the next vertical retrace, causing a significant slowdown.
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by xlucas »

Verified I have VESA 3.0.
I tried something like what Counting Pine suggested, but didn't work:
- I made a FakeScreenLock routine that created a counter like that used by ScreenLock and, when the counter was at zero, used ScreenSet to change the active page, but not the visual one, so everything got written to that one
- I made a FakeScreenUnlock that also used the counter and, when it reached zero, copied the contents from page 1 to page 0 with ScreenCopy and then used ScreenSet 0, 0 to return graphics to normal
- I #undef'd ScreenLock and ScreenUnlock and #define'd them again as these two routines
- The result was the same as with the original ScreenLock and ScreenUnlock. It looks like FreeBasic won't draw the mouse cursor if the current active page is not the same as the visual page???
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by MrSwiss »

@xlucas,

as far as I can recall (the old DOS times), the BIOS-Interrupt 10 (screen), is very slow.
The only alternative I know of, was writing straight to (VGA) Card-Memory, using ASM ...
(very much forbidden, by Micros...t)
DamageX
Posts: 130
Joined: Nov 21, 2009 8:42

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by DamageX »

You might need to use utilities such as FASTVID or MTRRLFBE to enable write combining for faster screen updates under pure DOS.

With write combining enabled, sequential writes (eg. framebuffer copy) to video memory usually become 2-3x faster.
DavidS
Posts: 3
Joined: Sep 27, 2016 3:55

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by DavidS »

As FreeBASIC writes dirrectly to the FrameBuffer on DOS, and locking the screen prevents redrawing the mouse pointer, you should definitely use offscreen buffers.

And for actualy updating the visable screen, instead of flipping the page it would likely work faster to just use get/put to blit the updated areas only (doing so while the screen is locked, to prevent artifacts from the mouse cursor).
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: Why are graphics so slow, especially in high resolution, in DOS?

Post by xlucas »

Thanks, guys. Yes, I think ScreenLock and ScreenUnlock were the whole problem. They do seem to trigger something slow in DOS. I disabled them completely for that platform and everything looks fine now. Of course, the screen is painted more slowly than in Linux and Windows, because it's being refreshed on every statement, but it does not flicker and now the mouse pointer moves smoothly :)
Post Reply