Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: chief1983 on November 02, 2011, 09:43:20 pm
-
RC2 here. (http://www.hard-light.net/forums/index.php?topic=79332.0) Go there.
(http://scp.indiegames.us/img/irrelephant.jpg)
The long-awaited 3.6.14 RC1 build is here at last!
Previous 3.6.12 Release Thread (http://www.hard-light.net/forums/index.php?topic=70692.0)
Important!!
As always, you need OpenAL installed. Linux and OS X come with it but Windows users will need to get Creative's OpenAL installer (http://connect.creativelabs.com/openal/Downloads/oalinst.zip).
Important!!
Also, since the internal code linking for TrackIR was revised, an external DLL is now required for FSO to use TrackIR functions.
The following DLL is simply unpacked in to you main FreeSpace2 root dir.
TrackIR is only supported on Windows.
TrackIR SCP DLL (http://www.mediafire.com/download.php?ihzkihqj2ky)
Launchers, if you don't have one already:
Windows: Launcher 5.5g (http://swc.fs2downloads.com/files/Launcher55g.zip) (Mirror (http://www.mediafire.com/?wdvzn7hhhzh418m))
OS X: Soulstorm's OS X Launcher 3.0 (http://www.hard-light.net/forums/index.php/topic,51391.0.html)
Linux: YAL (http://www.hard-light.net/forums/index.php/topic,53206.0.html) or by hand (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Graphics_Settings) or whatever you can figure out.
All platforms: wxLauncher (http://www.hard-light.net/forums/index.php?topic=67950.0) (ongoing project for a unified launcher)
Known issues:
- The now-standard Inferno builds have trouble converting retail pilots. You might experience crashes. Post logs.
- See the list of Fix for next release (http://scp.indiegames.us/mantis/search.php?project_id=1&status_id%5B%5D=10&status_id%5B%5D=20&status_id%5B%5D=30&status_id%5B%5D=40&status_id%5B%5D=50&priority_id%5B%5D=40&priority_id%5B%5D=50&priority_id%5B%5D=60&sticky_issues=on&sortby=last_updated&dir=DESC&per_page=200&hide_status_id=-2) bugs - mark a bug as an elevated priority (high, urgent, immediate) to get it included in that filter.
- Here is the filter for Target 3.6.14 (http://scp.indiegames.us/mantis/search.php?project_id=1&status_id%5B%5D=10&status_id%5B%5D=20&status_id%5B%5D=30&status_id%5B%5D=40&status_id%5B%5D=50&sticky_issues=on&target_version=3.6.14&sortby=last_updated&dir=DESC&hide_status_id=-2) bugs.
Shaders
In order to leverage changes in the shader code since 3.6.12, these are to be used to over-ride the MediaVPs shaders or in use for any mods.
Includes the Animated/Cloakmap shaders as well as optimized pixel lighting fragment shaders.
Main_Shaders-3.6.14.zip (http://swc.fs2downloads.com/builds/Main_Shaders-3.6.14.zip)
MD5: 4DC66A4114B6075B686797D381606144
WINDOWS Builds
Inferno Builds
If you don't know which one to get, get the third one (no SSE). If you don't know what SSE means, read this: http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
You can use freely available tools like CPU-Z (http://www.cpuid.com/softwares/cpu-z.html) to check which SSE capabilities your CPU has.
fs2_open_3_6_14_RC1.zip (http://swc.fs2downloads.com/builds/WIN/fs2_open_3_6_14_RC1.zip)
This one is based on the SSE2 Optimizations from the MSVC Compiler.
MD5: 1390ba7a914dc715abdfcc91c141895d
fs2_open_3_6_14_SSE_RC1.zip (http://swc.fs2downloads.com/builds/WIN/fs2_open_3_6_14_SSE_RC1.zip)
MD5: ad413a7187cabfe2c9ee98b13aa41902
fs2_open_3_6_14_NO-SSE_RC1.zip (http://swc.fs2downloads.com/builds/WIN/fs2_open_3_6_14_NO-SSE_RC1.zip)
MD5: 7ec47343472a78a68461f339e68b516b
What are those SSE and SSE2 builds I keep seeing everywhere?
Your answer is in this topic. (http://www.hard-light.net/forums/index.php?topic=65628.0)
OS X Builds
Inferno Build
FS2_Open-3.6.14_RC1.dmg (http://swc.fs2downloads.com/builds/OSX/FS2_Open-3.6.14_RC1.dmg)
MD5: 52cec209f6f115193263aa446a828419
LINUX Builds
Inferno Build
fs2_open_3.6.14_RC1.tar.bz2 (http://swc.fs2downloads.com/builds/LINUX/fs2_open_3.6.14_RC1.tar.bz2)
MD5: f5f8544321833c46af3d7d1503fa446f
Source Code Export
pending
MD5:
Changelog since the last RC:
( Additionally, see here: 3.6.13 Changelog (since 3.6.12) (http://www.hard-light.net/forums/index.php?topic=69362.0) )
Trunk SVN Log (http://svn.icculus.org/fs2open/trunk/fs2_open/?date=all&view=query), 3.6.14 was branched at r7811, further logs for the 3.6.14 branch can be found at 3.6.14 SVN Log (http://svn.icculus.org/fs2open/branches/fs2_open_3_6_14/?date=all&view=query).
-
Oh dang! It just went down!
Edit: is there any particular reason for this occasion?
-
Is the first Windows build listed SSE2?
-
Yep - SSE2 builds are now considered the default.
-
Why the builds are still being called Inferno builds even when there aren't even alternatives being provided anymore? Doesn't look like "INF" is part of file names anymore either.
-
They are still Inferno builds (same compile options and increased limits) :) It's just that they've become the default build, therefore INF was removed from the filename. If you want to build your own binaries the option to build NO-INF binaries (the old default) still exists (for now). However a decision was made to not provide the NO-INF binaries as part of this release.
edit: spelling!!
-
Stupid question.... i don't notice any more SSE2 build...
does that mean the first, standard one is SSE2?
-
Yep - SSE2 builds are now considered the default.
-
It's just that they've become the default build, therefore INF was removed from the filename
For very same reason I think they shouldn't be specifically categorized as Inferno builds anymore because any alternatives aren't being offered either. Not really important, but sometimes less is more when dealing with people new to FSO.
-
Good to see the sound code fix is in. The ingame sound is a lot more enjoyable this way.
Not waiting for shadows though?
-
No, unfortunately not. Shadows are still nowhere near being trunk-ready, let alone RC material.
-
For very same reason I think they shouldn't be specifically categorized as Inferno builds anymore because any alternatives aren't being offered either. Not really important, but sometimes less is more when dealing with people new to FSO.
Yes but this is the big change over. If we suddenly stopped calling them Inferno Builds now we'd have the same issue we're having on the thread above with SSE2. By the time we get to the official build a short announcement that Inferno is now default should suffice. Something like :
"If you're a developer looking for an Inferno build, those features have now been merged into this build. Non-Inferno builds may be built on request if required for bug fixing"
Something like that makes it obvious that this isn't something newbies need care about. And by the time we move on to 3.6.16 or 3.7 we won't even bother with that.
-
Does this have the pilot code from Antipodes 8?
-
No. This is the last release to use the old pilot code, after that we'll merge the AP branch into trunk.
-
Does this have shadows??
-
Does this have shadows??
No.
-
I'll give this a run after my midterm this afternoon, see if any issues pop up.
-
did my armor patch make this?
i also want to verify the status of rtt cameras. there was an issue of a render frame call only using 1/8th of the resolution of the texture. im about to test this.
simple rtt debug script is fail.
what should happen:
rear view camera texture should draw on hud and fill the box (as seen in 3.6.12).
what happens now:
the screen is black, the empty box in which the texture should go still draws to the black screen.
what should have been the contents of the texture is rendered in a tiny square it the bottom left of the screen,
partially obscured by the box which denotes where the texture should draw.
;rtt test script
;creates a rear view camera, then renders it to texture
;this texture is drawn to fill the green and blue box on the hud
;image should completely fill the box
#Conditional Hooks
$Application: FS2_Open
$State: GS_STATE_GAME_PLAY
$On State Start:
[
tex = gr.createTexture(255,255,TEXTURE_DYNAMIC)
cam = gr.createCamera("rearview")
]
$On Frame:
[
ship = mn.Ships["Alpha 1"]
if cam:isValid() and ship:isValid() and tex:isValid() then
--attatch camera to the ship
cam.Self = ship
--point camera backwards
cam.Orientation = ba.createOrientation(0,0,math.pi)
cam.Position = ba.createVector(0,0,-15)
--set render target
gr.CurrentRenderTarget = tex
--backfill
gr.clearScreen(0,0,0,255)
--set camera
gr.setCamera(cam)
--draw scene
mn.renderFrame()
--reset camera
gr.setCamera()
--reset target
gr.CurrentRenderTarget = nil
--draw textures on hud
x1,y1,x2,y2 = 8, gr.getScreenHeight()-tex:getHeight()-8, tex:getWidth()+8, gr.getScreenHeight()-8
--draw debug square first
gr.setColor(0,0,255,255)
gr.drawRectangle(x1,y1,x2,y2,true)
gr.setColor(0,254,0,255)
gr.drawLine(x1-1,y1-1,x2+1,y1-1)
gr.drawLine(x1-1,y2+1,x2+1,y2+1)
gr.drawLine(x1-1,y1-1,x1-1,y2+1)
gr.drawLine(x2+2,y1-1,x2+2,y2+1) --draw primitives are still innacurately positioned, lol
--now draw the texture
gr.drawImage(tex,x1,y1,x2,y2)
end
]
$On State End:
[
tex:unload()
]
#end
-
Not waiting for shadows though?
No, unfortunately not. Shadows are still nowhere near being trunk-ready, let alone RC material.
:yes:
There'll always be something new and awesome around the corner - waiting for every feature is a great way to never make it to release. Congrats to the SCP guys for doing what many campaigns can't and avoiding crippling feature creep.
-
It says "3.6.13:7903" on the bottom, when I launch the game with Windows 3.6.14 RC1.....
Can someone please confirm?
-
That is correct and as intended.
-
Then what is different between 3.6.14 RC1 and the latest 3.6.13 builds, other than the sound code?
-
The sound code.
The point is, this is a snapshot of the current svn, one we feel is stable and feature-rich enough to deserve the label "3.6.14". Barring some bugs appearing in there, that's what is going to be the next stable version.
-
And while it does deserve the label 3.6.14 the emphasis is on release CANDIDATE, it is still a developmental build, same as the .13 nightlies, do not confuse it with a release build.
-
i think the reason it carries the 3.6.13 version number is so that it doesnt get mistaken for a release build (which i believe has happened before) causing support issues. so consider it an evaluation of trunk which may or may not become the 3.6.14 build of which there should only be one.
-
i think the reason it carries the 3.6.13 version number is so that it doesnt get mistaken for a release build (which i believe has happened before) causing support issues. so consider it an evaluation of trunk which may or may not become the 3.6.14 build of which there should only be one.
That is precisely the reason that the RC identifies itself as .13 and why we skip the odd numbers for the releases so that the version number is always increasing.
-
http://scp.indiegames.us/mantis/view.php?id=2509 still happens. http://pastebin.com/YHx5QhX3
-
http://scp.indiegames.us/mantis/view.php?id=2509 still happens. http://pastebin.com/YHx5QhX3
I have posted a reply (http://www.hard-light.net/forums/index.php?topic=77314.msg1561082#msg1561082) in that thread. Lets continue the debugging there.
If anyone else is able to replicate the issue that Qent is reporting please post in the linked thread
-
Also This is still hapening http://scp.indiegames.us/mantis/view.php?id=2506
-
Without more detailed information about how to reproduce that crash, there's nothing we can do to fix it.
-
That's a duplicate of this bug. (http://scp.indiegames.us/mantis/view.php?id=2521)
-
I'm still getting the subspace flare issue on this build.
I couldn't find the Mantis issue, sorry.
-
That's a duplicate of this bug. (http://scp.indiegames.us/mantis/view.php?id=2521)
Indeed
However with the RC1 build I still need to uncheck recheck the boxes for the ships to appear on the list, I can't get it to crash with this build though.
Still works fine with debug.
-
i updated the rtt bug (#2400 (http://scp.indiegames.us/mantis/view.php?id=2400)) with the most recent information i had about the issue.
-
So how long for the .14 MVPs?
And will we release .16 when shadows are ready?
Also, when this does hit release, will the debug build be obviously labeled as such?
-
So how long for the .14 MVPs?
And will we release .16 when shadows are ready?
Also, when this does hit release, will the debug build be obviously labeled as such?
Not relevant to this.
We already have more than enough stuff for the following release, so only if shadows are done in time, and if we want to add even more new features in.
Yes.
-
Can has feature list link plox?
-
ASSERTION: "num == bm_bitmaps[n].handle" at bmpman.cpp:2469
Int3(): From c:\code\fs2_open_3_6_14_rc1\code\globalincs\windebug.cpp at line 902
Is this one still not fixed? How long have we been encountering this one?
-
That one does not have a single cause. Complaining that it's not been fixed is like complaining that sudden crashes while playing hasn't been fixed!
-
What causes that!?
-
What causes that!?
Strictly speaking, it means that the bitmap handler doesn't have the bitmap that it thinks it does, which can be anything from running out of bitmap handles to bad formatting of the textures to a screwup in the code somewhere, without an example that does it reliably we are just guessing.
That code is literally called from dozens of places, but until spoon files a mantis report with reproduction information there is nothing that we can do.
-
That one does not have a single cause. Complaining that it's not been fixed is like complaining that sudden crashes while playing hasn't been fixed!
Reporting and asking why = complaining now? With this attitude I'm becoming less and less inclined to even bother trying to help.
That code is literally called from dozens of places, but until spoon files a mantis report with reproduction information there is nothing that we can do.
Oh I see, a crash that several people have encountered over time has somehow become my sole responsibility to track down.
-
....
Could we please not have drama about this? Please?
First of all, Spoon, saying Is this one still not fixed? How long have we been encountering this one?
really does sound an awful lot like complaining.
Second, whatever the cause of this bug is, it's not reproducible on standard FS2, but requires some arcane combination of assets to get it to appear. I know that for a time, BP:WiH2 caused it, and I tried to address that issue in code, which seemed to make it go away. I still do not know exactly what happened, and my fixes were blind guesses as to what was happening. As with any bug, being able to reproduce it is key to being able to fix it, and in this case, I suspect that the actual cause of the bug is far removed from the Assert that is triggered; as such, tracing it is a nontrivial process. So please, if you have a test case that can reliably reproduce the issue, please share it. We literally can't do anything about this otherwise, unless some other team stumbles across this issue by chance.
-
Reporting and asking why = complaining now? With this attitude I'm becoming less and less inclined to even bother trying to help.
Your earlier post did sound a bit like a complaint to me but it's possible I was reading it wrong. If so I apologise.
Oh I see, a crash that several people have encountered over time has somehow become my sole responsibility to track down.
As I pointed out in my first post there is more than one cause for this problem. There is no guarantee that whatever is causing their crashes is causing yours. So you can wait for someone else to get an issue, let a coder solve it and then still find you're getting a crash because there was more than one issue.
-
....
Could we please not have drama about this? Please?
Well if Karajorma could stop jumping at everything I post :blah:
First of all, Spoon, saying Is this one still not fixed? How long have we been encountering this one?
really does sound an awful lot like complaining.
It sounds like 2 questions to me.
Second, whatever the cause of this bug is, it's not reproducible on standard FS2, but requires some arcane combination of assets to get it to appear. I know that for a time, BP:WiH2 caused it, and I tried to address that issue in code, which seemed to make it go away. I still do not know exactly what happened, and my fixes were blind guesses as to what was happening. As with any bug, being able to reproduce it is key to being able to fix it, and in this case, I suspect that the actual cause of the bug is far removed from the Assert that is triggered; as such, tracing it is a nontrivial process. So please, if you have a test case that can reliably reproduce the issue, please share it. We literally can't do anything about this otherwise, unless some other team stumbles across this issue by chance.
Aright, that's clear enough and answers my question.
Your earlier post did sound a bit like a complaint to me but it's possible I was reading it wrong. If so I apologise.
Well apology accepted, but you really ought to stop jumping on every post I make. Cause inbetween this post and the last 2 encounters we had it's really hard for me not to have this feeling you got this personal grudge against me. (and after that lovely pm exchange we had, I'm pretty sure that you do tbh.)
-
Nope, no issue. My list of enemies is short (and getting shorter by the day as The Plan reaches completion.) :p
-
Nope, no issue. My list of enemies is short (and getting shorter by the day as The Plan reaches completion.) :p
:shaking:
-
Dubble posting because I can.
I actually do have a reproduceable situation of this crash, in debug it always seems to happen right when a capital ship is about to blow up.
-
If you have a test mission that produces the error, and that you can share with us, that would greatly help in finding & solving the issue.
-
If you have a test mission that produces the error, and that you can share with us, that would greatly help in finding & solving the issue.
I'd love to, but you'd need the whole wod2 svn to play the mission. (which I wouldnt mind sharing to the coders that are interested in trying to fix this thing)
-
I'm happy to have a go at solving the issue - how do I access the wod2 svn? :)
-
I'm happy to have a go at solving the issue - how do I access the wod2 svn? :)
Shooting you a pm asap
-
Here's a bug. When using the F3 ship lab, open a box (e.g. Class Description) and try to close it. It won't work. 3.6.12 had it working before.
EDIT: New bug. F3 to Weapons to Lasers to Subach HL-7. Click on Class Variables. Crash. Doesn't happen in 3.6.12.
-
Here's a bug. When using the F3 ship lab, open a box (e.g. Class Description) and try to close it. It won't work. 3.6.12 had it working before.
EDIT: New bug. F3 to Weapons to Lasers to Subach HL-7. Click on Class Variables. Crash. Doesn't happen in 3.6.12.
Both fixed in trunk.
-
Noticed some quirks with the new HUD. Some of these observations aren't new and found back in the latest antipodes 7 release but since I got something to say about this release as well, I'll stick them in here.
-The 'killed by' and 'viewing from' messages are colored red instead of being the same color as the messages. If that's how it's supposed to be, then fine.
-The 'killed by' and 'viewing from' messages are placed higher than usual. The 'viewing from' message in particular gets in the way of the messages.
-The 'killed by' message no longer shows up in 3.6.14 RC1. This was a bug somewhere in antipodes 7 that got fixed but for some reason it resurfaced.
-The first line of messages is slightly cut off at the top when there's three lines of messages present.
-The 'Message' label of the head ani is slightly displaced.
Also, I noticed a bug with 3.6.12 (also from retail?) where the 'viewing from' message (and I assume also the 'killed by' message) is initially colored deep green then only uses the user defined color when a message shows up.
-
Got a weird problem;
I downloaded the RC and Launcher 5.5g, but when I try to set fs2_open_3_6_14_RC1.exe as the Freespace executable it churns away for a bit and then crashes with the good ol' "Launcher.exe has generated errors and will be closed by Windows" dialog.
Anyone else had this...?
Not sure if it's of any relevence but my system is Win2K SP4 with a GeForce 7950GT (Forceware 172.28)
The actual game will run fine if I run it manually (with linux-long command line params ;))
-
We do not support Win2K actively. There may be issues with that OS and the OS version the Launcher is compiled against.
-
Couldn't say; It's fine with .12... I suspect it's crapping out when retrieving the options in .14 so there may be some issue with whatever entrypoint it uses to pull the options list?
Also, I've noticed some odd glitches with the sound; It's like it's running out of channels, or sometimes not loading the sound file at all.
In the newly voice acted Fall of Epsilon Peg for instance, the briefings sometimes have not voice, but if i play the mission, die then restart they suddenly will or vice versa.
In game, I sometimes notice certain weapons/effects (e.g. afterburner, collision, shield) will lose their sounds, but sometimes get it back later!
-
Is there any possibility of getting another updated build (or possibly another Nightly) as there are fixes to a series of FRED bugs pertaining to jumpnodes in Head that need testing, and I'm afraid that I'm not set up to compile FRED myself.
-
Jump nodes aren't broken in RC .14 though. That's only in Trunk. Check your PMs, I'll send you my FRED build.
-
Thanks.
-
Hello, I am having trouble running the 3.6.14 build on Kubuntu Linux 11.04 amd64.
I have already installed ia32-libs, and I recently installed (using getlibs) a few packages, whose names I cannot remember.
When I run the game, I get the following output on the command line:
./fs2_open_3.6.14_RC1: /usr/lib32/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./fs2_open_3.6.14_RC1)
3.6.12 runs fine with exactly the same command line options.
People in #hard-light have suggested to compile the Linux executable from source code, but you have not provided any on this page.
System specs in brief:
OS: Kubuntu 11.04 amd64 (and Windows Vista, in which 3.6.14RC1 runs successfully)
Graphics card: ATi Radeon HD 5570
Graphics driver: the one provided by jockey-kde (Presumably fglrx 2:8.840-0ubuntu4; see http://packages.ubuntu.com/natty/fglrx)
Q1: could you tell me where I could find the source code? (is it in SVN?)
Q2: could anyone explain why 3.6.14RC1 is not working, but 3.6.12 is?
EDIT1:
Command line options:
./fs2_open_3.6.14_RC1 -spec -env -glow -missile-lighting -normal -3dshockwave -dualscanlines -targetinfo -rearm_timer -ship_choice_3d -weapon_choice_3d -3dwarp -snd_preload -fps -res 1680x1050 -mod mediavps_3612
-
You get the source code from a subVersion repository.
-
You get the source code from a subVersion repository.
Specifically, the SVN repository for the RC is found at: svn://svn.icculus.org/fs2open/branches/fs2_open_3_6_14/
-
Thanks for clarifying that. I didn't know, myself. I just know the overall SVN trunk, so I figured I'd err to the side of being general, as someone else had to know the specifics.
-
Hi guys; I decided not to go down the re-compile route yet; instead I tried to work with the current binary.
Using this suggestion (http://stackoverflow.com/questions/4133674/glibcxx-versions), I ran
strings /usr/lib32/libstdc++.so.6and got this output:
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
No mention of GLIBCXX_3.4.15.
So I manually downloaded the libstdc++6 package for Oneric Ocelot (Ubuntu 11.10), and replaced the old /usr/lib32/libstdc++.so.6 and libstdc++.so.6.0.14 with
libstdc++.so.6 and libstdc++.so.6.0.16 from the Oneric 11.10 package.
Output of strings /usr/lib32/libstdc++.so.6 |grep GLIBCXX now includes the lines:
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTHso promising.
However, when I run the fs2_open_3.6.14_RC1 executable, I get this error:
./fs2_open_3.6.14_RC1: error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS64I think this is because I symlinked my /usr/lib/libstdc++.so.6 to the one in /usr/lib/x86_64-linux-gnu/
So I instead symlinked /usr/lib/libstdc++.so.6 to /usr/lib32/libstdc++.so.6. Output:
mesh-c2q:~/freespace2$ ./run_fs2open_3.6.14RC1.sh
./fs2_open_3.6.14_RC1: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: Permission denied
So tried running it in sudo:
sudo ./run_fs2open_3.6.14RC1.sh
Unrecognized command line parameter "-missile-lighting". Ignoring...
Home directory /home/username not ours.
Home directory /home/username not ours.
Home directory /home/username not ours.
Home directory /home/username not ours.
./run_fs2open_3.6.14RC1.sh: line 4: 12551 Segmentation fault ./fs2_open_3.6.14_RC1 -spec -env -glow -missile-lighting -normal -3dshockwave -dualscanlines -targetinfo -rearm_timer -ship_choice_3d -weapon_choice_3d -3dwarp -snd_preload -fps -res 1680x1050 -mod mediavps_3612For a brief period, I saw a 1680x1050 window filled with black, as if the game were about to start. But then I get the segmentation fault.
For reference, I've been using a shell script to invoke the game executable:
#!/bin/bash
#cd ~/fs2open
./fs2_open_3.6.14_RC1 -spec -env -glow -missile-lighting -normal -3dshockwave -dualscanlines -targetinfo -rearm_timer -ship_choice_3d -weapon_choice_3d -3dwarp -snd_preload -fps -res 1680x1050 -mod mediavps_3612
Thoughts? If I have an opportunity tomorrow, I shall try to compile the code. Where should I start? Because when I paste http://svn.icculus.org/fs2open/branches/fs2_open_3_6_14/ into Firefox, I get a whole load of folders, and I don't see any files named "configure" nor "make".
P.S.: sorry for my newbieness; I have patchy experience with using Linux.
Also sorry for the wall of text.
-
Unrelated to my previous Linux-oriented posts, I just wanted to praise this release candidate on providing pleasant surround sound!
Speakers: (el-cheapo Logitech) 5.1 setup.
Soundcard: Realtek onboard audio ("MCP51 High Definition Audio"), part of the Asustek P5N-E SLI motherboard.
OS: Windows Vista 32-bit
Sounds such as gunfire is definitely panning around as I turn my ship.
There are a few minor problems: for instance, sometimes the sound stutters -- more noticeable when a voice is being played (e.g. when Command or wingmen speak). Also, I think some sounds are not playing; I'm not sure if this is because those sound sources are too far away, or because my soundcard is crap :P
I did not have to use the RealTek 3d Sound Back utility.
If you need me to test anything to do with 3d/surround sound, please get in touch.
EDIT: I forgot to mention, with the openal32.dll supplied by Creative Labs, I was getting crackling and harsh sounds from the speakers, overlaid on the proper ones (iirc). I found that using OpenALSoft (http://kcat.strangesoft.net/openal.html) solved all these problems, and got the 3d / surround sound working.
(Instructions: get file from http://kcat.strangesoft.net/openal.html, back up the OpenAL32.dll that is found in the Freespace 2 folder, extract openal-soft-1.13-bin\Win32\soft_oal.dll to the Freespace 2 folder, rename soft_oal.dll to OpenAL32.dll)
-
Thoughts? If I have an opportunity tomorrow, I shall try to compile the code. Where should I start? Because when I paste http://svn.icculus.org/fs2open/branches/fs2_open_3_6_14/ into Firefox, I get a whole load of folders, and I don't see any files named "configure" nor "make".
First, take a look at the FS wiki's notes on compiling FSO on Linux (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Preparation) to make sure you have installed both Subversion and the necessary development libraries for compiling FSO. Before installing anything, though, update your local listing of the contents of your distro's repository by typing
sudo apt-get updateat a shell prompt. You'll be prompted to type your user password.
The wiki's instructions will have you download the code in trunk; to check out a copy of the code from the 3.6.14 branch, type
svn co svn://svn.icculus.org/fs2open/branches/fs2_open_3_6_14which will check out a copy and put it in a folder called fs2_open_3_6_14 in your current directory.
As for compiling, once you've checked out the code and installed the development libraries, type
./autogen.shIt looks like autogen.sh automatically runs configure for you.
If all goes well, the result will be a Makefile, at which point you can type
maketo compile FSO.
Hope that helps.
[Disclaimer: Although I've compiled software on Linux before, I've never compiled FSO specifically. ;)]
EDIT: When installing the development libraries (http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/Installing_the_Development_Libraries) (for Kubuntu, use the Ubuntu listing), you'll need to prefix the command with sudo (which means "do as superuser/administrator"), since you need administrator rights to install software. In other words, instead of typing
apt-get install etc. etc. type
sudo apt-get install etc. etc. and then type your user password when prompted.
Those pages would benefit from some revisions; it's on my TODO list but I'm not sure when I'll get to it. :doubt:
-
The current 3.6.14 Linux binaries were made with an older GCC than normally used on Ubuntu now as a workaround for a compilation issue. That issue has since been more permanently fixed, and the next RC will be built with a newer GCC, so you might have more luck when it is released. Emphasis on might.
-
I find that I can't run the 32bit pre-built Linux binaries on my 64bit Linux system, there's some library somewhere that doesn't seem to have a 32bit version (I didn't bother tracking it down, I just built from source - if we ever get around to building native Linux packages this problem will go away... fairly big ongoing task though to cover the major distros and their various current releases)
I also don't think that replacing your 11.04 libraries with 11.10 ones is a good idea, it may work, but it may equally break something horribly.
Building FSO is pretty easy, between the wiki & jg18's instructions you should be able to get it figured out if you built other programs before.
-
jg18: thanks very much for your clear instructions; I shall try to follow them later today! Certainly some point in the near future.
chief1983: eagerly awaiting the RC2!
niffiwan: true; I think I shall restore the original ones, in order to avoid breaking anything.
-
So, I had an absolute derp moment when I realized that the Official Shaders were not posted for linking in the first post. This has now been rectified.
The 3.6.12 MediaVPs shaders of course will and do still work, but they are not the most efficient when compared to these shaders.
-
Hello, all! Very glad to see development on one of my favoritist games continues. . . Quick Question, though.
Where am I supposed to extract those new shaders to?? I assume they go into the MediaVPS_3612 folder? (No instructions on front page)
-
Put em in Mediavps_3612 > Data > Effects
So I obtained a call stack of that bitmap handle crash I keep getting with RC1 debug when a ship explodes
http://pastebin.com/5Yq6bAxZ
Does this tell anyone anything? (I pm'd this to niffiwan already, but he seems busy with things as I haven't heard from him for a while now)
-
Unfortunately, no. The assertion is a standard bmpman sanity check; triggering it means that something has gone wrong somewhere else.
To elaborate, here's what's happening:
Whenever the engine loads a bitmap, it assigns a unique handle to that bitmap. The handle is generated by taking an internal counter multiplying it by the max number of bmpman slots and adding the number of the first free bitmap slot. Internally, the engine tracks bitmaps only by their handle; when it needs to get the actual data from the bitmap (when accessing a texture, for example), the handle is passed to bmpman (BitMaP MANager, the subsystem in charge of bitmap handling). bmpman then takes that handle, applies a modulo (Max number of bitmaps) operation to it, and gets the index into the bitmaps array to get to the actual data.
The sanity check it is tripping over here is a very simple comparison between the number passed to bmpman, and the handle of the bitmap actually present in the bitmap array at the index indicated by the passed map. If they are different, something is very definitely wrong.
-
Well what do I do then? I can't use debug because it crashes everytime a capital ship blows up. Nobody can reproduce the error and this call stack business turned out fruitless too.
Not being able to use debug for inmission errors is kinda putting a damper on development...
Edit: I am now 90% certain the crash is caused by framebuffer shockwaves...
-
I have some good news - I've managed to reproduce the bug, and I have a possible workaround :)
Remove this option in the launcher:
Enable Framebuffer Shockwave
-fb_explosions
It's worked for me so far, enable it and crash 3 times in a row. Disable it and run normally 3 times in a row.
Edit: you're one step ahead of me :D
-
Haha :D
Thanks for confirming, I'm happy to see that it was not just me :p
-
Put em in Mediavps_3612 > Data > Effects
Thank you, sir!
-
Can that engine ripple effect be made optional? I hate it and it has a huge performance hit on my GPU.
-
while modding i found this very same crash with ASSERTION: "num == bm_bitmaps[n].handle" at bmpman.cpp:2504 , same fix, disable framebuffer on the launcher and the debug build dosn't crashes anymore.
-
What were you doing when the crash occurred? Was it a capship blowing up, or something else?
-
while modding i found this very same crash with ASSERTION: "num == bm_bitmaps[n].handle" at bmpman.cpp:2504 , same fix, disable framebuffer on the launcher and the debug build dosn't crashes anymore.
Have seen this one during Diaspora development. What ship is blowing up?
-
So I don't follow the community as much as I used to...what's the status on the 3.6.14 MediaVPs to go along with this from FSU?
-
Updated MediaVPs will be released when they are ready. We are not tied to releasing along with SCP. I cannot guarantee that there will or won't be a 3.6.14 MediaVPs.
-
Ok the crash was coming from the framebuffer shockwave code i assumed the default shockwave animation to be always loaded but it seems that when no bombs define the animation as their shockwave it doesnt get loaded bam crash i commited a fix to trunk
-
Thank you very much sir! I can confirm that the patch fixed the issue in the WoD2 mission Spoon gave me.
edit: fix spelling...
-
Valathil... do you think this fix could effect (possibly related?) crashes on capital ship explosions?
I have noticed a minor chance to crash when cruiser+ class ships explode ;o
-
To echo QD's report, while I have not experienced the crash myself, I have noticed that the hosts of multiplayer games sometimes crash during capital ship explosions.
-
No cause-of-death messages (http://scp.indiegames.us/mantis/view.php?id=2549)
Seems worth fixing for 3.6.14, ya?
-
Valathil... do you think this fix could effect (possibly related?) crashes on capital ship explosions?
I have noticed a minor chance to crash when cruiser+ class ships explode ;o
if you have framebuffer explosions enabled yes
-
No cause-of-death messages (http://scp.indiegames.us/mantis/view.php?id=2549)
Seems worth fixing for 3.6.14, ya?
confirmed (vanilla data)
-
Anyone care to post idea what the status of this release is? The front page at HLP still says release candidate, but that is over two months old now. And this thread hasn't seen any comments since mid-december..
Just curious what is happening..
Best wishes,
Oscar
-
Anyone care to post idea what the status of this release is? The front page at HLP still says release candidate, but that is over two months old now. And this thread hasn't seen any comments since mid-december..
Just curious what is happening..
Best wishes,
Oscar
We're on RC2 (http://www.hard-light.net/forums/index.php?topic=79332.0) now (which is a sticky), and hopefully RC3 sometime soon.