King InuYasha

Quote: Originally written by Miramor: It would be nicer if the site had some decent bandwidth. Ehh, I got what I could. At least I have a lot of space...

Quote: Originally written by DarkTreader: King, I understand and agree with your sentiment, but at this point you might be pushing a wee bit too hard. Jeff began on a mac, so he too understands your sentiment. However, spiderweb has spoken right now. In situations like this, it's better to politely state your arguments up front, be very magnanimous, and step back. Continuing to push your point after they already said no is going to just make people annoyed. In the future I recommend a polite email, expressing your interest in buying a linux copy, briefly lay out your facts, then ask all of your friends to do the same. This will show spiderweb the demand in a Linux version. If it's in the cards, it will happen in a future avernum release. Very well.... I'll cool it.... for now.....

While what I am doing does not use the Mac sources (as I have only a little idea on how Windows sources work, much less Mac ones...), I have figured out a way to determine which parts of Blades of Exile need porting from Win16 to Win32. Simply put, Winelib can parse the sources and attempt to build them. Winelib does not suppport anything the Win32 API does not support, and thus the parts of the Win16 API dropped from the Win32 API are given back as errors, stopping the build. BoE game source: Code: wineg++ -c -mno-cygwin -I. -o actions.o actions.cppglobal.h:447: error: expected unqualified-id before ‘short’global.h:447: error: expected `)' before ‘short’global.h:447: error: expected `)' before ‘short’global.h:447: error: expected `)' before ‘short’global.h:448: error: expected unqualified-id before ‘short’global.h:448: error: expected `)' before ‘short’global.h:448: error: expected `)' before ‘short’global.h:448: error: expected `)' before ‘short’graphutl.h:3: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:4: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:6: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:7: error: expected initializer before ‘*’ tokengraphutl.h:10: error: expected ‘,’ or ‘...’ before ‘*’ tokenactions.cpp: In function ‘void check_cd_event(HWND__*, UINT, UINT, LONG)’:actions.cpp:1511: error: ‘MAKEPOINT’ was not declared in this scopeactions.cpp: In function ‘void flash_rect(RECT)’:actions.cpp:1571: error: ‘SetViewportOrg’ was not declared in this scopeactions.cpp: In function ‘void flash_round_rect(RECT, short int)’:actions.cpp:1603: error: ‘SetViewportOrg’ was not declared in this scopeactions.cpp: In function ‘Boolean handle_keystroke(UINT, LONG)’:actions.cpp:1829: error: ‘GFSR_USERRESOURCES’ was not declared in this scopeactions.cpp:1829: error: ‘GetFreeSystemResources’ was not declared in this scopeactions.cpp:1832: error: ‘GFSR_GDIRESOURCES’ was not declared in this scopewinegcc: g++ failedmake: *** [actions.o] Error 2 PC editor: Code: wineg++ -c -mno-cygwin -I. -o bladpced.o bladpced.cppglobal.h:447: error: expected unqualified-id before ‘short’global.h:447: error: expected `)' before ‘short’global.h:447: error: expected `)' before ‘short’global.h:447: error: expected `)' before ‘short’global.h:448: error: expected unqualified-id before ‘short’global.h:448: error: expected `)' before ‘short’global.h:448: error: expected `)' before ‘short’global.h:448: error: expected `)' before ‘short’graphutl.h:1: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:2: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:5: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:6: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:7: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:8: error: expected initializer before ‘*’ tokenbladpced.cpp:171: error: ‘_export’ does not name a typebladpced.cpp:174: warning: ‘__stdcall__’ attribute only applies to function typesbladpced.cpp:174: error: ‘int WinMain’ redeclared as different kind of symbol/usr/include/wine/windows/winbase.h:2386: error: previous declaration of ‘int WinMain(HINSTANCE__*, HINSTANCE__*, CHAR*, int)’bladpced.cpp:174: error: ‘hInstance’ was not declared in this scopebladpced.cpp:174: error: ‘hPrevInstance’ was not declared in this scopebladpced.cpp:175: error: ‘lpszCmdParam’ was not declared in this scopebladpced.cpp:175: error: ‘nCmdShow’ was not declared in this scopebladpced.cpp:180: error: expected unqualified-id before ‘{’ tokenwinegcc: g++ failedmake: *** [bladpced.o] Error 2 Scenario Editor: Code: wineg++ -c -mno-cygwin -I. -o blscened.o blscened.cppglobal.h:352: error: expected unqualified-id before ‘short’global.h:352: error: expected `)' before ‘short’global.h:352: error: expected `)' before ‘short’global.h:352: error: expected `)' before ‘short’global.h:353: error: expected unqualified-id before ‘short’global.h:353: error: expected `)' before ‘short’global.h:353: error: expected `)' before ‘short’global.h:353: error: expected `)' before ‘short’tfileio.h:9: error: variable or field ‘make_new_scenario’ declared voidtfileio.h:9: error: ‘Str255’ was not declared in this scopetfileio.h:9: error: expected primary-expression before ‘short’tfileio.h:9: error: expected primary-expression before ‘short’tfileio.h:9: error: expected primary-expression before ‘short’tfileio.h:10: error: expected primary-expression before ‘short’tfileio.h:10: error: initializer expression list treated as compound expressiontfileio.h:36: error: variable or field ‘flip_rect’ declared voidtfileio.h:36: error: ‘Rect’ was not declared in this scopetfileio.h:36: error: ‘s’ was not declared in this scopegraphutl.h:3: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:4: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:6: error: expected ‘,’ or ‘...’ before ‘*’ tokengraphutl.h:7: error: expected initializer before ‘*’ tokengraphutl.h:10: error: expected ‘,’ or ‘...’ before ‘*’ tokenblscened.cpp:154: error: ‘_export’ does not name a typeblscened.cpp:157: warning: ‘__stdcall__’ attribute only applies to function typesblscened.cpp:157: error: ‘int WinMain’ redeclared as different kind of symbol/usr/include/wine/windows/winbase.h:2386: error: previous declaration of ‘int WinMain(HINSTANCE__*, HINSTANCE__*, CHAR*, int)’blscened.cpp:157: error: ‘hInstance’ was not declared in this scopeblscened.cpp:157: error: ‘hPrevInstance’ was not declared in this scopeblscened.cpp:158: error: ‘lpszCmdParam’ was not declared in this scopeblscened.cpp:158: error: ‘nCmdShow’ was not declared in this scopeblscened.cpp:163: error: expected unqualified-id before ‘{’ tokenwinegcc: g++ failedmake: *** [blscened.o] Error 2 I would have preferred -Wall switch enabled, but that's too much pain at once.... Apparently, the code is C++, here I thought it was C when i glanced at the Mac vs Win16 sources and saw how similar they were... Hey, at least it's progress... These files are being built using autogenerated makefiles from Winemaker. By no means is Winelib a substitute for a genuine native port to Linux. It is merely a stopgap development measure. Note: Pushed fix in filename to Mercurial repository....

Quote: Originally written by Thuryl: Quote: Originally written by King InuYasha: If the game you are referring to is Exile III for Linux Blades of Avernum, actually. Not a Linux port, just a game with disappointing sales. It makes me wonder though, how well did Exile III for Linux sell? Note for anyone reading the PDF I linked to in my previous post, there are a few SDL addon libs for Audio, in particular, SDL_mixer and SDL_sound. SDL_sound is the one created by Loki though, and supports a wider range of formats and features. In any case, the recommended compressed audio format for games is Ogg Vorbis. Edit: Wow, I'm on a roll! I found a PDF on Cross Platform GUI Programming with wxWidgets ! To those reading this PDF, apparently there is errata regarding this eBook .

Quote: Originally written by Thuryl: Quote: Originally written by King InuYasha: The problem is that it is a circular dependency (hehe, software developer term). If no one takes the plunge, others will not follow. Generally, smaller companies would be in a better position because they don't have bureaucrats controlling them as much, telling them what they can and cannot do. It is those companies that start trends. Smaller companies also doesn't have the money to absorb big losses. Jeff has said before that he's not in a position to take risks. In the past, he's nearly been sent out of business by a single game that didn't sell as well as expected. I don't think any of us wants to see that happen. That is true. However, if Jeff were to incorporate use of cross-platform libraries, a Linux binary would merely be a recompile away. Being able to build from one codebase four different targets (Darwin/x86, Darwin/PPC, Windows/x86, Linux/x86_32) is a mighty thing. When Jeff plans to port from the Mac OS X version to Windows, instead of choosing to use Windows native APIs, he could choose to port to cross-platform APIs, which provide him the ability to simply rebuild his code to make it work on different platforms. Additionally, if future games would designed with cross-platform APIs, he could reduce his work time to build for his needed targets. If the game you are referring to is Exile III for Linux, its because he outsourced to someone else who I suspect didn't do a complete port, but rather wrapped the code using something like Visual MainWin. MainWin ports are generally not very good, and are considered merely stopgap measures to full native portings. Note: Darwin/x86 and Darwin/PPC are Mac OS X/x86 and Mac OS X/PPC respectively. Darwin is the official GCC target name. Windows/x86 official target name is mingw32, since Windows is a registered trademark of Microsoft, and all the other things we don't really want to get into.. Quote: Originally written by *i: I impart with you the wisdom that change begins on the individual level. If you feel strongly about this matter, start your own company and sell games to a bunch of platforms. Be part of the solution rather than asking others to. Yes, for that I am attempting to re-learn C++. I am hoping to try to port BoE to Linux using open source technologies. First step obviously is to get the Win16 code to work on Win32, but I can't find any resources on Win16 => Win32 porting, so for the moment, I'm looking for resources on using SDL and wxWidgets in apps. Hopefully something will turn up or someone can suggest some material I can read. Edit: Just found this nice PDF on Linux Game Programming that focuses on SDL and OpenAL. This will definitely be useful....

Quote: Originally written by *i: The issue is, regrettably, one of money. Fortunately a port from OS X to Linux is, in general, not too bad. However, time being money and these games being Jeff's source of income, there have to be priorities of releasing new games versus capturing the Linux users, which are (at current) a small market share. Personally, I would love to see the Linux community grow so that it becomes a more business viable focus for software companies. The problem is that it is a circular dependency (hehe, software developer term). If no one takes the plunge, others will not follow. Generally, smaller companies would be in a better position because they don't have bureaucrats controlling them as much, telling them what they can and cannot do. It is those companies that start trends. Case in point, id Software. id Software was one of the first companies to make truly 3D game engine. They pretty much made Linux a possible gaming platform by releasing every game they made for Linux (though not always at the same time). Consequently, Loki Software (now defunct unfortunately) was able to garner some business in porting games to Linux, and all the tools they created to ease the porting efforts were released as open source (SDL, Loki Setup). Today, the chief porting man of the Linux world is Ryan Gordon, known for the icculus.org projects and the one who handles the Linux porting project of Unreal Tournament and quite a few others. He is also rewriting the Loki installer to be cross platform and much more sophisticated as well as less error prone. The name of it is MojoSetup. Currently it has support for CLI, GTK2 Linux, and support for Windows and Mac OS X is in the works. As more commercial games show up for Linux and begin to succeed, major companies will take notice and go forward. Unfortunately, there is a flip side to this. Consumers will not use Linux unless there are game titles that they enjoy to play, and companies will not make them unless there are Linux users asking for them. Unless smaller companies start making their games available for Linux alongside whatever platforms they currently support, there will be no change among the larger companies, and thus few commercial games on Linux, and finally keeping people from taking the plunge to use Linux.

I do wish to see a Linux port of the game. The time is ripe too.... With the resurgence of the Linux desktop, and more businesses using it in corporate environments and the work people seeing it and trying it out at home, Linux will gain a foothold. Also, Windows Vista hasn't been doing so well... Already with all the other advancements in propagation of Linux to the masses (Dell selling Ubuntu PCs, Everex and ASUS low cost machines, etc.), Spiderweb Software should rethink their position about Linux games. Anyone who says that the games always work fine under Wine are crazy. The latest versions of Wine + any of the Exile and a few of the Avernum games = borked up screen and sound. Sound is easily fixed with driver emulation, but screen issues... Also it is a very weak excuse to not support Linux natively when there are very powerful cross-platform toolkits that can be used for game development (SDL, OpenAL, wxWidgets, MinGW, Code::Blocks, wxFormBuilder, etc.), and all these tools work on Linux, Windows, and Mac OS X. I just hope Spiderweb reconsiders it for Avernum 5. Now that would be sweet for Linux.

I liked Exile III the best. It was well designed, in my opinion more so than the other two, and kept me busy longer.... It also helped that when I made my switch to Linux, I could take Exile III with me. Given that I only played the demo because my wallet was already hurting at the time, I feel bad that Spiderweb Software became discouraged and demoralized about making Linux games. With the resurgence of the Linux desktop, and more businesses using it in corporate environments and the work people seeing it and trying it out at home, Linux will gain a foothold. Also, Windows Vista hasn't been doing so well... Already with all the other advancements in propagation of Linux to the masses (Dell selling Ubuntu PCs, Everex and ASUS low cost machines, etc.), Spiderweb Software should rethink their position about Linux games. Anyone who says that the games always work fine under Wine are crazy. The latest versions of Wine + any of the Exile and a few of the Avernum games = borked up screen and sound. Sound is easily fixed with driver emulation, but screen issues... Also it is a very weak excuse to not support Linux natively when there are very powerful cross-platform toolkits that can be used for game development (SDL, OpenAL, wxWidgets, MinGW, Code::Blocks, wxFormBuilder, etc.), and all these tools work on Linux, Windows, and Mac OS X. I just hope Spiderweb reconsiders it for Avernum 5. Now that would be sweet for Linux.

Quote: Originally written by Tyranicus: Quote: Originally written by Andrea: GF4 probably requires at least Windows 2000 because (and this is a guess) it probably needs a version of DirectX not supported on previous iterations of the operating system. I highly doubt this, since DirectX 9.0c is available for 98 and ME, and DirectX 10 is only available on Vista. However, there are incompatibilities between the 9x and NT versions of DirectX, intentionally in order to make more people move to the NT platform. The reason why DirectX 9 was even supporting the 9x platform is because at the time, the big game developers had a significant 9x userbase. However, that changed very quickly after most of the 9x series lost support from Microsoft. The big game developers could no longer hold onto that claim, and were pretty much forced to move on.

Quote: Originally written by Celtic Minstrel: I don't know whether this matters at all to you, but Khoth has a darcs repository for the Mac source. The only reason I say this is that it might make sense to keep them both in the same type of repository. Also, two Google code projects have been created – one is called oboe, the other blades-of-exile. If the creators of those projects were contacted, and you had a Google account, the source could be moved to their repository. (I think it's Subversion?) These are just suggestions. Follow them or ignore them as you please. I'm currently trying to get the Mac character editor to work, and making very little progress. Part of my problem is that, like you, I don't really understand all the API functions (in my case, the Carbon API). It would probably be simpler (and messier in some sense) if the Mac version switched to a file system more like the Windows version, where each graphic is in a separate file. You could make it look neater though – on the Mac these files could probably be hidden inside a file package (a folder that is treated like a file); on Windows they could perhaps be zipped or something (this would require using zlib though, or something similar). Maybe someone should do a comparison of the Mac and Windows source to determine which parts are identical. It would be nice if this were to finally start to progress again. While I do remember about those, I do have a Google account, but I do not wish to use Google's rudimentary system. I didn't want to use SF because of its extremely limited support of DVCSes. And I have worked with a project before using a DVCS. Personally, I find darcs to be lame, and besides, that codebase is for Mac. Most people haven't made a VCS version of the Windows version. Anyways, my tree is in a Mercurial repository for two reasons: 1) Because I always seem to lose track of my files 2) I wanted to allow others to see my tree help contribute to it. The website is here . At the website you can find links to various parts of the project, including the source. Anyone that does want to help with this effort, which would be greatly appreciated, merely register at sharesource.org and send king_inuyasha a private message there requesting developer level access. Also, I would like to know what your skills are in the message. Mac, Linux, and Windows developers are all welcome.

