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?

Originally Posted By: VCH Originally Posted By: Spidweb We are building up the energy to port our games to a new platform . . . - Jeff Vogel Interesting Probably a console port. That's the big thing nowadays. Originally Posted By: Spidweb All of our games, as far as I know, work on Wine. The number of Linux users who refuse to use Wine and who don't have another machine for gaming is a pretty thin slice of pastry. - Jeff Vogel I do use Wine, and I do have plenty of machines. But, I had been hoping (perhaps foolishly) that over the course of the years, you had been streamlining the dependencies of your game code to cross platform ones so that you could release a native Linux version fairly easily. Since Linux is what I use primarily, I generally prefer running games natively on Linux.

Is there a possibility that Avadon will be available for Linux? If so, when? If not, why?

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?

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?

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?

Originally Posted By: Cryolemon Originally Posted By: Thuryl ...unless we actually get the go-ahead to distribute the Exile series for free outright. And that seems unlikely. Actually. That doesn't. Given the current situation for the Exile series, he might actually permit it.

*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?

Originally Posted By: Cryolemon Originally Posted By: King InuYasha If it doesn't match what the file is for an unregistered version, it's likely to be registered, so that's all that has really has to be done then. The only problem there is that someone with a hex editor could just alter one byte of the shareware file to get around registering. You have to make sure it matches the registered misc.dat But wouldn't that be rather difficult given the varied keys used for registering?

Originally Posted By: Cryolemon Well, since all registration does is change the misc.dat file, you could get an unregistered version and a registered version, compare them and you'd know exactly what to check. We probably would need Jeff's permission for any of this though. If it doesn't match what the file is for an unregistered version, it's likely to be registered, so that's all that has really has to be done then.

Originally Posted By: w-dueck Ishad Nha seems to be able to pull info from the data files from the Exiles using mathey crap. I assume said mathey crap could be used by a modified BoE to load from--and convert--the data to be playable. However, I think this would mean that you could get around paying for the Exiles, since the registration is (?) done by the game, not the data. Thus, Jeff probably wouldn't approve of doing this. Well, there is an easy way around that. Figure out where the "valid" registration data is stored and use that to figure out if there is any registration data. If not, restrict to what the demo would be. Or, just not worry about it. The Exile series is not really playable anymore under 64-bit Windows (unless you use a VM of 32-bit Windows to run it), nor is it playable under current Macs. Jeff could probably chime in and give his approval. But, honestly, I don't think he cares. The games are quite old and they don't run under the latest versions of Windows that ship with most new PCs, since most PCs now come with 64-bit Windows, and OS X (Classic doesn't exist for Intel Macs).

Originally Posted By: Celtic Minstrel Yes, with some alteration of the BoE code and permission from Jeff. It would be similar to how Nethergate: Resurrection is based on the BoA engine: the same underlying engine would be the same, yes, but there would be differences in the engine as well (such as the spell sets). Why would you need Jeff's permission to support the original Exile games with the BoE engine? It's not like you are creating new distributions of Exile series. You could simply have it pull the data from the Exile games on install or runtime. Although, getting his permission is a good idea if you want to make packages with the game data included.

Couldn't the Blades of Exile engine be used to power the Exile games?

Originally Posted By: Celtic Minstrel Originally Posted By: King InuYasha How much of it has been ported to C++ then? A fair amount of it. However, the Windows version has different parts ported than the Mac version, and in a way incompatible with my mode of operation in the porting... so, I'm going to have to do something about that somehow. Originally Posted By: King InuYasha And while this is going on, are you planning on separating the platform-specific code out? In theory. I haven't really paid attention to it much so far, though. You might want to start comparing each file as you go and merge in the differences. Start bringing the codebase back to one set of files. I don't understand all the code very well, but I did run comparisons of files of the same name in osx and win32 folders and they are still largely the same. There are chunks that exist in one or the other, but most of it is identical.

