Blades of Exile for Linux :D

[Celtic Minstrel]

I'm not quite sure if wxWidgets has switched to Cocoa either, but if they haven't yet I'm pretty sure they're in the process of doing so. I think a Cocoa version may be in alpha or beta stages.

 

I know nothing about CMake and have no desire or motivation to learn at present. Even with CMake, project files for MSVC and Dev C++ should probably be included. Xcode project files and Dev C++ project files already exist.

 

(The idea behind this is to make it so that anyone can download and compile the source, regardless of which compiler/IDE they use.)

 

If we used wxWidgets (or even Qt), I bet we could use the HTML rendering system to display the dialogs, since I've already refactored the dialog format to XML (though most dialogs are yet to be converted). And clicks could probably be handled with DOM events or whatever those things are called... though I actually have no idea how that would work or if it could work when there's no scripting language (eg JavaScript) in the equation.

[King InuYasha]

Originally Posted By: Celtic Minstrel

I'm not quite sure if wxWidgets has switched to Cocoa either, but if they haven't yet I'm pretty sure they're in the process of doing so. I think a Cocoa version may be in alpha or beta stages.

I know nothing about CMake and have no desire or motivation to learn at present. Even with CMake, project files for MSVC and Dev C++ should probably be included. Xcode project files and Dev C++ project files already exist.

(The idea behind this is to make it so that anyone can download and compile the source, regardless of which compiler/IDE they use.)

If we used wxWidgets (or even Qt), I bet we could use the HTML rendering system to display the dialogs, since I've already refactored the dialog format to XML (though most dialogs are yet to be converted). And clicks could probably be handled with DOM events or whatever those things are called... though I actually have no idea how that would work or if it could work when there's no scripting language (eg JavaScript) in the equation.

There is MSVC support in CMake, and I would be willing to write the CMake scripts once we have a Windows, Mac, and Linux version in the source tree. CMake is extremely flexible, it supports both GCC, MSVC, and ICC (Intel C/C++ compiler). It might even support DMC (Digital Mars C/C++ compiler) and OWC (OpenWatcom Compiler).

Dev-C++ projects would be the stick in the mud, since no project generator currently supports it. However, Dev-C++ project files could be provided separately, as they are now.

Using HTML rendering system for the dialogs would be an interesting way to do it. I believe only Qt's built in QtWebKit control would suffice. wxWidget's built in HTML control is only HTML and CSS. There is a separate Gecko control, but Gecko is a huge beast, you don't really want to include Gecko in an application like this. WebKit is much lighter and I believe is only a single DLL in Qt. Obviously, WebKit has JavaScript support, so QtWebKit does as well.

WebKit is available for wxWidgets in the form of an experimental (under active development and in a separate repository) control called wxWebKit.

As for Cocoa support. wxWidgets has it in the SVN trunk, but it still isn't usable yet, according to the wxWidgets wiki. Given that the wiki is possibly out of date, it would be a good idea to download a copy of wxWidgets SVN trunk and try to build it for wxOSX/Cocoa instead of wxOSX/Carbon. If it builds and loads, then great! Otherwise, meh...

Interestingly, there is a branch of wxWidgets that now includes a Ribbon UI implementation. Qt still doesn't have a Ribbon implementation, so wxWidgets wins on that one.

Since I doubt you want to use a Ribbon in BoE, I would still say Qt would be a better choice because Qt's Cocoa and WebKit implementation is mature and working, quite well too. Additionally, Qt has 64-bit support on Windows, Linux, and Mac OS X. Unfortunately, you have to compile the Win64 libraries yourself currently...

[Celtic Minstrel]

What's the reason for Qt requiring a separate preprocessor (moc)? Wikipedia says it's for signals/slots and for introspection, neither of which I'd expect to need; could the "moc" step be skipped?

[King InuYasha]

Originally Posted By: Celtic Minstrel

What's the reason for Qt requiring a separate preprocessor (moc)? Wikipedia says it's for signals/slots and for introspection, neither of which I'd expect to need; could the "moc" step be skipped?

I think it was to standardize the compilation step of meta objects, like the UI files, etc. However, you can manually compile those and skip that step in normal compiling if you want, by simply converting the meta objects into C/C++ files.

