Re: [AD] SF.net SVN: alleg:[11766] allegro/branches/4.9/src/macosx

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 7 mrt 2009, at 06:27, Elias Pschernig wrote:
> Did we really bring A5 into a state already where this starts to be a
> problem? :)

I don't know. I agree it's fairly stable for me now.

> The usual places to check would be:
>
> http://sourceforge.net/tracker/?group_id=5665&atid=105665
> http://sourceforge.net/tracker/?group_id=5665&atid=355665
> http://wiki.allegro.cc/index.php?title=Allegro_TODO
>
> But I don't see anything obvious there.

Hmm. Some of those things on the TODO list are actually done now, I'll  
take them off. The OS X TODO list is more or less empty: the first is  
nice, but not necessary, the second one needs some attention, there  
doesn't seem to be anything we can do about the third and the fourth  
would presumably just require setting a CMake code generation options?

Now that I think about it, there are one or two (minorish) issues:  
when compiling, the code still generates warnings about obsolete  
functions relating to code designed to "avoid a dead bootstrap  
context". The only google result for this is the ACC thread where  
someone contributed a patch for this, so I have no idea what this  
means in practice or how to update that piece of code. Looking for the  
relevant function or immediately goes into kernel programming details.  
I do get the impression that the problem it's set out to solve is no  
longer present on newer versions of OS X, so maybe we can just remove  
that?
Another issue: all programs currently show up in the dock, even if  
they're commandline utilities. A4 had a special flag for console  
applications that prevented this, is there something similar for A5?  
It doesn't bother me too much though.

> There's just lots of small things everywhere which require a lot of  
> work
> (cleaning up and fixing the display selection, e.g. under OSX it uses
> NSOpenGL's selection algorithm instead of ours;

For the most part, I think that's what we actually want. Not that we  
have much of a choice.

> clean up all the pixel format conversion stuff

You mean src/pixels.c?

> and find a way to optimize it a bit more again;
> also make it easier to add new formats (we still don't support any
> floating point color components); ... lots more like these ...)

Ah yes: find and clean up some "FIXME" or "TODO" comments.

> > A zlib fshook addon is in the works I assume, right?
> I don't think it is. Also a libzip addon would be nice - finally we
> could replace .dat with .zip :)

Yes, that would be cool. Both would be nice, actually.
In fact - if we have a zlib addon, do we even still need stdio (except  
when zlib is not available)? From what I remember, the two are pretty  
much function-for-function compatible, so zlib could replace stdio,  
right?
Someone mentioned PhysFS for reading .zip files (among other formats).

Evert