Blades of Exile for Linux :D

[Nikmind]

Hello!

 

I'm new on this forum and joined for telling people my little story

 

For like two months ago i went back to the Spiderweb site since i remember loving to play the Exile games. To much surprise i noticed that the source code had been released for Blades of Exile. I quickly searched for someone who had done a Linux port but was unable to find anything but people who wrote about doing it

 

After some consideration i decided to try it myself. I've not done much coding since my good old Amiga, so it was gonna be a funny side project.

 

Firstly i thought that SDL would be great for it and tried to do it. I quickly noticed that SDL was not really suited for this kind of game with menus and so on. Hence i quickly went for GTK+ instead. One funny thing i quickly noticed was that its not a good idea work with the whole code at once... That way i would never be able to try the code for each step i took. So now i add the functions as they are needed while going through the steps.

 

While going through the functions i quickly ended up at the sound handling code. This is where a big shortcoming of GTK+ came up... It doesnt have anything related to audio.

 

I tried many different systems for sound and finally found that allegro fit my bill. ie. it was veeery easy

It worked well for me until i noticed that allegro wont work with the gtk_main() function In the end i had to take back SDL for the sound part and it works great.

 

One of the biggest challenges was to choose how to draw the graphics. I fooled around with draw areas, goocanvas and gnomecanvas. In the end i ended up with the Gtk Layout which works for my needs.

All the graphic handling in the game centers around the rectangular draw function. This is what probably has taken me the most time to fix so far. Mostly cause of the whole pixbuf and pixmap crap in GTK. I'll not go deeper into details but i've got 4 different rect draw functions

 

Another important part is the drawing of strings and Pango fit the bill for that (being a part of GTK and all). Was a bit tricky, but in the end i managed to fix the font, fontsize, bold, italic, color... ie. everything to work.

 

With all this and lots of little bits and pieces i got the main screen to show Some more tweaking with timers and the little animation also plays.

 

Sigh, now the code suddenly needed to show a tip of the day. This meant it was time to implement the dialog code.

It was no picnic so that part is now in place and working. One can even go through the tips and press done to close the window

 

This is all ive managed to do in a couple of months... mostly cause i decided not to write wrapper functions around the windows specific ones. I've replaced them directly in the code. For example such a trivial thing as the difference between RECT and GdkRectangle... SIGH.

 

Anyhow, i've now started on the code for handling mouse clicks in the main window. That is one huge function and it will probably bring in much of the functions left for me to add... so dont hold your breath.

 

 

Anyway, there will probably come some other port of this for Linux long before i finish. I just see this as a funny project and a good learning experience.

 

I'll keep you posted on my progress

 

/Mikael

[Niemand]

It's great to see that there's the interest to undertake projects like this, particularly since it sounds like you're rewriting most of the supporting code.

 

Best of luck with this.

[The Almighty Doer of Stuff]

"Nikmind"

"Niemand"

[Niemand]

Yes, our PDNs are similar. However, I have never heard of Nikmind before in my life, to the best of my knowledge. Also, note that he closes his post '/Mikael'. It's good to have another 'N' person though. If he becomes a regular, we should have 6.

[Celtic Minstrel]

Hmm... if he finishes this, what would that mean for the goal of platform independence? It sounds like he's at least isolating the platform dependent code, and also using some cross-platform libraries...

[Nikmind]

I have all intentions of finishing it, but for all means make your version portable No harm in having choices is there.

 

Didnt really think much about it being portable at all. Just thought about linux since there is already a working windows version. My version should be pretty portable as i'm using GTK and SDL. Should work pretty much as is on other platforms having GTK and SDL.

The porting thing will have to be the work of someone else when i've come that far. For me i'm only interested in getting it up and running under linux.

 

/Mikael

[Nikmind]

My little project is still going slowly forward. I dont have as much time as i want, but who does.

 

Yesterday i came to the part where you add and remove spells and monsters from the menus. At that point i noticed that the itemfactory i used for the menus is already deprecated

I'm now trying to port my menus into the new uimanager. Then i'll have the fun of trying to add/remove items from the menus somehow...

 

The next tedious work is to add the rest of the dialogs. For now i've only added the Tip of the day dialog since it came early in the program. Since there is no .RC file under linux, ive added it in the code in other ways.

 

