What hardware are you doing this on? Have you seen Allegro? [0][1]
[0] http://liballeg.org/stabledocs/en/index.html
[1]
https://github.com/liballeg/allegro5/releases/download/v4-2-3-1/all4231.zip
On Thu, Jul 19, 2018 at 5:42 AM David McMackins <cont...@mcmackins.org>
wrote:
> > 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 www.delwink.com
> www.eff.org www.gnu.org www.fsf.org
>
> 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.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
