Re: [AD] show_os_cursor

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


On Wed, 2005-03-23 at 00:06 +0100, Evert Glebbeek wrote:
> > 
> > - You can now use custom bitmaps with MOUSE_CURSOR_ALLEGRO, and hide the
> > cursor with MOUSE_CURSOR_NONE. So that makes show_os_cursor complete.
> 
> First of all, great! But I have some questions/concerns:

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

> 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. Just the current API gives you
now possibility to say "enable the OS cursor, but only if possible".

> How does your patch affect scare_mouse()? Do I need to encapsulate every 
> call to scare_mouse() with a check if I have a hardware cursor active? I 
> got the impression you removed the flags from gfx_capabilities - is there 
> a different way for me to check this?

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

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

> 
> > - The functions enable_hardware_cursor, disable_hardware_cursor,
> > select_mouse_cursor are gone, since they are no longer needed.
> 
> Hmm... can we remove symbols between WIPs? I guess so, as the docs 
> explicitly state that WIP releases can break compatibility, but this still 
> feels a bit iffy to me. I think this has always meant that symbols can be 
> added in previous releases. Are there precedents for this?

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

> > - In X11, the mouse mickey hack is gone.
> 
> I object to this because I think it is a mistake. It means that 
> get_mouse_mickeys() is broken in X11. Remember that in X, the mouse only 
> generates movement events while it is within the window, meaning you don't 
> even get movement events if the mouse is on the edge of the screen for 
> fullscreen modes or outside the window in windowed modes. That breaks 
> existing programmes without an obvious fix for the end user of the 
> library.

But those programs already are broken in Windows windowed mode. But
then, I know that it's a problem. 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 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.

> The reason is that mouse mickeys cannot be retrieved reliably across 
> different platforms, but this is something that should have been realized 
> and put into Allegro's docs back when the X11 port was made and Allegro 
> became cross-platform, I don't think we should change it now. Of course, 
> such things are easier to say with hindsight.

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

> As much as I hate the mickey hack and how it uglifies and complicates the 
> X11 mouse driver code, unless we can come up with something that provides 
> the same functionality (ie, mouse mickeys) I think it should stay. For 
> reference, SDL uses the same hack Allegro uses (warping the mouse to the 
> centre of the window) but it needs to be enabled explicitly by switching 
> the mouse to `relative' mode rather than `absolute' mode as opposed to 
> providing both relative and absolute coordinates as Allegro does.

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 also added show_os_cursor to exmouse to test it. But the real
> > advantage is in programs who use e.g. double buffering.
> 
> What's the advantage over the current way with a call to 
> enable_hardware_cursor() at the start? It shouldn't make any difference at 
> all with the current implementation as far as I can see.

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.

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.

-- 
Elias Pschernig





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