[GEM Development] Video mode - bitplane vs packed pixels

[Cyprian Konador]

On Sat, 3 Feb 2024 at 16:14, Michael Bernstein wrote:

> Hi Cyprian,
>
> > I'm working on a small application which operates on offscreen graphics
> > data, that I transfer via vro_cpyfm to the screen.
>
> There is one step missing in your handling.
>
> > Now I wonder how to distinguish video mode: bitplane vs packed pixels.
> > Do you have any tips?
>
> Do you speak about the graphic format of the Video RAM itself used by
> the hardware? Then the answer is: you should take it as unknown. But
> there is no need for applications to have this information.
>
> The VDI distinguish between the hardware-dependent format which is used
> by hardware and the VDI graphics driver. And the standard format which
> is well defined and a bitplane mode. You can query the number of planes
> with the VDI function vq_extnd()
>
> So the proper handling of offscreen bitmap is:
>
> - Make your graphic handling with a buffer in the standard format. The
> field fd_stand of the MFDB structure for this buffer is 1.
> - Then call vr_trnfm() to transform the standard format graphic buffer
> to a device-dependant buffer (fd_stand = 0 for destination MFDB). This
> transformation may be done in place. But this took a longer time. So
> better use a second buffer for the destination.
> - Then use vro_cpyfm() to copy the graphic buffer in hardware dependant
> format to the screen buffer. The field fd_addr of the destination MFDB
> is set to NULL (0) and all other field can stay uninitialized.
>

good point,
Initially I had a plan to do that conversion on myself due to performance
and memory limitations, but I'll try to do that in a proper way: image
--> vr_trnfm
--> vro_cpyf.
It might work in low color video modes, but it may run out of RAM in 256
color modes. I need 1x buffer for loaded image, 1x buffer for standard
image, 1x optional buffer in device-dependent buffer.


Atari ST/TT/Falcon computers use with GEM the same graphic system. So
> you can use the GEM part of https://toshyp.atari.org/ also as a
> documentation. This documentation is available in german and english.
> Another source of information is the Atari Profibuch, which is now
> available for download in pdf format. But this is only in german. The
> Profibuch contains an example function how to calcuate the RAM size of a
> graphic buffer for the actual graphic resolution.
>

Actually I'm quite familiar with Atari stuff. I have paper Profibuch book,
I'm on daily basis on TosHyp and Atari-forum.com.
But I'm here to learn more about the root of our beloved OS - Intel GEM and
GEMDOS (DOS Plus?).

btw nice website

Regards
Cyprian
https://260ste.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.simpits.org/pipermail/gem-dev/attachments/20240205/e0ffece6/attachment.html>