I'm just guessing here, I don't really know for certain.

The reason moc is used is because they avoided using C++ templates. According to Qt, there were some things that could not be expressed in templates that required the creation of moc to simplify matters.

The moc step could be skipped if you really want to pre-compile those parts for each platform and stick it in the source tree. Otherwise, it's not really useful to do that.

[Celtic Minstrel]

Okay then. In that case I still would prefer wxWidgets. However, I guess Qt isn't completely out of the question.

[King InuYasha]

Originally Posted By: Celtic Minstrel

Okay then. In that case I still would prefer wxWidgets. However, I guess Qt isn't completely out of the question.

Technically, neither is using Cocoa.

Through a project called Cocotron, Cocoa based Objective C code becomes portable to Windows and Linux. It's just a matter of recompiling to the Cocotron target on XCode.

I don't really know how complete Cocotron is, so YMMV.

It seems much more likely that the basis for the cross platform BoE will have to come from the Mac base, since the Windows codebase doesn't actually compile... The Mac version is also being maintained much more than the Windows one, so this possibly simplifies the matter a great deal to those who want BoE to be ported to use Cocoa.

[Chokboyz]

Originally Posted By: King InuYasha

since the Windows codebase doesn't actually compile...

It does (see the google code project).

Originally Posted By: Kung InuYasha

The Mac version is also being maintained much more than the Windows one

Both versions are actually being maintained ... The main differences are in the project advancement : the Mac code has more code refactored/new format implemented and the Windows code has more bugfixes and new features. The two codes should merge eventually.

Chokboyz

[King InuYasha]

Originally Posted By: Chokboyz

Originally Posted By: King InuYasha

since the Windows codebase doesn't actually compile...

It does (see the google code project).

Originally Posted By: Kung InuYasha

The Mac version is also being maintained much more than the Windows one

Both versions are actually being maintained ... The main differences are in the project advancement : the Mac code has more code refactored/new format implemented and the Windows code has more bugfixes and new features. The two codes should merge eventually.

Chokboyz

Whenever I try to compile the Windows version, I get syntax errors for gamedlog.rc, so I know it doesn't compile.

[Chokboyz]

Originally Posted By: King InuYasha

Whenever I try to compile the Windows version, I get syntax errors for gamedlog.rc, so I know it doesn't compile.

What kind of error ? What compiler are you using ? Do you use the last version of the code ?
I've just tested it, and it compiled fine (gcc 3.4.2 in last Dev-C++) ...

Chokboyz

[King InuYasha]

Originally Posted By: Chokboyz

Originally Posted By: King InuYasha

Whenever I try to compile the Windows version, I get syntax errors for gamedlog.rc, so I know it doesn't compile.

What kind of error ? What compiler are you using ? Do you use the last version of the code ?
I've just tested it, and it compiled fine (gcc 3.4.2 in last Dev-C++) ...

Chokboyz

TDM-GCC 4.4.2-tdm2 in Code::Blocks IDE 8.02. SVN openexile rev137.

[Chokboyz]

Originally Posted By: King InuYasha

TDM-GCC 4.4.2-tdm2 in Code::Blocks IDE 8.02.

