[Ohrrpgce] Mac OS X port

[Ralph Versteegen]

On 1 October 2010 04:35, James Paige <Bob at hamsterrepublic.com> wrote:
>> I still haven't managed to compile a fully working fbc. It turns out
>> dim shared variables are in most cases not compiled correctly. I have
>> no idea why they work in the ohrrpgce binaries, which is lucky because
>> I'm totally out of ideas aside from "figure out why on earth game and
>> custom aren't crashing, and replicate that"
>
> Heh :)
>
> Have you shown any of this off to the fbc devs yet?
> Maybe some of them will have ideas?

Well, I'm having problems with the ELF to Mach-O conversion. I worked
out what the crashing problem was: relocation entries which point past
the beginning or end of a .bss section (normally because the lower
bound of an array is larger than 0, so the 0 element is at a negative
offset from the real array) are treated as pointing into the
preceding/succeeding section (bizarre - the correct section is
specified, but ignored), and not relocated correctly. I couldn't
figure out how to fix this, only how to detect it. I'll look into what
Apple's gcc/gas do.
I did manage to compile a copy of fbc that can compile fbc without
crashing. But then the lab closed.

I'm confident that I can get everything working later today.

>> >> I really should have implemented cross compiling from linux in fbc
>> >> before working on native mac-to-mac compiling!
>> >
>> > Is it too late to go back and approach it that way?
>>
>> Oh now I remember why I skipped this: because cross compiling requires
>> a cross compiling linker, system libraries, etc, which is just too
>> much work to set up.
>> I have this figured out near-enough though. I can cross compile from
>> linux, and perform the linking step in OSX without a complicated
>> Makefile.
>
> Ah, that is cool.
>
> I bet I could even work that into a two-machine nightly build system if
> we have no other option.
>
>> > My concern is how should you browse into out out of the app bundle.
>>
>> I imagined that a ghostly import/ would appear out of the ether at the
>> location of the .app bundle, but it sounds dangerousls confusing.
>
> Hmmm... yeah, that might be a little weird.
>
>> > I have been thinking about our file browser, and I realize it is fairly
>> > confusing for most people. These days nobody but programmers really seem
>> > to understand filesystem layout at all, and a lot of users are even
>> > fuzzy on the concept of folders.
>>
>> Really? Hmm... I guess it's quite different to most native filesystem
>> browsers. And we have all these entries for the directories in the
>> current path, which can add a lot of junk.
>>
>> We should start by hiding directories above the user's home directory,
>> like we do for My Documents.
>
> Oh! I forgot we didn't do that already!
>
>> We could, as you suggested long ago, add shortcuts to the Desktop and
>> the home directory/My Documents.
>
> ....Idea... forming...
>
> Imagine this:
>
> By default the browser would *only* show a few predefined preferred
> subdirectories. Then there would be two additional options "browse for
> other folders" and "add a folder to prefered list"

Rather than "browse for other folders", I suggest just showing the
root directory/drives, but not all the parent directories. Selecting
one of these means you want to browse around.
It would be neat to also show mounted devices in unix. Might need a
lot of heuristics to exclude uninteresting mounts.

> So maybe by default, browsing for music just shows import/ but you could
> add $HOME/mp3files/ if you wanted. Something like that?
>
> I dunno.. the half-bakedness of that idea is dangerously high ;)

"add a folder to prefered list" sounds useful, but maybe what you
actually want is bookmarks, because there are a lot of folders I would
want to bookmark, but not have in the list staring at me continuously.
On the other hand, I never use bookmark features in file browsers.

>> > Of course I have no idea what to do about that :)
>> >
>> > Maybe platform-native file browsers would help, although I don't know
>> > any way to make those play nice with full-screen mode.
>>
>> It seems totally reasonable to not support it under full-screen. Do
>> people edit games in full-screen anyway? I only use it for playing -
>> and that only when I really want immersion.
>>
>> But are native file browsers a good idea? We have a lot of extra
>> functionality in ours.
>
> Yeah, the BMP size/depth info, the music previwing, the display of RPG
> internal names... That is all important stuff.
>
>> > The packaging menuy would do the following things:
>> >
>> > If zip is available, it would provide a choice to package your game and
>> > a renamed copy of game.exe and the appropriate DLL files along with
>> > LICENSE-binary.txt and your README.txt
>> >
>> > If on linux, package a similar tarball
>> >
>> > If on Windows, and Innosetup is installed, automatically generate an
>> > installer
>> >
>> > Maybe provide the same support for NSIS also/instead
>> >
>> > If on Linux and the tools for creating .deb packages are available,
>> > have the ability to create one of those.
>> >
>> > If on Mac OS X, create an app bundle of the game
>>
>> What about packaging for other platforms? Just because you're not
>> using a Mac doesn't mean you don't want to create an .app bundle.
>>
>> I suggest having an extra download that contains all the binaries
>> needed for cross-packaging to each system.
>
> That would be excellent. It has limitations-- for example, we can't run
> Innosetup on Linux, we can't run debian packaging tools on Mac OS X, and
> we can't create mac dmg files on Windows, but wherver it is possible to
> do cross-platform pakaging, we should do it.

Apparently you can easily create a dmg file, just like you would an
iso, but with HFS+ filesystem. Are dmg's noncompressed? What's the
standard file compressor? Should we just use bz2?

>> > The packaging menu should probably also contain something for managing
>> > your README.txt file, and something for importing an application icon
>> > (or drawing one with the sprite editor?)
>>
>> Speaking of which, what about the icons for Game and Custom? You said
>> you wanted new ones: should I even bother working out how to use
>> custom.ico and game.ico for the app bundles, or would they be worse
>> than nothing? :P
>
> I wouldn't worry about them just yet.
> And we can always just figure out how py2app does it and copy that.
>
> I do want to get better default icons for game and custom, and I want to
> allow people to create their own icons for renamed copies of game, but
> the first is a job for an art contest on the forums, and the second
> sounds low-priority high-work thing :)

I doubt it's much work to set icons. I may look at it today.

>> >> > I used to want to learn wxWidgets, but lost interest when I learned
>> >> > gtk :)
>> >>
>> >> I don't think that wxWidgets is better than GTK or anything, I just
>> >> don't have the patience to learn another GUI library, so I don't think
>> >> I'll be switching.
>> >
>> > Does WxWidgets have anything like Glade3? That is what sold me.
>>
>> There are a few different such projects, but my quick impression was
>> that they weren't so marvellous.
>
> Glade is glorious.
> I made the ui for Hamster Whisper with it, and it was a breeze.
> I have got a gigantic project at work going that uses it.
>
> Basically I can design the whole layout of an ui graphically, and have
> all my signal handlers connected automatically.
>
> I can also leave strategic empty containers which I can populate
> dynamically at runtime when I need to, and I can even use glade to make
> complex compound widgets which I can insert at runtime (and still have
> my signal handlers connected automatically)
>
> It makes developing gtk apps as easy as developing VisualBasic apps
> (without any of the the crappyness otherwise associated with developing
> in VisualBasic )
>
> The only downside with gtk is that its Mac OS X port is a real second
> class citizen. I haven't been able to get it to work any way other than
> Macports.
>
> As far as I know that is not the case with WxWidgets, which has good
> native Mac support, right?

Yes, it seems to work pretty well. However it's always behind on
supported UI components. on all platforms.

> ---
> James