[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat, 2005-03-19 at 18:11 +0100, Evert Glebbeek wrote:
> > Speaking of hardware cursor clarifications - my local copy of Allegro
> > has the attached additional function.
>
> Sorry I didn't respond to this earlier. Anyway, I think the (at the time
> proposed) system_cursor API originally worked like that: you call a
> function to display the OS system cursor and it tells you if it succeeded
> or not and if it didn't you show your own.
> I changed it because someone (I thought it was you, but I could easily
> remember wrongly) didn't like it and wanted it to use the show_mouse()
> API.
Heh. Too lazy to look it up now, but may be. In any case, back then I
hadn't used the current API yet :P
>
> > The latter got annoying to me, after using the HW cursor a lot. Not only
> > is it more (and un-intuitive) code,
>
> I agree - obviously.
> Please note that Allegro historically made a distinction between hardware
> and software cursors before it could use the native system cursor.
> I think it would be best to keep the nomenclature distinct to make sure
> we're not talking about different things when talking about `hardware
> cursors' or reading the documentation: a hardware or software cursor, for
> Allegro, is a cursor made from a custom bitmap selected by the user of the
> library. A system cursor is a cursor Allegro (or the library user) has no
> control over: it is set by the OS (ok, so the user can change it there -
> but you get the point). The power of hardware cursors is in the fact that
> they share with system cursors that Allegro doesn't need to do teh drawing
> or buffering for them: the OS takes care of that.
The fact that everyone confuses them alone makes them confusing.. so I'd
actually not distinguish, and deprecate the historical "hardware
cursors", and simply have either the software cursor drawn by Allegro,
or another (i chose show_os_cursor over both show_hardware_cursor and
show_system_cursor because of this nomeclature.. but any of the 3 names
would work).
> > I'm even wondering if we shouldn't completely drop the software
> > cursor from 4.3.x - or at least find a way to draw it from the main
> > thread.
>
> We can't drop it. DirectX doesn't support drawing a mouse pointer. We get
> around this in Windowed mode where we can just use the normal Windows API
> to draw it, but in fullscreen mode we can't do that. DGA2 also doesn't do
> mouse cursors.
Yes. The compatibility layer would have it in any case, so yeah, can't
drop it from 4.3.x, butfrom the 4.3.x *API*. I.e. the part of the code
which is not in the compatibility layer.
> > - I only tested it in X11, not sure if
> > mouse_driver->select_system_cursor works the same in windows and OSX
>
> It does (and if it doesn't it's a bug).
>
> > - Allow MOUSE_CURSOR_ALLEGRO (to set a custom os cursor)
> >
> > - Allow MOUSE_CURSOR_NONE (to hide it again)
>
> Both make sense.
>
> About the problem your code aims to solve though, you should just be able
> to call
>
> enable_hardware_cursor();
> set_mouse_cursor_bitmap(MOUSE_CURSOR_ARROW, custom_bitmap);
> select_mouse_cursor(MOUSE_CURSOR_ARROW);
> show_mouse(screen);
>
> Allegro should now use the default system MOUSE_CURSOR_ARROW and fall back
> to your own custom_bitmap drawn in software if it can't do that. No need
> to check if you will get a system cursor after calling show_mouse()
> because you actually don't have to care except for calling
> scare_mouse_area() which should be safe to call because it does nothing if
> the OS draws the cursor.
Ideally, that would be true. But show_mouse(screen) causes Allegro to
blit a bitmap the screen bitmap from the timer thread. Because there's
no public access to a timer mutex, this basically break programs, even
if the user protects all access to screen with mutexes. At any time,
there may be a back-and-force blitting from the timer thread. The design
simply is broken. So I absolutely need to check the
gfx_capabilities&GFX_HW_CURSOR flag, and call show_mouse(NULL). Agreed,
since I wouldn't do any drawing between the check, this actually would
be safe, even if by a race condition the software mouse may flash up and
disappear.
--
Elias Pschernig