| Re: [AD] mac port of allegro |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
newbie question how works this mailing list?
ABOUT SOURCES.
My sources are target to PowerPC (Sorry 68K Users but)
My machine is Performa 6360(4/5 years old;160Mhz CPU;40Mhz BUS;48MB RAM) no
hardware acceleration! MacOs(8.1).
I couldn't determine if sources are fine to others machines(I know be the
only person which use Mac)
I am using the DrawSprockets and I working only on fullscreen mode
My sources consider which VideoMemory is always linear, I not verify
this!(others sources I see apper not verify too)
Resolutions and dephts suported from my machine (1MByte of VideoMemory in
Main System DRAM)
640x480 1,4,8,15
800x600 1,4,8,15
832x624 1,4,8
1024x768 1,4,8
The Apple 16bpp is an 15bpp real depth (5 bits for r,g and b,1 bit pad) and
the Apple 32bpp is an 24bpp real depth(8 bits for each primary color,8 bits
pad)
The others resolutions as 320x240 are like this
the real screen
+----------------+
| | * Work screen
| |
| ******** |
| ******** |
| ******** |
| ******** |
| |
| |
+----------------+(640;480)
I known, the Quake game double the pixel sizes to fill all screen in 320x240
mode.
how I send my sources?
>> src/mac/allegro.r
> What's a .r file? Not that it's a problem, I've just never seen
> one before.
this .r file is an resource file, all files in mac can have an resource part
(called resource fork, the macos makes be unique entity) it's contains
auxiliary data sample:
object resource
-image/sound/movie your preview
-file your custon icon
-text your formating, position of cursor, position on window
but most applications must have your resource fork to store:
-memory requeriments of program
-tell about some compatibility flags(32 bit clean);
-windows and control (Mac GUI) definitions;
-your icon, icon of your files;
-most of locale dependent data ( menu text, menssages );
-help text;
-optional data, image, sound, especial code;
-contol of version, copyright information;
-etc
Then many games which I see are only one file (Drag to install)
>> src/mac/macallegro.c All drivers in this file
> It might be nicer to split this up, but it's up to you. :)
I think the same (less PgDown)
>> 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.
>
My code already handle this it accept any DOS Unix format separator (the mac
suport is not important, only developers use the colon, all users never type
colon to access paths always use the mouse ) but it only support relative
path (start from current directory) not absolute (start from root of any
device)
I have to modify the file "allegro/src/file.c" to call an wrapper
_al_open(char*,int ) instead open(char *,int ,int).
<--code included-->
#ifndef ALLEGRO_MPW
f->hndl = open(uconvert_toascii(filename, NULL), O_WRONLY | O_BINARY |
O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
#else
f->hndl = _al_open(uconvert_toascii(filename, NULL), O_WRONLY |
O_BINARY | O_CREAT | O_TRUNC);
#endif
<----------------->
the findfirst accept any DOS/UNIX format of pattern (?*) translate to mac
format (*? in mac are normal chars, user can put in filename) search the
files match and return the name in DOS format (UNIX are best right?)
in file.c i have to put this
#ifndef ALLEGRO_MPW
#include <sys/stat.h>
#endif
because not exist the <sys/stat.h> in my system
>> 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).
>
my code already return ".\current_app_name" as argv[0] and is ready to
return any additional "source defined" paramets, then will be easy popup any
dialog box to get paramets from user, I no method to detect if this is need.
an interesting thing about this is an DragDrop interface (Thanks Grzegorz
Adam Hankiewicz) where the user can create an empy folder and rename as "-h
480 -w 640 -bpp 16 /teste.dat" and drop in application. I have inclusive an
other source code which do this (DropUnix FrameWork) but is too strage
About this,who know how display any dialog box in mac GUI and get the user
type?
>> 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. :)
OK in my language (portuguese) was the term right (todo / "Para Fazer")
> 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.
>
> 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!
the allegro library can play looping between two points right?. my port do
this, but the maximum time is 16s
Others questions
What is pan?, i presume be in my language "balance" or how many volume is to
Left or Right channels
How works the scroll routines in GFX_DRIVER
How works the sweep_* and ramp_* routines in DIGI_DRIVER?
----------------------
Above (or Bellow?) is the drivers and the routines implemented (not all
right) if convenient mark the important to implemented (desc. are like)
Note the drivers call the allegro _handle_* functions
SYSTEM_DRIVER system_macos ={
SYSTEM_MACOS,
empty_string, *********is this which I put?**********
empty_string,
"MacOs",
_mac_init,
_mac_exit,
_mac_get_executable_name,****No full Path in this version!****
NULL,
_mac_set_window_title, ****No window no title*****
_mac_message, ****The window is a Mac GUI
****and suport only 254 chars
_mac_assert, ****I can put any Debbuger trap in?****
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
_mac_desktop_color_depth, *** not implemented *****
_mac_yield_timeslice, *** what do it ****
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
};
#pragma mark MOUSE_DRIVER
MOUSE_DRIVER mouse_macos ={
MOUSE_MACOS,
empty_string,
empty_string,
"MacOs Mouse",
mouse_mac_init,
mouse_mac_exit,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL
};
#pragma mark GFX_DRIVER
GFX_DRIVER gfx_drawsprocket ={
GFX_DRAWSPROCKET,
"",
"",
"DrawSprocket",
init_drawsprocket,
exit_drawsprocket,
NULL,
vsync_drawsprocket,
set_palette_drawsprocket,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
_mac_create_system_bitmap, ****Where I test code on bitmaps **
_mac_destroy_system_bitmap,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
640, 480,
TRUE,
0,
0,
0,
0,
};
#pragma mark KEYBOARD_DRIVER
KEYBOARD_DRIVER keyboard_macos ={
KEYBOARD_MACOS,
0,
0,
"MacOs Key",
0,
key_mac_init,
key_mac_exit,
NULL, NULL, NULL,
NULL,
NULL,
NULL
};
#pragma mark TIMER_DRIVER
TIMER_DRIVER timer_macos ={
TIMER_MACOS,
empty_string,
empty_string,
"MacOs Timer",
mac_timer_init,
mac_timer_exit,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
};
#pragma mark DIGI_DRIVER
DIGI_DRIVER digi_macos={ /* driver for playing digital
sfx */
DIGI_MACOS,
empty_string,
empty_string,
"MacOs Digital",
0,
0,
16,
4,
sound_mac_detect,
sound_mac_init,
sound_mac_exit,
sound_mac_mixer_volume,
sound_mac_lock_voice,
sound_mac_unlock_voice,
NULL,
sound_mac_init_voice,
sound_mac_release_voice,
sound_mac_start_voice,
sound_mac_stop_voice,
sound_mac_loop_voice,
sound_mac_get_position,
sound_mac_set_position,
sound_mac_get_volume,
sound_mac_set_volume,
/* pitch control functions */
sound_mac_get_frequency,
sound_mac_set_frequency,
NULL,
NULL,
sound_mac_get_pan,
sound_mac_set_pan,
NULL,
NULL,
NULL,
NULL,
NULL,
0,
0,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
};
Ronaldo