| Re: [AD] Allegro 4.2 planning |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Evert Glebbeek wrote:
I think making Allegro work properly on 64 bit systems should be something
that should definitely in 4.2, as is making it internally thread-safe. Not
entirely sure what needs to be done to make this so though. Eliminating
global buffers as much as possible for one thing and blocking on accessing
a bitmap I presume.
Eric did say he wanted to make a 64-bit compatible release of the 4.0
branch..
I don't have any strong feelings about using BITMAPs for Z buffers, and I
don't think we need to bother chaning that - people who are serious about
3D will use AllegroGL anyway.
Yes, forget that item.
I don't think we'll need to have a
replacement for set_gfx_mode()/set_color_depth(), since they'll be
replaced in the new_api_branch anyway.
Agreed.
The same probably holds for the X11
keyboard driver, although if it's really broken (I have a US keyboard, for
me it works fine) then having it fixed would be a good idea.
Some of the relevant code can be pulled in from the new_api_branch.
Elias has more idea of what needs to be done though, and I think he's
got some code also.
I'm clueless
about the Windows issues mentioned.
They don't sound too bad though.
Investigating the SIGALRM version of
the library is probably something that doesn't need to be rushed either; I
think I was the only one having problems with it (I should check if those
are fixed now)?
Some other random tidbits that could be useful to add: spellcaster has
posted a detect_keyboard_layout() function that makes Allegro detect the
proper keyboard layout on Windows using OS functions. I think it would be
nice to have that function in for 4.2, even if it would only work in
Windows for 4.2.0, since that is the largest audience.
That would be great, and I think it should be done by default rather
than the user calling some function.
Given this deadline, is the second week of december a reasonable deadline
to put the code in feature-freeze as far as new features are concerned?
Fine with me.
If we can get 4.2 out by the end of the year, I think it's reasonable to
try to have a 4.3.0 out somewhere in early februari.
This depends solely on getting the MacOS X port working again by then.
Peter