edit: unabbreviated title in topic!
[ September 22, 2006: Message edited by: Toady One ]
edit:The code compiles and it plays the title song, just doesn't display anything.
[ October 11, 2006: Message edited by: jerkloaf ]
code:
SDL_SetVideoMode(600, 600, 16, SDL_OPENGL|SDL_RESIZABLE);
Then you can just use standard OpenGL functions inside the event handling loop. I might have missed something. I didn't look at it very closely. There are lots of short samples floating around though.
Note:These are just the updated source files. You'll need to download SDL and add it to your library/header include directories. enabler.cpp will link sdl.lib and sdlmain.lib assuming you have them.
[ October 11, 2006: Message edited by: jerkloaf ]
[ October 11, 2006: Message edited by: jerkloaf ]
(1) The horrifically huge case-statement with all the windows-specific key-codes. Changing those to SDL key codes is mostly a mechanical task, although there are a few places where they don't match up perfectly.
(2) the main program loop.
(3) various windows data types are used throughout, and need to be typedef'd (or avoided) on systems that don't have them.
I did most of (1) and some of (3). I've been too busy to even think about (2).
But I really want to be able to play DF on OS X. How much do I have to raise in donations to convince you to just do it? :-)
[ October 17, 2006: Message edited by: peterb ]
quote:
Originally posted by peterb:
(3) various windows data types are used throughout, and need to be typedef'd (or avoided) on systems that don't have them.
Which ones, exactly? The only problems I encountered when ripping out windows.h were with files.cpp, game.cpp and enabler.cpp. files needs to be rewritten and so does enabler, but game.cpp just has a MsgBox that needs to be taken out. Of course, I didn't try to compile it on any other systems but I don't recall seeing any windows-specific stuff.
[ October 18, 2006: Message edited by: jerkloaf ]
[ October 18, 2006: Message edited by: jerkloaf ]
#ifndef MAC
#define MAC 1
#include <SDL_keyboard>
#define TRUE 1
#define FALSE 0
typedef unsigned int DWORD;
typedef int WORD;
typedef int BOOL;
typedef int32_t LONG;
typedef int64_t LONGLONG;
typedef int32_t HINSTANCE;
typedef void* HANDLE;
typedef union {
struct {
DWORD LowPart;
LONG HighPart;
};
struct {
DWORD LowPart;
LONG HighPart;
} u;
LONGLONG QuadPart;
} LARGE_INTEGER;
typedef struct tagBITMAPINFOHEADER{
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER, *PBITMAPINFOHEADER;
#define VK_F10 121 // Magic!
#endif /* MAC */
X
quote:
Originally posted by X:
<STRONG>But those are only for the windows-specific bit that needs to be chopped out anyway, right? Don't need to spec BITMAPINFOHEADER at all if you're using SDL as it has all its own image loading routines, etc.X</STRONG>
Perhaps, although if the goal is to create something Toady could easily integrate into DF proper, it would probably be best to keep these kind of checks, at least at first.
At the moment you can get to the main game screen, but that's about it as the keyboard input handling still needs doing properly. And texture transparency isn't done yet - everything's very pink.
code:
~/Desktop/kobold$ make
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/adventurer.o mysource/adventurer.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/basics.o mysource/basics.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/cave.o mysource/cave.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/command_line.o mysource/command_line.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/critter.o mysource/critter.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/definition.o mysource/definition.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/graphics.o mysource/graphics.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/kobold.o mysource/kobold.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/music_and_sound.o mysource/music_and_sound.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/random.o mysource/random.cpp
mysource/random.cpp:103: warning: this decimal constant is unsigned only in ISO C90
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/unit.o mysource/unit.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/game.o mysource/game.cpp
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/enabler.o mysource/enabler.cpp
mysource/enabler.cpp: In member function ‘void enablerst::add_gennum_tile(long int, double, double, double, double, char)’:
mysource/enabler.cpp:1525: warning: converting to ‘long int’ from ‘double’
mysource/enabler.cpp:1526: warning: converting to ‘long int’ from ‘double’
mysource/enabler.cpp:1527: warning: converting to ‘long int’ from ‘double’
g++ -I/usr/include/SDL -D_REENTRANT -DNO_FMOD -c -o mysource/interface.o mysource/interface.cpp
mysource/interface.cpp: In member function ‘bool interfacest::handleEvent(SDL_Event&)’:
mysource/interface.cpp:863: error: jump to case label
mysource/interface.cpp:857: error: crosses initialization of ‘interfacekeyst* iks’
mysource/interface.cpp:867: error: jump to case label
mysource/interface.cpp:857: error: crosses initialization of ‘interfacekeyst* iks’
mysource/interface.cpp:871: error: jump to case label
mysource/interface.cpp:857: error: crosses initialization of ‘interfacekeyst* iks’
mysource/interface.cpp:875: error: jump to case label
mysource/interface.cpp:857: error: crosses initialization of ‘interfacekeyst* iks’
make: *** [mysource/interface.o] Error 1
-it assumes that you have the Linuxy sort of install of SDL in the /usr/local tree.
-it reaches in to the system openGL framework for includes and libraries, which is vaguely obscene.
but, on the up side, it only took me about 10 minutes to roll it up from popecharlotte's tarball.
I also added a few casts in places where we were passing unsigned int pointers to interfaces that really want a GLuint pointer.
unified diff: http://www.tleaves.com/kobold/kobold-mac-diff
source tarball: http://www.tleaves.com/kobold/kobold-mac.tgz
When I have time i'll try to create an Xcode project for this so it can be made into a "real" app.
[ October 19, 2006: Message edited by: peterb ]
[ October 19, 2006: Message edited by: peterb ]
For now, the "data" directory has to be manually put in the same directory as the app. Eventually what should happen is it should just keep and load that stuff from the bundle, but I'm too lazy to do it tonight.
New version can be found here.
-The mouse does not change to the kobold pointer.
-In the cave name section, several keys do not produce any letters. Alphanumerics not appearing are: "cdegikpqst0123456789"
-All letters that are produced are lower case, regardless of caps lock and shift.
-Once the game starts, you can mouse-click between kobolds, but the number keys don't move them. (My laptop lacks a numberpad, so I can't check that.) Period also does not cause time to pass.
-The key-binding menu in options will not accept any input to change the controls.
Seems to work -- I get music, sound, and keyboard input, although the keybindings are tragic for mac users (many of us don't have numeric keypads, especially on laptops).
I was unable to change any keybindings, as per the earlier report.
Note that I did nothing to the source to make this compile -- I just took popecharlotte's last source drop and copied the files in. The only tweaks I made were to the project file.
I've uploaded new binary and source packages. If someone with a mac could download the binary and let me know that it works for them, that would be great.
src: http://tleaves.com/kobold/KoboldQuest-src.tgz
binary: http://tleaves.com/kobold/KoboldQuest.tgz
[ October 20, 2006: Message edited by: peterb ]
#ifdef MAC
#include <zlib>
#else
#include "zlib/zlib.h"
#endif
Thanks.
Still, this is exciting, and I'm grateful to everyone who's been working on the ports- this is closer than anyone's come so far, and I'm sure it won't take much more to work out the bugs. The dream of Mac and Linux versions of Dwarf Fortress may come true yet...
Source code here:
http://tleaves.com/kobold/KoboldQuest-src.tgz
No source code changes needed to make it compile.
One heads up for the future: it's pretty clear to me that the save file format is super-unportable. You might want to think about that as an area to work on, although it's obviously not a top priority. (In fact, it was the fact that I accidentally packaged the save file with the binary that hosed me on last week's build).
[ October 30, 2006: Message edited by: popecharlotte ]
It sounds like you got it working on more than one machine, so this might be just some weird conflict with something on my computer. I might try it on a couple of other Macs later and see how it does on those...
What would be super-helpful to me would be if you could open the console application, run the game until it crashes, and then copy the output of the console to me in an email. You can send it to peterb - a t - gmail d o t com.
Thanks! And yes, I've gotten confirmation that it runs on at least two machines now. That certainly doesn't mean there aren't still bugs.
(and just to make sure: you threw out the old folder and completely replaced it with the new one, right? The issue in the old folder is that it had a save file generated on my machine, and I suspect endianness issues).
Wow almost one month gap between these last 2 posts. I don't use a mac but a cafe I like to go to only has two imacs, and I would love to play some DF there. I could probably get at least 5 people hooked (its a comics cafe, tons of nerds there).
code:One easy way to see int as 4 bytes LE.Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack("i",7)
'\x07\x00\x00\x00'
X
and their reverse after loading
ntohl
ntohs
See also here: http://www.penguin-soft.com/penguin/man/3/byteorder.html
I'm not sure I understand the sizeof issues as well - is this to do with 32/64bit compatibility or something else?
And more importantly, i have one!
:-)
-p
Those functions are in winsock.h on windows, and on linux/macs:
code:#include <sys>
#include <netinet>
#include <inttypes>
Essentially what you would need to do is:
When reading a 32-bit variable from the save files: fread it, then ntohl it.
When writing a 32-bit variable to the save files: htonl it, then fwrite it.
For 16-bit variables use ntohs and htons instead.
For 8-bit variables, you don't need to do anything. (Endianness is the order of bytes in words (16 bit / 2 bytes), dwords (32 bit), etc, so a big-endian 8-bit variable would be the same as a little-endian one)
If you have ASCII (one byte per character) strings being written, you shouldn't have to do anything to them either. But if they're being written in unicode, maybe you would.
That may probably break compatibility with old save files, however.
Alternately, you try can hackish things to determine whether the system is little-endian or big-endian: Set a short (16-bit) to 0x0001, and then cast it to a two-byte char array, and check to see whether it's index 0 or 1 which is 0x01. Then you can just have a custom byte-swapping function being called which only does anything if the endianness of the platform doesn't match the endianness on the save files. This would preserve compatibility with old save files, and would make them work on machines with different endianness. (First you'd need to do the above test on the PC to see where the 0x01 is, then code it to enable the byte-swapper only if the 0x01 is in the other byte instead)
I'm assuming the compiler won't be so smart that it swaps the bytes around. I've seen them do some annoyingly smart things from time to time, though... So if the 0x01 appears to be in the same place on both little-endian and big-endian systems, then you know that won't work (ntohl etc should still work then though).
P.S. The reason ntohl etc are in network sockets libraries, is that they were created because networks (like the internet) needed a platform-independent protocol, as no network node could be expected to know the endianness of other arbitrary nodes.
P.P.S. You can manually swap bytes by doing something like this:
code:integer fooSwapped = ((foo&0xff)<<24)+((foo&0xff00)<<8>>8)+((foo&0xff000000)>>24);
[ December 11, 2006: Message edited by: SL ]
I did modify the basic read and write code to load and write files as little endian therefor it should maintain compatability.
code:// This will modify read_file and write_file
// to save and load all data in little endian notation.const static char BIG_ADDE[2] = { 0xAD, 0xDE };
char file_compressorst::read_file(void *read_var,long read_size,bool raw)
{
//---------------SNIP1
// {raw} is an endian dependant type if trueunsigned short ELVIS=*(unsigned short *)BIG_ADDE;
bool BIG_ENDIAN=(ELVIS!=0xDEAD);bool endianSwap=!raw; // endian swap if it is not going to read in the data raw (i.e. strings)
if(!raw)
{
else if(BIG_ENDIAN)
{
// swap if big endian
endianSwap = true;
}
}
//---------------SNIP1if(h==INVALID_HANDLE_VALUE)return 0;
//NOW LOAD INTO read_var UNTIL DONE
while(read_size>0)
{
//GET A BUFFER IF NECESSARY
if(in_buffer_amount_loaded==0||
in_buffer_position>=in_buffer_amount_loaded)
{
if(!load_new_in_buffer())return 0;
}//BAIL IF STILL NO BUFFER LEFT
if(in_buffer_amount_loaded==0)return 0;//SET THE AMOUNT TO COPY
long copy_size=in_buffer_amount_loaded-in_buffer_position;
if(read_size<copy_size)copy_size=read_size;//COPY
//memmove(read_var,in_buffer+in_buffer_position,copy_size);
//---------------SNIP2
char *data = (char *)read_var;
if (endianSwap)
{
for (long read=0;read<copy_size;read++)
{
// read in reverse
data[read_size-read-1]=in_buffer[in_buffer_position+read];
}
}
else
{
for (long read=0;read<copy_size;read++)
{
data[read]=in_buffer[in_buffer_position+read];
}
}
//---------------SNIP2read_var=((char *)read_var) + copy_size;
read_size-=copy_size;
in_buffer_position+=copy_size;
}
return 1;
}char file_compressorst::write_file(void *write_var,long write_size,bool raw)
{
//---------------SNIP3
// {raw} is an endian dependant type if true
// this does not have backwards compatability because it really isn't necessaryunsigned short ELVIS=*(unsigned short *)BIG_ADDE;
bool BIG_ENDIAN=(ELVIS!=0xDEAD);bool endianSwap=!raw; // endian swap if it is not going to read in the data raw (i.e. strings)
if(!raw)
{
if(BIG_ENDIAN)
{
//swap if big endian
endianSwap = true;
}
}
//---------------SNIP3if(h==INVALID_HANDLE_VALUE)return 0;
//WRITE OUT THE VARIABLE CHUNK BY CHUNK
while(write_size>0)
{
//FLUSH THE BUFFER IF NECESSARY
if(in_buffer_amount_loaded>=in_buffersize)
{
if(!flush_in_buffer())return 0;
}//SET THE AMOUNT TO COPY
long copy_size=in_buffersize-in_buffer_amount_loaded;
if(write_size<copy_size)copy_size=write_size;//COPY THE NEXT CHUNK INTO THE BUFFER
//memmove(in_buffer+in_buffer_amount_loaded,write_var,copy_size);
//---------------SNIP4
char *data = (char *)write_var;
if (endianSwap)
{
for (long write=0;write<copy_size;write++)
{
// read in reverse
in_buffer[in_buffer_amount_loaded+write]=data[read_size-read-1];
}
}
else
{
for (long write=0;write<copy_size;write++)
{
in_buffer[in_buffer_position+write]=data[read];
}
}
//---------------SNIP4write_var=((char *)write_var) + copy_size;
write_size-=copy_size;
in_buffer_amount_loaded+=copy_size;
}return 1;
}
And for reading an endian important data type (short, int, long) is:
read_file(&var,sizeof(long));
You must call:
read_file(&var,sizeof(long),false);
Similar for writing.
I'm unsure if floating point numbers are endian independant or not.
[ December 11, 2006: Message edited by: Jifodus ]
At the moment it byte-swaps the data coming in to file_compressorst::write_var (and out of read_var) on big-endian machines. However, I'm not sure if what comes out of zlib's compression needs to be fiddled with as well, or if zlib handles that itself.
I don't have access to a big-endian machine so I have no idea what will happen, so it would be handy if someone were to test it.
but then you have to maintain at least two copies of everything, and do cross-platform testing on each release. it doesnt exactly double the workload and bug reports, but it sure dosent reduce either of them.
quote:
Originally posted by Toady One:
<STRONG>I imagine most of the source files will be exact copies between the two machines, if two machines is the way to go. Handling the strange bugs that I don't even understand because I don't work with these other operating systems will likely be the hard part. Any other thoughts on the OS setup from people that wanted ports? I need to be 100% clear on this before I can proceed.</STRONG>
Well, for starters most linux distributions (and all the good ones, imo) are completely free. You can run OS X, linux and windows on one single computer, you can even run all three OS'es at the same time.
Look into something like VMware, it's an application that allows you to run several virtual machines on one physical machine. The standard server version is free.
So in order to run linux, you just install vmware and some linux distro on the virtual machine. If you're not familiar with linux, go with something like Ubuntu. It's popular and user-friendly.
[ January 13, 2007: Message edited by: odd2k ]
[ January 13, 2007: Message edited by: Toady One ]
Ubuntu is coming in over 4 hours... the VMware virtual machine is set up, and I guess it wants me to burn the Ubuntu ISO onto a CD for it.
[ January 13, 2007: Message edited by: Toady One ]
[ January 13, 2007: Message edited by: Tormy ]
So, I have a VMware virtual Ubuntu computer, and I played that faux-"mahjongg" matching game on it, so it seems to work fine.
I have a few questions.
edit: From what I've been reading, up to August 2006, OS X isn't really available unless you are running on Apple hardware, and they've resisted virtualization. I do not know the current situation.
[ January 13, 2007: Message edited by: Toady One ]
It's not exactly legal though. Although I wouldn't feel terribly bad about buying OS X and installing it virtually, illegal or not. It's not exactly piracy.
As for compiling on linux, you usually need a make file. Most programs are compiled by calling make, which reads the make file and in turn calls the compiler/assembler/etc.
Look into autoconf and automake, I believe that's what most people use. You'll need gcc(and gcc-g++ if you're compiling c++ code), as well as gnu make, autoconf, automake, and some other annoying dependencies that I can't remember. Just google whatever error messages you get.
Oh, and there is a working linux port for kobold quest, lastest I could find was posted by popecharlotte on page 2:
http://johnbrawn.cabspace.com/kobold-20061030.tgz
By the looks of the makefile, you just have to enter the 'kobold' directory and issue 'make kobold', and that should be it. If you're unfamiliar with using the prompt, just goto tldp.org and read a quick bash tutorial.
[ January 14, 2007: Message edited by: odd2k ]
edit: I had found that same article when I was looking for OS X information, and I'm not going that way... I guess I'll have to figure out something else for Mac.
[ January 14, 2007: Message edited by: Toady One ]
Now, question, would be useful to have KQ on a public source control system? I don't really see how platform-experts can be expected to track changes when everyone's working off their own master. Hosting it on Bay12 would be yet more pointless distractiveness for the Toad, I don't like sourceforge much... anyone used this yet? Or other suggestions?
X
Look up the Bloodshed C++ IDE, it uses MinGW which uses GNU c++. GNU c++ is available on a lot of platforms.
Basically I followed this old thread it its entirety this morning and was disapointed to find that the link to the most recent mac os x port/build was dead :(
I would really love to try this game out, can anyone put the link back up? I will be trying the irc channel otherwise...
I'm not a licensing expert, but would it be feasible to turn the KQ code into an open-source library derivative of Wine and then just have DF link it? That should allow you to release DF on your own terms using section 6a or 6b of the LGPL.
If the issue is the "must allow modification and reverse engineering" clause of section 6, then I think that would prohibit you from using any LGPL library at all, including SDL.
As for turning KQ into a library, I doubt it would have to go that far, but whatever works. My requirements are that it has to be easy for me to understand how to lay DF on top of it, and I have to be able to release it without releasing the source code of DF.
quote:
Originally posted by Toady One:
<STRONG>It was my impression that you could use an LGPL DLL and not release the source code of your own project (since you don't become a derivative work at that point, and the modifications can occur at the DLL level), but I don't know much about it.</STRONG>
Right, that's what section 6 covers. It does seem to include the annoying requirement that the DF license must allow users to modify and reverse-engineer the DF executable. I brought it up because the current DF license agreement doesn't permit modification of the executable.
It may be somewhat ignorable. The SDL overview of the license doesn't even mention it.
edit: To be specific, it seems like using the DLL would be fine, until such a point that a new version of the DLL is no longer compatible with the binary, at which point the binary must be opened up to allow compatibility. This would put me at the mercy of whoever is maintaining the LGPL project.
[ May 17, 2007: Message edited by: Toady One ]
That's only ~750 lines total, and is not a technically hard task for anyone who knows a little about win32 and enough about their target platform. Add in finding other stray calls to stuff like MessageBox and re-routing through the enabler, the task is still of hours order, not days.
Anyway, it served its purpose of shutting up the I'd-port-this-if-you-gave-me-the-source bullshitters. Whining is easier than WINEing, but WINEing is easier than porting, and they're all about path of least resistance.
X
[ June 04, 2007: Message edited by: Toady One ]
Testing is still far from extensive, I think a few keybinding things may be broken (in particular, ctrl and alt, though shift seems to work). GLFW has some small quirks which I'm not entirely sure of, so they'll take a little prodding.
You can safely use LGPL code in a proprietary project, as long as you leave the LGPL portion of the code under the LGPL. In other words, either make no changes to it and distribute it as is (should be easy enough with SDL), or optionally make changes to it and redistribute the source for the changed LGPL code only.
This exact scenario is exactly why the LGPL was developed in the first place. If it was regular GPL you'd have to GPL the entire code base, but with LGPL you only have to MAINTAIN the license, not PROPAGATE it through the rest of your code. Hope that helps in case anyone is still concerned about the licensing issues around this.
If you linked statically SDL to your project, your project would become LGPL too.
Just use it (dynamically), many did before :)
quote:
6. Revised Versions of the GNU Lesser General Public License.The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy's public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.
If so, I fail to see how that is a problem. since:
quote:
The Simple DirectMedia Layer library is currently available under the GNU Lesser General Public License (LGPL) version 2.1 or newer.
Finally, according to the SDL website (http://www.libsdl.org/license-lgpl.php)
quote:
To comply with this license, you must give prominent notice that you use the Simple DirectMedia Layer library, and that it is included under the terms of the LGPL license. You must provide a copy of the LGPL license.
You must also do one of the following:1. Link with the library as a shared object (e.g. SDL.dll or libSDL.so)
2. Provide the object or source code to your application along with any libraries and custom tools not available with a standard platform development kit. You may also simply provide a written offer, valid for three years, to provide these materials upon request to anyone with a legal copy of your application.If you include the SDL library in binary form, you should also make available the source code to the version you provide, including any customizations you have made. If you link to a standard version of the library, simply referring to the SDL website is sufficient.
Also, I kind of stumbled upon this cool tutorial for SDL: http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/gfxsdl/index
Just in case someone is interested in it. (Or in case Toady still doesn't know SDL)
EDIT: Ahh, could the problem be if you need (for example) SDL1.2 and that will no longer be available on the SDL website at some distant point in the future? (which will mean using a newer version which could be under any license)
I highly doubt the chances of that happening. And even if it will, the dll will still most probably be available (if not on the SDL website, then somewhere else), so there would be no problems.
[ August 27, 2007: Message edited by: Slartibartfast ]
In practice what it means is that if you use SDL 1.2, and I decide I want to use my own version of SDL 1.2 with some of my own changes in it, and I need to reverse engineer portions of your code to get my version of the SDL to work, you won't take me to court. But if I reverse engineer your code and then publish specs online about how to circumvent some non-SDL feature as a result of that, then I still could be running afoul of your terms (assuming, of course, that your terms don't allow me to do that). That clause was put there specifically to combat Tivoization. So if you want to use LGPL code, you're perfectly welcome to do so, but you can't take people to court because the way they use that same code isn't exactly what you had in mind.
(Allegro is under a "giftware" license, which basically means "do what you want with it, just don't blame us if your computer catches on fire")
[ August 28, 2007: Message edited by: Slartibartfast ]
Is there anything I should know? Like, is anyone else already doing this (so we could collaborate), or would porting it no longer help much?
I'd also be willing to sign an NDA to do the same work on Dwarf Fortress itself. Yes, for free, if toady is listening - I'd consider this my payment for the game. ;)
I would pay cash on the barrel head (and, as a somewhat well known game blogger, encourage other Mac users to do so) for an OS X native port. There may be fewer of us, but we are loyal as hell. And our marketshare is growing :-)
-peterb http://tleaves.com
quote:
Originally posted by Toady One:
<STRONG>I think nornagon did something and X has it put together somewhere for KQ, though I'm not sure at this point exactly how far that got. I was busy with this latest release and never got a chance to look at it. I might again after I get most of the bugs sorted out.</STRONG>
Then I won't do anything further.
The port does appear straightforward, from what I've seen, but if you don't have time yourself (too busy making it better?) then I'd urge you to consider asking someone else. It wouldn't be much work to write a contract that lets you keep all rights for my work - god knows I've seen enough of them. :P
Alternately.. lots of people have suggested that they'd pay for this port. Perhaps it's time to collect those pledges on a wiki page, so they can be summed?
quote:
Originally posted by peterb:
<STRONG>I would pay cash on the barrel head (and, as a somewhat well known game blogger, encourage other Mac users to do so) for an OS X native port. There may be fewer of us, but we are loyal as hell. And our marketshare is growing :-)-peterb http://tleaves.com</STRONG>
I just joined this forum to say I would pay for a Mac port. Dwarf Fortress is amazing, but I can't stand booting into Windows. No offence to Windows users: I'm sure you'd be just as annoyed if you had to boot into Mac OS to play.
[ November 11, 2007: Message edited by: Muriac ]
quote:
Originally posted by Muriac:
<STRONG>I just joined this forum to say I would pay for a Mac port. Dwarf Fortress is amazing, but I can't stand booting into Windows. No offence to Windows users: I'm sure you'd be just as annoyed if you had to boot into Mac OS to play.
[ November 11, 2007: Message edited by: Muriac ]</STRONG>
*shudder* I considered myself pretty literate with computers, until I tried using a Mac for the first time since 10 or so years ago. So confusing compared to the familiar windows.
I don't know what the status of other folks on this is... I downloaded and started working on this before I saw some of the latest replies.
I have a stubbed-out version compiling on the Mac. For non-coders, stubbed out means lots of empty functions that now need to be filled in to make things actually work. The biggest thing there is replacing the Windows message pump and window creation with a similar Mac setup. Once that's done, the rest should fall into place quickly.
This would not rely on anything else... no SDL, etc. I've completely disabled fmod at the moment, since at least in DF it's just background music... iTunes would be suitable for that. =) But I've seen the fmod website, which seems to be available for all platforms, so could be done eventually.
Gotta keep pushing.
Right now, I have a base OpenGL window up and running... and accepting render from the game. See here, click for larger version:
(http://lh3.google.com/matthew.moss/R0n11qz_fKI/AAAAAAAAALQ/gdJc12Tz4bE/s288/kqmain.png)
Currently I'm working on keyboard input... That's a bit of a pain, but I think I'm close. I need to actually boot into Windows and play KQ to see the expected behavior, so I know where I might be failing. Right now it's just windowed, no fullscreen, but that's a lesser priority.
[ November 25, 2007: Message edited by: mattmoss ]
Just to make sure I've been reading your posts correctly, this will be a native OSX application?
quote:
Originally posted by Jifodus:
<STRONG>Congratulations for making it so far. Now make it robust and perfect... not that I have a Mac(or tel) to test it on. It's just exciting to see the next step to cross platform availability.Just to make sure I've been reading your posts correctly, this will be a native OSX application?</STRONG>
Yes, this is a native OSX app that doesn't rely on things like SDL or similar, something I believe Toady wanted to avoid. Once this is done, I will give full ownership of the code to Toady in the hopes we can also have a native DF.
quote:
Originally posted by Toady One:
<STRONG>The only Mac I potentially had access to is big-endian... I'll have to figure out how I'm going to compile things.</STRONG>
I had a few thoughts on this...
1. When I have the native Mac code working for KQ, you can send me the source to DF which I can get up and running and build a Universal Mac app. I know this doesn't particularly appeal to you as I've seen said a number of times. All I'll say towards this is that I am a professional game developer, used to NDAs, can keep it secure, and I can stick solely to making the port work and leaving everything alone. It would also be easier to get a native OSX port working with someone familiar with and owning both Intel and PPC macs. Additionally, it would leave you free to fix bugs and add features rather than worrying about a port.
2. If that's still not an option, I may be able to set up my tower Mac as a server and provide you a login account with ssh/sftp and possibly vnc access. That should keep your code secure and allow you to build the project mostly without my involvement. That has some disadvantages... namely, you couldn't test it that well... VNC would probably work, but it ain't going to be fast. Also, being the admin of the machine, I would still technically have access to your code; even if I promised to not look, you might not consider this much better than #1.
3. The cheapest Mac is US$600, the Mac mini. You hook up your own display/keyboard/mouse and you've got a mac. That comes with the OS, and all the dev tools are free. It's Intel-based, so you wouldn't easily be able to test the endian issues that would come up on PPC machines, but if all your file-reading code happens in one place, that shouldn't be much of an issue. It ain't the fastest, most powerful machine, but this ain't Unreal Tournament, so that shouldn't be a problem.
Linux: I think I've got a computer I can stick Linux on now if the virtual computer idea doesn't work. The Lord Packman still has nornagon's code, I think. I'm not sure if there was a license included with it though. Hopefully there was. I'll ask LP about that tonight and see if I can get that ball rolling again.
quote:
Originally posted by Toady One:
<STRONG>Mac: Hi, yeah, paranoid so 1/2's not gonna work. But I was thinking of getting back into this porto stuff now that things are settling down again. 600 dollars should be negligible -- I'm sure all the friendly Mac people will donate that much over the life of the mini, assuming it all works out. I'd have to have somebody help me dig up tools and figure out... everything, but whatever, should be fine.</STRONG>
Understandable paranoia... It's cool.
Towards a Mac mini, or heating bills, or whatever, I just sent a donation via PayPal. Enjoy. :)
As far as further Mac porting... I will continue on Kobold Quest and make it as complete and clean as I can. When it's done, we can chat about how it works, how to integrate and build it, whatever... I'm happy to help with a Mac port however you need.
quote:
Originally posted by Toady One:
<STRONG>My brother and I drove around a while, but I guess they don't sell Apple computers around here and the nearest Apple store is in Seattle, so I got a mini online instead. It will arrive whenever. I suppose low availability is part of the Apple marketing strategy, unless they've been driven out of the local stores by force or something.</STRONG>
Apple has tried a few times in years back to have a retail presence without luck, until they started opening their current chain of Apple stores, and they do that slowly, choosing locations with care. There are occasional 3rd-party retailers that will sell Apple products... I know of two in my area... but that is pretty rare. Apple resellers generally have been online-only.
quote:
Originally posted by Helmaroc:
<STRONG>Sorry for being a newb, but what are differences in DF and Kobold's Quest?</STRONG>
Well, they're quite different games. DF is much, much deeper than KQ. But, according to Toady, DF uses basically the same engine as KQ. So in porting KQ to another platform makes it easier and more likely that DF could be ported.
quote:
Originally posted by Toady One:
<STRONG>I now have a Mac Mini. It came with a few cables. Now I need to dig up a monitor that will work in the mini and in the linux computer.</STRONG>
Woo! Okay... I have some time off this week, so I'll get back to some more of the KQ porting and cleanup, and we can chat later about how you want to do this.
Additionally, the dev tools (XCode) are most likely not installed by default, but you should be able to pop in one of the discs that came with it and install XCode from there.
edit: I guess it's supposed to come on one of these DVDs. I'll have to try to find it out without destroying something.
[ December 11, 2007: Message edited by: Toady One ]
edit: Okay, I've installed XCode. Everything seems to be working correctly.
[ December 11, 2007: Message edited by: Toady One ]
Most 3rd party application installation is basically "drag application into Applications folder". Whee.
Toady, sorry I haven't replied yet with anything on my KQ work. I will shortly.... just typing up my turn for a succession game. :D It will be cool if I can get it running in OSX, since DF is about the only thing I reboot into XP for.
[ December 28, 2007: Message edited by: Toady One ]
10.3 fix below (file is enabler_osx.cpp, line 418)
---------------
code:
if (HIPointConvert != NULL)
{
HIPointConvert(&hipt, kHICoordSpaceScreenPixel, NULL,
kHICoordSpaceView, dstView);
}
else
{
hipt.x -= cr.left;
hipt.y -= cr.top;
HIViewConvertPoint(&hipt, NULL, dstView);
}pt.h = (short) hipt.x;
pt.v = (short) hipt.y;
[ December 29, 2007: Message edited by: eli ]
The text input is also a bit wacko, I partly fixed it by taking out the cast to char on the Unicode value, but the virtual keycode lookup seems problematic. You can probably get away with it, but the table looks wrong, apparently OS X uses the keycodes from the good old Apple Extended Keyboard 2 as described here keycodes from OS X.
All of my changes were limited to enabler_osx.cpp, let me know if you'd like the new file.
quote:
Originally posted by Toady One:
<STRONG>Okay, I've put up a preliminary version of mattmoss's port here. There's a known issues text file with the application zip. I don't really know what's going on with the glDeleteTextures() call. Let me know if there are any other problems and we'll try to deal with them. Once this is sorted out, we can move on to DF.[ December 28, 2007: Message edited by: Toady One ]</STRONG>
I sent you an email about a fix for the glDeleteTextures issue.
quote:
Originally posted by eli:
<STRONG>I played with it a bit more and adding the endian conversions after the fread() calls fixed the graphics on PowerPC.The text input is also a bit wacko, I partly fixed it by taking out the cast to char on the Unicode value, but the virtual keycode lookup seems problematic. You can probably get away with it, but the table looks wrong, apparently OS X uses the keycodes from the good old Apple Extended Keyboard 2 as described here keycodes from OS X.
All of my changes were limited to enabler_osx.cpp, let me know if you'd like the new file.</STRONG>
Yeah, the text input is a bit wacko... It's been a while since I've done regular Mac coding, and a lot has changed. I was trying to just get from the mac key codes to windows, to keep as much of the port work in enabler_osx rather than scattered elsewhere through the code. (I certainly don't write cross-platform code this way, but in this instance, it seemed better to try and isolate the mac stuff that start telling Toady how to rearrange everything.
But hey, another Mac-head lookin' at my code is just fine. :D
EDIT: Oh, and on the endianness issue... Doing the porting work on an Intel mac meant I could leave that to last... since I try not to mix sources of potential problems. Once that was finished, I had planned to go back and fix then endian stuff for PPC. I haven't yet looked to see how Toady was reading
things in... as text, structured, or as binary blobs dumped into structures. Each requires different endian-ness handling, and it's not difficult stuff, just needs to be looked at.
[ December 29, 2007: Message edited by: mattmoss ]
quote:
Originally posted by Toady One:
<STRONG>Okay, I've put up a preliminary version of mattmoss's port here. There's a known issues text file with the application zip. I don't really know what's going on with the glDeleteTextures() call. Let me know if there are any other problems and we'll try to deal with them. Once this is sorted out, we can move on to DF.[ December 28, 2007: Message edited by: Toady One ]</STRONG>
I can download and unzip the archive for the game, but the source/project zip file isn't working for me...
quote:
Originally posted by mattmoss:
<STRONG>Yeah, the text input is a bit wacko...
...
but in this instance, it seemed better to try and isolate the mac stuff that start telling Toady how to rearrange everything.But hey, another Mac-head lookin' at my code is just fine. :D
EDIT: Oh, and on the endianness issue... Doing the porting work on an Intel mac meant I could leave that to last...
...
[ December 29, 2007: Message edited by: mattmoss ]</STRONG>
I agree the endian thing isn't a priority, I just needed to put it in to verify that my 10.3 fix worked.
I'm 90% sure the keycode stuff you did actually will work when the table is adjusted, even if it is wacko. I agree that it's much better to have code that's easy for Toady One to integrate than code that's 100% kosher OS X approved but ends requiring extra hoops.
I emailed Toady One, but for anyone else following along it will be very easy for him to build a single Universal application that supports 10.3 and later on PowerPC and intel (at least for Kobold Quest).
Also, big thanks to mattmoss for doing all the work. Nobody should think that me calling something wacko is an actual criticism of his code - more of a joke. ;)
edit:typo
[ December 29, 2007: Message edited by: eli ]
quote:
Originally posted by Toady One:
<STRONG>Is the source zip working now? I think my FTP might have crapped out while it was sending before.</STRONG>
Yes, working now, thanks.
quote:
Originally posted by eli:
<STRONG>I'm 90% sure the keycode stuff you did actually will work when the table is adjusted, even if it is wacko. I agree that it's much better to have code that's easy for Toady One to integrate than code that's 100% kosher OS X approved but ends requiring extra hoops.
</STRONG>
I wonder if another solution is needed.... When you say "when the table is adjusted", do you mean that some of your keys are not mapping to what the game expects? E.g., the arrow keys aren't doing what they should, or something like that?
Because, aside from some missing ones and the general wonkiness of the code, the table seems fine on my computer.
I wonder if the keycodes I'm fetching are at too low a level to be consistent across different keyboard layouts/locales/manufactures? I should probably look at that stuff again... find a way that will be more consistent.
quote:
Originally posted by mattmoss:
<STRONG>
I wonder if another solution is needed.... When you say "when the table is adjusted", do you mean that some of your keys are not mapping to what the game expects? E.g., the arrow keys aren't doing what they should, or something like that?
</STRONG>
Apologies, I was assuming the key table from that image was in hex, but it is actually decimal, and the keycodes you were getting are right. Sorry about that, I had just glanced at a few and they didn't seem to match. The other odd keycodes I was getting were the result of an endian issue, but removing the cast to char fixed those.
My impression is that the keycodes in OS X are all either identical to or auto-magically morphed into the old Apple Extended ones, in which case you're good to go on the translation.
~Charlie
quote:
Originally posted by taargus:
<STRONG>I can't wait to play. Thanks for going through all this work just so us mac users can play.</STRONG>
And you'd BETTER donate the $300 it cost him.
-p
quote:
Originally posted by Armok:
<STRONG>And you'd BETTER donate the $300 it cost him.</STRONG>
I thought the Mini was donated to Toady? I don't have a Mac but I support going multi-platform, its a good way to futureproof a game.
quote:
Originally posted by axus:
<STRONG>I thought the Mini was donated to Toady? I don't have a Mac but I support going multi-platform, its a good way to futureproof a game.</STRONG>
Futureproof? You're expecting Windows (w/OpenGL) to die anytime soon?
:D
I think I'm going to put up the PowerPCish KQ on Monday. I was planning on trying to finish the DF port then as well, but that might have to wait a little until I get together something releasable for Windows again. I'm hoping to be able to release the next version of DF on both platforms (the Mac one would be a MegaAlpha, of course), but we'll have to see how that plays out.
Very glad to see your hard work on the Mac Port of DF. I've just contributed 50.00 for your existing efforts and will contribute 50 more on delivery of a working mac binary. Don't let that little incentive rush you though. We love stability, and quality is more important than speed. Also, I own several macs , Intel and PowerPC and would be happy to beta test any builds that you want to help chase down bugs.
Zeb.
Date/Time: 2008-01-09 22:59:30 +1300
OS Version: 10.3.9 (Build 7W98)
Report Version: 2
Command: Kobold Quest
Path: /Volumes/USB HD/downloads/kobold quest/Kobold Quest.app/Contents/MacOS/Kobold Quest
Version: ??? (1.0)
PID: 593
Thread: Unknown
Link (dyld) error:
dyld: /Volumes/USB HD/downloads/kobold quest/Kobold Quest.app/Contents/MacOS/Kobold Quest Undefined symbols:
/Volumes/USB HD/downloads/kobold quest/Kobold Quest.app/Contents/MacOS/Kobold Quest undefined reference to _HIPointConvert expected to be defined in Carbon
It starts up fine. Loads front end with the picture of that thing (kobold?), then regardless of any input it crashes.
I did notice that it was eating the mouse click and not registering it if I opened the About Box so that it overlapped the game window, but I'm too sleepy to look at that tonight.
edit: spelzin
[ January 10, 2008: Message edited by: eli ]
I searched for how to changed the architecture settings, and what I found made it look like I should type "ppc i386" into the Architectures area, so that's what I did. It made a couple of different object folders upon build, but I have a warning about adding -bind_at_load that I don't know what to do with.
Other than that, congratulations. I hope this has allowed you to take a pretty big step towards getting DF on Mac. :D
quote:
Originally posted by Toady One:
<STRONG>Well, I've changed the settings and uploaded it again.I searched for how to changed the architecture settings, and what I found made it look like I should type "ppc i386" into the Architectures area, so that's what I did. It made a couple of different object folders upon build, but I have a warning about adding -bind_at_load that I don't know what to do with.</STRONG>
Hey Toady,
I'll download the latest source this evening and check it out...
I'll also work on the fullscreen swap, and perhaps clean up the menus (i.e. remove all the unused junk).
[ January 15, 2008: Message edited by: mattmoss ]
Granted it would only play nice with Intel Macs. But it's a start... And any Mac under two years old is Intel anyway.
I saw someone mentioned using Cider ... is that out of the question? It seems like it'd be the easiest and fastest way to get an OSX port out, and it might even be free, since DF is a nonprofit game and they operate by profitsharing.
Granted it would only play nice with Intel Macs. But it's a start...
Seeing as how DF is pretty much running on the Mac (specifically, Toady's Mac), I don't see that Cider is necessary. As I understand it, DF uses little platform-specific code, and much of that has been accommodated in code that Toady now owns.
It switches from window to fullscreen now, but something weird is going on switching back. I may have to hook up a 2nd monitor so I can debug properly.
The textures are also going a bit weird when switching. It's not unplayable, but it's like they're lower rez or something. Weird...
Anyway, should have it all good soon...
What does not work is going fullscreen: I get big blocky graphics and it won't switch bach to windowed. Pressing Alt-Aplle-Esc crashes KQ.
Also I don't seem to be able to kill adventurers. Maybe I'm stupid but they just walk over pits and throwing critters at them make them flashing but nothing else happens.
quote:
Originally posted by poesel:
<STRONG>Just a report that KQ 1.05 works on a PPC G4 with 10.5.1 (Powerbook).
Thanks for the report...
quote:
What does not work is going fullscreen: I get big blocky graphics and it won't switch bach to windowed. Pressing Alt-Aplle-Esc crashes KQ.
Yeah, I'm dealing with the fullscreen/window switching code now.
quote:
Also I don't seem to be able to kill adventurers. Maybe I'm stupid but they just walk over pits and throwing critters at them make them flashing but nothing else happens.</STRONG>
As I understand it, throwing critters is generally a last resort... you need to rely on the pits more. Pick up a critter, drop him in a pit, then cover the pit. (Adding multiple critters to a pit is also good...) Then keep the pit between you and the adventurer... assuming he didn't actually see you cover it, in which case I believe he'll avoid it.
1. Make it fully robust. While it is most likely robust as it is, I have this nagging feeling that there might be cases where it would get stuck in fullscreen mode and the user won't be able to switch away, forcing power off and reboot. I'll have to check this further...
2. Textures still get slightly mangled when switching to the other mode from which you started. It's still playable, just not as pretty. Have to look into this more.
3. Windows of other apps are getting moved/resized due to the screen change... It's not supposed to happen; trying to figure out why.
Anyway, will be sending you the revised code later today, Toady.
[ January 28, 2008: Message edited by: mattmoss ]
quote:
Mac portage... there are still various gigantic problems with the peripherals (sound/movies/BMP export/etc.), but there was quite a bit of progress. I generated a world with the same seed on both of my computers and got the same exact map and history. It was a bit of a chore though since the order of RNG calls between MSVC and XCode was different based on compiler optimizations (so I had to break some expressions up, once I found out what was going on). I can't guarantee there won't be a lot of addition problems along these lines. I then went on to mine a tunnel in dwarf mode and join a temple in adventure mode. Speed was fine, except in a few places where the number of refreshes needs to be cut down (unit offloading is the big one).I'm at a point where I can't continue without some email correspondence, so I'm going to release the Windows version now. I'll just be bug fixing with more frequent releases for a while though, so as soon as the main Mac issues are handled I can get the port out with one of those. I have the actual code transfer/Mac compile/archive process down to about a half hour which I can mostly spend working on other release procedures, so once the initial problems are sorted out everything should actually go smoothly from now on.
quote:
Originally posted by Toady One:
<STRONG>From dev log:
</STRONG>
I've been AWOL (stupid job) but probably have a few hours this weekend if there's anything specific I could help out on. Is music still broken in Kobold Quest? I could work on that if it's the same system used in Dwarf Fortress...
Another option might be taking the tabs I saw in another thread and putting that into midi. But again, that's another area I've never dealt with. For either of these, I don't imagine it's that difficult, but it would take time to figure out, and for the next month or two, my time is going to be extremely limited. (Moving)
eli, if that's something you know about, please have a crack at it.
The changes were very minor, most of my time was spent being stupid and missing the line right in front of my nose where it tried to set fmod to use DirectSound output (nice sanity checking, guys.)
[ February 14, 2008: Message edited by: eli ]
[ February 14, 2008: Message edited by: Toady One ]
edit: He he he, full screen toggle suddenly started working for no reason! This is both good and bad, but I'll let the bad slide for now and possiblye forever.
[ February 20, 2008: Message edited by: Toady One ]
Don't worry too much about fullscreen on the Mac. I'm new to them myself and can't speak for everybody, but in general a lot of Mac users seem to prefer running apps and games in a window. Most are also going to have LCD screens these days, which can look like ass when forced into non-default resolutions or aspect ratios and seems to disable task-switching for me.
ps: I've been running the game in Crossover/Wine since switching to a Mac, and it seems to be locked at a solid 21-22 FPS regardless of how large or complicated the fort is (within reason). Feels like a bottleneck somewhere, either in Crossover, my system, or DF itself.
However, being used to a variety of interfaces, DF's interface is, uh, well there's a bug logged about it, but its status is future.
I note, for example, the following systems of movement / resizing (in today's world, equivalent tasks). Sometimes its legitimate that two would be needed (left pane / right pane). But in others, like lists, sometimes its -/+ for the left list and arrows for the right.
Types of movement & resizing tools:
wasd
wasdx
uhkm
shift-uhkm (alongside uhkm)
-/+
arrow-keys
Similarly for selection / quantity
space
enter
left/right-keys
-/+
For abort / dismiss
space
enter
F8/F9
tab
Additionally, there are some interesting interface flow issues, sometimes (for instance Dwarf management via [j]obs or nits) abort/dismiss returns to Map, instead of to prior menu. Other times abort/dismiss returns to prior menu. Some panes/panels aren't available from logical places. Found I was incorrect about: [[From Zoom to Dwarf, the option of View Dwarf mood / relationship isn't available, and from View Dwarf the option to zoom to General / Labour assignment isn't available.]] * * * But: this is bitching from someone used to the (relatively) integrated and controlled Mac interface, someone who's a Human Interface Guidelines lover, reads Style Manuals for fun, and is into typography. Learning the DF interface idiosyncracies is possible, but its frustrating on about the same level as obsessive / compulsive stone management. [ April 01, 2008: Message edited by: fifelfoo ]
null
Clearly, I have spent far, far too many hours playing the game.
The only interface problem I have is going from a full keyboard to my laptop - now that can be weird. :)
1. Is anyone working on porting Kobold Quest to Linux?
2. Was SDL ruled out (because of the LGPL or otherwise) or will Toady One accept a port using this route (for the purpose of furthering it into a Linux DF)?
3. Is there any abandoned or otherwise in-progress KQ port? What's its status/license?
Sorry for my laziness. I didn't want to read a year and a half worth of posts and come to the wrong conclusions.
2. I don't remember the particulars with SDL, but if I remember, I didn't want to use it.
3. I have something that nornagon cooked up for KQ 1.02. I think there was some roughness with it, and I haven't gotten a chance to look at it, and he's been busy. I can't find a licensing discussion in my email with him, so I can't post the source at this point. I doubt there'd be a problem, but since I don't have time to look at it until later, I haven't contacted him.
So in the end, I might have something I can or can't use. Maybe not best to rush forward with another port in that environment.
quote:
Originally posted by tarsier:
<STRONG>Toady, I want to thank you so much for your progress so far on making an OS X version - running DF in virtual PC makes it run extremely slowly, so I can't wait until I can play DF at it's intended speed!
Keep up the great work, all of us mac geeks are really really excited! :D</STRONG>
Me too and I have a Pc! Low key jab at framerate optimization.......