[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> - More error checks would be nice
Heh, yeah. ^_^;; It gleefully overwrites files in its current form.
I need to find some better shell-scripting tutes, though, because the
one I used to write the fixbundle script is woefully
information-deprived.
> - *move* and not copy the exe into the bundle by default; you could
> add an
> option to just copy instead of moving, but I think moving by default
> is
> better: saves space and is what the user wants if he's creating an
> app
> bundle
Simple to do.
> - Do not use a default .icns file; if user doesn't specify an icon
> file,
> leave the icons resource blank to let the system display the default
> applications icon in the finder
Actually, that is the default behavior. Run 'fixbundle exscn3d' in the
examples dir, then look at the exscn3d.app/Contents/Info.plist file --
it has a blank string for the CFBundleIcon file key, and at program
startup the icon is the default project builder one.
It'd be better, however, to remove that key altogether, although OSX
happily ignores it. Though right now I'm not sure how to do that in
the shell script (don't know how to append a text file using pipes
^_^;; ). I'm looking into it. As soon as I can I'll post a third
version of fixbundle.sh.
> - The .icns file is MacOSX specific; in the spirit of the *fixicon
> tools
> currently available for Win32 and BeOS, it'd be nice if the tool
> would take
> an Allegro supported image file, and create the icon out of it,
> without
> needing the user to write the .icns file. This is the reason I
> guessed a
> real app would fit better the need, rather than a shell script...
Ahh... okay. See, I've never used the windows port at all, so I didn't
understand that that's what those tools do. I'll look into it. I'd
bet anything the icon format is open. (And from the looks of it, it
might just be four uncompressed runs of images for the icons, and three
one-bit runs for the bitmask, with a header, though I could be wrong).
I can't promise anything this week, though, due to a number of
unforseen personal circumstances.
> 16bit isn't supported in fullscreen under OSX. Only 8, 15 and 32 bits
> are
> ok. When you set a 16bit fullscreen mode under OSX, it is actually
> 15bit;
> dunno why they made it so, but probably is for ease of coding, as in
> 15bit
> each sample is 5 bit... Just a wild guess!
Probably also for speed of execution in "thousands of colors" mode.
I'd bet anything it was to simplify dithering calculations.
- Charles