Oh well, enough status info for now

[King InuYasha]

For the most part, in GTK+ the equivalent of RC files I believe are .glade files. In Qt, the equivalent is .ui file type.

 

GTK+ and Allegro is a good combination, the only issue I can think of is that you are going to wind up rewriting the whole thing from C++ to C, since GTK+ raw uses C as its programming language. Also, GTK+ is well tuned for UNIX style applications, as it was designed with the assistance of people from GNU project, who hold the POSIX model in high regard. In contrast to this, wxWidgets or Qt both abstract away from both the OS2/Win32/VMS model and the POSIX model so that one codebase works with both types of platforms.

 

If I had more time, I would be trying to do this kind of work, but alas, school and life are a higher priority.

 

Also, do you plan to post your changes in a repository so others can see it and try it out soon?

[Celtic Minstrel]

Blades of Exile is in C already, so the C++ to C should not be an issue.

[Niemand]

Besides which, calling C functions from C++ is trivial, and my cursory research indicates that both Allegro and GTK+ are both developed with C++ compatibility in mind.

[Nikmind]

Equivalent is not totally true for RC->glade. Since the dialog engine of the game is custom i was unable to convert it into GTK+ dialogs.

Hence i have converted the RC dialogs into structures using my own little awk script

 

I also must say that i have no idea how you managed to get allegro to work with GTK+. As soon as the gtk_main function starts, allegro crashes. Seems its a known problem when i look around the net. I really dont care since SDL work fine for my purposes.

 

The game is in C and not C++, so ive had no problems with that.

As for wxwidgets and QT, they are more C++ centered and hence didnt feel right for this.

 

I have no plans for putting it in any repository for now. If and when i ever get it up and running, we'll see then.

[Celtic Minstrel]

I recommend emailing Catphive for SVN access on his new Google Code project.

 

(see this thread)

[catphive]

Hi, if you are still working on this, how would you feel about adding it to SVN?

 

I'm putting together a project to host all of the various BoE work that has been very divided into a number of places until now.

http://code.google.com/p/openexile/

 

currently the osx port is there in the osx directory of the trunk.

 

http://code.google.com/p/openexile/source/browse/#svn/trunk/osx

 

If you would like, I will give you authorization to commit, and further development of the linux port can take places in a linux directory. This would give an opportunity for other linux developers such as myself to provide bug fixes in an orderly way.

 

Please email me with your google account name (usually your gmail email address) and I can add you to the project.

 

Currently, there is a thread about this project here:

http://www.ironycentral.com/forum/ubbthreads.php?ubb=showflat&Number=158120&gonew=1#UNREAD

[King InuYasha]

Do you plan to reorganize the code so that the front end code is separated from the back end code? Doing so would definitely make it easier to change out GUIs if it was ever needed. A few months ago, I had used Qt Designer to design from scratch the initial screen when loading up BoE, but I couldn't make it more "functional" because I couldn't figure out heads or tails of the code. I didn't know where the front end code ended and the back end code began.

 

I also had a wx GUI written, but again, the same issue caused problems.

 

I'm not sure if GTK+ support for Mac OS X has improved to the point that it no longer requires the installation of Apple's X11.app, but Qt 4.5 allows you use to use Carbon or Cocoa, so it would make it a bit easier to continue using it since Carbon doesn't extend well to 64-bit. Additionally, wouldn't a GTK+ port still be able to be built for Windows too, even if it uses autotools, especially since Fedora introduced a toolchain for crosscompiling to Windows and testing through Wine?

[Nikmind]

I've not thought much about where to host this. It will stay on my hd only until it actually works.

I'm not especially proud of my code but i've atleast so far managed to get the main drawing functions working and also this mess of a dialog system.

 

I'm woking on adding the rest of the functions to actually be able to start a game. In the process i'm also rewriting my drawing code to be more clean, flexible and quicker(like not redrawing whole window each time...).

 

When i'm satisfied with the function of the game, we can do this.

 

As for answering to the second question about modular code... I would not say it is. At this stage i'm just replacing needed windows functionality into GTK ones. This is pretty much very integrated in the code, so such and approach has not been taken. I just want to get the game up and running and have no intentions at this stage for much else.

