[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] MiNT +problem with background in Teradesk
>> >> by starting with providing a window region that already has a texture
>> >> in it (before drawing begins). Then looking at how vdi/aes draws
>> >> objects, and (if code is available) how others are doing textures
>> >> currently (XaAES)
...
> You need to learn how the windowed approach of GEM works before trying to do
> any AES development, from what I can tell.
> Having the AES draw textures (or anything else for that matter) *inside* a
> GEM windows work area is about as legal as painting the windscreen of your
> car solid black.
While I agree with the comments in this thread about the impossibility
of having the AES draw a window background, there might still be a way
to get a similar effect, for some applications at least...
(Not that I'd ever recommend doing this, but it might be an
interesting experiment, if you have lots of time to spare. ;-)
The thing is that while the AES has no concept of a window background,
the VDI does, in effect (even explicitly in NVDIv5), have a background
_colour_. In principle, that background colour could be exchanged for
a background pattern/picture. Inside an application, that should be
feasible to use (but you'd probably be better off drawing the
background separately and then using a different drawing mode for the
foreground).
There are lots of problems with this, however. Among them the fact
that there is no guarantee that the foreground/background colours are
always used "as expected". You can switch them around, or use both of
them as "foreground colours", for example.
Also, a simple window scroll using vro_cpyfm() would cause alignment
errors between the old (moved) background and newly drawn one.
It might be possible to deal with some problems by keeping the actual
foreground contents separate from the background, "mixing" them in
when drawing to the actual screen (that is, using a background buffer,
a foreground buffer and a foreground mask buffer, besides the screen
itself). But then you should probably give up trying to get things
working with anything approaching reasonable speed without a CT60 and
preferably a CTPCI/Radeon (or ARAnyM).
Again, as mentioned earlier, it is impossible to get this kind of
thing working in the general case under AES/VDI.
/Johan