You're asking questions about performance so of course the hardware
matters. And it also seems you're choosing a software path that is very
inefficient as well (maybe you're calculating an alpha channel & then
drawing pixels using the BIOS? Hard to tell; you're speaking vaguely). My
suggestion regarding Allegro was so that you could see how a very optimized
graphics library does it and then emulate it in 16-bit C.
On Thu, Jul 19, 2018 at 9:57 AM David McMackins <cont...@mcmackins.org>
wrote:
> I said at the very beginning of my first email what hardware I'm using,
> but I also said that I'm not just writing this for my own hardware, so
> that is really irrelevant.
>
> I'm not sure what this has to do with the topic at all. Yes, I know
> about Allegro. Allegro is big and fat, doesn't work on 16-bit, and is no
> longer actively receiving updates for DOS (the new version won't even
> run on it). Besides, you don't even know what I'm trying to do.
>
> "Have you tried using different software?" is not an answer to "Why is
> this program behaving this way?". You must be a regular on
> StackOverflow.
>
>
> 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 2018-07-19 09:48, Louis Santillan wrote:
> > What hardware are you doing this on? Have you seen Allegro? [0][1]
> >
> > [0] http://liballeg.org/stabledocs/en/index.html [8]
> > [1]
> >
> https://github.com/liballeg/allegro5/releases/download/v4-2-3-1/all4231.zip
> > [9]
> >
> > 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 [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.
> >>>
> >>>
> >>>
> >>
> >
> ------------------------------------------------------------------------------
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot [6]
> >>> _______________________________________________
> >>> Freedos-devel mailing list
> >>> Freedos-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/freedos-devel [7]
> >>>
> >>
> >>
> >
> ------------------------------------------------------------------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot [6]
> >> _______________________________________________
> >> Freedos-devel mailing list
> >> Freedos-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/freedos-devel [7]
> >
> >
> > Links:
> > ------
> > [1] http://www.mcmackins.org
> > [2] http://www.delwink.com
> > [3] http://www.eff.org
> > [4] http://www.gnu.org
> > [5] http://www.fsf.org
> > [6] http://sdm.link/slashdot
> > [7] https://lists.sourceforge.net/lists/listinfo/freedos-devel
> > [8] http://liballeg.org/stabledocs/en/index.html
> > [9]
> >
> https://github.com/liballeg/allegro5/releases/download/v4-2-3-1/all4231.zip
> >
> >
> ------------------------------------------------------------------------------
> > 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
