Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Nightly Builds => Topic started by: SirKnightly on October 29, 2010, 02:20:38 pm
-
Here is the nightly for OS X on 29 Oct 2010 - Revision 6705
Group: Inferno
fso-OSX-Inferno-20101029_r6705.tgz (http://swc.fs2downloads.com/builds/OSX/fso-OSX-Inferno-20101029_r6705.tgz)
MD5Sum (http://swc.fs2downloads.com/builds/OSX/fso-OSX-Inferno-20101029_r6705.md5)
------------------------------------------------------------------------
r6697 | The_E | 2010-10-28 20:10:19 -0500 (Thu, 28 Oct 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/parse/sexp.cpp
Patch for minor snafu, from FUBAR
------------------------------------------------------------------------
r6699 | The_E | 2010-10-28 21:22:51 -0500 (Thu, 28 Oct 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/parse/sexp.cpp
Adding a warning and proper error handling to the "/" operator in order to catch div-by-zero scenarios.
------------------------------------------------------------------------
r6700 | The_E | 2010-10-28 21:44:14 -0500 (Thu, 28 Oct 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/mission/missionparse.cpp
Fix for faulty check
------------------------------------------------------------------------
r6701 | The_E | 2010-10-28 23:14:13 -0500 (Thu, 28 Oct 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/parse/sexp.cpp
Woops. How did I screw this up?
------------------------------------------------------------------------
r6704 | chief1983 | 2010-10-29 14:09:26 -0500 (Fri, 29 Oct 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/windows_stub/stubs.cpp
This should fix a OS X 10.5 crash, possibly others.
------------------------------------------------------------------------
-
This should be running on 10.5 again. Please verify and report your findings.
-
I am pleased to report the divide by zero error appears to have been squashed. Unfortunately, for testing purposes I am now running OS10.6. However, the bug still appears in 10.6 in older builds, so I doubt that is an issue. I have 10.5 ready should the need to testing be required.
Also unless this is a bit of news I missed, for 10.6, I am guessing with the Apple GFX update, the -nogls flag no longer needs to be used as it now appears not to incur the performance penalty, and in fact might be faster. Whether there is an actual speed gain is untested.
-
I wouldn't be surprised, GLSL mode, when running properly, could run faster than the old fixed rendering path.
-
...only if the GPU has proper support for it, which I believe is limited to only unified shader architecture cards such as the 8-series and later nVidias and the 2000-series and later Radeons. I could be wrong about that though. I know I get better results having it turned off on the 7300 Go in a laptop I've been playing with recently (under Linux though, not OS X).
-
Wrong. The only requirement (From the engine's POV) is the ability to use GLSL 1.2 or higher, which is part of the OpenGL 2 standard. (Of course, you need shaders capable of running on SM2 hardware; the standard mvp shaders are written for SM3 and are thus not usable on those cards. Replacement shaders (Which, however, require a recent nightly build) can be found on the wiki (http://www.hard-light.net/wiki/index.php/OpenGL_Shaders_(GLSL)#Per-Fragment_Lighting_Shaders_for_FSO_3.6.13)
-
I wasn't wrong about needing proper hardware support for it to get best results, just about how much hardware is actually able to support it :P
Seriously though, are the ones in the wiki the same as the ones Fury put me onto in IRC the other day? If so, then I can say without exaggeration that my frame rates on the 7300 Go practically doubled by having GLSL turned off over having it on. I'm not sure why that is, other than the 7300 Go being a pile of turd, but if you have any insights, let me know.
-
There are several possible reasons for this. Without having a log available, I couldn't tell you which is responsible here.
-
I just tried to generate a debug log, but after switching to the debug build and running the game I'd see the FS2 intro cutscene and skip past it only to have it CTD instead of jumping straight to the pilot selection. I guess it'll have to wait a bit :P
-
...
You could still post the log, you know.
-
I just tried to generate a debug log, but after switching to the debug build and running the game I'd see the FS2 intro cutscene and skip past it only to have it CTD instead of jumping straight to the pilot selection. I guess it'll have to wait a bit :P
The log was still generated. Post it up.
-
Actually, I'm not 100% sure it was generated and that's what I believe may be causing the crash.
See, I have FSO in /opt/FS_Open which is set to read-only by anyone except root. FSO, I'm told, dumps is logs in the folder the binaries are in, but since it's read-only that's what's causing the crash. If that's not the case then I have no idea where else the log is because there's nothing in ~/.fs2_open...
-
If I can be of service. Here is the bug report in regards to a GLSL issue on OSX, http://scp.indiegames.us/mantis/view.php?id=1881 (http://scp.indiegames.us/mantis/view.php?id=1881). The results of the bug was catastrophic to say the least. As far as I recall, I have always switched on -noglsl as it has always been broken.
I missed version 3.6.11, but I would periodically turn the flag off to see whether it was still briken or not.
Out of curiosity, I went back to 3.6.10, switched off -noglsl in os10.6, and behold, no slow down. I will need to hop back to 10.5 to verify, but bits of ogl was always a bit iffy in osx, hence the slaping by Valve to Apple to fix it so they could release Left 4 Dead 2.
A fair bit of this is conjecture, so feel free to give me an educated slaping as I could all be very wrong about this.
-
You're right about Valve being a driving impetus for Apple to straighten their **** out. OpenGL on Apple has been pretty hairy for as long as I've had a Mac, and unfortunately only 10.6 really got any of the most recent updating. Those still running 10.5 are probably stuck with the state of things before Valve got involved. Still, I know there's probably still some combinations of hardware/builds/OS that may be having issues, and I'd love to get detailed reports of any of those so we can try to hunt down any remaining issues that we can fix.
-
Actually, I'm not 100% sure it was generated and that's what I believe may be causing the crash.
See, I have FSO in /opt/FS_Open which is set to read-only by anyone except root. FSO, I'm told, dumps is logs in the folder the binaries are in, but since it's read-only that's what's causing the crash. If that's not the case then I have no idea where else the log is because there's nothing in ~/.fs2_open...
On Linux/Unix, fso logs are in ~/.fs2_open/data
-
I could have sworn I looked there and didn't see it. It was however 3:30 in the morning, in my sleep deprived state I missed it. Also, I found out what was causing the crash: debug builds have never liked my pilot with the name of "Lysergic Acid Diethylimide". Moving that out so only my WiH file "LSD WiH" remains and all is well. Anyway, here's the logs for starting up and running the intro cutscene with GLSL turned on and off.
If there's anything else in that list that can be nuked or adjusted for better performance, I'm open to suggestions. Those lighting values in particular concern me. I copied most of the original string straight from BW, so I have no idea what they're doing or what the effect of adjusting them is so I've been leaving them alone.
[attachment deleted by admin]
-
Hmm. img2dds is still there? Interesting. Might try taking that and -mipmap out unless you are testing stuff which is in non-mipmapped DDS format, and even still (like for testing textures for a model) you can still get away with it for the most part.
Optionally, recent builds have a "-disable_glsl_model" option available that may or may not help.
Question of curiosity, do you not like -env or have you tried having that on vs. off?
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
How is that still happening? That was or should have been fixed in Antipodes testing before go_faster got put into trunk.
-
I don't know if -img2dds actually does anything or not, I just saw "compressed non-compressed images" or whatever it says in the flags and checked it thinking it may help. I have a very vague understanding of what mip mapping does so it seemed like a good idea to leave on. I'll try disabling both when I get around to putting the Linux drive back in the machine (puts its original XP drive back in to rule out the possibility of it being linux driver related) and see what happens. As for -env, that's disabled for the same reason as most of the other stuff is: it didn't seem particularly important so it was among the first things to get cut. I was about the round this off by saying I though having -no_glsl on made checking things like -disable_glsl_model redundant, but then it hit me that I could have GLSL on, while having that option off. Adding that to the list of things to try when I get the machine booted back into Linux again.
As for all that null pointer stuff, well, your guess is as good as mine :P
-
I come bearing more bugs and they are both graphical and maybe one audio. All are non-crashing.
Now, I am not sure whether this is some sort of scripting error, but after viewing the commentary by the War in Heaven devs, I believe this is an engine issue. When a large capital ship explodes they normally produce junk pieces that fly off into space and if large enough, continue to explode. This bug in fact renders the entire ship as the debris. These ghost ships vanish once the the attached debris explode.
(http://d.imagehost.org/t/0431/WiH_Mission_3_GFX_bug.jpg) (http://d.imagehost.org/view/0431/WiH_Mission_3_GFX_bug)
This happens in other campaigns, but I have only tested Wings of Dawn. It never to appear to be more than 2 ghost ships at anyone time. Here is a past somewhat similar report. It's real old. http://scp.indiegames.us/mantis/view.php?id=72
The second is les serious and relates to warp in and warp outs. Best described with a screenshot.
(http://b.imagehost.org/t/0517/WiH_Mission_00_GFX_bug_jpg.jpg) (http://b.imagehost.org/view/0517/WiH_Mission_00_GFX_bug_jpg)
Again, I verified by checking footage from the Dev commentary. The whole ship appears the moment the first part of the ship to suppose to appear. On small ships and fighters, this is almost invisible and the same apply during warp outs. Ship enters warp point and doesn't fully vanish until last part to pass the threshold.
This bug has also been observed in multiple mods and affects all warp in and outs.
There is also an audio bug, but you guys already know about that. http://scp.indiegames.us/mantis/view.php?id=2266 although it is different from the description in that is appears to only affect far away sounds. It's reproducible during Mission 00 in War in Heaven cutscene. Sound from distant beam fire is broken up.
All found in this current build. I will have to double check if these bugs appear in retail campaign.
-
These bloody bugs. Sounds familiar.
-
Yep, they are in retail also, I can't confirm the audio bug in retail as the soundscape is no where as dense as any of the mod campaigns.
Death of the Belisarius.
(http://b.imagehost.org/t/0397/Retail_Mission_1_GFx_bug.jpg) (http://b.imagehost.org/view/0397/Retail_Mission_1_GFx_bug)
GVD Psamtik warp in
(http://b.imagehost.org/t/0968/Retail_Mission_1_warp_bug.jpg) (http://b.imagehost.org/view/0968/Retail_Mission_1_warp_bug)
Edit: Both GFX bugs are in 3.6.12 stable.
-
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
How is that still happening? That was or should have been fixed in Antipodes testing before go_faster got put into trunk.
It's in the new/delete global overrides, so it doesn't necessarily mean that it's an issue in the code base since those overrides will get called by all linked libs too. A backtrace would probably show that those lines are from an external lib.
-
Did some more digging and it appears it might be isolated/related to media VP 3.6.12. Switching the media VPs off resolves the GFX bugs at a massive cost of prettiness. This also has to be isolated to Mac, otherwise the forums would have been aflame with this by now back in August with the last update.
-
Yup, I am pretty sure it's isolated to OS X. Are you running 10.6.4?
-
I can do you one better, I have isolated it down to the GLSL system. Turning off GLSL removes the issue. The -disable glsl mc flag has no effect.
I am running 10.6.4 64bit and no I can't run the 32bit kernel.
-
Err... Not that it's relevent to the issue, but how can you not run the 32-bit kernel? 32-bit kernel boots by default on all machines bar the Xserves by default. You have to manually specify the 64-bit kernel at boot up (Command+Shift+6+4 as you power on I believe), but that only works on 64-bit EFI machines. I believe there are hacks to force the 64-bit kernel, but nothing that should prevent you from booting 32-bit...
-
I think any Mac that came with 10.6 _can_ boot to the 64bit kernel with the keyboard shortcut. And I think it can be set in the EFI to always boot 64bit. But yeah I've never heard of having to run it.
-
Oh I thought you guys knew. I am running a Hackintosh. There are a couple of minor quirks I had to sort out like networking, otherwise it is for all intents and purposes it is a real machine. That only thing it can't do is output a kernel panic log, that and 32bit kernel. I tried to boot to 32bit, but it panics on start up, and since I had no issue with the 64bit kernel, so I took the easy way out. I kid you not, I seen the same bugs across multiple machines when I did checks to make sure it wasn't a "My machine only" issue.
The GFX drivers are the Apple's and the only thing I needed to do was to tell what card I had installed. Heres the specs for the interested.
C2Q q9550 @ 2.83GHz. Nvidia 9800gt 512MB, Gigabyte ep45 ud3r Motherboard, 4 GB DDR2 @ 1066MHz. I specifically choose these parts for maximum compatibility.
I am sorry of this has lead to some confusion.
-
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
Why are you trying to free a NULL pointer? [fsmemory.cpp(19)]
How is that still happening? That was or should have been fixed in Antipodes testing before go_faster got put into trunk.
It's in the new/delete global overrides, so it doesn't necessarily mean that it's an issue in the code base since those overrides will get called by all linked libs too. A backtrace would probably show that those lines are from an external lib.
I'm aware of that, but those lines occurring in the log when and where they did _used_ to occur on Windows until Antipodes Commit 6502 which is why I'm confused that they are in the log (presumably from this build)
-
I think any Mac that came with 10.6 _can_ boot to the 64bit kernel with the keyboard shortcut. And I think it can be set in the EFI to always boot 64bit. But yeah I've never heard of having to run it.
You need 64-bit EFI to be able to run the 64-bit kernel, which is everything after the 945/5000X series machines (even those with 64-bit capable processors. My MacBook can't run it, for example, despite having a T7400 Core 2 Duo), but all except the Xserves boot up in 32-bit by default (for compatibility). I've read that it is possible to have non-XServes boot up in 64-bit by default with some hackery, but it's definitely not supported by Apple.