Since i use GTK and SDL it should be decently portable to various platforms i guess, but at this stage my focus is 100% linux.

 

/Mikael

[Celtic Minstrel]

Originally Posted By: King InuYasha

I'm not sure if GTK+ support for Mac OS X has improved to the point that it no longer requires the installation of Apple's X11.app, but Qt 4.5 allows you use to use Carbon or Cocoa, so it would make it a bit easier to continue using it since Carbon doesn't extend well to 64-bit.

I don't think it would be worth porting it to Cocoa. It would be a lot of work, certainly, and would probably require a major rewrite. For now, I think it's best to stick to Carbon.

[catphive]

Ah, fair enough. If you do reach a point where you are comfortable releasing your code, please consider putting it in the repository, for the sake of keeping all the ports organized and publically available in the same place. I'm a Linux developer as well, so I might be able to help out.

[King InuYasha]

Originally Posted By: Celtic Minstrel

Originally Posted By: King InuYasha

I'm not sure if GTK+ support for Mac OS X has improved to the point that it no longer requires the installation of Apple's X11.app, but Qt 4.5 allows you use to use Carbon or Cocoa, so it would make it a bit easier to continue using it since Carbon doesn't extend well to 64-bit.

I don't think it would be worth porting it to Cocoa. It would be a lot of work, certainly, and would probably require a major rewrite. For now, I think it's best to stick to Carbon.

I worded that wrong, Qt 4.5 will use Cocoa or Carbon APIs for its Mac build. Which means, a single recompile of Qt app targeted for Cocoa instead of Carbon will make it use Cocoa without any work at all.

[Nikmind]

Time for a small status report again. This weekend i at last came to the point that i would be able to press the make party button on the start page

This however soon made me realize that i'd totally missed the point that the game has recursive dialogs

Using the GtkDialog widget suddenly was not usable for this. Hence i had to rewrite the whole dialog code, which was no fun at all. Yesterday though i managed to get it working at last. Now i can create a party at last. This however also brought forward the save_file function. Hence i'm at the moment working on the load/save game functions.

 

Also noteable is that i rewrote the whole main drawing functions to make it more consolidated and clean. It still has some bugs, especially with regards to resizing the window.

 

I'm soo looking forward to actually be able to start a game... maybe next weekend if i get some more free time then.

 

In any case, i hope i have most of the major gameplay functions done now that the dialogs seems to work.

 

/Mikael

[Celtic Minstrel]

I assume you're not touching the gameplay functions?

[Nikmind]

Yes, for now i'm not touching the gameplay. The goal is for it to work like the original version.

 

/Mikael

[Nikmind]

Another quick update.

 

Load/save of games/scenarios now work. Never thought this part would give me sooooo much problems. After hours of swearing i found out that align padding of structures was the problem. The "#pragma pack" compiler directive was my saviour in the end. So, unless the compiler used supports this... my version wont work. Will have to make this part more robust further on, also in regards to big/little endian. This since a linux version can be both. This should not be so hard, since those flip functions are already in place.

Still, saving structs is generally a baaaad idea for portability.

 

Also had to put down lots of time on the dialog code again... sigh. Hope to have it working fully now, even the custom dialogs.

 

Now i can finally start a scenario and see my char lying in a bed in Fort Talrus

Also added the mouse motion code so the mouse cursor changes as it should while moving around the mouse.

 

The code for clicking anything is totally crap though and instantly crashes the game. This will be my next priority.

 

Also a small and odd bug is that the location string under the terrain pic says "Fort Talrus" and in the original game it says "Guest Quarters" (i think it was... at work now so cant check). Dont know how this can happen, will have to look into it.

 

In any case, i'm closing in on getting it actually running

[Celtic Minstrel]

What about keyboard input? Can you use the keys to move your character around yet?

[Nikmind]

No, i did the mouse input first.

 

I've fixed that bug now. This means i can move around now. Found another bug then since the char is invisible

Trying to find the source of that problem now.

 

I've also fixed so it says Guest Quarters as it should.

Also noticed that the map crashes the game. I've still got some way to go for it to be usable.

 

Oh well, one problem at a time

 

/Mikael

[Nikmind]

There, no the char is no longer invisible

 

I can now move around and picking up stuff also work. The event "Dot" works fine and also the opening door info. Looking at the sign outside the door crashes game though. Will be my next project.

 

/Mikael

[Nikmind]

There, now the signs works fine. I've also had to do some rewrites in my dialog code again... never ending story...

 

The map now works, but is missing the "OK" button. Should be a quick fix for that, but to tired tonight.

 

Going into combat mode also work, and also running into people for combat. Not tried and actual fight yet though.

Going in and out of town works nicely also it seems.

 

Talking to people is seriously bugged. This will be my next part to fix. After that i'll try combat and see how well (or not) it works.

 

/Mikael

[Celtic Minstrel]

It's possible that I've asked this already, but are you separating interface code from gameplay code while you do all this?

[Nikmind]

I tried to at first, but it quickly noticed it would be too much work. The interface code is so deeply integrated, it would be very hard without a total rewrite.

Since i was in no way upto this, its like the original code... very integrated.

This means it will probably be as much work to change this to something other than GTK, as it was to get it to GTK.

 

Its getting very close to being playable under linux now, and that was pretty much my goal.

 

/Mikael

[Nikmind]

Now the keyboard support is there. Really made it more playable in a jiffy

 

Still need to fix the talking part... and the targeting code in combat makes the game crash. There is still things to do...

 

/Mikael

[Prince of Kitties]

When you've fixed the talking and the crashes, can you upload it somewhere? I run Linux, so I can be your first beta tester.

[King InuYasha]

I will gladly test as well

[Nikmind]

Haven't had too much to work on it lately, but i have atleast come a bit further.

 

Talking now works and after many not so nice words the targeting is also ok now.

 

Lots of various other fixes also has been done. Most notably some long standing problems with my clip regions code.

 

With the targeting in place i'm gonna try out the combat mode tonight. Will be interesting to see how that works.

 

There are some big showstopper bugs i know of that needs to be fixed. Like the fact that event "dots" arent triggered outside (works in town). Some dialogs never gets shown making some noteable info missing.

 

The menus in game needs to be coupled to functions, they are just stubs at this moment.

 

There are probably several other bugs i've forgotten to mention as well as havent found yet

 

In any case i'm making nice but slow progress. Will keep you posted on any further progress...

 

/Mikael

[Nikmind]

So, now the event handling is fixed (as far as i can see) and at the same time the missing dialogs appeared... hence they where event driven.

 

Shopping mode has now been tested when i could finally run into a shop "dot". It worked without a hitch. hooray!

 

Scrollbar functionality has been added now. So the scrollbars are no longer just for show

 

Combat works but throws out lots of errors when doing missile animations. This will be my next concern.

 

All in all i actually think the game is playable now. All mayor parts should now be implemented i think.

 

Gonna play through a scenarion soon to see what new bugs i can come by...

 

/Mikael

[King InuYasha]

Mikmind, do you plan to release the scripts on how you converted the RC files to their GTK+ equivalents?

[Nikmind]

I have no intentions of doing that no. It was just a dirty quick hack to make the .RC file into structs. Ie. the .RC files are now just .h files with some special code around it.

 

I've now also fixed some trimming errors which gave me odd graphical results in some cases.

Also i went into a dark cave and noticed that the light cropping was not working. Found and fixed that error.

 

Ive not been able to locate the strange GTK errors which fills my console. Seems that i some cases the src or dest rectangle into rect_draw_some_item have negative values. I'm not sure if this occurs in windows version also and its handled by the StrtchBlt function. It doesnt in any case give any graphical errors on screen so its not really a problem. I can supress those errors if i want to but have decided to keep them around for now. Maybe i'll find the culprit in the end.

 

Now I'm working on locating some errors around ending scenarion and starting a new one. This gives some strange and random errors. Need to look into what gets wrongly initialized when i start a new scenario as opposed to starting a new one at startup.

 

The game is fully playable now and this atleast gives me the push to continue this tiresome work

 

/Mikael

[Chokboyz]

Quote:

Seems that i some cases the src or dest rectangle into rect_draw_some_item have negative values

In the GRAPHUTL.cpp, function rect_draw_some_item() lines 106-109

