Celtic Minstrel

I haven't actually touched any code yet, just tweaked the lex.l file a little (to fix things like floor_shimmers), added a couple of lines to common.h (which were needed for it to compile with Visual Studio tools), and fiddled with makefiles. I think what that actually does is, normally it skips any file without a .txt extension, but with -a it checks those files too (if they're passed on the arguments list at least). So yes, the description could be clearer.

Okay, I uploaded a version that should fix the non-working *.txt. The issue with commas will need more investigation, I think. I suppose it could also be an issue with the version of bison or flex being used.

Hm, curious, your example works correctly on my Mac but fails on my Windows, just as you say... I wonder why that could be... Failing to open "*.txt" could be a result of trying to run it in a directory with no text files, maybe? I'm not sure if that last line of your post is a complaint or just a random observation.

Ishad Nha, I've uploaded another version to the same place that (theoretically) supports Windows XP. Try it and let me know it it works.

I dunno, is there an older version of VS Express around somewhere? Or you could try MinGW, or maybe even Dev C++. Or I could try to figure out how to build an XP-compatible binary, I suppose.

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.)

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.) 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?

It was built on Windows 7, so being on XP still could be something of an issue. You should be able to build the code yourself though. If you have some version of Visual Studio (including an express version, which can be downloaded for free) you should be able to build it from the console by something like this: "C:\Progam Files\MS Visual Studio\Common7\Tools\vsvars32.bat" nmake -f Makefile.win The exact path on the first line depends on where Visual Studio is installed, so you'd need to check that. You also need to have flex and bison installed (probably from the sourceforge link you mentioned) and accessible in your %PATH%, with the executable files named flex.exe and bison.exe. If on the other hand you're using MinGW, you should be able to just type "make" to build it. This should create an output file "alint" which you'd have to rename to "alint.exe". Again, you'll need flex and bixon install; I'm not sure if MinGW comes with versions of them, but if it doesn't, you'd need to install it, rename the executables, and put it in your %PATH%. As for how to add it to your %PATH%, try this.

Well, the four preset scenarios apparently use set_sdf, so I decided to guess it was valid.

Or even improve its error messages.

Okay, I fixed some of the minor errors in alint and uploaded new binaries here. I also put the source on github and created a makefile that works with the Microsoft compiler (this didn't take a lot of work). I ran the four preset scenarios through it; they seem to give quite a few errors, but I'm not sure if these are a problem with alint or actually a problem with the scenarios. Also, this version currently accepts both "set_flag" and "set_sdf" as correct, and also accepts both "print_big_str_num" and "print_big_str_color". I'm not quite sure if this is right/

Hm, I'm not getting errors on sanctitem.txt in The Za-Khazi Run... One more question - do set_flag and set_sdf both work correctly? (In the game, I mean.) Also, you still haven't answered this:

Ah, what I meant is that SANCTIFICATION_STATE is in the lex.l file... I'll double-check, maybe it was misspelled. How does print_big_str_num work, by the way? I don't see it in the docs. EDIT: When I said it accepts it as a number, I meant it accepts SANCTIFICATION_STATE to be valid and considers it to be a number.

You'd need a decompiler only if the special nodes were coded in C(++). Which probably isn't very likely. It's possible they're hard-coded as struct values though, in which case they wouldn't be accessible as resources.

So, only those four errors? (I'm ignoring the "unreported" section for now.) What should be the signature for print_big_str_num? (That is, the ssi type stuff.) Huh? What do you mean by this? It does accept SANCTIFICATION_STATE as a number...

Where's the source code, again? And is there a list of such errors? EDIT: Never mind the first one, found it on Kelandon's page. Also threw it up on github.

If it's in the executable it might be found with a resource editor?

Fair enough. Can it wrap an existing X window?

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.)

I tried it at one point and can confirm that Exile runs on Windows 3.1 under DosBox.

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. 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.) 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?) SFML doesn't handle text fields. I have a partial implementation in the dialogxml folder (in field.{c,h}pp). 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.

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...

You can think what you like, but that doesn't make it right. It's almost certainly not encrypted. It's encoded in a bonary format, which I think is what you really mean when you say "encrypted". However, it's not encrypted. Encryption is like the XOR effect applied to the BoE save files, a way of obfuscating the encoded data.

Yeah, it's not too hard with SFML. You can take a look at how I did it as well as the docs. I think I'm currently using the Windows WAV files on the Mac side.

I want to get away from using a dll for sounds on the Windows side, in favour of having all the sound files in a folder. That'll make this sort of thing much, much easier to do.