Quote: Originally written by Celtic Minstrel: I wonder – is there anyone who has access to both a Mac and a Windows compiler? Because porting to SDL (and possibly, as someone suggested, wxWidgets?) is probably a good idea, but would ideally (I think) be done in parallel on the Mac and Windows sources. The GNU compilers are the official ones for Mac and Linux, and also available for Windows. It is also the compiler my sources are being tuned for. Specifically, I am using the MinGW GCC 4.2.1-sjlj-2 tech preview version. I'm hoping once I figure out what the heck I am supposed to do, I will set up a Mercurial repository and allow people to work on the sources as well. And I was the one who suggested wx and SDL. I am also pushing for consolidation of the codebase to one tree, so that it is easier to maintain. If there are Mac and Windows developers interested in consolidating the codebases while providing native apps for their respective platforms, I would implore them to help me here, because I am a novice programmer, and I don't really know how to do the complex porting required to move code from raw APIs to encapsulated cross platform APIs. My goal is to try to move sound from MMSystem to SDL because that seems the simplest right now.

Quote: Originally written by Celtic Minstrel: Feel free to redo it. Ormus has not read my message yet, so he either doesn't check his email often or has disabled email notification of private messages. There's not much more that can be done, really. I'm actually attempting to do it. Given that this is my first major C++ project since I designed a tiny math program for a science fair project, I'm having to relearn C++ and find materials on porting from Win16 to Win32. Hopefully, I can additionally ease platform porting by porting some of the interfaces to SDL at the same time. I have also reorganized the source tree to a more logical format so there is no recursive path searching in the sources.

