[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> Yes, that's probably what we need to do. I will replace my last patch
> with another less rigorous one, trying to do just this. And it will also
> have to set the gfx_capabilities flags then.
I guess so.
> Maybe should at least make a new variable mouse_cursor_state though to
> distinguish between the 4 possible cases:
Makes sense to me. May want to make it a function though ;)
> And leave gfx_capabilities to be the static gfx driver capabilities,
> i.e. "can this driver do accelerated masked blits" (with the exception
> of the flag to tell if triple buffering was enabled).
I was thinking about this. The problem is that gfx_capabilities is used for
two things: to report what the hardware can do and to indicate what the
hardware does right now, just as cpu_capabilities is used to specify what
the processor can do and what it is allowed to do (hence unsetting CPU_MMX
to disable MMX code works).
By the way, gfx_capabilities is appropriate to report wether or not it's
possible to draw a hardware cursor since this is a property of the graphics
driver.
> Yes, makes sense. It just makes the hardware cursor API quite complex.
Tell me about it ;)
I had nightmares when I was trying to make sense of how to get it to work
nicely as well as look pretty. I ultimately settled for just getting it to
work and not bother about pretty.
> Hm, maybe set_mouse_sprite(bmp) should simply call
> set_mouse_cursor_bitmap(MOUSE_CURSOR_ALLEGRO, bmp)?
Yes - provided it takes effect immediately, which set_mouse_cursor_bitmap()
does not in the current API.
That would normally only affect MOUSE_CURSOR_ALLEGRO though, since the
other MOUSE_CURSOR_s normally don't display a user bitmap.
Evert