[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Some of you may be aware of the fact I've been working on a native Allegro 4
port to MacOS X in the last months. I made a first attempt, and spent about
a month trying to solve a problem with multithreading and the native
objective-C API of OSX: Cocoa. The problem was the app window got
unresponsive if the events weren't fetched from the main app thread, and
also if drawing to the window didn't happen in the main thread as well.
So I tried running the entire user program in a secondary thread, and do
window updates and events pumping from the main one... But still with no
luck.
Well, now I got it to work :)
There were also some other things to take care about, but eventually I found
how to make it work properly using multithreading, and continued my old work
on the OS X port. As by now, I have:
- C versions, endianess aware, of the asm common color-conversion routines,
to update the app window. Only *->15 and *->32 have been properly tested
though, as under OSX 15 and 32 bit are the only possible desktop color
depths. Tests on the other is welcome, also considering I fear they *have*
bugs if the target machine is big endian...
- Working system driver
- Fully working windowed gfx driver
- Nearly complete fullscreen gfx driver (it works, but gives some minor
problems when you quit)
- Initial support for hw accelerated video bitmaps
- Mouse driver (it always report 3 buttons though for testing - how should I
deal with 1-button mice so common under Macs?)
- Complete keyboard driver (I needed to add 4 new KEY_* contants to deal
with Apple keyboards)
Said this, I'll let you know all Allegro shipped programs/examples compile
(only static lib is supported so far btw) and run flawlessly, including test
and demo :)
During development I also found and fixed a small bug in the C sprite
drawing routines: draw_trans_sprite wasn't skipping bright pink pixels.
So, what is still missing is a sound/midi driver, joystick driver (but I
have no USB joysticks, so I fear I can't write the driver for now) and of
course eventual bugfixes and refinements to the code.
BTW, the code is built on top of a 3-months old CVS snapshot; I hope syncing
it with cvs update -Pd will not break it...
Now I was going to commit the whole port, but I want to be sure I am allowed
to do so. Is it ok to commit it to the default branch?
--
Angelo Mottola
a.mottola@xxxxxxxxxx