Anything I can do to help with WxWidgets/Linux development?

[Nephil Thief]

Just thought I'd put it out there. Linux is now my day job, and I maintained my own Angband variant for a while, so I can sorta kinda do C. Oh, and I have a Github account. I'd be interested in helping out with the cross-platform version.

 

Caveat: I'm really really busy most of the time. But I would be quite willing to pitch on in weekends, especially if it might teach me a thing or two more about C++/WxWidgets/etc.

 

Anyway, if there's anything that needs working on in the Wx editor, please mention; I will probably want to start small (don't know much about the more advanced C++ stuff) but hopefully will be able to help matters.

 

Thanks for keeping the game alive!

[Celtic Minstrel]

I actually abandoned the wxWidgets fork; I'm now using SFML, which isn't a GUI library, just a graphical library similar to SDL. At this point, the code under the osx/ directory is largely multiplatform - there are a few files that will need to be completely rewritten for Windows and Linux (which are easily identified by the filename), and there may be a few remaining OSX-specific references in other files, but the majority of the code is now platform-agnostic.

 

I just (finally) pushed my changes that get the scenario editor functional, though some dialogs are still left unimplemented which I need to convert from the old format soon (help with that would be nice, but it kinda requires a Mac since the old format is DITL resources).

 

To get it to work on Linux, you'll need to define the menus and write the code to attach them to the main window (that is how windows work on Linux, right?) and glue them to BoE's main menu handling code. You'll also need to do a few other things, like handling files dropped on the program icon, setting the mouse cursor, and some windowing things such as making a window modal. The preferences code is also currently Mac-only, but I'm guessing Linux and Windows should be able to use the same code for that, with maybe just a simple #ifdef to determine where to store the file (something in %AppData% on Windows; on Linux, probably something invisible in the home folder; you'll need to call getenv). I think the Windows version currently stores preferences in the application folder, but that should be changed.

 

Since I'm not using a GUI, all the dialog controls have basically been coded by me, which meant re-implementing scrollbars and text fields; the latter still need a lot of work before they behave much like a text field is expected to behave. It's particularly complicated by the fact that the scenario editor uses multi-line text fields.

 

There are numerous graphical glitches to fix, and I suspect there are also performance issues in the rendering, though it might only be noticeable when running with a debugger attached. If you want to start small, figuring out things like why animations aren't showing might be a good start. I think I also temporarily disabled the code that renders "fog of war" (which might be why you can see monsters through walls in combat mode); it was slowing the game down quite a bit and also wasn't even drawing in the correct place on the screen. Another thing that seems to be taking a lot of time is some of the routines in graphtool.cpp that use a temporary texture for drawing; I think it should be possible to do this without the temporary texture, but the library doesn't seem to provide a means to do so, and I'm not sure if I can manage it by mixing direct OpenGL calls with SFML calls.

 

Um, that's all I can think of off the top of me head...

[Nephil Thief]

Well thank you, I had never even heard of SFML until today... I'll take a look at the "osx" code tomorrow.

 

Edit: Just curious though, why SFML? It looks painful to use for 2D stuff, with buttons and things that ought to be widgets.

 

Re the dialogs, you mean they had graphics stuff stored in resource forks? Argh.

 

To get it to work on Linux, you'll need to define the menus and write the code to attach them to the main window (that is how windows work on Linux, right?) and glue them to BoE's main menu handling code. You'll also need to do a few other things, like handling files dropped on the program icon, setting the mouse cursor, and some windowing things such as making a window modal. The preferences code is also currently Mac-only, but I'm guessing Linux and Windows should be able to use the same code for that, with maybe just a simple #ifdef to determine where to store the file (something in %AppData% on Windows; on Linux, probably something invisible in the home folder; you'll need to call getenv). I think the Windows version currently stores preferences in the application folder, but that should be changed.

 

Not sure what you mean about how windows work on Linux? Shouldn't SGML handle the abstractions needed for dealing with X11 vs. Quartz vs. whatever Windows uses? But I'll see what can be done.

 

Since I'm not using a GUI, all the dialog controls have basically been coded by me, which meant re-implementing scrollbars and text fields; the latter still need a lot of work before they behave much like a text field is expected to behave. It's particularly complicated by the fact that the scenario editor uses multi-line text fields.

 

Hmm. How does SFML handle text fields exactly? I'm looking through the API docs but it seems the usual level of abstraction is much lower.

 

There are numerous graphical glitches to fix, and I suspect there are also performance issues in the rendering, though it might only be noticeable when running with a debugger attached. If you want to start small, figuring out things like why animations aren't showing might be a good start. I think I also temporarily disabled the code that renders "fog of war" (which might be why you can see monsters through walls in combat mode); it was slowing the game down quite a bit and also wasn't even drawing in the correct place on the screen. Another thing that seems to be taking a lot of time is some of the routines in graphtool.cpp that use a temporary texture for drawing; I think it should be possible to do this without the temporary texture, but the library doesn't seem to provide a means to do so, and I'm not sure if I can manage it by mixing direct OpenGL calls with SFML calls.

 

