www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/01/17/15:15:47

Message-ID: <F77915E7F086D31197F4009027CC81C91CC4F0@probe-2.as-london.acclaim.com>
From: Shawn Hargreaves <SHargreaves AT acclaimstudios DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Slow blit function
Date: Mon, 17 Jan 2000 17:12:33 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Reply-To: djgpp AT delorie DOT com

Todorovic writes:
> Since last week my blit function became very slow.

Do you mean the Allegro blit() routine, or some other similar function
that you have written yourself? If it's the Allegro one, which Allegro
graphics driver are you using? You mention below that you have UniVBE,
but the important thing is which of the Allegro GFX_* drivers is being
selected to go with this: VESA 1.x, VESA 2, VBE/AF, or whatever...

But the most important thing that jumps out at me here is when you say
"since last week". What changed? I presume that it used to go faster,
in which case the sensible thing would be to do some detective work
and find out what is different since then. Did you change your program
in some way, or perhaps you changed some driver settings or altered
some other aspect of your system?

> It takes 12 miliseconds to blit from memory to screen 640x480x15 
> bitmap!!!! 

That doesn't sound so bad to me! A 12 msec blit from memory to screen
will give an 83 fps screen update (although obviously a bit worse since
you also have to draw the image in memory), which is not at all 
dissimilar to the performance I get on this machine here. Certainly
some machines can go much faster, but this is not so far outside the 
common range that I'd instantly discount it as a bogus result...

Think of it this way: that's a 48 meg/sec transfer rate, which is just
over a third of the theoretical maximum for the PCI bus. It's likely
that your graphics card can't even go as fast as the bus maximum, but
even if it could, it's quite normal to find that real world programs
go much slower than the theoretical limits, so I'd personally be quite 
happy with this kind of performance!

> I count with simply counter which increments variable time_count 
> every milisecond. 

You might consider running your timer a bit more slowly: interrupts
have quite a bit of overhead, and the faster you operate them, the
less time remains for doing other things. DOS Allegro can't actually 
run timers faster than 1/200 of a second when running under win95, 
and Linux Allegro is (if I remember right) limited to 1/100 sec
precision, so it's a good idea to avoid needing anything much faster
than this (faster timers still work, but the ticks get clumped up
together so they aren't so accurate).

> - UniVBE 6.0, becase my monitor is old (January, 1992) - here I got 
> VESA3.0 and it says VBEAF (this should be software emulation, or what?)

VESA and VBE/AF are both software driver systems: the only difference
between UniVBE and the drivers included with your card is that UniVBE
is loaded as a TSR, while the build in drivers are stored in ROM on
the board. Both are just software, though: no emulation involved.


	Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019