| Re: [AD] This Allegro app can freeze under Windows 2000 |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
On Wed, 2005-12-28 at 16:07 +0100, Evert Glebbeek wrote:
On Wednesday 28 December 2005 15:31, Elias Pschernig wrote:
What if you remove the show_mouse and acquire_mouse stuff? I always
thought it is broken except under DOS.
I mean, show_mouse/scare_mouse/unscare_mouse.
I tried removing scare/unscare_mouse and the problem did not appear. I
also tried nesting scare/unscare_mouse outside of the
acquire/release_bitmap and the problem went away as well.
Should work whenever there is a software cursor (*scare_mouse() is a no-op
when the OS is responsible for drawing the cursor).
By software cursor, do you mean manually drawing a sprite at the
mouse-co-ordinates with the app, or do you mean the cursor that Allegro
provides (ie. not the new hadware/OS cursor stuff that's been added to 4.2)?
Yes, but since the mouse is drawn from the timer thread, this never
worked correctly in the multithreaded ports.
The screen is locked with acquire_bitmap from the main thread, then the
timer thread does acquire_bitmap from another thread - and now it either
is already deadlocked (under linux), or will deadlock sooner or later
when also the timer lock is acquired, and scare_mouse tries to remove
the timer interrupt.. it simply is very flawed design :/
So does that mean that the only 'non-flawed' way to avoid
'mouse-droppings' is to either draw a sprite at the mouse-coordinates or
use the new hardware/OS cursor stuff if it is supprted on the platform
it's running under?
Also, is vsync() the likely culprit for where the code gets stuck, or is
it in one of the acquire/release/scare/unscare functions? Seeing that
it's the timer-trhead that gets locked, then the main thread might be
waiting for the timer thread to do a vsync().
AE.
PS. Under Windows 2000, I am using DirectX 9.0c, and under Windows 98,
Direct X 8.1