Originally Posted By: Celtic Minstrel Originally Posted By: King InuYasha Porting to C# might not be a bad idea, No. I'm porting to C++. I do not want to go to C#. How much of it has been ported to C++ then? And while this is going on, are you planning on separating the platform-specific code out?

Originally Posted By: Almkaz Looking closer into the GPL license question, I think this idea is not allowed under the terms of use for the XBOX Indie Community program. It says clearly that one needs to own the IP rights for the game. The GPL is a license but obviously not ownership. I am not sure who owns IP rights for open source projects in general but it's not me as a user. Technically, under the GPL, the IP question isn't really that much to consider. The GPL only covers code. In the case of games, the IP rights would need to be considered for game data. As it is, I believe there are plenty of scenarios out there to use. One of them is possibly licensed under a content license that is compatible with the GPL (CC-BY-SA 3.0 is generally a good choice). The intellectual property clause is written to make sure that plagerizing games isn't somehow permitted. It is an important point, but in the case of Blades of Exile, it is moot.

Originally Posted By: Almkaz Hello, Thanks for all of the insightfull replies. Regarding the GPL licence, my understanding is the same as the King, in that I would have to provide a way to make the source available. I think porting to C# would be a big job for sure - one hope is that since they share the same root syntax, and the .NET framework has pretty good coverage for standard C library calls, that it would not be too overwhelming. The main deterrent for me seems to be the user input. Perhaps I should wait for a year to see how Project Natal works out - maybe I will get the freeform movement after all. Chomping at the bit to bring some nice deep RPGs to the console... Porting to C# might not be a bad idea, but porting it to XNA would likely not be worth it. XNA is a largely closed platform. It also isn't the only set of APIs in C# you can use for making games. Probably the best choices would be SDL and GTK# or wx.NET.

Originally Posted By: Lazarus. I don't really know too much about the developer's program, but unfortunately I believe it would be illegal. From what I've heard Microsoft has a big say in the prices on downloadables, and they definitely aren't in the business of distributing free open source programs. Selling BoE is illegal unless you're Jeff, so that kind of rules out Xbox live. It would be kind of cool to try to bring the game to such a wide audience, but besides the potential technical difficulties (which I can't really comment on), there's the issue of the xbox controller. Exile doesn't really lend itself to play without a mouse, or at least a keyboard. Managing the inventory, casting spells, dialog-- that would all be have to be overhauled or else it'd be pretty clunky. There are two misconceptions here: That free games cannot be published to Xbox Live, and that BoE cannot be sold by anyone except Jeff. First off, Microsoft DOES provide a way for regular people to publish games to Xbox Live. It is called the Creators Club. You must be a premium member of the Creators' Club though. Secondly, Blades of Exile CAN be sold by anybody. The GPL does not prevent that. The only restriction on distribution is that the source code must be provided and accessible. Binaries can be sold for any price point as long as source code is still available. However, you MUST indicate that it isn't an official Blades of Exile version because only Jeff Vogel can publish an official version. Either that or change its name entirely... In any case, Blades of Exile doesn't lend itself to being very portable to game consoles. Its design makes it very difficult to play under the restricted input of a game controller that has no form of freeform movement. Only the Wiimote has a method of freeform movement.

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

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

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.

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.

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.

Originally Posted By: The Almighty Doer of Stuff People tell me E3 for Linux is just Windows E3 with an old version of winelib attached to it, and is slower than just running Windows E3 in WINE. Exile 3 for Linux doesn't use Wine at all, that's why it is slower. It was developed by having a third party partially reimplement the needed parts of the Win32 API and then fuse the code. Running Exile 3 on Linux through Wine is faster, though it would be great if a Winelib binary could be made to replace the binary included in Exile 3 for Linux. Wine does support fusing with Win32 app source code to create Linux binaries supported with libraries that translate the Win32 API into Unix equivalent calls, however, not many applications take advantage of that.

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.