12
Feb
15

Creating a Benchmark: part2

A couple of weeks ago I created a basic benchmarking program for measuring the speed of the Borland Graphics Interface and its drivers. I’m primarily interested in how they compare not only to each other, but also to a hand-coded implementation. So this week I created a VGA graphics unit by hand and made a benchmark program around it.

I chose coding for VGA 320x200x256 as it is the easiest mode to code for and matches more of the BGI drivers. You simply initiate the graphics mode 13h (h for hex) with the video BIOS, this sets up a linear buffer for drawing at the memory location A000h:0000h. Each pixel is a single byte, so drawing a pixel doesn’t require bit masking unless you want it to. Drawing a pixel simply involves changing the byte at the offset following this simple formula. (y*320) + x.

Given this information it was no problem at all to code up a basic graphics unit. I didn’t use much in the way of assembly code to implement the unit, partly out of laziness, instead opting to implement it using Pascal code mostly. I haven’t implemented all the graphical functions in the BGI, simply because there are way too many.

Here are the results when tested under Dosbox with 3000 cycles. I used pretty much the same code to perform the measurement to ensure as much consistency as possible. It’s quite interesting to see that implementing your own graphics unit doesn’t really provide that much extra performance for most functions, and in this case blitting sprites is actually slower using my code! I suspect this is because I used a built-in Pascal function for copying memory that may not be super fast. I did note it is still faster than both the VESA and SVGA256M driver in the same mode.

So is it worth implementing your own graphics driver instead of using the BGI. The answer is a sorta, maybe. I haven’t optimised my graphics code in this case, so it surely could be a bit faster, but I did manage to use less memory for storing the sprites, and my code was much smaller in terms of size. However the Graph unit and VGA256 actually seem to have some decent performance comparatively, so if you need compatibility with other cards that are more difficult to code for, or simply don’t have time to code a graphics unit of your own, then the graph/BGI implementation isn’t too bad.

Code and DOS binary are available here.

Advertisements

0 Responses to “Creating a Benchmark: part2”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.


Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

MS-DOS game reviews, retro ramblings and more...

%d bloggers like this: