[SirKnightly]

Here is the nightly for OS X on 29 Oct 2010 - Revision 6705

Group: Inferno
fso-OSX-Inferno-20101029_r6705.tgz
MD5Sum

Code: [Select]

------------------------------------------------------------------------
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.
------------------------------------------------------------------------



[chief1983]

This should be running on 10.5 again.  Please verify and report your findings.

[oohhboy]

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.

[chief1983]

I wouldn't be surprised, GLSL mode, when running properly, could run faster than the old fixed rendering path.

[Admiral LSD]

...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).

[The E]

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

[Admiral LSD]

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

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.

[The E]

There are several possible reasons for this. Without having a log available, I couldn't tell you which is responsible here.

[Admiral LSD]

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

[The E]

...
You could still post the log, you know.

[General Battuta]

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

The log was still generated. Post it up.

[Admiral LSD]

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...

[oohhboy]

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. 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.

[chief1983]

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.

[The E]

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

[Admiral LSD]

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]

[Zacam]

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?

Code: [Select]

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.

[Admiral LSD]

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

[oohhboy]

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.



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.



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.

[General Battuta]

These bloody bugs. Sounds familiar.