Quote: Originally written by Celtic Minstrel: Quote: Originally written by Arenax: I'm ripping apart the source code in an attempt to port it to C# Please, no C#! This is originally a Macintosh game, and C# is basically a Windows programming language. It needs to run on both platforms. Quote: Originally written by Thomas Frost: Is there any compiled registed version for windows? 16 bit will do Ormus had a Win32 release. Check out this thread . C# will work on Mac OS X AS LONG AS it is Mono compatible. And Ormus's release functions as if it was unregistered.

Quote: Originally written by Celtic Minstrel: I just sent him a private message about this. If he hasn't been checking the forum recently, then hopefully he has opted to be notified by email upon recieving a PM. Really all we can do about this is wait, I think. The question now is, how long should we wait before we assume we need to redo the porting process to relicense it? Should we really wait? It has been quite a while since it was announced the change to GPLv2, and BoE/win32 is stagnant since then. Perhaps it should just be redone.

If Ormus has vanished, doesn't that mean that the Win32 version he made is going to get stuck as CPL? That would mean that someone else would have to re-port the whole game to Win32 to get it under GPLv2 licensing.

Quote: Originally written by Celtic Minstrel: Well, I decided to add it to the list in my first post. But I don't think OS integration is a priority here - the game uses a custom dialog engine, so the only titlebars will be OS dependent. (The game window and the map window titlebars). Although I've noticed that on Windows the dialogs also have titlebars. Well, the wx stuff would let you get the native Mac OS X UI you want, and the SDL library is important because of the the custom interfaces used in the game. Obviously you cannot use wx for the dialog engine, so SDL would be the logical choice there. This kind of port would make having a separate Mac and Windows codebase pointless since one codebase can build for all the targets. Essentially you modernized the Win32 code, while also providing native Mac OS X support and gaining Linux support. It seems like I am reiterating, but I am stressing what I would consider very important to the road on getting the game fully working on OS X and Windows as well as Linux. Plus, having one codebase would definitely be easier to manage than having two or three separate ones, eh? Here is a link to a page on combining SDL with wxWidgets .

