Board index » delphi » Aren't BGIs too slow?

Aren't BGIs too slow?

I heard that BGIs were far slower than coding the whole gfx system in  
assembler. Is this true?

After two days of TP7.0 I finished writing a whole assembly graphics
system. It seems far less hassle to use than BGI where you have to
init drivers and all that stuff.

If anyone wants the library then you're welcome to it. But I was just
wondering if BGIs are slower than ASM.

Cheers, ;-)

--
 PP  EEE TTT EEE  RR   _______-------~~~~~~~~~~-----------_________--------~~~
 P P E    T  E    R R       Author of the Basic fanzine + UV1
 PP  EE   T  EE   RR      wishes you a happy christmas and a happy new year
 P   E    T  E    R R                    
 E   EEE  T  EEE  R  R _______-------~~~~~~~~~~-----------_________--------~~~

 

Re:Aren't BGIs too slow?


Quote
Peter Cooper (pe...@trenham.demon.co.uk) wrote:
> I heard that BGIs were far slower than coding the whole gfx system in  
> assembler. Is this true?
> After two days of TP7.0 I finished writing a whole assembly graphics
> system. It seems far less hassle to use than BGI where you have to
> init drivers and all that stuff.
> If anyone wants the library then you're welcome to it. But I was just
> wondering if BGIs are slower than ASM.

Yes, it is far slower than writing directly to video memory.  But unless you
need to display a graph as fast as possible (i.e. animation), .BGI is
enough.  More over, you don't need to spend hours making its replacement.

--
-Eddy

Re:Aren't BGIs too slow?


Quote
ew4...@kestrel.fen.bris.ac.uk (Eddy) wrote:
>Peter Cooper (pe...@trenham.demon.co.uk) wrote:
>> If anyone wants the library then you're welcome to it. But I was just
>> wondering if BGIs are slower than ASM.
>Yes, it is far slower than writing directly to video memory.  But unless you
>need to display a graph as fast as possible (i.e. animation), .BGI is
>enough.  More over, you don't need to spend hours making its replacement.

Yeah, but there are a lot of freeware and shareware graphics libraries
availible, though.  Sometimes if you don't know (or want to code) the
assembly this is the best way to go.

Chris

Re:Aren't BGIs too slow?


Quote
On Mon, 11 Dec 1995, Peter Cooper wrote:
> I heard that BGIs were far slower than coding the whole gfx system in  
> assembler. Is this true?

> After two days of TP7.0 I finished writing a whole assembly graphics
> system. It seems far less hassle to use than BGI where you have to
> init drivers and all that stuff.

I thought the BGI's were writen in assembler?

Re:Aren't BGIs too slow?


In article <DJIzxs....@uns.bris.ac.uk>
           ew4...@kestrel.fen.bris.ac.uk "Eddy" writes:

Quote
> Peter Cooper (pe...@trenham.demon.co.uk) wrote:
> > I heard that BGIs were far slower than coding the whole gfx system in  
> > assembler. Is this true?

> Yes, it is far slower than writing directly to video memory.  But unless you
> need to display a graph as fast as possible (i.e. animation), .BGI is
> enough.  More over, you don't need to spend hours making its replacement.

Well, I did offer to give mine away... Anyway you can get hold of libraries
off of FTP sites anyway.

Quote
> --
> -Eddy

Thank you all for your comments. ;-)

(lets go and optimize my font code..;-) )
--
 PP  EEE TTT EEE  RR   _______-------~~~~~~~~~~-----------_________--------~~~
 P P E    T  E    R R       Author of the Basic fanzine + UV1
 PP  EE   T  EE   RR      wishes you a happy christmas and a happy new year
 P   E    T  E    R R                    
 E   EEE  T  EEE  R  R _______-------~~~~~~~~~~-----------_________--------~~~

Re:Aren't BGIs too slow?


Quote
On Mon, 11 Dec 1995, Peter Cooper wrote:
> I heard that BGIs were far slower than coding the whole gfx system in  
> assembler. Is this true?

yes

Quote
> After two days of TP7.0 I finished writing a whole assembly graphics
> system. It seems far less hassle to use than BGI where you have to
> init drivers and all that stuff.

BGI:

var
  gd, gm, ge : integer;

  procedure EGAVGADriver; {$L egavga.obj}

begin
  gd := RegisterBGIDriver((@EGAVGADriver)^);
  initgraph (gd, gm, '');
  ge := BGIError;
  if ge <> grOk then
    etc.etc.
end;

asm:

asm
  mov ax, 013h
  int 10h
end;

Okay, so I was taking the most unfair case for BGI where I was linking
the driver, etc. into the executable, but also remember: that unfair case
for BGI (which doesn't have stupid external files BTW :) adds around 100k
(or however big the BGI drivers are, I can't remember).  The asm version
adds in 5 bytes.

    ________________________________________________________________________
   / Joshua Shagam                    /    (Quantum Porcupine / Versatile) /
  / mailto:JSha...@nmsu.edu          /       http://web.nmsu.edu/~jshagam /
 / phone://1.505.645.3856/~joshua   /  for the Quantum Porcupine Archive /
/__________________________________/____________________________________/
  Stop the execution of King Louis XVI!  If you agree, copy these three
             lines to your .signature file and send funds to:
       Long Live the King, 207 Alumni Avenue, Las Cruces, NM 88003

Re:Aren't BGIs too slow?


In article <Pine.A32.3.91.951214141553.84028H-100000@hector>,
Quantum Porcupine  <jsha...@nmsu.edu> wrote:

Quote

>Okay, so I was taking the most unfair case for BGI where I was linking
>the driver, etc. into the executable, but also remember: that unfair case
>for BGI (which doesn't have stupid external files BTW :) adds around 100k
>(or however big the BGI drivers are, I can't remember).  The asm version
>adds in 5 bytes.

What's your point?  This has nothing to do with speed (the topic
at hand), only size.

The BGI's have very nice high-res functionality, especially when
you want to do graphs and diagrams.  But no, don't use them for
real-time action games--they're too slow for that.
--
Jim Leonard (Trixter / Hornet)                          Email: trix...@mcs.com
*THE* PC Demo WWW page:  http://www.cdrom.com/pub/demos/hornet/html/demos.html
The 8086 Compo is a reality! URL is http://www.cdrom.com/pub/demos/hornet/8086
Make A Computer easy enough for a fool to use, and only fools will use it!

Re:Aren't BGIs too slow?


Quote
>I heard that BGIs were far slower than coding the whole gfx system in  
>assembler. Is this true?
>After two days of TP7.0 I finished writing a whole assembly graphics
>system. It seems far less hassle to use than BGI where you have to
>init drivers and all that stuff.
>If anyone wants the library then you're welcome to it. But I was just
>wondering if BGIs are slower than ASM.

I do not know, I have the kit to create BGI driver, and they seem very
optimized (parameters in registers. etc..etc), but i think the problem lies in
the graph unit, It would be interesting if i could call the bgi routines
directly instead of passing by the graph unit. I think that would make things
MUCH faster

What modes does your library support exaclty? I am  mainly interested in
640x350x16, 640x400x16c, and 620x200x2c.

Carl Eric Codere aka Black One.
cecod...@andrew.sca.usherb.ca
carl.cod...@evening.magicnet.com
http://www-edu.gel.usherb.ca/codc01
<Electrical Engineering, University of Sherbrooke>

Re:Aren't BGIs too slow?


In article <4asab5$...@Venus.mcs.com>,
Trixter / Hornet <trix...@MCS.COM> wrote:

Quote

>The BGI's have very nice high-res functionality, especially when
>you want to do graphs and diagrams.  But no, don't use them for
>real-time action games--they're too slow for that.

Can anyone point me at something better? I want to provide
"real-time action" in "high-res" modes ... as few as 16
colors would be all right if I could get virtual paging
(or the equivalent) at 640x480 or greater resolution.

Any hints or pointers would be greatly appreciated!

Thanks in advance.

-- Perry Domzella                     ( pe...@mks.com )

Re:Aren't BGIs too slow?


Quote
pe...@mks.com (Perry Domzella) wrote:
>Can anyone point me at something better? I want to provide
>"real-time action" in "high-res" modes ... as few as 16
>colors would be all right if I could get virtual paging
>(or the equivalent) at 640x480 or greater resolution.

the asphyxia demo team put out some really good pascal demos on coding
FAST graphics routines, and even though they were written specifically
for mode 13h (320x200x256), the algorythms and methods used have been
invaluable to me since.  There are also a number of assembly coded
graphics libraries out right now that are much faster than using the
graph unit and BGIs.  If you'd like the URL for asphyxia just mail me, i
don't know it off the top of my head...

--
          + James Lee * Co-System Administrator: WLJSHS +
     + http://io.wl.k12.in.us/~sleej * sl...@io.wl.k12.in.us +
+ Experience with QB, TP, C, C++, 8086 ASM, OOP, UNIX Programming +

Re:Aren't BGIs too slow?


Quote
>pe...@mks.com (Perry Domzella) wrote:
>>Can anyone point me at something better? I want to provide
>>"real-time action" in "high-res" modes ... as few as 16
>>colors would be all right if I could get virtual paging
>>(or the equivalent) at 640x480 or greater resolution.

It is of course possible to initialise graphics modes greater than
MCGA's 320x200x256 using Pascal's built in assembler.
All you basically need - is a list of AX-register for different video
cards , and different resolutions. A while ago - i wrote a unit to
handle all that for me - i'll have to find it, if i do - i will post
it.

-Dudley LeRoux
  delo...@connx.vironix.co.za

Experience in :    Pascal 6.0, 7.0 + Pascal 1.5 for windows + Delphi +
C ++   and assembler

Re:Aren't BGIs too slow?


  I have not really programmed in Pascal yet, but I know a lot of the
graphics functions in the BGIs for C++, are slowwer then QuickBASIC's
graphics functions..  Much, Much too slow for game making.  
  But Peter already knows this..

I suggest writing the stuff in asm, if you are making a game.

--
Signed,    

     ##   ####   ##      ## ####### ######
     ##  ######  ####  #### ##      ##  
##   ## ##    ## ##  ##  ## #####   ######
##   ## ######## ##      ## ##          ##
####### ##    ## ##      ## ####### ######

Re:Aren't BGIs too slow?


In article <4at7f9$...@ia.mks.com>, pe...@mks.com says...
Quote

>In article <4asab5$...@Venus.mcs.com>,
>Trixter / Hornet <trix...@MCS.COM> wrote:

>>The BGI's have very nice high-res functionality, especially when
>>you want to do graphs and diagrams.  But no, don't use them for
>>real-time action games--they're too slow for that.

>Can anyone point me at something better? I want to provide
>"real-time action" in "high-res" modes ... as few as 16
>colors would be all right if I could get virtual paging
>(or the equivalent) at 640x480 or greater resolution.

>Any hints or pointers would be greatly appreciated!

>Thanks in advance.

>-- Perry Domzella                     ( pe...@mks.com )

ok... well.. you'd probablly need to either access protected mode, or use XMS
for virutal pages in 640x480x256 since that takes up around 300K... plus you'll
need to know how to use VESA modes fairly well and write your own engine (i've
done it, its not too hard) just copy the 4 banks in using 32-bit code (use asm
w/ db 66h) to copy the data to the screen.. doing that I got around 58 frames a
second simply writing directly to the screen.. i hope that helps any...

zeuz

oh, and BTW - BGIs are pathetically slow, however, they do work on video cards
w/o VESA...

Other Threads