Print

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

[Jaqie Fox]

re how to test and run multiple operating ystems on a single PC: the best way is with the free version of VMware. it emulates an entire PC in the 'host' OS, even has an actual BIOS file licened from (IIRC) phoenixBIOS.  Check out vmware, I use it pretty constantly here. the only thign to be aware of is the increased RAM demands for running multiple OSes concurrently. 1GB is prettymuch minimal.... but compared to the alternative of having multiple PCs more RAM is dirt cheap.

[Toady One]

Yeah, that's actually how I ran the aborted Linux port -- on a VMWare Ubuntu.  There was a little lag, sure, but it worked fine.  I gather VMWare wouldn't help with a Mac port unless I broke some kind of law though.

[Peristarkawan]

The LGPL issue is unfortunate. I haven't looked at the code yet, but it sounds like a revived porting effort would have to start over from scratch.

I'm not a licensing expert, but would it be feasible to turn the KQ code into an open-source library derivative of Wine and then just have DF link it? That should allow you to release DF on your own terms using section 6a or 6b of the LGPL.

If the issue is the "must allow modification and reverse engineering" clause of section 6, then I think that would prohibit you from using any LGPL library at all, including SDL.

[Toady One]

It was my impression that you could use an LGPL DLL and not release the source code of your own project (since you don't become a derivative work at that point, and the modifications can occur at the DLL level), but I don't know much about it.

As for turning KQ into a library, I doubt it would have to go that far, but whatever works.  My requirements are that it has to be easy for me to understand how to lay DF on top of it, and I have to be able to release it without releasing the source code of DF.

[Peristarkawan]

quote:Originally posted by Toady One:
<STRONG>It was my impression that you could use an LGPL DLL and not release the source code of your own project (since you don't become a derivative work at that point, and the modifications can occur at the DLL level), but I don't know much about it.</STRONG>

Right, that's what section 6 covers. It does seem to include the annoying requirement that the DF license must allow users to modify and reverse-engineer the DF executable. I brought it up because the current DF license agreement doesn't permit modification of the executable.

It may be somewhat ignorable. The SDL overview of the license doesn't even mention it.

[Toady One]

From what I've managed to google, people seem confused.  Section 6 seems dangerous to me.  Perhaps a non-SDL approach will be required, which I guess amounts to what, handling input in some way, and getting the OpenGL initialized in Linux?  Perhaps that's a lot of work.

edit:  To be specific, it seems like using the DLL would be fine, until such a point that a new version of the DLL is no longer compatible with the binary, at which point the binary must be opened up to allow compatibility.  This would put me at the mercy of whoever is maintaining the LGPL project.

[ May 17, 2007: Message edited by: Toady One ]

[Peristarkawan]

I think that setting up the OpenGL directly would be fairly platform-dependent. Right now I'm looking at possibly using ClanLib as an alternative to SDL that uses a BSD-style license. It looks promising, although I don't really know how it compares in terms of performance.

[Toady One]

I guess as long as it's not awful, it's fine.  The performance issues with DF are mostly independent of any graphics etc, so a bit of overhead wouldn't be a major problem.  I think.

[X]

More to the point than any LGPL issues is that you don't even frekin' want WINE code in a KQ port - it's not needed.
Only the enabler code uses windows.h for anything relevant, and of that:
 enablerst::loop
 enablerst::create_window_GL
 enablerst::destroy_window_GL
 enablerst::register_window_class
 WindowProc
 WinMain
Wants rewriting from win32 to platform equivalents, and:
 enablerst::load_bitmap_header
 enablerst::load_bitmap_file
 enablerst::load_bitmap_file_with_alpha
 enablerst::save_texture_data_to_bmp
Want junking and replaced with stuff that calls libpng.

That's only ~750 lines total, and is not a technically hard task for anyone who knows a little about win32 and enough about their target platform. Add in finding other stray calls to stuff like MessageBox and re-routing through the enabler, the task is still of hours order, not days.
Anyway, it served its purpose of shutting up the I'd-port-this-if-you-gave-me-the-source bullshitters. Whining is easier than WINEing, but WINEing is easier than porting, and they're all about path of least resistance.

X

[nornagon]

It turns out the LGPL is mostly fine, except for a reverse engineering clause in section 6. I guess I'll have a stab at porting stuff with glut. The windows-specific stuff I can see is mostly in enabler.cpp and a bit in files.cpp and definitions.cpp, yes? Are there any caveats I should be warned about?

[Toady One]

There are a few more MessageBox() in game.cpp, one in game.h.  GetTickCount() is used in game.cpp, interface.cpp, random.cpp.  Not sure what the other problems are beyond what X said.

[ June 04, 2007: Message edited by: Toady One ]

[nornagon]

Okay, finished. The game compiles and runs under linux, near-perfectly as far as I can tell (having never played the game under windows). The build process is a little involved, so I'm reluctant to post a tarball just yet, but if anyone wants to have a go, join us on worldirc.org #bay12games or private message me here. I'll try to have a nicely buildable tarball sometime soon.

Testing is still far from extensive, I think a few keybinding things may be broken (in particular, ctrl and alt, though shift seems to work). GLFW has some small quirks which I'm not entirely sure of, so they'll take a little prodding.

[Peristarkawan]

I was going to do a ClanLib port since it uses BSD licensing, but I never found the time to actually work on it. Glad to hear that somebody's picked this up.

[nornagon]

GLFW is pretty nice for this purpose. It's sort of a GLUT replacement, with a few bells and whistles. SDL is possibly better still, but there lie licensing issues.

[Peristarkawan]

Oh, I wasn't aware of that one.  Looks nice!  The other reason I was looking at ClanLib was that it includes modules for sound and for performing serialization in a platform-independent manner, but obviously there's no reason those things need to be handled by the same toolkit.