Graphics Engines

Massively important in almost every program, in Pascal or any other language, is the ability to display the output in some way to the user, and so to allow immediate and intiuitive interaction with the program. In addition, very few computer programs, by dfinition, simply process predifined data: many of your application will continually recieve new instructions from the user and be required to produce output in a way that correlates witht his input of information. Whether you are designing a computer game or a mouse based editor, the most intuitive and satisfactory method of output is in graphical format. However, the BGI graphics engine supplied with Pascal 6.0 has several major shortcomings: it only allows a 4-bit, 16 colour palette, making it all but impossible to display a variety of clearly defined graphics. In addition there is no source available for the routines, limiting the user to the highly restricted set of procedures that Borland inteded for use; pixel and sprite plotting is purgatorial; and all the routines leave much to be desired in the way of speed. Graphical programming, and graphics engine, have hence become one of the most widly represented aims of the internet pascal community, and there are uncountably numerous solutions in various forms, making use of different memory buffers, graphics modes, and image fomats out there for those that are interested. I was initially introduced to graphical programming through the investigation of such units, and quickly found that the number of ways of integrating graphical routines into your own programs was effectively unlimited, the only barriers being the knowledge of the hardware interupts and techniques that prerequisite such programming. From these early beginnings, my two modern graphics engines; for use with MCGA (320x200x256) and SVGA (640x480x256) respectively; have emerged with a common motif. Central to both engines is the ability to have rapid direct pixel access as well as simple geometrical routines (such as clearing the screen or drawing blocks of colour) on both the graphical display, and a memory buffer that represents a second screen, the 'virtual' screen. The advantage of this is that the entire display for one cycle of an enigne can be drawn, at leisure, upon the virtual screen, and then this transfered to the display at speed with a single command. The virtual screen can then be blanked ready for the next round of drawing, whilst the previous image remains static on the display. This is the fundamental basis of animation and smooth dynamic graphical programming. It proved a much greater challenge for the SVGA engine, due to the fact that the size of the display (640x480x8 bits = 307,200 bytes) exceeds the segment limit, meaning the real display must be divided between no less than 5 banks, and the virtual screen similarly arrayed in the memory. Once this has been established, the display of sprites and images must be achieved, through an equally speedy set of routines designed for use on the virtual and real screens, as well as procedures for intialising the buffers images are stored in, and loading the images off the disk or extracting them out of image libraries. It has taken me some time to refine the engine to the point where highly graphically demanding games such as Trooper II could be implemented, and the original system I acquired from elsewhere has been repeatedly modified and tweaked by myself, but I now believe the engines to be almost faultless, and one of the fastest SVGA engines I have come accross, written as it is in pure optimised 32-bit assembly language. Each graphics engine automatically makes use of EMS and XMS as requested, facilitation loading of images into the memory, something that is challenging for less experienced programmers. I hope the many hours of work that went into producing the engines are of use to someone out there. Enjoy, Jon