so basically you want to find out how fast you can
update blocks of 64 000 pixels
I never said that. I wanted to find out why my frame rate was dependent
on the mouse activity.
You probably want to optimize that copying routine.
Game programmers would at least use MMX to do the
alpha checks for several pixels at the same time.
Not sure what that is.
In C, you can at least use logic calculations, to
avoid having to do "if then" for every single pixel.
Not sure what you mean here.
If by gcc you mean DJGPP: Pointers are protected mode
there, so everything is "far" in the sense that each
pointer can point anywhere in your allocated memory.
Maybe I need to check again, but I'm pretty sure VGA RAM is considered
outside my allocated memory.
Yeah I know about this, but I want my program to be compatible with
various video modes. Mode 13h is easy...
Easy yes, but also slow.
You missed the whole point of the first sentence you quoted.
"Optimizing" by using a better video mode that *might not be supported
by the hardware* is not a real answer. I *will* use VESA, but I will
*not* throw out plain VGA support just because it's slow. I'm not using
mode 13h because it's easy; I'm doing it because I want to support
pre-VESA hardware. The fact that it's easy is merely why I decided to
implement support for it *first*. By this logic, I could just as easily
assume faster hardware and be unconcerned with optimization, but that's
a non-solution that wastes everyone's time to consider.
Various games used a somewhat convoluted
variant with the same resolution but with pages and bits and so
on, just to have several pages to flip between.
I may very well eventually support page flipping in VGA, but it's simply
not what I'm trying to do right now.
Which settings are available for that BIOS idle slowdown? Maybe a
compromise is possible which has good frame rate but still saves
at least some energy :-)
There are no options. The setting is either on or off.
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 14:07, Eric Auer wrote:
Hi David,
so basically you want to find out how fast you can
update blocks of 64 000 pixels, starting at a VSYNC
and if possible taking at most very few VSYNC periods
until the update is done. Assuming ALL pixels change.
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.
You probably want to optimize that copying routine.
Game programmers would at least use MMX to do the
alpha checks for several pixels at the same time.
In C, you can at least use logic calculations, to
avoid having to do "if then" for every single pixel.
If by gcc you mean DJGPP: Pointers are protected mode
there, so everything is "far" in the sense that each
pointer can point anywhere in your allocated memory.
For Watcom, things depend on the target memory model,
whether you want to use real or protected mode etc.
I suppose I could remove alpha support from my screen
copying routine and only support it between bitmaps.
That can be a sensible optimization, but depends on what
your requirements are, so the decision is yours.
You mean without cutemouse, frame rate is fixed to 15 fps?
That probably means that the IRQ and I/O activities of cutemouse
do give your drivers or BIOS the impression that the computer is
busy, keeping it from entering lower clock states to save energy.
Yeah I know about this, but I want my program to be compatible with
various video modes. Mode 13h is easy...
Easy yes, but also slow. Various games used a somewhat convoluted
variant with the same resolution but with pages and bits and so
on, just to have several pages to flip between. The downside is
that you have to switch between different hardware pages and the
whole "one pixel one byte" thing is lost. So VESA would clearly
be less pain. The obvious way would be to use VESA when available
and fall back to MCGA mode 0x13 otherwise, even if it is slow.
It is probably not worth the effort to use complex VGA modes just
to have faster frame rates on ancient hardware when most computers
will have VESA anyway. So mode 0x13 is okay when VESA is absent.
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.
Which settings are available for that BIOS idle slowdown? Maybe a
compromise is possible which has good frame rate but still saves
at least some energy :-)
Regards, Eric
------------------------------------------------------------------------------
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