Um, that's all I can think of off the top of me head...

 

Okay, thank you.

 

In fact, I think I will take a look at the code tonight... I just finished installing SFML on my workstation, give me a minute.

[Slawbug]

Which Angband variant?

[Nephil Thief]

https://gitorious.org/neoband

 

(Google and the NSA already know who I am, so what the heck...)

[Nephil Thief]

Celtic Minstrel: umm, how do I compile this (or try to)? I don't see any makefiles or related stuff, only an XCode project...

[Celtic Minstrel]

Edit: Just curious though, why SFML? It looks painful to use for 2D stuff, with buttons and things that ought to be widgets.

It's not particularly painful for 2D stuff in general, but for widgets, yeah, it's a bit painful. I wouldn't be opposed to finding a way to integrate native text edit fields (Jeff himself did this), as reimplementing them is going to be a lot of work otherwise, but I'm not really sure how to do this with SFML - it'd probably involve something like what I did in the winutil file, namely fetching the native handle to the window and doing things to it.

 

Some of the more advanced graphical stuff also took a bit of work, like ellipses and masking; the latter may still need work.

 

Re the dialogs, you mean they had graphics stuff stored in resource forks? Argh.

Not the graphics stuff, I'm referring to the layout information for the dialogs. (Though the graphics were originally in resource forks too, but in a separate file from the executable.)

 

Not sure what you mean about how windows work on Linux? Shouldn't SGML handle the abstractions needed for dealing with X11 vs. Quartz vs. whatever Windows uses? But I'll see what can be done.

SFML most of the abstraction, but it's not a GUI library - it's just a graphics library like SDL. There are a few things we need that it doesn't do, like making a window modal or calling native file get/put dialogs, so we need to use the native window handle to do these things ourselves. I think the only file where I did this is winutil.mac.mm, which will need to be rewritten for Linux and again for Windows.

 

(Actually, does Linux have native file get/put dialogs in the X window system?)

 

Hmm. How does SFML handle text fields exactly? I'm looking through the API docs but it seems the usual level of abstraction is much lower.

SFML doesn't handle text fields. I have a partial implementation in the dialogxml folder (in field.{c,h}pp).

 

Celtic Minstrel: umm, how do I compile this (or try to)? I don't see any makefiles or related stuff, only an XCode project...

I'm afraid there's no makefiles yet, sorry. If you like I can help you by providing the information you'd need to make one, or something equivalent? You might also be able to glean some stuff by opening the XCode project in a text editor, though it's not particularly a great format for browsing in plaintext.

 

I'll start off by listing files you'll need for the compilation. To compile the game itself, you'll need the following files. (All paths relative to the osx directory.)

• boe.*.cpp
  