Oh, then you're probably using a newer version of the binutils (i.e > 2.17). The windres.exe included in these is quite picky with the syntax in ressource files and quite incompatible with older coding shortcuts (oddly related to these kind of bug : http://old.nabble.com/-Bug-binutils-6714...td18215541.html ); all-in-all, it's just an omitted comma that crash windres.
The next commit will be both old and new windres compatible (and i'll probably throw a code block project file too).

Chokboyz

Edit : ok, everything is now compiling, but i've hit another bug (put in better word by others, see : http://forums.codeblocks.org/index.php?topic=2334.0;prev_next=next ).
The simpliest way to solve that is to fuse the three different .rc ressource files in one big file (something Dev-Cpp automatically does right before compiling, where CodeBlock compiles the three files separately, but link only the first compiled). Or we could write a script that mimic Dev-Cpp's behavior and fuse the three files at compiling time ...
Forget that, using some #include did the trick (side effect, Dev-Cpp now warns about ressources duplication. No consequence, since it avoids them) ...
I'll upload a CodeBlock/newer Binutils compilant version of the code soon.

[King InuYasha]

Originally Posted By: Chokboyz

Originally Posted By: King InuYasha

TDM-GCC 4.4.2-tdm2 in Code::Blocks IDE 8.02.

Oh, then you're probably using a newer version of the binutils (i.e > 2.17). The windres.exe included in these is quite picky with the syntax in ressource files and quite incompatible with older coding shortcuts (oddly related to these kind of bug : http://old.nabble.com/-Bug-binutils-6714...td18215541.html ); all-in-all, it's just an omitted comma that crash windres.
The next commit will be both old and new windres compatible (and i'll probably throw a code block project file too).

Chokboyz

Edit : ok, everything is now compiling, but i've hit another bug (put in better word by others, see : http://forums.codeblocks.org/index.php?topic=2334.0;prev_next=next ).
The simpliest way to solve that is to fuse the three different .rc ressource files in one big file (something Dev-Cpp automatically does right before compiling, where CodeBlock compiles the three files separately, but link only the first compiled). Or we could write a script that mimic Dev-Cpp's behavior and fuse the three files at compiling time ...
Forget that, using some #include did the trick (side effect, Dev-Cpp now warns about ressources duplication. No consequence, since it avoids them) ...
I'll upload a CodeBlock/newer Binutils compilant version of the code soon.

I see you updated the SVN, and it compiles! Now I have new errors:

Character Editor:
Syntax error in BLADPCED.RC Line 293

Scenario Editor:
Error: cast from 'HWND__*' to 'short int' loses precision in DLOGTOOL.CPP Line 580

[Chokboyz]

Originally Posted By: King InuYasha

I see you updated the SVN, and it compiles!

Great ! Now people wanting to fiddle with the code will be able to choose their IDE

Originally Posted By: King InuYasha

Now I have new errors:

Character Editor:
Syntax error in BLADPCED.RC Line 293

Scenario Editor:
Error: cast from 'HWND__*' to 'short int' loses precision in DLOGTOOL.CPP Line 580

Yup, i (wrongly) assumed you were only interested in the game code and postponed the scenario/character editor code tweaking ... I'll do that soon

Chokboyz

[King InuYasha]

Originally Posted By: Chokboyz

Originally Posted By: King InuYasha

I see you updated the SVN, and it compiles!

Great ! Now people wanting to fiddle with the code will be able to choose their IDE

Originally Posted By: King InuYasha

Now I have new errors:

Character Editor:
Syntax error in BLADPCED.RC Line 293

Scenario Editor:
Error: cast from 'HWND__*' to 'short int' loses precision in DLOGTOOL.CPP Line 580

Yup, i (wrongly) assumed you were only interested in the game code and postponed the scenario/character editor code tweaking ... I'll do that soon

Chokboyz

You know what they say about assumptions

Seriously though, great! Thanks for your work on it...

[Chokboyz]

Originally Posted By: King InuYasha

You know what they say about assumptions

To be perfectly honest, i was quite tired of checking whether a comma was missing or not in 1600+ lines of ressources and changing the compilation priority of .rc files to understand how Code::Blocks was linking compiled .res files, so my assumption was a little "forced" or "biaised"

Nonetheless, both the Scenario and Character editors have been tweaked to compile with newer windres.exe and Code::Blocks .rc handling methode (be careful with speed optimization, i've been lucky to notice that with -O2 optimization, the Scenario Editor was broken (monster and items dialogs weren't accepting any input value)).
Note that Code::Blocks produce bigger executable than Dev-Cpp, probably because of compilation options i'm not aware of (but both are tested and working).

While i was at it, i've cleaned the two editors code of any unused variables (given the number of such, i'm pretty sure it was the first time someone did so ), so there should be far less warning now

Chokboyz

[Lilith]

Originally Posted By: King InuYasha

You know what they say about assumptions

They make an ass out of you and mptions?

[King InuYasha]

*BUMP*

 

It's been yet another month. It's quite obvious that Nikmind is gone and so is a potential Linux branch.

 

