Universal binaries and incbin - little problem!
Archives Forums/MacOS X Discussion/Universal binaries and incbin - little problem!
| ||
| Thanks to the recent purchase of an Intel Mac, I am now able to produce universal binaries, which I figured out pretty quickly thanks to Nigel Brown's little tut. However, there is one slight problem if you include media and other files in your game by usig Incbin ... you end up with the media/files being included TWICE! This obviously means that you end up with a file that is roughly twice the size of a binary meant for just a single platform. This means that currently, I am offering three downloads from my site, giving a user the choice between PPC only, Intel only, or a universal - depending on their needs. Now the obvious solution to this would be to not use Incbin and have all your media stored in a separate folder alongside your app. This is not only messy, as your media/files are clearly visible, but also allows for unscrupulous types to nick your media, easily. Now I don't know how this old universal binary stuff works, but is it possible to compile a single universal binary that accesses the one set of media/files? I know this isn't possible within BlitzMax at the moment, but it would be nice if this were possible when Mark decides to add it. Mark, you did mention you may look into this when 10.5 is out ;o) Any thoughts? In the mean time, the second solution would be to include the media as part of the application bundle itself. This question was asked before, by Indiepath, who also found a solution, but then didn't reveal how it was done to the rest of us. Come on, Indie, do tell ;o) Anyone else noticed this problem and if so, what did you do about it? Or are you just living with it for the time being? |
| ||
| I know this is an old post but since becoming part of the intel mac crowd I thought I'd give my ideas... What if you have just one large `data` file which contains all your media in some kind of format that would be similar to incbin, ie generate it by loading in all your media stuff and outputting all of it to a single binary file, keeping track of the offsets of each file (as if you had incbinptr's). Then this file is not very easily accessible or readable by most users, only shows up as a single file (not a mess), and then both of your versions of the app can open it and read it as needed. You could even encrypt it and/or compress it. I don't think you'll be seeing an official universal-include in blitzmax prior to blitzmax fully supporting generation of universal binaries all by itself. |
| ||
| Yes, it is one solution, but a bit of a pain to code and put into practice. As such, it would be something that you would do at the end of a project, i.e. when all media has been finalised, otherwise you'll find yourself having to to re-do the binary file every time you make a change to just one of the media files. A solution, nonetheless. What I plan to do, and it appears to be something done by most developers, is to include the media in the Resources folder of the application bundle itself. It's still easy to get at, but it's not as messy as a separate folder outside of the bundle. The final version of the game would then only be a couple of meg bigger than a single PPC or Intel version, as it's the media that takes up most of the space. Apparently, although I've yet to implement this into my current project (which is still in development), the folders within the application bundle can be accessed just like normal folders. However, it is highly recommended that you don't write anything there during execution (use the relevant user folders instead). |
| ||
| I've not needed to do this with BlitzMax yet, but I did a similar thing in Blitz3D. I loaded a media file by calling my own loading function ie: _LoadImage("gfx/background.jpg") my _loadimage function then checked if gfx/background.jpg was inside my binary data file, and if it was, extracted the file, loaded it, and deleted the extracted file. If it wasnt in the binary file, it was compressed and added to the binary system. Then, as I was developing, the binary file just made itself :) |
   |