Re: [AD] Allegro 4.2 planning

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

> I agree, making Allegro 64 bit clean should be done as soon as possible.

Should we use C99 int32/int64 etc. types to do this? I'm not sure we want 
to switch the 4.2 branch to C99 at this point... I don't know of any other 
way to get an integer of a specific size though.

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

Yes, that's also the impression I get. It even seems to run fine on a dual 
processor machine, which I think is about the strongest test you can do 
for something like this.

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

Ok, I understand the problem now. Do you know how SDL handles the same 
issue? Or have they just side-stepped it?

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

Well so was the DOS version, but that's still in 4.2 too ;)
But yeah, I sortof agree to let it be for now.

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

Sounds good! :)

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

Yes - although I'd prefer something that gets the first font from the 
datafile rather than requiring the font to be at index 0. If we do demand 
a specific format though, then we could also load the associated font 
palette.

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

In Windows, the problem is the broken notion of a non-portable WinMain() 
function. It looks like it's possible to get away with a normal main() 
function in MinGW at least, but maybe not always and possibly not with 
MSVC either. As I recall, results were inconclusive.

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

Sounds reasonable.

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

Well, my idea was to merge the new_api_branch with 4.2, clean up a bit, 
then release a first WIP - based on the assumption that it's in proper 
working order right now. If it isn't though, well, there's no rush really.

Evert