Click to reveal..

StretchBlt(hdcMem3,dest_rect.left,dest_rect.top,dest_rect.right - dest_rect.left,
dest_rect.bottom - dest_rect.top,
hdcMem2,0,0,src_rect.right - src_rect.left,
src_rect.bottom - src_rect.top,SRCAND);

should read

Click to reveal..

StretchBlt(hdcMem3,dest_rect.left,dest_rect.top,dest_rect.right - dest_rect.left,
dest_rect.bottom - dest_rect.top,
hdcMem2,0,0,dest_rect.right - dest_rect.left,
dest_rect.bottom - dest_rect.top,SRCAND);

because the hdcMem2 handler is initialized at dest_rect size and read at src_size.
The same error is present in the function, few lines later (lines 145-148 for Windows) and needs to be fixed too.

The result in Windows was that custom graphics who were not standard size were giving gibberish (white "noise") when masking them in the inventory.
Maybe that is what causes your error.

I was wondering, since you made OBoE use SDL for sound, if you considered trying to implement a cross-platform (wxWidget, QT4.5, ...) GUI. If you did, that would be great as, when done, we could fusion the two codes (Bug Fixes, New Features and Cross-Platform support). I've given it a try, but i was far out of my league

I may well understand that you are fed up with all of this though

Edit : Found this in the previous posts :

Quote:

As for wxwidgets and QT, they are more C++ centered and hence didnt feel right for this.

This answer my last question So, nevermind ...

Hope it helps,
Chokboyz

[Celtic Minstrel]

If the game is playable, why not add it to the repository?

[King InuYasha]

What happened to BoE for Linux? Is it dead or what? Haven't heard a peep about it in a month....

[Chokboyz]

Originally Posted By: King InuYasha

What happened to BoE for Linux? Is it dead or what? Haven't heard a peep about it in a month....

Let's hope not ... Supposely, it's still being ported ...
Nikmind if you're fed up with that (i can understand it's quite draining ), please upload what you've done (pretty much judging from your previous posts) to the repository or wherever you like and we (at least I) will continue your work ...
Then again, if you're still kicking, take your time

Chokboyz

[Celtic Minstrel]

He needs to be given access before he can upload it, though!

 

I do hope he shows up again sometime.

[Nikmind]

Hi everyone

 

I'm not totally gone but have too much to do atm. to have time for working much on this.

I've finished the game so all should be in place now and only minor bugs (induced by me that is) should be in there.

 

Maybe i'll try and clean up the code a bit and leave it to you or i might decide to continue myself...

We'll see what happens... just thought i would drop by and tell you how things are atm.

 

/M

[Celtic Minstrel]

Why don't you get a Google account and email me so you can access the repository? You don't have to put the code in there immediately if you don't want to...

[King InuYasha]

It's been almost two months. Nikmind, if you can't continue working on the Linux port, why don't you have it imported into the Google Code project that Celtic Minstrel is managing so that other people can work on it too?

[Celtic Minstrel]

Partly (mainly?) because he hasn't been around, I guess.

 

In fact, if he does post the code, and it works, I would seriously consider using it to replace all the platform-dependent interface code in the game; that would mean we don't need so many conditionals.

[King InuYasha]

Originally Posted By: Celtic Minstrel

Partly (mainly?) because he hasn't been around, I guess.

In fact, if he does post the code, and it works, I would seriously consider using it to replace all the platform-dependent interface code in the game; that would mean we don't need so many conditionals.

Well, when you guys were updating the Mac version, you did have the opportunity to do all that. You guys just didn't take it, that's all.

You guys could probably still do it though. I don't think you would, but you COULD. It would make merging the Mac and Windows versions far easier. Also, considering that you guys used Carbon for the Mac version, something eventually will need to be done, since that API has been deprecated for quite a few Mac OS X releases and is probably scheduled to disappear soon...

[Niemand]

Quote:

Well, when you guys were updating the Mac version, you did have the opportunity to do all that. You guys just didn't take it, that's all.

The opportunity (to abstract out platform dependencies) has existed since the code was released, and hasn't gone away. However, it is a very large task, and players were clamoring for executables that ran, bug fixes, and feature additions.

Quote:

