On 1 October 2010 04:35, James Paige <[email protected]> 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 _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