• tools/*.cpp
  
• tools/gzstream/gzstream.cpp
  
• dialogxml/*.cpp
  
• dialogxml/xml-parser/*.cpp
  
• classes/*.cpp
  

 

To compile the scenario editor or the character editor, only the first entry changes (to scenedit/scen.*.cpp and pcedit/pc.*.cpp respectively).

 

You'll need to add any directory with header files to the include path, since XCode does that automatically and I haven't included the partial paths. That means tools/, tools/dialogxml, tools/dialogxml/xml-parser, tools/resmgr, tools/gzstream and classes. (Pretty sure that's all of them.)

 

Besides Boost.(File)System and SFML, you'll also need to link in zlib... I think those are the only required libraries though. You might need to explicitly link things some dependencies of SFML like sndfile or freetype (not sure). Also, SFML comes in several components - you don't need the network component. Just link the system, window, graphics, and audio components. You'll also need a modern C++ library and compiler that supports some C++11 features, but on Linux that probably won't be an issue (I'm fairly sure the latest gcc qualifies, and I'm using an older version of clang anyway).

 

The expected directory structure after compilation is as follows:

Blades of Exile/
 Blades of Exile Scenarios/
   busywork.exs
   stealth.exs
   valleydy.exs
   zakhazi.exs
 Blades of Exile
 data/
   dialogs/
     (many xml files)
   fonts/
     bold.ttf
     dungeon.ttf
     maidenword.ttf
     plain.ttf
   shaders/
     mask.vert
     mask.frag
   strings/
     (many txt string-list files)
 Scenario Editor/
   bladbase.exs
   Blades of Exile Character Editor
   BoE Scenario Editor
   graphics.exd/
     mac/
       cursors/
         (cursor gif files; the hotspots are currently hard-coded)
       (many png files)
   sounds.exa/
     (many wav files)

 

Of course, the scenario graphics files also need to be in the scenarios folder, whether they're BMP or PNG. Either should work correctly (if not it's a bug). I also want to get rid of the mac/ sub-directory of graphics.exd/, as the only purpose of that is to allow the user to switch between mac and win graphics (which differ in brightness/gamma), something I think might be better automated somehow. (After all, the Mac graphics are the original graphics, I'm pretty sure, and the Windows ones were derived from them.)

 

I think the current osx code expects bladbase.exs to be named "Blades of Exile Base", so if I haven't already you might need to tweak that. It should work for either name, since the Mac version called it that all along while on Windows it was always bladbase.exs.

 

You might also want to add a subdirectory to data/ to store menu definitions, unless you hard-code them or otherwise include them in the executable itself. In the Mac version, the xib files are compiled to a nib file that's stored in the application package.

[Nephil Thief]

Oy, this could turn into quite a task. Methinks I will attack it next weekend, when I have the time to throw some brainpower at it.

 

(Actually, does Linux have native file get/put dialogs in the X window system?)

 

No. Definitely not. X Window System only provides primitives, everything else is done with higher level widget toolkits; so if you want file dialogs, you have to make calls to GTK/Qt/Fltk/etc. so you might was well use one of those in the first place.

[Celtic Minstrel]

So we might need an additional dependency just on Linux... one possibility might be to try using GNUStep, which would mean less conversion of Mac code is needed, but I think SFML only provides an X window ID on Linux platforms, so if there's no way to get a GNUStep window reference from that, it would be kinda difficult to use GNUStep. (On the Mac you can get the Cocoa window reference from an SFML window, so there's no issue.) I did a quick search and didn't find anything promising on this topic.

 

I think using GTK or Qt is a bit much, considering that for most things I've basically got a custom GUI system based closely on the custom dialog engine Jeff himself wrote. You can look in tools/winutil.hpp(?) to see what windowing things are needed - besides modality and file dialogs, I think the only other things are making a window stay on top of other windows and making a window come to the front. We also need to be able to set the mouse cursor (I'd assume this counts as a primitive, though, and is available in X directly?). If any of those things (other than the file dialogs) are impossible with just the X window system, then we'd need to make sure to choose a library that can construct a window object from an already-existing window specified by an X window ID, since that's what SFML gives us to work with as a native window handle, as I recall. If the only thing we need an external library for is file dialogs, though, we could probably pick almost anything; I'd personally prefer something lightweight, but we could easily use GTK or something instead. (We could also write our own file dialogs, I suppose, but that's something I'd prefer to avoid if possible. While it has the slight advantage that they'd look the same on all platforms, it also has the slight disadvantage of giving them a non-native appearance, plus it'd probably end up being less flexible than the native file dialogs.)

[keira]

I would imagine using GTK as a dep on linux would be fine, since its pretty much a default install on any graphical distro. Not sure what that adds to the overhead, but its pretty safe to assume the average linux user has GTK already

[Celtic Minstrel]

Fair enough. Can it wrap an existing X window?

[Nephil Thief]

First off sorry for the slow response, last week was the work week from hell topped off with a head cold.

 

Fair enough. Can it wrap an existing X window?

 

I don't know, but a nagging voice in the back of my head tells me this might be impossible in X.

 

@sylae: please be aware that GTK2 is no longer developed, and GTK3 is considered an internal Gnome3 library and subject to API breakage with every major release. Qt4 (or is it 5 now?) might be an option, but it is extremely huge.

 

(And people wonder why the heck nobody uses Linux on the desktop.)

[Celtic Minstrel]

I'd rather have something more lightweight if all we're using it for is file dialogs. If you can make a window modal or stay-on-top with X, and force a window to the front with X, and attach menus to a window with X, that should be enough, I think. (I forgot to mention the menus before.)

 

I don't know, but a nagging voice in the back of my head tells me this might be impossible in X.

What might be impossible? Creating a window wrapper class around an existing window? That seems kinda unlikely... Or do you mean one of the above required tasks sounds like it might be impossible?

[Nephil Thief]

I'd rather have something more lightweight if all we're using it for is file dialogs. If you can make a window modal or stay-on-top with X, and force a window to the front with X, and attach menus to a window with X, that should be enough, I think. (I forgot to mention the menus before.)

 

That's all the province of either the widget toolkit or the window manager. X itself doesn't give you anything AFAIK (but I'm not a Linux desktop programmer so...)

 

What might be impossible? Creating a window wrapper class around an existing window? That seems kinda unlikely... Or do you mean one of the above required tasks sounds like it might be impossible?

 

Sorry, I thought you meant something completely different there. I know barely anything right now about the guts of GUI toolkits.

 

I think you should be able to extend a GTK window class (or whatever that is in GTK terminology). GTK is written in pure C though. Not sure how it handles inheritance.

[Celtic Minstrel]

Okay, fair enough. I've listed what we need, but I don't think it's necessary to create the window with SFML first and then wrap in in the GUI toolkit - SFML can construct a window object from an existing window (by X window ID), so a GUI toolkit that provides a way to get that ID would be fine; if necessary we could create the window with the GUI toolkit and then pass the ID on to SFML to finish the job. (This would only be necessary for the main window, I think, where we need menus, unless modality and stay-on-top is really difficult to implement without a GUI toolkit.)