Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lachek]

POSIX compliant (i.e. Unix-centric or platform agnostic code) using cross-platform libraries (SDL, etc) should compile without tweaking on both Mac and Linux. Note I didn't say will, but should.  

As far as compiling goes, I've never had much luck with cross-compilation - it seems to me to be far less work setting up a Linux box to do the compiling on (your closet-dwelling castoff will do just fine for that) and get some trusted friend with a Mac to try the compilation under XCode or GCC for Mac (both available free of charge from the Apple Developer Connection website, if it didn't ship with the system).

You may be able to get Mac OS X running on a PC by using weird hacked installation discs floating around on the 'Net but I wouldn't suggest it. It's far easier to just get a blue&white G3 PowerMac or iMac off eBay for a couple hundred.

I'm sure there would be umpteen volunteers who could give you shell accounts on their boxes (Linux or Mac - both have SSH support these days) for compilation purposes, myself included. It would be difficult for you to test using this approach, but you could always email the compiled binary off to testers to try out.

I've still not given up on convincing you to open source the code though - I have a half-finished draft in my GMail that I will hopefully have time to finish and send you soon. I know you're itching to read it.  

[lachek]

As to whether you can actually compile the code for both Mac and Linux on a single machine, I'd assume no - though they're both Unices, the Mac uses BSD underpinnings while the various Linuxes uses the Linux kernel (duh), thus requiring a recompilation to work.

Besides, the Mac will need special care in compilation to ensure the binary runs on both the old PowerPC-based Macs and the new Intel Macs (their term is "Universal Binary"). Unless you can somehow score a new Intel-based Mac, or know someone with access to one (hint hint) you're much better off compiling for PowerPC only and let the Intel Macs' emulation layer (Rosetta) take care of the translation for you in real-time as the app is run. Any Intel Mac should have more than enough horsepower to not be bothered by the emulation overhead, especially not after world generation is complete.

Hope that helps!

[Toady One]

Yeah, I read some things about running linux on a mac, or something like that, and I still have no idea if you can do some kind of partition type deal to get binaries compiled in each environment on a single machine.  I don't have any castoff computers or trusted computer bearing friends to impose upon.  Anyway, I'll wait on all this a bit in case someone has any other ideas about how to minimize my expenses and hassles.

[lachek]

Ah, yes, I overlooked the obvious option of running Linux on a Mac and dual-boot. That is definitely a possibility, though there are two problems:

1) It tends to be a bit trickier to get Linux to run on a Mac than a PC, especially a brand new or very old Mac. A dual-boot setup is even worse. I hear UbuntuPPC is straightforward, but Ubuntu is really not my dev platform of choice seeing how it doesn't even install with GCC or devel libraries by default.

2) While you can be assured that if your code compiles and runs on LinuxPPC, it will also compile and run on Linux-x86 (unless you did some sort of funky PPC assembly linking, but that's a different story), the binary you make will obviously not work so a recompile is required anyway. Further, you will not have a way of testing any code optimizations made for for the x86 CPU, which should probably be the main target for your optimizations since it's the most used processor.

All in all, I still think if you want to pursue cross-platform compatibility the best approach is to do the Linux version yourself on some junker PC, and offload the Mac version to someone with a Mac. The good news is that once the Linux version works, compiling for Mac OS X (especially if targetting the X11 server instead of Aqua) should be straightforward.
As for not having any PC castoffs, take a stroll through the neighbourhood early in the morning on bulk garbage pickup day - anything PII or better should do fine (though playtesting may take a little while on such a CPU) and even charities don't accept such slow PCs anymore.  

[X]

Argh, this thread is pissing me off. There's only so much BS I can take.

quote:lachek:
<STRONG>If the code was GPL'd...</STRONG>

Yeay! The solution to everything. Turns a pile of shit like StarOffice into an open source pile of shit like OOo. (Whose's one redeeming feature is the corin-esque name)

quote:foxxtrot:
<STRONG>However, I have trouble understanding why smaller developers don't begin using things like the Simple Direct Media Layer for their projects.</STRONG>

However, I have trouble understanding why smaller developers don't begin using things like Haskell for their projects.
Seriously now, how about suggestions other than "you should have used something else"?
True, SDL is probably less of a giant heap of crap than it was six years ago, but all Toad'd really get from it would be some image loading code and event handling, which doesn't seem worth the extra indirection and library cruft to me.

quote:lachek:
<STRONG>It's far easier to just get a blue&white G3 PowerMac or iMac off eBay for a couple hundred.</STRONG>

Here's the donations box. But 'a couple hundred' is a lot of weeks food...

Nixers can (and do) WINE, and I presume Intel/BSD Macers have some options too. So, personally I think any time that Toad spends farting around with compilers is time lost on working on stuff the game actually needs.

Anyway, as this is partly my fault as well for suggesting Sam despite the fact I know what he's like, how about this as a solution. BSD licence the enabler, and release some subgame code (or squiggles, if you're too proud to let kobolds loose on the world), and *when* there are working binaries for that, revist the porting issue.
What's needed is not teams of barely organised hackers gpl-style, but a couple of vaguely reliable people to compile bins and raise issues.

X

[Toady One]

Didn't he die when he saw the enabler though?  I assume that's why it isn't done.

I had suggested this on the earlier thread, but I still can't get dwarves compiled even if I have some portable enabler code.  It's not like I know anybody I'd send the dwarves code to.  Might be an excuse to write another subgame though.

[X]

He didn't die, and he actually did a fair bit of the work, but his silly-bastard mode kicked in before the end. He might eventually get round to replacing his dead mainboard so he could use his computer again, but there's little point waiting any more months.

Porting the enabler isn't the whole job, but it's the biggest chunk. Working out issues like making you go through the enabler for timer and keyboard, using stdlib for files (and / not yen), and compile pains, is going to be far easier on a small game.
If you get that working, could potentially set up a buildbot or something on another pc so you *could* compile the code, even without the hardware.

X

[foxxtrot]

quote:Originally posted by X:
<STRONG>However, I have trouble understanding why smaller developers don't begin using things like Haskell for their projects.
Seriously now, how about suggestions other than "you should have used something else"?
True, SDL is probably less of a giant heap of crap than it was six years ago, but all Toad'd really get from it would be some image loading code and event handling, which doesn't seem worth the extra indirection and library cruft to me.
</STRONG>

SDL has been used in every Linux port, many a Mac port,and has been showing up in native Windows games since 2000.  It has virtually no overhead, a far cleaner API than DirectX or Win32/MFC.  And the event handling and everything it provides is inherently cross-platform.  A very good thing.  

I did mention that at this point in the project, it may not be worth converting, especially at the current time.  It's an option, and one that I believe really ought to be explored, at least for future work.

I want to see Dwarf Fortress cross-platform, and Toady has indicated he might be open to the idea.  He doesn't want to release the source, which I feel is reasonable, so I'm supplying options.  Fact is, if you want a cross-platform game, SDL is the best option.  And it's proven itself many times.

[X]

I was just going to take your post and replace 'SDL' with 'Haskell', and similar appropriate terms for the rest, but figured that'd be being too mean.
Look, Toad is not using DirectX. He's not trying to program *on* nix or a mac. Stop tunneling in thin air.
If you wish to rewrite the enabler using SDL, I'm sure that's possible, and perhaps even the right thing for some platforms, but stop treating it like a magic bullet.

X

[lachek]

quote:Yeay! The solution to everything. Turns a pile of shit like StarOffice into an open source pile of shit like OOo.

Which, by virtue of being open sourced, was ported and customized to every Linux flavour on multiple architectures as well as Mac OS X, and earned Sun the position of the only true competitor to Microsoft Office and the favourite choice for governments leery of locking themselves into a single platform for the foreseeable future. Yeah, that was a pretty dumb move.
I'm not saying a GPL license would magically turn Dwarf Fortress into a 3D MMORPG that runs on your SNES. I'm saying that GPL'ing (or otherwise open sourcing) the code - or at least the UI/frontend code - would leverage the community support that Toady obviously already enjoys and would free him from the arduous task of recompiling and debugging for every platform so he can focus on adding the features he enjoys. GPL'ing (in actuality, LGPL'ing, but whatever) StarOffice didn't fix its bloated code, but it did bring it to multiple platforms, which is what this thread is about.

quote:Here's the donations box. But 'a couple hundred' is a lot of weeks food...

I'm sure plenty of Mac users would donate money or hardware to Toady if he committed to attempting a Mac OS X port. The alternative, as I mentioned, is giving Toady a shell account on a Mac box and so on, which I have offered. No need to pull out the starving children of Africa on me.

[Gezol]

Toady- check your PMs.

It sounds like there's a sub game involving kobolds in the works?

[Toady One]

Well, there was a game, in that category, some time ago, that was never released, and it involved kobolds.  It was really exceptionally stupid.  However, it might be revived in some form now, possibly.

edit:  I've sent off a PM.  It might even email notify you now that the famous Sam has made the bulletin board slightly more working.

[ September 07, 2006: Message edited by: Toady One ]

[Toady One]

Okay, during the phone call tonight ThreeToe and I reworked the Kobold Quest idea, and I'm going to try to get it set up tomorrow, though it'll take some time to make sure everything's ready to go.  Might even be a couple of weeks (most of which I'll be working on DF instead of course).  Anyway, Kobold Quest will give you all some idea of what's up, as far as porting issues are concerned.  A BSD license sounds reasonable from what I remember.

[X]

Ahahaha! And thus my sekret desire is fulfilled! First person to a nix bin wins a cookie with "non-bullshitter" written on it.

X

[Toady One]

So, I guess X wanted KQ more than HV/CV then?  You'll have to find some new leverage for that one.