BGI file linked in EXE file? 
Author Message
 BGI file linked in EXE file?

Hello,

Is there someone who can tell something about linking a non-Borland BGI
file in the executable of a program?

I'm fairly new at programming in Pascal, so I looked at some
SWAG-snippets, but I don't quite get it.

What I understood sofar is:
convert the BGI files to OBJ files, build a unit (let's say Video.tpu) in
which OBJ files are linked using the {$L} compiler directive.
The procedure for this is 'RegisterBGIDriver(some_name, pointer)'.
Is this the way to do it?
Can this also be done with non-Borland BGI files for screen resolutions
other than those provided by Borland (like some I found on the net for
640x480x256)?

In the main program, is it sufficient to use

driver:= detect; {or directly state the name of the driver}
InitGraph(driver,mode);

or do you still need 'InstallUserDriver' for non-Borland BGI files?
Is there a call needed to the procedure that registered the BGI driver in
the Video.tpu unit?
Then after compilation of the main program the BGI driver is no longer
needed with the EXE file?

Someone cares to end the confusion for me?
Thanx in advance,




Wed, 18 Jun 1902 08:00:00 GMT  
 BGI file linked in EXE file?


Quote:

>Hello,

>Is there someone who can tell something about linking a non-Borland BGI
>file in the executable of a program?

                   From: Turbo Pascal for DOS Tutorial
                           by Glenn Grotzinger
                         Part 21: Use of the BGI.
                 copyright (c) 1995-6 by Glenn Grotzinger

BGI loader
==========
Here, I will describe how to make the BGI files functionally more
useable than in their current state....Compile with looking for the
external BGI files is fine, but will run into an annoyance quick,
especially with a distributed utility...it is easier to have the EXE
available with the BGI files binded to it than to make a user keep
track of the BGI files....

There is a utility available in TP called BINOBJ.  The BGI files are
video control files, while CHR files are font definition files.  They
both are usable in graphics as binary files...and that is what BINOBJ
does...it converts binary files to OBJect files, which may be handled
like described before.  The proper usage of this utility is...

BINOBJ <binary file name> <object file name> <internal procedure name>

Here is a sample command-line.  To convert VESA16.BGI to an OBJ, do
this:

BINOBJ VESA16.BGI VESA16.OBJ Vesa16driver

Locate the BGI files that should be in your TP/BGI directory.
You will need to copy them off to a separate directory.

After you convert all BGI files like this, I recommend you write a
unit to link the BGI files in -- optionally, if you need fonts, you
may write a unit to link those in likewise.  Be sure to define your
proper external procedures like it needs to be done.  Make use of
meaningful names, as you will have to remember them to make use of the
graphics set. For example, I call my unit bgivideo; for each
procedure, I put the first 8 chars of the name of the file, and then
driver for the BGI files.  These function names will be easy to
remember when we need to use them.

Going into Graphics Mode
========================
Now, hopefully you have your BGI video unit ready now, and sitting in
whatever directory you use to place your pascal code.  Now we will
discuss about how to go into graphics mode using the BGI.

Generally, going to graphics mode initially would require setting up
the BGI unit you created, and then performing an autodetect on the
graphics, followed by an init into graphics mode.

Let us look at some sample code...

program video_example_1;{1} uses graph, bgivideo;

var
  graphicsdriver, graphicsmode: integer;

procedure errormessage(driver: string);
  begin
    writeln('There was an error: ', grapherrormsg(graphresult),
driver);
    halt(1);
  end;

begin

     errormessage('ATT');

     errormessage('CGA');

     errormessage('EGA/VGA');

     errormessage('Herc');

     errormessage('PC 3270');

{3}detectgraph(graphicsdriver, graphicsmode);
   graphicsdriver := Detect;
{4}initgraph(graphicsdriver, graphicsmode, '');
{5}if GraphResult <> grOk then
    begin
      writeln('Video error.');
      halt(1);
    end;

{6}repeat
      putpixel(random(getmaxx), random(getmaxy), random(getmaxcolor));
   until keypressed;
   readln;

{7}closegraph;
end.

This is basically a random pixel place system using the video mode in
the recommended auto-detect.  Let's go through a few of the features
of the code, which were marked by {}'s.

{1} As we see, the graph, and bgivideo units are used here.  The graph
unit is the basic function interface for the BGI system.  We are
familiar with bgivideo from earlier.

{2} RegisterBGIDriver() must be called for any and all realistic
possibilities. I recommend that only the ones listed really need to be
checked.  If the function is less than zero, then there is a problem.
The errormessage function holds a function called grapherrormsg()
which will output a direct error as to why things aren't working
right.

{3} detectgraph detects the graphics card.  it takes integers
represented by graphicsdriver, and graphicsmode....graphicsdriver will
hold the recommended video type, and graphicsmode will hold the
recommended video mode (it can be changed).  This is why we registered
all the drivers...it will use whichever one it needs, and ultimately,
the program will work with all video modes.

{4} initgraph() takes us into graphics mode.  It is called basically
as indicated in the program.  the third param '', is for when we load
the BGI files externally.  To do that, do not include BGIVIDEO and
provide a path to the BGI files....to get a full auto-detect
capability, just make all the BGI files available....it is easier in
the long run to have the BGI files combined in the exec.

{5} For almost any graphics function, a variable called graphresult is
changed.  There are graphics mode constants, which will be covered
later, which are in there representing different things.  grok is the
one which indicates that things are OK.

{6} This is the real meat of the procedure.  It keeps placing pixels
of random position and color on the screen until a key is pressed.
getmaxx is the maximum screen position on the x axis.  getmaxy is the
maximum screen position on the y axis.  Graphics screens have the same
kind of dimensional setup as the crt graphics screens do.  The
putpixel procedure takes a x, y coordinate, then a color...getmaxcolor
is a constant that holds the maximum # of colors present in the
current video mode.

{7} Closegraph is pretty much self-explanatory.  It shuts down
graphics mode and takes us back to text.

Glenn Grotzinger
Web Page: http://www.geocities.com/Paris/3537
Writer of the Excellent Training Manual known as the TP Tutorial.
To email, if you hit the reply button, delete the {remove_this}
out of the replied message.  Just some protection from SPAM. :(



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Linking BGI driver into .exe file.???????????

2. Building BGI files into an EXE

3. Incorporating BGI fonts in EXE file

4. Including .chr and .bgi files in a program compiled into .exe

5. Linking BGI files into Executables

6. Linking BGI files - Help!

7. Link 2 exe and/or com files

8. How to link a .GIF file into the .EXE

9. Linking an .EXE file in my program

10. Linking EXE and OVL files

11. Linking several exe-files

12. Linking EXE and OVL files

 

 
Powered by phpBB® Forum Software