Quote: Originally written by Miramor: Porting it all to wxWidgets would be the best way to go, I guess. I'd be a bit weary of using both SDL and OpenAL though. I'm not speaking as a programmer here, so I could have the wrong idea, but use of both for sound (in one way or another) caused enormous problems for Vega Strike , with sound mixing not working and stuff. Well, I don't think this particular game would have any benefit from OpenAL. I just put that out there as information. I think SDL would still be needed for some of the custom output, unless you were to use wxUniversal (if it is possible to make wxUniversal use those bitmaps). But the problem with wxUniversal is that it looks ugly on all platforms. wxNative (which is what I call the standard toolkit) is better because it integrates with GTK, Aqua, and Win32 + native theming. For those people who use KDE, GTK will look like KDE apps when running under the KDE DE in certain distros (Fedora, SUSE, Mandriva, etc.) but not in others by default (Debian, Ubuntu, etc.)

The game itself still says it is shareware, while it is really CPL?/GPL? and it needs to be fixed to lessen confusion. Also, maybe if the sources were ported to use SDL and wxWidgets, we could get three birds in one stone? wxWidgets supports native UIs for Mac OS X, Linux, and Windows. SDL is a graphics, audio, and input library that works natively on Windows, Linux, and Mac OS X. I doubt we will need this, but for the sake of showing it, there is OpenAL, which is a cross-platform audio layer which has the ability to use "3D sounds" (EAX, etc.)

I wonder though, would it be possible for a native Linux port to be created? I think that would be great to see for the game!