Your definition of "force full redraw" sounds odd. What
should be forced by that? A graphics library? Hardware?
I suppose I'm not explicitly forcing, but since every pixel on the
screen is being changed, it shouldn't be something weird where the
hardware is not actually doing what I ask as an optimization.
Indeed. Do you use a fast way of writing the graphics memory,
such as the "string and block processing" Assembly language
commands or at least a library function in the programming
language of your choice which internally uses them?
No. In fact, my copying routine is extra slow, because since mode
13h
doesn't have hardware alpha checking, I have to do it myself.
Basically
I've defined my own alpha mask, and so I have to check if it's on
before
drawing to the screen. Also, I don't even know of a copying function
that supports far pointers in gcc, and I want my program to work
with
both Watcom and gcc. I suppose I could remove alpha support from my
screen copying routine and only support it between bitmaps.
You mean without cutemouse, frame rate is fixed to 15 fps?
More or less. I'm not measuring the rate each frame, but rather the
execution time of this program which has a fixed number of frames it
draws. This of course varies a little bit between runs, but the
difference when moving the mouse is very significant, and at these
frame
rates, it is even visible to the eye.
PS: Mode 13h is a bad choice for high frame rates. Try a VESA
mode with enough RAM for 2 or more frames, so you can update
one during the full time when the other is visible, then flip.
Yeah I know about this, but I want my program to be compatible with
various video modes. Mode 13h is easy when just getting started to
test
that the other graphics functions are working instead of worrying
about
if my VESA tricks are working. My program will eventually target
basically all DOS graphics modes. "Use something that you don't know
exists on your target machine" is not a solution.
P.S. I did some playing with BIOS power settings and found that
indeed
the BIOS can be blamed for this behavior. Even while leaving OS
power
controls enabled, disabling the "idle slowdown" fixed the issue.
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)
www.mcmackins.org [1] www.delwink.com [2]
www.eff.org [3] www.gnu.org [4] www.fsf.org [5]
On 07/19/2018 04:53 AM, Eric Auer wrote:
Hi David,
I've discovered something weird (to me). I'm on a 1998 Sony Vaio
with a
Pentium 3 processor running FreeDOS 1.2. I have a test program
which
draws 64 full frames to the screen via VGA mode 13h. Each frame
is a
different color to force a full redraw. In addition, I draw a
1-pixel
mouse cursor onto the frame buffer before copying.
Your definition of "force full redraw" sounds odd. What
should be forced by that? A graphics library? Hardware?
I regulate the frame rate by explicitly waiting for the vblank
period
before doing the buffer copy to VRAM. Normally, my program gets a
frame
rate of about 15fps. This seems a bit slow given my processor
speed.
Indeed. Do you use a fast way of writing the graphics memory,
such as the "string and block processing" Assembly language
commands or at least a library function in the programming
language of your choice which internally uses them? You can
for example use "rep stosd" to full a buffer of N * 4 bytes
at a speed of 4 bytes per iteration, or "rep movsd" to copy
from one buffer to another at the same speed. A good compiler
with 386+ awareness will automatically chose a good memcopy,
move, memcpy, memset or whatever you are using right now,
using variants optimized for your chosen CPU generation.
However, I've noticed if I am moving the mouse, the
frame rate doubles to nearly 30fps. [... but it ...]
stops happening (always low frame rate)
if I unload CuteMouse before running the program.
You mean without cutemouse, frame rate is fixed to 15 fps?
This is with a PS/2 mouse and the laptop's trackpad, which I
think is
also a PS/2 device since when I tell CuteMouse not to load from
serial,
it still loads the trackpad.
Your BIOS or drivers probably measure how busy your computer
is and throttle the CPU when it is not, lowering your frame
rate. The trackpad might actually be USB based with your BIOS
just simulating PS/2 based on the actions. You can also check
whether you use FDAPM or the IDLEHALT kernel options or have
BIOS settings about energy saving active. Of course you will
not want to waste battery, so it is probably better to make
your program "look more busy" to the energy drivers WHILE it
is important for you to have full speed, as opposed to just
disabling the drivers, but having minimal battery endurance.
Regards, Eric
PS: Mode 13h is a bad choice for high frame rates. Try a VESA
mode with enough RAM for 2 or more frames, so you can update
one during the full time when the other is visible, then flip.