So, it looks like a new one will have to be made from scratch...

 

How far along has the dialog refactoring come? Actually, how are the refactored dialogs supposed to work?

[Celtic Minstrel]

...not entirely sure what you're asking about here.

[King InuYasha]

Originally Posted By: Celtic Minstrel

...not entirely sure what you're asking about here.

You said that you refactored the dialogs into XML or something like that. How far along has that refactoring come and how exactly are these newly refactored dialogs are supposed to work in relation to the rest of the program?

[Celtic Minstrel]

Ah, yes. The refactored code still uses the Carbon API, unfortunately. It also doesn't quite work.

 

All I've done so far is write the draft of the dialog code, create a DTD for the XML format and an XSL/CSS stylesheet for previewing dialogs in the browser, then converted one major dialog into the format for testing purposes.

 

I've also converted some of the common dialogs too, such as the message dialogs that display one or two strings with an optional title string and an optional Record button... or the dialog that allows you to select an icon from a list.

[King InuYasha]

Originally Posted By: Celtic Minstrel

Ah, yes. The refactored code still uses the Carbon API, unfortunately. It also doesn't quite work.

All I've done so far is write the draft of the dialog code, create a DTD for the XML format and an XSL/CSS stylesheet for previewing dialogs in the browser, then converted one major dialog into the format for testing purposes.

I've also converted some of the common dialogs too, such as the message dialogs that display one or two strings with an optional title string and an optional Record button... or the dialog that allows you to select an icon from a list.

Why doesn't it work right now? And it uses the Carbon API? I thought you were trying to get it working with wxWidgets?

[Niemand]

While I can't speak for why it doesn't yet work, as I understand it the idea is that this new dialog format can then be interpreted and displayed by code using Carbon, Win32 APIs, wxWidgets, or whatever, unlike the old classic Mac OS resource formats, which could only be read and displayed by functions specific to Carbon.

[Celtic Minstrel]

Niemand is correct; the old dialog format was basically a variant of the Carbon API's dialog format; that is, it used the Carbon format but re-interpreted the data a little. The new format, on the other hand, is XML. This means that the same file can be used by the Mac and Windows versions, assuming that there is code written which interprets and displays it correctly.

 

I have written the code for the Mac version to load and display a dialog, but there are some problems that I have not been able to explain. For example, it fails to correctly read the height and width of the dialog. And there may be other problems that I've forgotten. Unless my recent upgrade to Snow Leopard magically fixes these bugs, it's not really ready for use.

 

As for wxWidgets... yes, that would be nice, but I'm still not sure if it's the best choice for this game. If there's a way to create multiple windows in an SDL program, that might be a better way to go.

 

Anyway, what I've written could probably be changed to use wxWidgets simply by modifying how it handles the internals, without touching the public interface.

[King InuYasha]

Originally Posted By: Celtic Minstrel

Niemand is correct; the old dialog format was basically a variant of the Carbon API's dialog format; that is, it used the Carbon format but re-interpreted the data a little. The new format, on the other hand, is XML. This means that the same file can be used by the Mac and Windows versions, assuming that there is code written which interprets and displays it correctly.

I have written the code for the Mac version to load and display a dialog, but there are some problems that I have not been able to explain. For example, it fails to correctly read the height and width of the dialog. And there may be other problems that I've forgotten. Unless my recent upgrade to Snow Leopard magically fixes these bugs, it's not really ready for use.

Somehow.. I doubt the upgrade will magically fix things. Snow Leopard mostly left Carbon alone, I think.

Originally Posted By: Celtic Minstrel

As for wxWidgets... yes, that would be nice, but I'm still not sure if it's the best choice for this game. If there's a way to create multiple windows in an SDL program, that might be a better way to go.

SDL cannot create multiple windows at this time. It is a planned feature, but I have no idea if SDL 1.3 is going to have it implemented or not.

Originally Posted By: Celtic Minstrel

Anyway, what I've written could probably be changed to use wxWidgets simply by modifying how it handles the internals, without touching the public interface.

