Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Paul Wratt <paul.wratt@gmail.com>]

Thanks for the other 2 or 3 posts, they are pretty much what is needed

On Fri, Dec 11, 2009 at 12:08 AM, Mark Duckworth
<mduckworth@atari-source.org> wrote:
> Johan Klockars wrote:
>>>
>>> a "must have", but an initial start to the sequence should be the
>>> ability to choose a screen rez and color depth, and I think that is
>>> what VDI cannot do, which is what a virtual worksataion should be able
>>>
>>
>> No, IM(ns)HO, a virtual workstation can not be allowed to change those
>> things (At least not colour depth. I think Jo Even mentioned something
>> about recent AES:es having support for telling applications about
>> resolution changes), since there can be any number of "sibling virtual
>> workstations" which would not understand what is happening.
>>
That is my point (i think). Any virtual screen should be independent
of physical hardware, and yes apps could be told about screen
attribute changes. As long as it is not a fullscreen non-desktop app,
then the virtual screen should not interfere with what is actually on
the screen, especially if it is running under AES

>> However, a newly opened physical workstation obviously has no one who
>> is depending on it and it can thus use whatever resolution and colour
>> depth.
>>
>> So, for a game (say) that wants a different resolution/depth, it could
>> be possible to open another physical workstation to the same screen.
>> Then we just need to define how it is decided which physical
>> workstation is actually displayed. Page flipping could be handled by
>> the same mechanism, I suppose.
>>
I am not sure of the use of multiple physical screens, except that
more than one full screen non-desktop app could be running at the same
time, and that would make sense, not interfering with each others
screen and 100% sure about "its" screen attribute (rez color depth,
etc). One of those physical screens should always be the AES.

In theory it should also be possible for any fullscreen app to be
viewed in a window, presuming something like AES is available to VDI,
or VDI can give "view port" access

Anyways, what you say is good solid stuff, and this seems to have
covered a lot of ground. I am also in the same space as Vincent
re:directx, its success can be measured by hardware support.

In the post where Johan did not understand a paragraph I wrote about
AES & VDI when both KM, the point there was that they dont have to use
trap calls (if that is one of the bottle necks). If they are not using
them, and there tighter comunication is far superior in speed, then
apps should be allowed access to that speed also. This would probably
mean a new API, that someone mentioned could be mapped back to support
older apps.

But because they "unified" (or in union) from the rest of the
(desktop) apps point of view, and in light of recent post regarding
direct screen access and use of video card features, it probably makes
sense to provide a unified API, one that can also deliver the sort of
things directx does as well.

On a hardware platform that support any form of graphics hardware,
multiple cards and multiple monitor are inevitable, an need to be
catered for from the start. If I ever get access to hardware that can
use PCI graphics, I have 2 64Mb Voodoo 5000, and it would be a crying
shame if I could not get direct access to there features. Note that
there are still PCI cards being made at the moment, which may not be
the case in years to come.

At some point someone will get an ACP hardware running in a machine
that shares PCI with AGP and PCIE, at which point I would like to be
able to enhance my OS by using advanced 3D hardware directly, weather
that is to hijack the GPU for custom for 2D work, or allow OpenGL (and
possibly directx) in my desktop (ala Compiz)

I believe a unified API (because they are KM's) could achieve that,
but I also believe that separate AES and VDI could allow the same
thing, only with some good solid revisions of each, but there is no
reason why a new API could not cater for post possibilities, and give
me the extend access that has been missing, while allowing across the
board compatibility.

>>
>>>
>>> From memory frame buffers can be redirected or re-pointed (on PCI/ISA
>>> hardware anyway), which will beat bliting any day.. this may be
>>>
>
> I like this idea honestly, and this would make a clean way to implement
> vconsoles if I'm not mistaken.
>
> Thanks,
> Mark
Mark: I'm not sure which bit you liked, but  I wanted re explained the
comment I originally made (above) ... are you perhaps thinking "view
ports" also.. I think I understand what you mean tho (vconsoles)?

Unfortunately Vincent's "concrete" comment is too true, so apart from
some obvious hard work for some people, there is quite a bit of
codeing to be done before any of the above is even proto-typed
(getting current support levels up), however I would like to see the
majority of these ideas formalized in some way, even if its just "on
paper", not just to allow documentation to be worked on, but also that
others could start preliminary work on it if they chose to.. it might
allow some of the more advance ideas to be proto-typed against current
hardware, and might provide code and solutions to some currently
unsolved (or unsupported) issues.

Cheers, and thanks a lot for everyones input so far, I think PeterP
was right, we are mostly on the same page, let us hope that the "hot
rod" performs well as a "family sedan" :)

Paul