Re: [AD] Progress report on Linux console Allegro

[Jason Wilkins <fenix@xxxxxxxxxx>]

George Foot wrote:

> These hooks in the
> GFX_DRIVER struct are there for the switching code to call, if
> non-NULL, to save/restore this extra information.

Oh, I see, very good point.  In my case my different screens are C++ 
objects with virtual functions to override, so my callbacks are
in a different place.  But I do see now why C code would have to
do this in the GFX_DRIVER.  I'll probably use the driver callback
and just call it from the BeOS callback, that way I'll be consistent
with the rest of the library.  

(I just realized I can't inline it like in my example because it
overrides a virtual, this is the first big C++ project I've done).

> > My big question is, does the library cache the information from the screen
> > bitmap anywhere, the reason is that there is no guarantee that the screen
> > bitmap will be at the same address when you acquire it again later.
> 
> I'm fairly sure this was/is the case with WinAllegro too -- it's
> partly what the acquire/release system is for.

Oh, so this is why sub-bitmaps on the don't work yet!  I hope Stefan
writes the code in a portable way so that I can use it.  Either that,
or I'll write it first (is he back yet?).

> > I was going to make the behavior configurable as well, so it can either
> > suspend when you switch, or just let it draw into a hidden buffer (which
> > is needed anyway to store the contents of the framebuffer during the
> > switch).
> 
> The current Linux console version has this support almost
> implemented -- completely untested though.  The old version had
> the support but Marek overlooked subbitmaps of the screen, I
> think -- remember that all their line pointers will need
> updating if the screen bitmap moves in memory.

It looks like I may be the first to tackle this problem if no one has
addressed it yet.


> > If we added a general function to control background behavior, it would
> > probably be added to the system driver.
> 
> Yes, but the user shouldn't call the system driver directly I
> think.  If the entry is NULL, assume switching is unnecessary or
> uncontrollable.  This is closely linked with lost bitmap
> callbacks...

Just to add to the idea: we should be able to disable switching
altogether with this function.  I don't think I can do this in BeOS,
but you can do it with DX and probably with Linux as well.

Switching is just a fact of life in BeOS, the only way to disable it would
be to change the ALT key to map to nothing at all so the OS won't get the
key.  The key would still work in Allegro, but it feels kludgy to do it
that way.

> Oh yes, good point.  Ah, except when two people extend the same
> structure; but then one of them just has to put extra NULLs in.

I think I agree with Shawn now that we should just break it so we
just compile, fix, and run again.

> No, it just tells you the bitmap has been lost.  It's called
> after the event, next time you acquire that bitmap, IIRC --
> that's from last year though, I'm not sure whether it's still
> the same now.

It would be great if they fixed that, then some of this would become moot.

> > I was just going to create a be_hidden_screen, that I saved everything to,
> > and that could even be drawn into if the user selected not to suspend
> > went they switched consoles, if they did suspend then it just won't be
> > drawn into when they are hidden.  In anycase I just restore the screen
> > when they switch back.  Easy.
> 
> Yes.  This is how it's done in Linux, too -- again, beware of
> subbitmaps of the screen, though.  I can't see a trivial
> solution.  It works fine if the app is just being suspended
> though.

There is a callback to create video sub-bitmaps right?  Then maybe
a linked-list of them could be kept.  In the switch callback you
would create an identical shadow list.  Are there any hidden traps
to this?  I am assuming that speed is not critical because screen
switches take a long time anyway (especially if you include the time
it takes my monitor to resync).

> Quite, but I've still given the option to install a switch hook,
> which will override the default saving routine, so you can turn
> off the saving if you want to.  Any application that wants to be
> portable to Windows has to be capable of redrawing like this
> anyway, and for large virtual screens it could save a lot of
> memory usage.

Again, a good point.  My video card has 16MB of memory, the one
I want has 32MB, a naive saving routine would have to save all of
this, making saving a restoration take MINUTES, not milliseconds.

We would have to tell people to ask for exactly how much virtual
screen they need.  And have the driver only save the whole vscreen
if scrolling is enabled.

> --
> george.foot@xxxxxxxxxx
> 
> ko cilre fi la lojban  --  http://xiron.pc.helsinki.fi/lojban/

-- 
           Phoenix -- President of The Artistic Intuition Company
       Caelius * Mirror Reflex * Runica * X-Domain * Infinite Realms
                          http://www.io.com/~fenix