Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: DaveTheEmbalmer on May 02, 2002, 05:45:07 pm
-
Are there any plans for a Mac or cross platform version of Freespace 2 in the works? It would require switching the renderer to OpenGL, and using something else for everything DirectX...but it would be possible.
-
i suppose it could be, but there is no reason to. no one who uses a mac deserves to play Freespace.
-
Originally posted by Carl
i suppose it could be, but there is no reason to. no one who uses a mac deserves to play Freespace.
How rude.
-
psstttt, that would be very cool as my FS-liking friend has a mac and can't play......
-
i suppose it could be, but there is no reason to. no one who uses a mac deserves to play Freespace.
:lol:
Anyway, I doubt there will be a mac port of FS2 any time in the near future because the community is so small and almost all of us use Windows. With the release of the source code, everyone is busy taking it apart and putting new stuff into the game. ;)
-
Originally posted by CP5670
:lol:
Anyway, I doubt there will be a mac port of FS2 any time in the near future because the community is so small and almost all of us use Windows. With the release of the source code, everyone is busy taking it apart and putting new stuff into the game. ;)
A mac version would be cool, for exactly the reasons stated way up at the top:
It would require switching the renderer to OpenGL, and using something else for everything DirectX...
OpenGL Freespace could be compiled and run on ANY platform: Mac, Win32, Linux, BSD, etc. You want to share Freespace? Make it so other people can play it. Not a good enough reason? How about OpenGL/AL programming would be interesting to learn and a markettable job skill?
Its an interesting direction to go in. Don't just ignore it because its 'a Mac'.
-
*ignores it because it's a mac*
-
Originally posted by CP5670
:lol:
Anyway, I doubt there will be a mac port of FS2 any time in the near future because the community is so small and almost all of us use Windows. With the release of the source code, everyone is busy taking it apart and putting new stuff into the game. ;)
heh, I don't have enough creativity to think of any new features, so I'm working on porting it... the idea would be that it would be portable to ANY platform that supports either DirectX (*cough* Windows *cough*) or OpenGL (pretty much anything).
The big deal is removing all of the Windows specific stuff (system calls & libraries) and the Intel specific stuff (little-endian assumptions). There's also a lot of non-standard C++ that has crept in (that MSVC accepts, but some other compilers don't).
And the texture mapping routines (all the tmap*.cpp files in the Graphics dir) are in assembly :mad:
My base platform is Linux, not Mac, but porting from Windows->Unix and DirectX->OpenGL should remove a big chunk of the Wintel dependencies, so it would be a matter of just adding the Mac-specific stuff.
-
Well, it looks like that there is a good possibility of a Mac Freespace in the far future...As soon as I learn some more about the carbon and Cocoa APIs, I should be able to help...(and I know a good deal about OpenGL, I should hook up with one of the OpenGL porting groups..)
Oh, and Carl, I'm deeply sorry that you're so insecure about yourself that you must make jabs at something simply because its different from what you use. Good luck on recovery!
-
Originally posted by DaveTheEmbalmer
Oh, and Carl, I'm deeply sorry that you're so insecure about yourself that you must make jabs at something simply because its different from what you use. Good luck on recovery!
...and you were doing so well up until right there.
-
Well, a unix port would pave the way to an OSX port, so, not sure this is "far" into the future, depends on the speed of the delivery of the *nix port ;)
Another thing that would be nifty, would be a developer list, things like who has what, I see porting projects as a seperate activity, that a small sub-group of the coders here could take on and do withoutrying about integration of nifty new features.
because if we document those nifty new features, they should be easy to integrate once the port is complete :)
-
Originally posted by Inquisitor
Well, a unix port would pave the way to an OSX port, so, not sure this is "far" into the future, depends on the speed of the delivery of the *nix port ;)
As I frequently put on my progress reports at work, "we are making slow, but forward, progress" :) The entire thing makes it through the C preprocessor now, so I got the filename thing straightened out, at least...
:V: has done things that irritate me in the code, but I can't blame them since I know what it's like having deadlines (and only needing to support one development platform)... But here's my top list:1. case sensitivity in file names -- the file named MODEL.H is included as "Model.h" "model.h" etc. My solution was to convert all filenames to lower-case only (and update the #include lines to match)
2. Non-standard C++: using variable and struct members that have the same name as the type (stepped_rotation *stepped_rotation) I am renaming the probematic typedefs to use _t at the end (e.g., stepped_rotation_t), which is what POSIX does.
3. Non-standard C++ part 2: anonymous structs (the x,y,z in struct vector; and the vectors in struct matrix) Anonymous unions are part of standard C++, but anonymous
structs?!?
4. Assembly in the texture mapping code. Dammit.
[/list]
Fixing #2 and #3 will require making a lot of little changes throughout the code (um, vectors and matricies are used a fair amount...). And #4 will require obviously a ton of work, especially to move to non-Intel processors (PPC, Sparc, ...)
Then there's the DirectX -> OpenGL, but I want to get the existing code to compile completely (using stub headers and libraries for the Win32 and DirectX stuff) before actually changing any functionality.
The good news is that the :V: developers did an outstanding job of separating the functionality (ai, sound, physics, graphics, etc.), so the port should move smoothly...
BTW, I am continuing to test to make sure my changes still work for that stinkin' MSVC compiler...
Originally posted by Inquisitor
Another thing that would be nifty, would be a developer list, things like who has what, I see porting projects as a seperate activity, that a small sub-group of the coders here could take on and do withoutrying about integration of nifty new features.
because if we document those nifty new features, they should be easy to integrate once the port is complete :)
Great idea. This will take care of two potential problems: multiple people working on the same problem (reinventing the wheel), and making sure people's work doesn't get lost.
-
Originally posted by Carl
i suppose it could be, but there is no reason to. no one who uses a mac deserves to play Freespace.
So true.
-
1. It'd take a pretty huge effort, and since there is no FreeSpace for Macs, there are few people on HLP who could USE a Mac FS, and thus even fewer who would be interested in making a Mac FS.
2. If you need an Apple product to use computers, you probably couldn't handle FS anyway. I mean, if two friggin' buttons on a mouse is too much for you, I'd hate to see you trying to use the whole bloody keyboard.
3. See above. Two reasons not to so good that they could count as a third, fourth, fifth, sixth, and seventh as well.
-
Now that's just being combative ;)
-
A *nix port would be a good step toward OS X, but there'd still be all the drawing APIs (other than OpenGL. Probably done in carbon) sound (OpenAL?) etc. I don't even want to get into networking =).
Secondly, may I ask a few folks why you insist on demeaning me or my platform of choice? I play Freespace all the time, and I use a Mac. Its not "too much for me" and I'm not unintelligant because I use a Mac. And I have use 2-button mouse. I think a few people here need to take a chill pill, and follow the example of all the other mature, reasonable people on this board.
Now, I didn't want this to turn into some PC vs. Mac flame war, so if you stop the smart comments, I'll stop mine. Fair enough?
-
Yes, I am guessing OpenGL and OpenAL as well, that's what Torque uses, and it seems to work on teh OSX machines.
-
I would, but it's too fun to make fun of Macs, and right now I'm in the mood for an easily ridiculed target.:D
And like I said. Unless you're gonna do it almost solo, it's not gonna happen, because few, if any, others here use Macs.
...and those that do have trouble sorting out how to open specific threads.:p I couldn't resist.
-
Kazan will probly get a lot of the hard stuf done,
he wants a Linux port like I want a woman :nod:
-
...which, even after partial sterilization by excessive exposure to monitor-generated EM radiation, is still a lot?:p
I woulda thought Linux could port FS...
-
1. case sensitivity in file names -- the file named MODEL.H is included as "Model.h" "model.h" etc. My solution was to convert all filenames to lower-case only (and update the #include lines to match)
Yeah, that was dumb. We no longer do things this way, for the record :)
2. Non-standard C++: using variable and struct members that have the same name as the type (stepped_rotation *stepped_rotation) I am renaming the probematic typedefs to use _t at the end (e.g., stepped_rotation_t), which is what POSIX does.
Again, also dumb. I'll have to break out the Programmer Bat and deal out some justice to the author of _that_ code ;)
4. Assembly in the texture mapping code. Dammit.
Unless you want to port Fred2, there's no need to deal with this. Game doesn't use it at all.
-
Originally posted by daveb
Unless you want to port Fred2, there's no need to deal with this. Game doesn't use it at all.
Methinks daveb just saved you guys a lot of work. [grin] THANKS FOR READING, DAVE!
--TurboNed
-
Originally posted by TurboNed
Methinks daveb just saved you guys a lot of work. [grin] THANKS FOR READING, DAVE!
--TurboNed
what he said :D Thanks daveb
Status as of 10am EDT: everything now compiles on RedHat Linux, using gcc 2.95.3. except the very-windows-specific stuff (low-level graphics, sound, directinput, startup code, networking). Yeah, I know it's a big "except..."
I'm feeling much better since I don't need to worry about the 10K+ lines of asm in the tmapper code. There are still small chunks of asm scattered about, but they're much more manageable.
Although it would be nice to have an "open" FRED2, it's not much of a priority to me or anyone I've heard from. Since it's an MFC application, 75% will probably need to be rewritten anyhow. GUI applications are tough to port, since the basic paradigm is so different between Win32, Mac, and the many X11 toolkits. I'll leave that as an exercise for the reader :p in the meantime, I'll use wrinkle my nose and continue to use Win98 for those rare occasions when I need to build a mission :o
I'm gonna check w/ the folks at SourceForge and see if the :V: license is "open" enough for them... if it passes (and if I hear no ovverriding objections from daveb or anyone else at :V: ) I'll try to upload the CVS repository to http://jumpnode.sourceforge.net
-
DaveTheEmbalmer don't pay too much attention to our resident Shivan, I think he's getting under the table cash from M$ ;)
In realistic terms though a mac FS is exceptionally unlikely. Any talk of porting is aimed at linux and unless you consider the possibility of OSX compatibility, you're not going to see macFS anytime soon.
Still. You mac guys got 'Escape velocity' so you got one up on us windoze users ;)
-
Originally posted by Stryke 9
I would, but it's too fun to make fun of Macs, and right now I'm in the mood for an easily ridiculed target.:D
Well, if you put it that way, I'll admit that maybe, just maybe, I'm being a teeeeensy weeeeensy bit of a hard ass :devilidea.
I was really just wondering if there was anyone already working on such a project. I think I'll just wait until there is an open source version of FS2 with all the stuff possible using some form of a cross platform API (OpenGL, OpenAL etc.) and start from there. Why do work when you can let someone else do it for you? :D
EDIT: Grammer Fix
-
I think sourceforge is a no-go, Warpcore seemed to think they had the band to handle the CVS. Otherwise, I will suck it up and get it set up on my servers.