That's awesome. wxWidgets 2.9.x now has Cocoa support mostly complete, along with some other niceties. I'm going to try out wxWidgets 2.9.x again on my Mac and see if it can compile a wxWidgets program that I use a lot. Is the XML format handled by WebKit in Carbon or what?

[Niemand]

WebKit would be massive overkill for just parsing some XML. I think CM is using TinyXML/TinyXML++, which is simple, portable, and gets the job done pretty well. (And, as a result of this, I would assume that the OS update would make no difference whatsoever for a parsing problem, although I doubt he was seriously suggesting that it would have.)

 

I'm also rather baffled as to how reading the dialog dimensions could fail. I wouldn't mind taking a poke at it to see what's going on; how would I run whatever test you've been using to debug it, Celtic Minstrel?

[Celtic Minstrel]

Originally Posted By: King InuYasha

Somehow.. I doubt the upgrade will magically fix things. Snow Leopard mostly left Carbon alone, I think.

Well, I don't think the problem was in Carbon, so a magical fix is a distinct possibility. Still unlikely though.

Originally Posted By: Niemand

WebKit would be massive overkill for just parsing some XML. I think CM is using TinyXML/TinyXML++, which is simple, portable, and gets the job done pretty well.

Yes, I'm using TinyXML++.

Originally Posted By: Niemand

I'm also rather baffled as to how reading the dialog dimensions could fail. I wouldn't mind taking a poke at it to see what's going on; how would I run whatever test you've been using to debug it, Celtic Minstrel?

I'm baffled too, and from what I recall it seemed like it wasn't actually a parsing problem; the dimensions were read correctly, I think, but somehow they didn't find their way to where they belong, leaving the dimensions uninitialized with the random results that normally gives.

