Re: [AD] OSX Notes, Take 34

[Angelo Mottola <a.mottola@xxxxxxxxxx>]

> I was wondering if the poll_mouse() method is required under OSX?  I
> found that the mouse click detection under OSX has been highly
> unreliable without calling poll_mouse() once per frame (sometimes,
> without it I get no mouse presses at all).

No, poll_mouse() is not required under MacOS X. And the fact you used it
into the main loop of your program also explains the lock you're
experimenting (which is NOT related to floodfill): at the end of the main
loop, you do a while (mouse_b);... Which will hang because the mouse has
entered polling mode, thus the mouse global variables are not automatically
updated, and you have to call poll_mouse() inside that while.
So you can either add poll_mouse() there or completely remove everywhere
from your program, and it'll work.
About your code, there are some things you should check: first, if you
update the whole screen every frame even if the user didn't take any action,
it's a waste of time and the updates will be slow (since you also use double
buffer). Also, at the end of the loop, you assure no mouse buttons are
pressed, and this makes the app to not respond properly to click events...
Your loop infact does:

{
    handle input
    apply tool relative to click (if any)
    render everything using double buffer
    assure no mouse button is pressed
}

So when the loop restarts, it is assured the user has released the mouse
buttons, but then he should also instantaneously reclick it in order to
work... Most of the app time is spent updating the screen, so when the user
clicks, it is likely the program is in the middle of an update, after which
it forces the user to release the button (infact if you hold down the
button, the cursor will hang until you release it). The result is the tool
action is often (almost always) skipped...

> Also, I've had a number of strange and untraceable crashes while using
> Allegro/OSX.  There was a problem with the file routines that I
> couldn't sort out (and neither could the people in the IRC room), but
> which abated when I switched to normal fopen's/fwrite's -- the file I
> wrote out (around 200k) was truncated by around 2000 bytes.  When I
> wrote the file all the allegro packfile routines stated there was no
> error (I'm anal about checking error codes), but when I read the same
> file back in the file was missing information.  As I said, when I
> switched to the normal file routines the problem magically disappeared.
> Unfortunately, the code which provided this bug is now gone, or I'd
> have attached it.

As Vincent suggested, maybe it's a matter of flushing here...

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx