[AD] Allegro 4.2 planning

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Now that 4.1.16 is out and the year is advancing at a steady pace, I think 
it's a good idea to look at the plans for 4.2 again. I'd still like to 
have it done before the end of the year, also because I think it's 
important to have the new_api_branch marged back to mainline as soon as 
possible.
So, what needs to be done for 4.2? Off the top of my head, currently open 
issues are:
 * Documentation patches
 * The system mouse cursor
 * vtable hooks for AllegroGL
 * Some blitting problems in Windows reported by Richard Phipps on A.CC
Extract from the todo list:
 * make the library internally thread-safe
 * fix use of 32-bit 'long' on 64-bit platforms
 * don't use BITMAPs for zbuffers
 * replacement for set_color_depth/set_gfx_mode
 * (win32) Investigate Alt+Tab pop-up window being overdrawn in windowed 
mode
 * (win32) Investigate problem with keyboard in the dxwindow test
 * (win32) Modify convert_hbitmap_to_bitmap() behaviour with 8-bit DDBs
 * (X11) Rewrite the X11 keyboard driver
 * (X11) Investigate problems with the SIGALRM version
Random ideas/nice to have:
 * system/hardware mouse cursor functionality for MacOS X
 * Updated/newer DirectX graphics driver

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.
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. 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. 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. I'm clueless 
about the Windows issues mentioned. 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. I also discussed a 
while back with him a way to directly load a font from an Allegro datafile 
(ie, a load_font() function). While I think a generic font loading 
function would be too much, one that loads a (well defined) font from a 
datafile could be useful to have, mainly for new users who don't know how 
to use datafiles yet.
I'd like to tackle the END_OF_MAIN() on Windows and MacOS X, even though 
previous attempts to eliminate it have always failed. I'm at a loss for 
Windows, but for MacOS X I was wondering if it'd be possible to use a 
constructor function instead of the current mechanism?

Thinking about a christmas/new year deadline for 4.2.0, I'd like to 
increase the frequency of WIP releases. I'd like to put out 4.1.17 early 
november and 4.1.18 at the end of november. Maybe a 4.1.19 by mid 
december, which would be like a 4.2.0 beta. Of course, there'd need to be 
enough new material to justify a new release. ;) (Although a release 
candidate is probably justification enough).
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?

Maybe we should collect a `hard' todo list of goals we want to get done for 
4.2 and things which could be done at a later time.

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.

Thoughts? Comments? Suggestions? Anything I missed?

Evert





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/