All I was doing is setting a breakpoint in the function that loads a dialog (that's either the constructor or the function called by the constructor; I forget which) and the going into the scenario editor and attempting to edit a terrain. Then I was stepping through the debugger to try to figure out what was wrong, to no avail.

I think the problem might have been related to pointers somehow, but I can't remember now.

[Niemand]

O_0

 

That was. . . impressive. It's been over ten minutes since I ran that thing, and my system still hasn't fully recovered. As best I can tell, what it did when I tried to edit a terrain was that it created a gigantic window, far larger than my screen, and tried to tile it with one of the background textures. It was so large, though, that the space needed to buffer it greatly exceeded the capacity of my video RAM. By the time I was able to get past it scribbling all over my screen and force quit it, it had forced everything else but the OS out of RAM and into swap space.

 

During all of this, a lot (thousands) of log messages identical to this were printed:

Code:

time hostname BoE Scenario Editor[11402] <Error>: kCGErrorFailure: CGSLockWindowRectBitstime hostname BoE Scenario Editor[11402] <Error>: kCGErrorFailure: _CGSBindWindowBacking: cannot map backing data shmemtime hostname BoE Scenario Editor[11402] <Error>: kCGErrorFailure: _CGSLockWindow: Unable to lock window

Anyway, now that I can very much see it malfunctioning, I'll try to get some idea what's going wrong. I suggest that we take this to a thread of its own, as it may require more discussion and it would be nice to cut down on the thread hijacking/rambling in this forum.

[Nikmind]

Hi again

 

Interesting to see that no one has been able to make a linux port of this one yet. It's nearly two years ago since I worked on this and my port is fully playable.

 

My port is totally dead though and I'm not going to do anything more about it. Anyone who is interested in taking over the code? It will come as is with no comments or anything so take it for what it is. And I will probably not be much use in answering questions on the code. Don't remember much about it.

 

Maybe Celtic Minstrel is still around. Remember him being interested in taking over the code.

 

Take this as my way of getting some kind of linux version out there more or less quick Hope you can make some use of the countless of hours I spent on this.

 

/Mikael

[King InuYasha]

Originally Posted By: Nikmind

Hi again

Interesting to see that no one has been able to make a linux port of this one yet. It's nearly two years ago since I worked on this and my port is fully playable.

My port is totally dead though and I'm not going to do anything more about it. Anyone who is interested in taking over the code? It will come as is with no comments or anything so take it for what it is. And I will probably not be much use in answering questions on the code. Don't remember much about it.

Maybe Celtic Minstrel is still around. Remember him being interested in taking over the code.

Take this as my way of getting some kind of linux version out there more or less quick Hope you can make some use of the countless of hours I spent on this.

/Mikael

I'd like to have a copy of the source code, if that isn't a problem?

[Nikmind]

Sure, just PM me with your e-mail address.

 

/Mikael

[icelizarrd]

I just PMed you, I'm interested too.

 

I estimate that it's VERY likely I won't ever use it, but you never know...!

[Chokboyz]

Hi Nikmind, welcome back...

 

Originally Posted By: Nikmind

Interesting to see that no one has been able to make a linux port of this one yet. It's nearly two years ago since I worked on this and my port is fully playable.

Unfortunately, time has become too scarced on my part to continue with the wxWidget port (it should be doable, but if i remember well, Celtic Minstrel has already begun coding a new multiplatform version from scratch, partly inspired by the wxWidget one).

 

Originally Posted By: Nikmind

My port is totally dead though and I'm not going to do anything more about it. Anyone who is interested in taking over the code? It will come as is with no comments or anything so take it for what it is. And I will probably not be much use in answering questions on the code. Don't remember much about it.

On the other hand, if you have a fully functional Linux port, adapting the already existing Classic Blades of Exile to make it run on Linux should be doable fairly easily (provided the graphical/sound/etc functions haven't changed too much...).

I've then PM you with my mail address, hoping you can send me your sources (don't worry abouthaving to explan it ).

 

Originally Posted By: Nikmind

Take this as my way of getting some kind of linux version out there more or less quick Hope you can make some use of the countless of hours I spent on this.

And thank you for sharing your work with us.

Thanks to it, if all goes well, we may have a Linux running version in the (hopefully not sot distant) future (while waiting for a multiplatform port).

 

Chokboyz

[keira]

If i could help, i would, but i can't program worth a crap...

 

However, if you need testers or a nightly-build thing (all systems), i can probably do that. Anything to run BoE outside of WINE...

[Celtic Minstrel]

I'd be interested in seeing your code, at least. If you used wxWidgets, your source code might even be merged into the final code.

 

Originally Posted By: Chokboyz

(it should be doable, but if i remember well, Celtic Minstrel has already begun coding a new multiplatform version from scratch, partly inspired by the wxWidget one).

I did do this. I did not get very far, but I did start.

[Aran]

Does anyone have a version of this code? I've messaged Nikmind, but he seems to be gone.

 

I probably won't be able to contribute much, as I don't know C++, but it can't hurt to look. If it works, the code also seems to be more advanced than anything available at the Google project now, which has nothing but the Character Editor.

[CromagnonCoder]

I know it has been 7 years since this thread has been updated, but I was wondering if anyone has gotten Blades of Exile to work on linux.

[The Almighty Doer of Stuff]

Sorta kinda. It runs. I think it still doesn't have menus and is unplayable. The Windows version doesn't run especially well with Wine either. We're working on it though. I think.

Hey, since you're a coder, Cromagnon or otherwise, I don't suppose you'd like to help out the project? We like help. Celtic Minstrel does nearly all the programming work himself which is why it's so slow-going.

[CromagnonCoder]

Wish I could say yes but I don't know anything about SDL, GTK+ or WXWidgets. There was a linux version, are you basing your work on it?

[The Almighty Doer of Stuff]

I don't know any of the details of the programming, although the Linux version is based on Celtic Minstrel's work, not the other way around. The goal is to make the whole thing cross platform, I think, and the Linux branch of it is fairly recent. For more details, ask CM. He'll probably see this soon enough, or you can pop into the IRC chat room ( http://webchat.freenode.net/?channels=%23openboe ), which he checks more often. He's not there now but I suspect he will soon enough. The chat is a convenient place to coordinate development things, I think.

Edited September 15, 2017 by The Almighty Doer of Stuff
boy is my head in a fog i don't know what's going on

[Mea Tulpa]

Cromagnon, you may be thinking of the Linux version of Exile III, which seems to have been a one-off.

[The Almighty Doer of Stuff]

Oh, right. That. That's just the Windows version of Exile III with an old version of Wineskin stuck on it, not a real Linux version, IIRC. That's what I remember hearing. (Actually I think this came up before and we determined I made that up? But maybe I'm making this up instead. We've got low barometric pressure here though, boy am I sick today...) Yeah, anyway, BoE never got the Linux treatment. We've just got a partially done BoE Linux version that isn't releasable.

Edited September 15, 2017 by The Almighty Doer of Stuff

[Celtic Minstrel]

OBoE does not use SDL, GTK+, or wxWidgets, though there is a possibility that the Linux port would have to use GTK+ for menus and file dialogs (but I'd prefer Qt or wxWidgets if we absolutely have to; I've also been contemplating a custom menus implementation). What it does use for rendering is SFML.

 

As far as I'm aware, the Linux branch is fully playable (unless there are game-breaking bugs that haven't been discovered). However, the lack of menus, combined with a bug in the "Save" function ("Save As" works, "Save" does not), means that it is impossible to save your game, so I wouldn't really recommend trying to complete a scenario on the latest linux branch build. The lack of menus also renders the scenario editor and party editor utterly useless.

