[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