[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 2005-03-23 at 18:04 +0100, Evert Glebbeek wrote:
> > You need to care in so far as if you enable the os cursor, and it
> > succeeds, you probably don't want to call show_mouse after that.
>
> How about this: suppose we want to display the Allegro cursor. This is
> actually not displayed until show_mouse() is called. Calls to show_mouse()
> are ignored (return silently) if we have selected a different cursor from
> the default OS one. This would mean something like:
>
> show_os/hardware/whatever_cursor(type)
> {
> /* black magic */
> }
>
> show_mouse(bmp)
> {
> if (wanted cursor is allegro cursor) {
> if (hardware cursor available)
> use_the_damn_thing();
> else
> cry();
> }
> }
Yes, that's probably what we need to do. I will replace my last patch
with another less rigorous one, trying to do just this. And it will also
have to set the gfx_capabilities flags then.
Maybe should at least make a new variable mouse_cursor_state though to
distinguish between the 4 possible cases:
- no cursor is in drawn
- software cursor is currently being drawn
- hardware cursor is currently being drawn with a custom bitmap
- hardware cursor is currently being drawn with a system shape
And leave gfx_capabilities to be the static gfx driver capabilities,
i.e. "can this driver do accelerated masked blits" (with the exception
of the flag to tell if triple buffering was enabled).
> > Yes, so the next time they could be removed would be 4.3.x. We would
> > just mark them as deprecated. Hm, so actually everything marked as
> > deprecated sine 4.0 will be in 4.2? And then in 4.4? I'm too tired now
> > to think about this..
>
> On a related issue, I think it's fine if 4.4 emulates the API of 4.3, but
> leaves some things less well optimized than 4.2 does. Different discussion,
> anyway.
Well, with 4.3.x we get the infamous compatibility layer, so we will
have a clear cut between official API, and compatibility layer, I hope.
And the latter should not influence design of the former. And the
compatibility layer would then work like you said.. it should allow old
programs to continue to compile and work, but not necessarily in an
optimal way.
> > Well, one advantage is, like I said, the reason why I added a patch at
> > all in the beginning: What if I use some sort of buffering/flipping, as
> > surely most Allegro games do? The show_mouse API then simply is useless,
> > since I have a fixed point in my program logic where the graphics are
> > updated, and an asynchronous mouse drawer in the timer thread doesn't
> > help at all. And for something like exmouse, it really doesn't matter
> > much. Where you called enable_hardware_cursor/show_mouse before, you now
> > first explicitly enable the hardware cursor, then only show the software
> > mouse if necessary.
>
> Yes, but you need to keep track of wether or not it's nescessary instead of
> tell Allegro to deal with it. Or do I misunderstand you?
No, you're right. Just in my experience, most of the time I can't use
the software cursor at all - so I have to keep track if I need to do
"draw_sprite(back_buffer, mouse_sprite, mouse_x, mouse_y" just before
the flip or not, anyway.
>
> > Anyway, I think now we need both. The question is, how to make the API
> > so it's not confusing. And without making show_mouse() away of
> > show_os_cursor as well.. the current just doesn't separate the software
> > cursor from harware cursors, where show_os_cursor aims to be separate.
> > Now separating show_os_cursor from show_mouse is doomed to fail, if
> > show_mouse itself can use hardware cursors with the current API.. hence
> > I simply removed that feature. Just seemed like the simplest and
> > cleanest solution.
>
> How about what I outlined above? The allegro cursor is not shown until
> show_mouse() is called, and show_mouse() does nothing if a different cursor
> is already being displayed. In the case that it is to display the Allegro
> cursor and a hardware cursor is available, it just tells the OS to do what
> you tell it from your API.
Yes, makes sense. It just makes the hardware cursor API quite complex.
> Or we could just have show_mouse() do nothing at all if an OS cursor is
> already in use, in which case there is a slight discrepancy in when then
> mouse cursor first appears, but maybe that's not too important.
>
> Oh, by the way - we need to keep track of set_mouse_sprite() - that should
> affect the hardware mouse cursor if it's a custom one. Not sure if your
> patch did this or not. If it already did, just ignore this reminder. :)
>
Hm, maybe set_mouse_sprite(bmp) should simply call
set_mouse_cursor_bitmap(MOUSE_CURSOR_ALLEGRO, bmp)?
--
Elias Pschernig