Re: [AD] mac port of allegro

[George Foot <gfoot@xxxxxxxxxx>]

On Sat, Dec 09, 2000 at 08:44:36PM +0000, ronaldo hideki yamada wrote:
> I working in a mac port of allegro in MPW ide (free from Apple).
> 
> I write some drivers methods and I get all the generic C files to build the
> library
> 
> Most of allegro(all3933.zip) examples and some games are runnables over my
> code.

Excellent!  Well done!

> List of modified files

I think it would be good to merge in your changes as they stand,
assuming they don't break the existing platforms.  After that
you can send smaller patches, or if you know how to use CVS
we'll add you as a developer so that you can commit code
directly.

> src/mac/allegro.r

What's a .r file?  Not that it's a problem, I've just never seen
one before.

> src/mac/macallegro.c        All drivers in this file

It might be nicer to split this up, but it's up to you. :)

> How I get any help? Examples of questions?

Just ask here, like you did.  Some people have asked about a mac
port in the past, so there are definitely at least some people
around who may be able to contribute.

> Could any driver callback code allocate memory?In my port this can crash the
> system.

You mean timer callbacks, keyboard callbacks, etc?  No, they're
not allowed to do much at all really -- certainly not allocate
memory, and shouldn't call any functions from Allegro or other
libraries (including the C library).  Your guarrantee here is
that the user has to (in theory) lock all code and data accessed
inside these routines, which isn't possible for the C library;
in the particular case of allocating memory, that's a definite
no-no in DOS where this causes exactly the sort of problem that
locking solves.  (You can't lock the memory it allocates
*before* it is allocated.)

> In mac the path separator is ":" how the our opinion about handle the files
> access

Allegro has some macros defining the path separator, alternative
path separator, and drive separator.  I think if you don't
define a drive separator, it won't be supported (Unix doesn't
have one).  If you do, it's probably required that the drive
specifier is just one letter, as in DOS.  So:

> see the examples. 
> Mac                     --- Dos
> allegro.h               --- .\allegro.h

That's fine.

> :include:allegro.h      --- .\include\allegro.h

That's awkward, because the natural translation is
/include/allegro.h which is not the same.

> ::allegro.h             --- ..\allegro.h

That's just plain weird. :)

> MacHD:allegro:allegro.h --- C:\allegro\allegro.h

Hmm, how would you write MacHD/allegro/allegro.h?  With an extra
colon on the front?

I think I see the pattern.  If there are no colons, it's a file
in the current directory.  If there are colons but not one at
the start, it's a full path including drive specifier (like the
MacHD above).  If there are colons and one at the start, it's
relative to the current directory; if two at the start, relative
to the parent; etc.

I'm not sure how Allegro should deal with this.  DOS/Windows and
Unix have very similar ways of writing paths, but the Mac
looks rather different.  In terms of compatibility, it would be
better to accept DOS/Windows/Unix format paths (maybe using :
instead of / or \) and translate them to Mac format in the file
access functions (packfiles and datafiles).  That makes programs
that blindly calculate paths work better.  However, it means
displayed paths won't make sense to Mac users.

Another option is to use / as a directory separator for
Unix-style paths, and translate these to Mac format as
necessary, while also supporting : as directory separator and
not converting this type of path.  This doesn't merge too well
with Allegro's existing system though.

Part of the point of Allegro is to make programs work on all the
platforms, and while games won't do much directory access,
having to put a : on the front of the path if it contains
directories (do you have to do this?) will complicate things.  I
think it would be best to make the packfile functions emulate a
Unix-style filesystem.  I think it's important to get other
people's opinions here though, especially anyone who uses Macs
already.

> In mac does not exist the command line, the programs couldn't get the argv
> and argc. How I could emulate this?

Don't bother, at least for now -- I very much doubt any Allegro
programs really use the command line for anything.  If you don't
provide a better version of get_executable_name, you should fill
in the first element with the path to the executable, then set
argc to 1.  You could pop up a dialog box on startup to let the
user enter something, but this would be annoying because most
people wouldn't want to enter anything for most programs.  Maybe
it would be possible to offer this only if the program accesses
argc or argv[1] or above, but that would be complicated (it
could be done with gcc's constructors, to some extent).

> The stdclib in a mac redirect all printf() out to an file called stdout I
> must to solve this?

That doesn't matter.  printf output is discarded in graphics
modes in DOS and Linux, and under X if you didn't run the
program from the command line, and in Windows if the program
doesn't have a console window.  Portable Allegro programs will
use allegro_message before setting a graphics mode (which calls
printf on most platforms, but brings up a message box on
Windows), and their own graphics calls after setting a graphics
mode.

> *******todo**************
> suport to command line parameters
> mididriver
> switch hability
> sndloop are wide 16s only make them wide infinitly
> more suport to all drivers
> more speed to routines

This looks more like a wishlist. :)  From the sounds of things,
what you have already is a great start.  Of the above, the
command line is only important for get_executable_name to work,
and the MIDI driver isn't too important.

Switch handling is only important if you support it, and it's
quite acceptable not to or to only support one mode (e.g.
SWITCH_NONE!) though supporting as much as possible is
desirable.  Extra switch modes come into the same category as
MIDI and other drivers; they're not essential.  So long as it
doesn't crash if you try to switch! :)

I don't quite understand what you mean about the `sndloop'.  As
I just said, driver support is good but not essential, as is
speed -- the first stage of a port is just getting all programs
to run, and it looks like you've pretty much done this already!

> Sorry for my poor (erroring) english

Your English is just fine -- not perfect, but very
understandable!  The worst problem is your signature:

>                                         Sorry for my inconvenience

It's not really appropriate to sign off that way when you're
offering to us!  You should only sign off like this if you're
asking for something, or apologising about making a mistake.  I
very much doubt that you're inconveniencing anyone here. :)

George