Release FreeSpace 2


Hey, FS2Open dev here, this looks like some pretty awesome work.  Looked at your source diff from the FS1 thread, it looks like you're using a common binary with the FS1 and FS2 game data somehow?  And it also seems the code was based off of SVN revision 318?  We are actually looking at getting the SCP Core Profile compatible, and possibly also OpenGL ES compatible after that.  This might allow something like Diaspora, The Babylon Project, or the pending Star Wars: Fate of the Galaxy mods to be playable on Pandora then.
 
Hey, FS2Open dev here, this looks like some pretty awesome work.  Looked at your source diff from the FS1 thread, it looks like you're using a common binary with the FS1 and FS2 game data somehow?  And it also seems the code was based off of SVN revision 318?  We are actually looking at getting the SCP Core Profile compatible, and possibly also OpenGL ES compatible after that.  This might allow something like Diaspora, The Babylon Project, or the pending Star Wars: Fate of the Galaxy mods to be playable on Pandora then.
Hi there, and welcome.

For Freespace/Freespace2, I used code from Icculus vanilla version as a base.

About FS2Open, in fact, with the latest glshim library (that convert GL calls to GLES), I have a running build of FS2Open. I tried with FS2 datas and it runs fine. But with "The Babylon Project", I have some issue, as it seems it needs support for S3 compressed texture?

And with WC Legacy, I have other issue (don't remember exactly what). I haven't tried Diaspora.
 
Last edited by a moderator:
Retail data was just PCX with a built in converter, but most mods use DirectX Texture Compression (DXTC) which is supposed to be natively supported by most video cards and therefore allows storing the compressed textures in memory and saving texture space.  I believe the latest version of TBP (might need the Zathras patch found on the Community Development subforum of TBP on hard-light.net) should be using almost exclusively .dds (Direct Draw Surface) maps, which are compressed with one variant or another of DXTC.  The combination of glshim and DXTC and the color space swapping (BGRA vs RGBA) might be causing some issues, not sure.  We hope to get native OpenGL Core Profile soon though, which should also allow native OpenGL ES support with little work, and eliminate the glshim step.  Look for new versions of FSO to be released much more rapidly in the coming months, as I've just about finished fully automating the release build process, in a similar vein to the nightly build script I wrote years ago.  That should allow features to find their way into stable SCP releases much faster, and encourage more dev activity as well.  We'll also be moving to Github soon, so if you do feel like making any contributions to the SCP to help with OpenPandora support it will be as simple as submitting pull requests.

Also, I was the head of the SCP for several years until just recently and I didn't even know that icculus website existed, or had long forgotten.  Seems it's just a much much older revision of the SCP codebase, back when not much had been done except adding OpenGL and Linux support.  Still curious about one thing, and that's how it seems to natively support FS1 data.  As far as I know, the current SCP builds can't do that, due to slight differences in table formats, map and model chunk data, etc.  Did that just work for you, or am I misunderstanding something?
 
Retail data was just PCX with a built in converter, but most mods use DirectX Texture Compression (DXTC) which is supposed to be natively supported by most video cards and therefore allows storing the compressed textures in memory and saving texture space.  I believe the latest version of TBP (might need the Zathras patch found on the Community Development subforum of TBP on hard-light.net) should be using almost exclusively .dds (Direct Draw Surface) maps, which are compressed with one variant or another of DXTC.  The combination of glshim and DXTC and the color space swapping (BGRA vs RGBA) might be causing some issues, not sure.  We hope to get native OpenGL Core Profile soon though, which should also allow native OpenGL ES support with little work, and eliminate the glshim step.  Look for new versions of FSO to be released much more rapidly in the coming months, as I've just about finished fully automating the release build process, in a similar vein to the nightly build script I wrote years ago.  That should allow features to find their way into stable SCP releases much faster, and encourage more dev activity as well.  We'll also be moving to Github soon, so if you do feel like making any contributions to the SCP to help with OpenPandora support it will be as simple as submitting pull requests.
Yes the color space conversion (BGRA -> RGBA) slow video, and for now, DXTC is a no-go. I suppose I can hack some kind of support inside glshim, but I'm not sure about licensing issue (it should be ok as long as it's not in hardware, but I have to check).


Anyway, once in github and full OpenGL profile, I can work on an GLES renderer :)

Also, I was the head of the SCP for several years until just recently and I didn't even know that icculus website existed, or had long forgotten.  Seems it's just a much much older revision of the SCP codebase, back when not much had been done except adding OpenGL and Linux support.  Still curious about one thing, and that's how it seems to natively support FS1 data.  As far as I know, the current SCP builds can't do that, due to slight differences in table formats, map and model chunk data, etc.  Did that just work for you, or am I misunderstanding something?
Yep, that code base support both FS1 & FS2 (and the demo version too), but not at the same time, there are some Makefile variable to set. It's basically the original released sourcecode + linux/opengl support yet.
 
Dug. this out from a compilation CD which ive had years and not played, it runs really well on my CC unit :) cant believe i missed this for so long, even the menus are readable with my bad eyesight, thanks PtitSeb! by the way it cam on a CD with a game i DID want which was Freelancer, now that is a game i'd love to see on the Pandora, would it be theoretically possible given that its smaller than. freelancer, and seems to have the same PC specs (showing my ignorance again  :unsure: )
 
Dug. this out from a compilation CD which ive had years and not played, it runs really well on my CC unit :) cant believe i missed this for so long, even the menus are readable with my bad eyesight, thanks PtitSeb! by the way it cam on a CD with a game i DID want which was Freelancer, now that is a game i'd love to see on the Pandora, would it be theoretically possible given that its smaller than. freelancer, and seems to have the same PC specs (showing my ignorance again  :unsure: )
I don't think there are any sources available for Freelancer, sorry.
 
Good news then ptitSeb, both the Github transition and the OpenGL core profile support are under way and might be done this year, possibly after this next release or two.
 
So, I have done some work on the DXTc side of glshim.

So I move forward... Than I had some "Bus Error", because of some float reading on unaligned address (in parse_tmap function, and in the modeloctan.cpp file). Fixed (using some memcpy instead, like I had done with Project X Forsaken).

The Babylon Project start now.

It's a very professional game! Very impressive PreRendered intro, very nice breifing voice. The modeling of the ships are nicely done too.

But a very heavy game! I get Segfault from the very beggining with default settings, and I get a bit into game when I lower setting donw a bit. I'm going to implement some autodownscaling of DXTc textures to save memory, as I suspect the segfault is du to some lack of GPU Mem or something like that (don't forget all DXTc texture is expanded to RGBA 32bits, so maybe also converting to RGBA 16bits could be a good move).

Here are some screenshots (mostly of the prerendered cinematics and GUI).

babylon1.png

babylon2.png

babylon3.png

babylon4.png

babylon5.png
 
Ok, found the segfault. It's caused by the Particle system that wants VBO. But it's not implemented yet on glshim, so I disabled them in the code for now.

Seems to works now.

babylon6.png
 
New build on the repo.
Mouse button fixed, default control are the Pandora ones, and a script to automatically extract the data from GoG version (just put the setup_freespace2_*.exe in appdata/freespace2).
Also, full sources are on my github now.

Build 07
----------

  • Fixed mouse buttons issues
  • Default config is now the Pandora one
  • Fixed a potential segfault
  • Added script to automatically extract GoG data from setup exe
 
Splendid work as usual. Pleased for the mouse button fix; this is a game that likes many buttons.
 
Back
Top