Re: [Fwd: Re: [AD] Mouse cusor documentation]

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2004-10-06 at 00:32 -0400, Jon Rafkind wrote:
> email message attachment (Re: [AD] Mouse cusor documentation)
> On Wed, 2004-10-06 at 00:32 -0400, Jon Rafkind wrote:

> Elias Pschernig wrote:
> > 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.
> 
> I doubt this would be hard to do, if it can't already be done now.

Yes. I guess, it would be a matter of checking that the size of the new
sprite is 32x32 in windows, and either true or false in X11 depending on
if you compiled with libxcursor or not. All I think should be there is a
way to not have to display a software cursor from a timer in order to
know if a HW cursor can be used, as is the current design. (And I don't
think it really is a big problem, just not doing it feels a bit more
clean :)

> 
> > 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 :)
> 
> But if you only allow the hardware mouse, and not show the software
> mouse, what will the users who can't use the hardware mouse do? They'll
> have an invisible cursor and make it impossible to do anything
> mouse-related.
> 

That's what I'm talking about - I don't want to use the
software-mouse-drawn-from-a-timer at all, instead either a HW mouse or a
mouse I draw myself (e.g. in every frame).

> > 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.
> 
> Depends on how you do it. You don't need to have Allegro draw it in the
> timer function to see the mouse, even before. Your typical game will
> update 60 times a second (or more). Before Peter's patch, the mouse only
> updated 50 times a second (now it's 100), so that's plenty. All you'd
> have to do is manually blit the mouse sprite to the buffer before
> sending it to the screen (or if you want to keep the buffer clean, do a
> vsync, blit the buffer then the mouse). This has the extra benefit of
> not having the mouse/timer thread keeping the CPU from the main program
> as it draws durring your game's logic, giving you (albeit a little)
> faster frame rates.
> 
> IMHO, the async mouse drawing was only intended for the GUI, or similar
> situations where you don't double buffer.
> 

Exactly what I tried to say all the time :) Only a HW mouse would always
be superior (well, except in situations where the mouse position must be
synchronous). Anyway, show_hardware_mouse() would just be an alternative
to show_mouse(), which does exactly the above: It never uses a software
mouse. The only difference is to avoid the little cludge where
show_mouse() automatically enables drawing from a timer currently. If
show_mouse(NULL)/set|select_mouse_cursor/set_sprite are changed to also
update the HW_CURSOR flag - the software mouse isn't displayed as well.
But then the meaning of GFX_HW_CURSOR changes, and it still isn't as
nice as just calling show_hardware_mouse().

-- 
Elias Pschernig