Re: [AD] Mouse cusor documentation

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


On Mon, 2004-10-04 at 16:39 -0700, Chris wrote:
> Elias Pschernig wrote:
> > Hm, so you could do:
> > enable_hardware_mouse();
> > show_mouse(NULL);
> > if(gfx_capabilities & GFX_HW_MOUSE)
> >    // hardware mouse is possible
> 
> Actually, all you'd have to do is enable_hardware_mouse(), then check 
> the flag. show_mouse(NULL) is the default, so unless you were already 
> showing a mouse pointer, you wouldn't have to call it again.
> 

Yes, that would be better. set_mouse_sprite (set/select_mouse_cursor)
would need to check the mouse size though, so probably a vtable function
would be necessary to check.

> > A function like check_hardware_mouse() would look cleaner. Or, maybe we
> > can instead add a function show_hardware_mouse - which would take care
> > of the check function, and also do what the show_hardware_cursor I was
> > talking about previously would do:
> 
> But that way I suggested wouldn't show the mouse pointer.. that's the 
> whole reason for it. So you can just test and not have to show the mouse 
> yet.
> 
> > Can be
> > useful if you don't need Allegro's software cursor - but would still
> > want to use a hardware cursor in case it is available."
> 
> I can't help to wonder under what circumstances this would be desirable. 
> If you want a mouse and a hardware mouse is unavailable, wouldn't you 
> want a software mouse?
> 

I don't think so. I almost never used Allegro's software mouse - but I
often wanted to use the OS mouse (which is possible with Evert's
patch :)

> > If you have e.g. a mouse
> > drawing routine which draws flicker free above a playing animation,
> > which Allegro's software mouse can't do. But a HW mouse still would be
> > ok.)
> 
> If the animation is that big that the mouse would be flickering a lot, I 
> would think it'd be best to just disable the pointer outrighr. Nothing 
> worse than trying to watch a video and being unable to hide the mouse. 
> (And as long as the animation is <= 30FPS, you can vsync and hide/blit 
> anim/show with no flickering (as long as the system is fast enoung), 
> with no real percievable animation jitter. scare_mouse_area is your 
> friend. ;)
> 

It's not playing a video, but e.g. moving things in a 2D game. With
Allegro's mouse, you need scare_mouse everywhere, which may be awkward
depending on the code. And it always flickers, even if not a lot.

And, worst of all, it updates the mouse asynchronously. The HW mouse
also updates asynchronously, but with an important difference: You don't
need to care when drawing. Consider, you draw 100 objects to the screen
every frame. Now, you could just draw the mouse as object 101 in every
frame if there's no HW mouse - very simple and easy, no scare_mouse
around every draw command, no worrying where between those 100 objects
the mouse might be drawn from a timer. OTOH, a HW mouse would be fine as
well. So, at least for me, it actually would be the standard way to use
the mouse. Only Allegro-GUI apps would fall back to a software mouse
cursor (and they wouldn't use show_hardware_mouse).

But anyway, if I can do:

int
show_hardware_mouse(void)
{
   return gfx_capabilities & HW_CURSOR;
}

There's no need for it to be in Allegro. But if it is needed in the
vtable anyway, and the testing of the flag isn't reliable while the
mouse is not displayed already, I think it is much cleaner to just
expose such a function to the API.

-- 
Elias Pschernig





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