I committed changes yesterday that configure the thing with CMake, so linux compatibility is half-done now. I'll try to implement the platform interface and test it this afternoon, but it may have to wait for this weekend depending on exactly what my workload looks like.

Just curious.... is the LuaZM stuff done yet? (if this is on the back burner and won't be done for a while, dont worry, I understand )

Getting key reading requires the platform to intercept reads/writes to an arbitrary memory address, which afaik isn't implemented. (@Tari: LuaZM directly polls the keyboard port)

That's already implemented in the library, but the UI doesn't support input in any fashion yet. I am indeed emulating MMIO, though (as noted in the readme) it's unlikely to work on 32-bit systems.

I have a 64-bit cpu but i'm running 32-bit linux. will it work?

I haven't actually run it on Linux, but I think it'll work. The main requirement for those fixed mappings is that the requested addresses be in user (rather than kernel) space. On 32-bit Windows, user space is 0x00000000-0x80000000, and the rest is kernel space. The MMIO that's of interest, meanwhile is around 0xA00000000. Linux appears to use a 3GB region for userspace so it should work (0xC0000000 and above unavailable). With a 64-bit operating system, the user/kernel split gets pushed a lot higher, so it's not a concern.

The best way to see if it'll work on your system is just to run it. It's smart enough to tell you if it's not possible to reserve the regions, and warns that certain things may cause it to crash:And if sizeof(void *) <= 4:

Oh, ok cool. Just to verify, there is not a linux version out just yet, correct?

Correct, I didn't find the time to implement the platform interface today. Probably tomorrow afternoon, since that'll be the start of my weekend.

Bump.

I implemented the unix platform interface so the thing should be usable on Linux (and other unices) at this point, though I haven't actually tested that.

Notes on using it right now: both the UI and CL-backed programs need to take the shared memory name as arguments on the command line. On windows this can be any string as long as it doesn't contain a backslash, and it should be the name of an existent file that it can clobber freely on unix.
I intend to allow the UI to launch the backend program on its own (via some sort of dialog) eventually, but that's a low priority beyond implementing features that I have need for while building pLemmings.

Can I download a tarball somewhere?

Yes, from bitbucket (see the first post in the thread, which I edited to include URLs). Downloads->Branches->default will get you a snapshot of the current dev tree.

I ran cmake, got no errors, then ran make, and got this error:


Code:

Okay, it looks like I started implementing the unix platform stuff, then decided on a new approach to take with it and rewrote the win32 interface and forgot to finish the unix one. In any case, I just pushed a version that I've confirmed compiles, but whether it will correctly link and run is another question.
Code:


I'm currently traveling, so don't expect much from me for the rest of the week. I appreciate your bug reports though!

Do you have a win32 version I could try out then?

You'll be better off building it yourself. Basically the same procedure with cmake on Windows as it is on Linux. For example, what I do with Visual Studio 2012:
Code:
Then open up the solution it generates in Visual Studio and go to town compiling it. I've been using the win32 platform code, so that's known-working.

Any project that links against the library will need to have its library and include paths updated to include the headers and static library for [CL], just as you'd have to do with GCC.

For pLemmings, I've set it up with CMake and keep a copy of FX-CG[CL] under its source directory as a submodule, so it's pretty easy. Relevant parts of the CMakeLists for that:
Code:
In this way, simply building pLemmings ensures the library is up-to-date and easily handles the search paths.

I tried to compile CL and it gave me:

Code:

Looks like you're trying to build an addin and not linking against the [CL] library. More details, please (what are your trying to do, and what are you running?).

I was using Code::Blocks to compile main.c. I'm using Windows right now.

I'm going to assume you didn't run CMake, which would be the problem.. CMake has a CodeBlocks generator, which you may like. Running cmake without any parameters will make it print a list of available generators:eg
Code:
And open the project file it generates.

You can't just build main.c and expect it to work, because it's several modules.

The CMake thing gives me this:


Code: