> 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
