Mail Archives: djgpp/1995/02/16/04:49:13
Csaba,
I've been using your GRX 1.03 and there's on sugestion I want to make so that
maybe you can include it in 2.0.
Well, there's already a queue of events managed by you but "what if" one
wants to implement event-driven applications and wants to get good management
of event queues?
The solution I managed to get working is:
Initialize GRX
Redirect Mouse handler to a new handler
and call the previous (GRX) mouse handler within my handler.
I'll send you the code if you want BUT wouldn't it be cleaner and safer to
provide a event handler registry to be daisy-chained to your event-handler
routines.
This way one could get even-driven AND GRX to work together CLEANLY.
Hope this helps,
-Acacio
/
|
/\_/\ Auf Auf ...
(- -)
----------------------------oOO--\_/--OOo-------------------------------
Acacio Cruz Morada/Address:
MIS, Mailkeeper, Network Manager Rua General Ferreira Martins, 8, 4A
Oracle Portugal Alges 1495 Lisboa - Portugal
Mail: acruz.pt <acruz AT pt DOT oracle DOT com> T: (351) +1 4109666 Fax: +1 4108741
........................................................................
Q: Why do stars twinkle?
A: Bad connection in the power grid. We're working on it.
---- Included Message ----
Received: 02-15-95 20:05 Sent: 02-15-95 12:19
From: PTUNIX:djgpp-bounces AT sun DOT soe DOT clarkson DOT edu
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Graphics under Windog...
Reply-To: PTUNIX:djgpp-bounces AT sun DOT soe DOT clarkson DOT edu
About linear memory mapping:
IT IS NOT WORTH THE HASSLE. Consider this: if you
do graphics which is at least a little structured (you touch at least a few
hundred pixels before a 64K boundary crossing -- line drawing, etc all falls
into this category.) then the overhead of a function call and a few out
instructions is really negligible next to the time your CPU spends in wait
states until your video card is ready to accept the next pixel written. Yes,
even your whiz-bang VESA LB or PCI card is pityfully slow compared to the
system memory in your 486 or Pentium. Enabling linear memory addressing on a
non-accelerated SVGA, even if it is local bus, is NOT the thing which will
automagically turn your PC into a Silicon Graphics. If that's what you want
then buy an SGI or at least an accelerated video card.
As far as the possible performance gains are concerned, you can get a good
idea by writing a small program using GRX which fills, say, a 100x40 rectangle
in the 1024x768x256 mode. Position it once within the same bank, once such that
it crosses a bank boundary, run it a couple thousand times, and time the
difference. This is the gain you would get by using linear memory access.
I haven't done this recently, but I did it some time ago, and the difference
was really negligible (a few percents). Properly written banked frame buffer
codes (what I am just doing for GRX 2.0) can actually be slightly faster than
the GO32 virtual VGA banking. But again, we are talking about a few percent
difference.
The arguments against linear memory mapping are numerous: it depends on many
factors, including VGA chip type, installed memory, bus type, memory manager
(EMM386, DPMI host, etc...). At best, this would lead to a proliferation of
drivers (currently most drivers for a certain chipset can be used on the
ISA, VLB and PCI versions of the same card) -- when the driver situation
is already getting out of hand. At worst this would lead to many more of the
"help-my-graphics-is-not-working-on-my-pc-with-this-and-this-card-and-this-is-
my-environment-setting" posts of which we have already seen too much.
Additionally, in the DPMI compliant GRX this would require a completely new set
of frame driver codes, next to the banked ones which have to be there for those
people who cannot map their cards linearly => code bloat, etc...
About the new GRX:
GRX 2.0 is out for alpha testing. (Note ALPHA, not BETA!!) Send me an e-mail
and I will tell you where you can get it.
You can compile it with DJGPP v1.1[12]m*
ALPHA status means that:
1) it is incomplete and possibly quite buggy,
2) in general, you should know what you are doing before you touch it,
3) most likely your exisiting GRX program will not work with it, and
4) detailed bug reports are especially appreciated.
Before everyone gets very excited here is the current status:
- basic stuff (lines, rectangles, filled rectangles, etc..) works in
16, 256, 32K, 64K and 16M EGA/VGA modes.
- works under DPMI and Linux (using svgalib for video mode switching)
(according to Charles it also works with CWSDPMI and maybe NT???)
- NO: * text drawing
* complex shapes (circle, polygon, etc...)
* patterned lines and fills
==== these routines are moved over from 1.03 as time permits ====
* manual (most of the 1.03 manual is still applicable, if it disagrees
with the code then the code is right 8-) )
* support for accelerated chips for now.
- the good news: the test programs from GRX 1.03 which do not use features
listed above seem to build and run OK in all environments and video modes.
- still uses the Turbo C make, and will continue using it until it is
possible to reliably run 2..3 levels of nested make-s and a gcc in
the DJGPP environment.
- 64K banked frame buffer codes (no reliance on GO32 virtual VGA mapping
any more) => all HiRes modes work in 16 bit (TurboC) versions as well!
Most of these are optimized, some are still quite crude and slooooow.
- has drivers for EGA VGA ET4000 CIRRUS54 and VESA (DOS and derivatives)
svgalib (Linux). These are all part of the library now. As the driver
spec is already quite stable, ALPHA testers willing to come up with
new drivers would be especially appreciated.
Csaba
- Raw text -