1. NGL - A bridge between a graphics device and the programmer
Here's the readme of something I'm working on.
It's not complete finished, but most difficult parts are done.
What still needs to be done is: the color adapters, the synchonization
routines, the text-simulation routines, the virtual screen routines. Of the
video mode device only the simulation of the extended commands has to be
done.
The command list manager is ready!
Most of the words are prolly confusing now, just read this inserted file..
(It looks the best with a fixed-width font, it was typed in EE)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
New GraphiX Library
===================
An platform independent graphical toolkit with customizable screen
devices, color adapters, text mode simulation, synchronization
drivers and virtual screen extensions will run with optimal
performance through the command list technique whereby speedy
platform and video mode independent routines will become available
to all Euphoric game and application programmers.
-- Ralf Nieuwenhuijsen, May 1998
Introduction
============
The programmer shall now get the tools that fits his usage, instead
of the tools that seem most basic, but are *so* system dependent.
A virtual screen which you can resize, move, and keeps its contents
could be considered a window. And thankfully, they ussually have
a much nicer interface towards the programmer. An image with
invisible colors, combined into different sets, and resized in
real time could be called a sprite, but also a font, or a
mousepointer. Not often do you want to control such a thing,
in the same constraining way as most libraries make you do. A
programmer should be able to work with a palette as well as with
real RGB values. No longer will he notice the difference between
Hi-Color video modes and, for example, the MCGA. No longer, will he
have to wonder if outputting text using the normal output routines
is possible. No longer should he worry about the disability to use
images of text used with graphical modes. No longer will he have to
wonder if he can read text or not from the screen. No longer will
he have to worry about flickering and the right synchronization
method. Nope, no longer will he or you have to do any of that..
The Concept
===========
We all agree, a device independent library is nice, but we also
have a few priorities, where speed is ussually on top of that list.
Most graphics libraries have routines written around the hardware,
the routines serve the hardware, not the programmer. The result is
that your program needs to do all the basic tricks itself, using
video device specific routines. This library is mainly the bridge
between the programmer and the core graphics routines. It offers
a set of powerfull graphical tools, using device specific routines,
yet maintaining the maximum performance. All available devices can
be "plugged" in, but need to tell NGL *how* to use the specific
core routines. Actually, when NGL gets configured for a certain
device, it will *compile* its own commands, which can be executed
with only a small, constant amount of overhead or none using asm
no matter which device you use. This document was only ment to
introduce you to NGL, now you can continue reading with either
<< routines.txt >> or with << devices.txt >> The first file
reviews all the routines and methods that NGL offers the programmer
However, the other file, about devices, contains information for
those who wish to write and extend NGL with another video device.
Because you don't want to re-invent the wheel all over again,
different type of devices are used. These type of devices are
supported:
|> Video Mode Devices provide the core routines to a certain
video configuration.
|> Color Adapter Devices provide the core routines to get,
set, rotate and adjust the palette colors and their RGB
values. I hope somebody will provide us with a device for
for true-color. Off course, NGL would automatically
support this and those programs who already try to have
too many colors, will then look a lot better. NGL will
try to compromize as less as needed when a program uses
too many colors.
|> Synchronization routines, to eliminate the flickering that
occurs when we draw something during the vertical retrace.
Its only a different device, so we can turn it off,
upgrade or to provide a win32 device in the future.
|> Text Mode Simulation will make sure the standard output to
the screen keeps working the way we want it to. I don't
think anybody will add other devices of this type, I've
already provided enough, I think. But for Win32 no device
is currently available. Maybe some one could write one ?
|> Virtual Screen Driver will create, copy, clone, clear
and display sprites on, from now on, called "windows". All
virtual screen devices will work with all video devices,
because the internal communication will go through NGL.
The virtual screen device is completely unaware and
shouldn't care what video mode it is in. It should *never*
assume a certain video mode, NGL will instructs the device
which methods are available and which are the fastest.
Contacting the author
=====================
If you have any question, comment or remark, direct your fanmail and
mailbombs to:
==[ Email: nieuwen at xs4all.nl ]==
You can also contact this 16-year old Euphorian at:
==[ Ralf Nieuwenhuijsen ]==
==[ Schoener 22 ]==
==[ 2401 MT Alhpen A/D Rijn ]==
==[ The Netherlands ]==
Or if you have I-Seek-You (icq), you could message me:
==[ I seek YOU (icq) 9389920 ]==
===========================================================================
=