Also, considering that you guys used Carbon for the Mac version, something eventually will need to be done, since that API has been deprecated for quite a few Mac OS X releases and is probably scheduled to disappear soon...

The game was already written with Carbon, that was not a choice made by the open source developers. Also, that framework is not deprecated, try reading the relevant documentation. While is does appear that Apple may deprecate it in the future, that hasn't come yet, and switching BoE away from Carbon would require rewriting a vast amount of the code. It would also preclude merging with the Windows source, since it would involve rewriting the game in Objective-C. (To switch to Cocoa. Your other choice is to use a multi-platform library like wxWidgets or Qt, which will still entail a huge amount of work.)

[Celtic Minstrel]

I dislike the fact that Qt requires a separate preprocessor; if I were to choose a cross-platform GUI library, I'd almost certainly go for wxWidgets.

 

Originally Posted By: Niemand

switching BoE away from Carbon would require rewriting a vast amount of the code. It would also preclude merging with the Windows source, since it would involve rewriting the game in Objective-C. (To switch to Cocoa.

Actually, I don't think you'd need to rewrite that much; GCC could be made to compile as Objective C++, and you could use Objective-C stuff for the user-interface code while staying with pure C++ for the main code.

 

Of course, that would still require conditionals to keep Objective-C code out of the code seen by the Windows compiler; it would also require making GCC override the file type so that the extension can stay as 'cpp' rather than changing to 'mm'. (This assuming that the Windows ans Mac code are indeed merged.)

[King InuYasha]

Originally Posted By: Celtic Minstrel

I dislike the fact that Qt requires a separate preprocessor; if I were to choose a cross-platform GUI library, I'd almost certainly go for wxWidgets.

Originally Posted By: Niemand

switching BoE away from Carbon would require rewriting a vast amount of the code. It would also preclude merging with the Windows source, since it would involve rewriting the game in Objective-C. (To switch to Cocoa.

Actually, I don't think you'd need to rewrite that much; GCC could be made to compile as Objective C++, and you could use Objective-C stuff for the user-interface code while staying with pure C++ for the main code.

Of course, that would still require conditionals to keep Objective-C code out of the code seen by the Windows compiler; it would also require making GCC override the file type so that the extension can stay as 'cpp' rather than changing to 'mm'. (This assuming that the Windows ans Mac code are indeed merged.)

I'm think that wxWidgets has an Objective-{C,C++} binding so you could still use Objective-{C,C++} on Windows since TDM-GCC and MinGW GCC 4 include ObjC compilers.

What's wrong with the moc preprocessor? With Qt 4.5 and higher, you could have the game in C/C++ and still be able to compile to target Cocoa on OS X.

[Celtic Minstrel]

It's just another step to worry about, which means figuring out how to get Xcode to call it as necessary. On the other hand, I've taken a look at wxWidgets, and I liked what I saw there.

 

I don't want to use Objective-C, by the way; I was just pointing out that Objective-C code could be mixed with C++ code in a file (Cocoa's binding is ObjC).

[King InuYasha]

Originally Posted By: Celtic Minstrel

It's just another step to worry about, which means figuring out how to get Xcode to call it as necessary. On the other hand, I've taken a look at wxWidgets, and I liked what I saw there.

I don't want to use Objective-C, by the way; I was just pointing out that Objective-C code could be mixed with C++ code in a file (Cocoa's binding is ObjC).

Creating separate projects seems sort of redundant, when there are better ways of doing it. I would figure making a set of CMake scripts to handle it would be better, since CMake can generate MinGW makefiles, Unix makefiles, Code::Blocks project files, and Xcode project files. As long as the moc step is taken care of in CMake, it would be fine.

Of course, qmake could be used instead, and it also supports generating Xcode project files. However, it does not generate Code::Blocks project files.

I was aware that C could be mixed with Objective-C, given that Objective-C is supposed to be a "true superset" of C.

My major problem with wxWidgets is that it doesn't work all that well under a KDE system. Other than that, wxWidgets and Qt are remarkably similar in their feature set. Although, wxWidgets uses Gecko instead of WebKit for their HTML rendering. I'm not sure if wxWidgets had switched from Carbon to Cocoa for wxMac as Qt had, but meh.