[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] WCOWORK implementation : conclusions.
integration, but it will be fast, esp. with FastRam - fVDI already
does such things IIRC (if FastRam avialible, there is whole-screen
buffer in fastram, all operations are done on it, and modified parts
are copied to st-ram (with simple move it is fast)).
Actually, that's exactly what the SDL driver for fVDI under ARAnyM does.
The fVDI Atari mode drivers are a bit different. They do indeed have a
whole-screen buffer in FastRAM (if you tell them to), but they never
copy from that to the Atari screen. Rather, they draw to the buffer and
the real screen concurrently, while reads are only done from the FastRAM
buffer.
There is a number of "free" clock cycles available between every write
to the Atari screen, so it's better to make use of them than to just
wait as you would if you copied the data afterwards (you could also use
those free cycles to do free 8 bit chunky to planar conversion while
copying, but I've never gotten around to writing a driver that does that).
Another thing that the Atari mode drivers were supposed to do, but still
don't because I got side-tracked with the Eclipse/RageII driver, was to
only write to the Atari screen if the data actually changed. Very often
an operation doesn't actually change everything and it could be useful
to compare the new data with the old in the FastRAM buffer and only
write to the Atari screen when needed.
When scrolling a normal text window, for example, you could likely often
avoid half or more of the Atari screen writes since a lot of the screen
would stay at the background colour.
Speeding up the screen on my AB040 Falcon this way was actually the main
reason why I began working on fVDI nearly a decade ago. There was no
documentation to be had on how to write an NVDI screen driver, so... ;-)
--
| Why are these | johan@klockars.net
| .signatures |
| so hard to do | http://www.klockars.net
| well? | (fVDI, MGIFv5, QLem)