Re: [AD] show_os_cursor

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> Well, it only uses your driver functions, just with a more direct user
> API.

Well, that's what  had questions about :)

> > Can I still use the show_mouse() API and get the benefit of hardware
> > cursors if they are available, ie, without having to change too much
> code?
> > If not, any chance of getting that back (shouldn't be too hard - just
> use
> > the hardware cursor if the target bitmap is the screen)? For me, the
> > hardware cursor loses much of its usefulness if it doesn't.
>
> That would be how the current API works.

Exactly - I don't have to change my programmes to take advantage of the new
feature.

> Just the current API gives you
> now possibility to say "enable the OS cursor, but only if possible".

That's what enable_hardware_cursor() does - but you can't know if it worked
or not unless you try to display a mouse pointer as well. That I would like
to see changed if possible though. As far as I'm aware, you can currently
be assured of the following:

For custom Allegro cursors drawn by the operating system:
 - it always works in X11 *if* the RGBACursor extension is available
 - it only works in Windows in windowed mode if the bitmap is 32x32 pixels.
Allegro will padd a bitmap smaller than that to 32x32.
 - it doesn't work in fullscreen in Windows
 - Works in MacOSX, but I don't know to what extend.
For OS native cursors:
 - Should always work in X11
 - Should always work in windowed mode in Windows, but not fullscreen mode
 - Don't know about MacOS X.


> I didn't change anything in the software drawer. So if show_mouse() was
> not called, scare_mouse has no effect I guess.

True. As I said though, I want to be able to use show_mouse() to be able to
take advantage of the hardware cursor if it's there.

> > But again, if I can't tell Allegro to use the hardware cursor (with a
> > custom bitmap) if it's available with show_mouse() or fall back to
> > software rendering if it isn't and not think about this in the rest of
> my
> > code it is almost useless to me. Native OS pointers are a different
> issue
> > as they didn't exist in Allegro until recently. For them, I think it's
> > perfectly fine and sensible to have a seperate API.
>
> 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, 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.

> But those programs already are broken in Windows windowed mode.

Less so than in X11 though, since the mouse only stops generating mickeys
at the edge of the screen rather than the edge of the window. And of
course, in X11 they would be broken in both fullscreen and windowed mode
(always, in other words).

> Ideally, this hack would never have
> been put it, and get_mouse_mickeys() would have stated that it can't
> reliably work in all cases.

I completely agree - but I'm afraid we're about four years to late for that
:(

> I guess it makes sense to only remove this
> for 4.3.x, and keep for 4.2.0. But then, every hack less would be a good
> thing.

Again, I agree - but I see now way around this :(

> Yes, I agree. I was just somewhat shocked to see how the HW cursor now
> needs another hack to disable the other hack :P And then while I was
> going over the code, just removed both hacks for that patch :)

Yeah, I agree with the motivation - just not the result.

> Yes, I remember having seen that. I wonder how they deal with HW cursors
> - but then, if you can explicitly switch, it's not a problem.

I'm not 100% sure, but I think SDL only tries to use a hardware cursor in
absolute mode. I'm not sure if it actually draws a pointer at all if it
can't let the OS do it.
I *think* I remember SDL being limited to monochrome bitmaps, but maybe
that's just in X11.

> 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?

> 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.
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. :)

Evert




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/