I'd been planning for a long time to write my own VDI. Mainly because I
wanted to experiment with some ideas I had for speedups on my AB040, but
also simply because there wasn't a free one available.
When the Fenix project
got to the point where substitutes for the various parts of TOS/GEM needed
to be implemented, I decided that the time had come to actually do something.
Implementing a complete VDI is of course a rather large project but there's
actually not very much left to do now on the normal VDI screen support
(with some of the most useful GDOS/NVDI extensions).
The list of things that don't work will be updated when I hear about more
problems (or when some of them are fixed).
Making a list of what works doesn't seem useful right now, since
most things actually seem to do so!
|
Name |
Symptom |
Cause |
Cure |
Date |
|
Thing |
Some versions seem to get confused and use the wrong icons or colours for them. |
TOS 4.04 probably lacks something that WDIALOG supplies. |
Seems fine with a patched WDIALOG (reported that TOS 4.04 didn't support colour icons, for some reason). |
000319 |
|
ImageCopy |
Quits on startup |
Uses lineA variables in strange ways |
Easy to patch |
990831 |
The monochrome device driver is now close to NVDI's speed for most things
and even faster for some (especially if you have an '040).
The 4 bit (16 colour) driver is also fast, but only draws text, mono-expand
blits and patterned fills in black and white right now.
I'll put some GEMBench, VDIBench (a program by Magnus
Kollberg and myself) and Kronos numbers here later.
Take a look at the
technical page
for detailed information on what fVDI does and how.
fVDI has been designed for ease of portability from the start. The amount of code needed to make it run on new hardware is as small as it could possibly be. The functions needed are only (for the current version):
Also, some simple setup code is necessary to tell the fVDI engine about the
graphics mode that's going to be used.
Later on there will be a need for hardware setup and a few other things as
well (at the moment fVDI simply doesn't support that at all).
The fVDI v0.85 archive contains the complete source code for the 15/16 bit
device driver. To make things easier to understand, I've written a complete
implementation of area fill in C, which can be used as a starting point for
further development.
One very interesting project would be to write partly native versions of fVDI for some of the Atari emulators. Letting fVDI take care of the details but implementing the accelerated functions in native code should, without much work, give some very nice graphics mode support in for example STonX, PaCifiST, TOSBox or GEMulator (STEmulator already has something similar built in). Writing blitting routines and such for standard PC graphics modes is simple enough, and it should even be possible to use Windows GDI and/or DirectDraw calls.
ARAnyM now does exactly this, using the SDL library!
If you try fVDI out,
please contact me.
Note that even if the latest release archive is quite new, you might
want to check if there's a newer beta available.
Comments, suggestions, bug reports, help offers etc are all very welcome.