[CromagnonCoder]

I was thinking the linux version may be a good reference, but you are making an open source version. I tried the linux branch, but could not get it to work. Either I have an outdated version or it did not install properly. I guess I'll virtualize a copy of Windows for now.

[Celtic Minstrel]

The linux branch is out-of-date. If you could merge master into the linux branch, I would expect it to work, but can't be certain (and the merge is probably not a clean one in any case). I'll get to that merge eventually; I just keep putting it off because booting up Linux means shutting down Windows.

 

The scons script "installs" the game in the source directory, under "build/Blades of Exile/", so if it said the build succeeded, that's where you'd have to look. If the build failed, I'd like to hear why. Note that the scons script doesn't quite seem to work on Windows (I was working on that a couple days ago).

[CromagnonCoder]

I think I did something wrong then. Or got the game from the wrong source. Or maybe a 32 bit app can't run on a 64 bit computer. The game was installed in usr/local/exile3. No worries though, I blew the dust off a windows 8.1 computer and will try it. Have you tried virtualizing Windows on linux? You wouldn't have to shut down one to use the other.

Edited September 16, 2017 by CromagnonCoder

[Celtic Minstrel]

*blinks*

 

Okay, I think we must have been talking past each other, because I was talking about Open Blades of Exile, not Exile III. Sorry for the confusion.

 

Note that Exile III for Windows is not a 32-bit app. It's a 16-bit app. 32-bit apps can run on 64-bit computers, and 16-bit apps can run on 32-bit computers, but 16-bit apps cannot run on 64-bit computers.

 

And uh, if I was going to go the virtualization route, why Windows on Linux? I barely use Linux at all, and I do use Microsoft Visual Studio since it's actually a pretty good IDE. Virtualizing Linux on Windows would seem to be a smarter plan if I were to go that way.

[The Almighty Doer of Stuff]

EDIT: Ugh.

Edited September 18, 2017 by The Almighty Doer of Stuff

[CromagnonCoder]

Okay, I guess we are on the same page about Exile. Maybe I can breathe new life into a 486 I have languishing in my bedroom. I suggested Windows on Linux because I assumed your primary os was Linux. But if you don't use Linux that much, there is no point.

 

https://xkcd.com/1891/

[The Almighty Doer of Stuff]

We are trying to make it cross-platform. My primary OS is Linux Mint and I only use Windows when I absolutely need to. So I would love to have BoE work on Linux. Mind you, I'm talking about Blades of Exile, not Exile III. They are different games. The Exile Trilogy will, hopefully, be someday possible to plug into Open Blades of Exile and play, but that's a ways off.

 

EDIT: Wait, I think I misunderstood. I just woke up. You ARE interested in breathing new life into... something? Which is... not programming, but just running it on an old computer? I think that's what you said...

Edited September 22, 2017 by The Almighty Doer of Stuff

[CromagnonCoder]

I did say I was interested in reviving an old laptop so I can play the game. Linux is my primary os, so an open source version would make that possible. I think it would be easier to have an open source version than running the game than using virtualization.

Edited September 24, 2017 by CromagnonCoder