Re: [AD] Allegro 4.2 planning

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sat, 2004-10-16 at 21:30 +0200, Evert Glebbeek wrote:
> 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.

True. We must not let new_api_branch get the new Allegro 5 or
allegro_new module.

> 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 agree, making Allegro 64 bit clean should be done as soon as possible.
About thread-safety - I think e.g. the X11 bitmap access is quite safe
now. I can successfully draw from different threads (well, Allegro timer
thread) to the screen after Chris' last patch.

> 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 

Agreed.

> 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 

I think new_api_branch is enough. I looked a bit into it, but I don't
think I want to do this anymore for 4.2. (And still haven't looked at
Peter's X11 keyboard code in new_api_branch..).

The X11 problem is, X11 primarily only reports an X11 keysym for every
keypress. But the mapping of keysym to positional PC key (which is
required for the current solution) is impossible. (But you can use
xkeymap to give Allegro some hints.. so that makes the problem less
serious. You *can* run xkeymap and have a working keyboard in X11.)

The problem with a proper solution is, mapping of X11 keysyms to unicode
characters is equally impossible than mapping to PC keys, at first
glance. So if we just map X11 keysyms to Allegro's KEY_*, we now have
KEY_* always working, but can't produce the unicode characters for it. I
got it trivially working with 7-bit ASCII.. but other keys either
require dealing with locales (which somehow scared me), or with XIM. The
latter I implemented, but it locks up if XInitThreads is used.. which
Allegro currently does.

> 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)?

I think the SIGALRM version was removed from new_api_branch. So we
should just try to forget it :)

> 
> 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 

Probably could add it also for X11, along with some heuristic [xkeymap]
sections for every language, as was discussed here a while back.

> 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.

You mean, something like:

FONT *load_font (char const *filename)
{
    DATAFILE *dat = load_datafile (filename);
    FONT *f = dat[0].dat;
    dat[0].dat = NULL; /* Hack so the next line works :P */
    unload_datafile (dat);
    return f:
}

Well, I guess it would fit into the API.

> 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?

Wasn't the result the on Windows, it can never work, and therefore no
point to look for a solution on other platforms? Or was MacOS X the one
where it wouldn't work?

> 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?
> 

Sounds great! And yeah, if we don't have enough new material for a
4.1.18 and 4.1.19, we could just call them 4.2.0 RC 1 and 4.2.0 RC 2, or
something like that.

> 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.
> 

Definitely would be good.

> 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.
> 

Heh, seems very optimistic :)

> Thoughts? Comments? Suggestions? Anything I missed?
> 

I just looked at my old list at
http://awiki.tomasu.com/bin/view/Main/AllegroAPIDesign
The font format and keyboard.dat are the same as mentioned above, and
some stuff is updated or only relevant for 4.3 or 4.4. I think, adding
the al_get_ticks might be a good idea - we just couldn't agree on a name
last time it came up, but eventually such a function is needed.

-- 
Elias Pschernig