OS X compilation

#1 I just compiled it again so I can add the compiler enhancements for OS/X optimizations and now it crashes after lighting the mission.

I also tried without the enhancements and it crashes in the same spot so it's not the optimizations.

Please someone help, I can't get it to compile and run. And without being able to optimize it with the compiler options it's useless. I get between 14 and 30 fps without the optimizations.

Edit: This is odd I can now get it to compile. It seems to be hit or miss. I will keep trying different configurations.

Edit 2: Now it works with -o 3 and the optimizations. I'm not going to sneeze on it. I don't get it, I tell it to clean the project and build from scratch, sometimes it works sometimes it doesn't.

#2 Hi Joe,

Are you performing a 'Clean' after changing the compiler options? I find that with Xcode I need to clean the project after every compiler change and with every switch from debug to release and vice versa. Also, is this a modified Lighting Pack or completely stock?

Are you testing the frame rates with a debug or release build? You should use a release build for performance testing, Torque has a ton of heavy debugging code that's compiled out of a release build making it significantly faster.

Let me know if this helps!

-John

#3 John,

Yes I do a clean build each time, I know how picky it can be. This is the stock code from you guys which I built today after my purchase. I grabbed the code open xcode and hit compile.

Oh and yes, this is a release build.

Using the stock build from GG I go from 15-18 fps to 10-12 when using your stock release build. This is while looking at the interior structure from outside which is rather large. Bigger than the great hall from the demo and has about 800 to 900 brushes and just over 4000 surfaces.

These are the compiler flags I'm using which give much better performance. I got these settings from one of the resources on the GG website.

-fpermissive -force_cpusubtype_ALL -D__MACOSX__ -faltivec -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -mcpu=G4 -mtune=G4 -mpowerpc-gpopt -ffast-math -funroll-loops -finline -fobey-inline -malign-natural

By the way, I have not removed any dif lights that were there and I have not adjusted the sun when reporting the figures mentioned above. Though at another point in the day I did adjust the sun and had the lights removed and I did not notice any change in speed. I have not started to use your lights yet. I don't know if that would impact the performance or anything.

I hope this is clear, if there is anything I can provide you let me know.

Joe

#4 Cool, I'll take a look at it. Out of curiosity what are your system specs, what mission are you testing with, and what frame rates do you receive running stock TGE against the same mission?

-John

#5 Ok, I tried it out here and it worked fine. I tried multiple clean rebuilds and several combinations of the performance options (including the -O3 dropdown), all ran great against the demo missions.

Can you reproduce the crash in a debug build (though the debug build probably bypasses the performance tweaks, it's worth a shot)? I'd really like to see what's causing this.

-John

#6 John,

With the stock build from Garage Games I get 15-18 fps and with yours I get 10-12. That's about a 30% drop. I just moved my interiors and objects to a new base based upon the fps demo that ships with the Torque SDK. I was using some old tutorial as a baseline and it's missing too much stuff. In the old baseline I was getting about 25-30 fps when outside and 40 to 50 inside. So I'm sure the demo fps has a bunch of stuff in there I don't need.

Either way, when running the executable from your build I notice a significant drop in frame rate.

I'll compile it again today with the debug version and the normal version trying to get it to crash. If I can reproduce this I'll save the apps and put them in a place so you can download them.

As a side note I tested this against the demo that comes with your product. There is one thing that happened that really stuck out in my mind.

When I ran the synapse demo, the one when you start out looking at a green lake in a very dark landscape and you head downstairs to see the different lighting effects, I noticed that I could only see the green blob.

I hit f11 to poke around and then I choose to re-light the scene, curious as to how long it would take. Here is the odd part, after I re-lit the scene the landscape wasn't black. I looked like it was suppose to look. Not bright like in the torque demo, but the light from above the pond faded onto the landscape so I could actually see the entrance to the under ground hole. I was as if the light was only lighting the green pond and not the landscape. Then after the re-light the landscape immediately around the pond was dark but visible.

I'll see if I can send you some screen shots of what happened. It really sounds like an initialization problem. The same I used to get when I worked in C/C++ a number of years back. Most times things work then every once in a while they wouldn't.

Joe

#7 John,

It must be something in the optimization code. I can't get the debug version to fail. I compiled the release version twice and it crashed on me both times. I always choose clean all targets before I click build and run. I will e-mail you a link to the app that I compiled so you can see where it's crashing.

Oh, by the way I have 768 megs of ram, the latest install of OS X and it's powered by two 1ghz g4's. I have the ati radeon 9000 car that came with the machine. The interesting thing is that the ATI program says 64mb of ram but I think I actually have 128 meg on the card. So I hope this doesn't turn out to be a driver issue but I doubt it since I have no problems with the standard torque version.

Joe

#8 Hi Joe,

"When I ran the synapse demo, the one when you start out looking at a green lake in a very dark landscape and you head downstairs to see the different lighting effects, I noticed that I could only see the green blob."

Was this immediately after running the TGE Demo? The TGE Demo cannot calculate the mission lights, it sounds like the mission lighting file was available, but previously generated by a stock TGE.


Those frame rates are really low, in the main Lighting Pack demo (with the green goo) I'm getting 60fps outside while facing the interior, and 110 fps inside. In the TGE demo missions (still using the Lighting Pack) while inside the smaller houses I get 160 fps. I'm only running a G4 1.33Ghz PowerBook, 256M ram, and an ATI 9600. I know this is apples-to-oranges as I don't have your demo to run, but you're receiving really low frame rates, even in the TGE demo.

What exactly is in your demo? Are you using a lot of dynamic lights?

Oh and can you get a few frame rates from the main Lighting Pack demo (for comparison).


I just downloaded your executable and am trying it out now.

-John

#9 Was the file you sent from a stock Lighting Pack, because it's acting very differently. When launched it's starting a shell window, and then the engine. Once started the engine refuses to keep focus, I need to keep the mouse button down for the pointer to follow the mouse.

The crash is appearing in MissionStart, but for what reason I don't know.

Also I'm running OSX 10.3.3 and Xcode 1.1 (IDE 300.0, Core 300.0, ToolSupport 300.0).

-John

#10 John,

When running your demo with your executable, one which seems to work, I get 40-50 fps inside and 30-40 outside. The executable is compiled with the compiler directives noted above. You should consider adding those directives to your demo build. It really improves the performance, try it for yourself.

In regards to my system I have an ATI 9000 card and I may have a driver problem I'm not sure. The ATI console shows it as 64mb but I think I have 128. I've been meaning to open the machine to find out for sure. But I have not seen the standard torque application crash or other GL based apps so I'm not too worried about it.

In regards to your other question, yes this was compiled from the stock lighting pack but I have not seen the issue with opening the shell window nor any mouse problems. The only thing different is that it crashes on mission start. So it's odd that your problems are so different from mine.

My OS is 10.3.7 and Xcode is 1.5 (IDE 389.0 core 387.0 and Toolsupport as 372.0) Hmmm, could this be a compiler problem?

In regards to the green blob problem, I started the demo and ran your demo project. I didn't run any other demos first. I can't replicate this so I'm not sure but I do know I saw it happen.

In regards to my demo I have not incorporated any of your lights yet. I don't want to do this unless I can get it to work properly.

If there is anything you need me to do please ask. I want to use your pack as I think it will solve some lighting issues I have... at least I hope. So if you want to Instant Message me and have me try things let me know, I'll make myself available.

On a side note, I noticed your diff project. I'm curious what that's about as I and another person are making a .map exporter for Blender. Right now we are focusing just on the exporter not so much tools. So I'm curious about your project.

Finally, your documentation talks about using your map2dif to take advantage of some lighting feature but I noticed that there wasn't a map2dif project with xcode. I don't know enough about XCode to make one efficiently. I did with project builder but I don't remember how I made it and I don't really have the time to learn XCode. Besides, it will help those who have no programming experience to get the most out of your product. If it's a big effort I wouldn't worry about it since there is a new map2dif coming from garage games that has a much improved parser.

#11 Hi Joe,

That still sounds really low, try downloading this Lighting Pack executable you should get results similar to mine (60 outside, 110 inside, 160 in little hovel).

The green goo problem definitely sounds like the mission lighting file was compiled by the a non-Lighting Pack executable (like the TGE demo executable), then the next time the Lighting Pack executable was run it reused the cached lighting file. When you forced it to re-compile the lighting, the full Lighting Pack lighting was restored.

I've been doing some research into this and I found this thread:

Dec 4 2004 security update problem

Someone reported a problem with a recent security update that causes Torque to crash, but only on some systems (not sure how or why that happens). At any rate the solution was removing the patch. I can see why I haven't run into this issue as I don't regularly patch my Mac (I only use it for development and it's never on the net).

I recommend trying to remove the patch, just to see if it helps, or to temporarily remove the performance tweaks. Meanwhile I'll continue looking into the problem, but it may take a little while to find and resolve.

I don't think there is a Mac map2dif, but I could be wrong. I thought that because no Mac map editor exists support for a Mac map2dif wasn't available.

-John

#12 Joe,

OMG, I re-read the thread above and realized that the solution posted was to enable run-time info, not to back out the update I don't know how I missed that. Anyway here's a quote from the thread:

Quote:The flag is Enable C++ Runtime Types, which gets enabled by default in "development" type builds in Xcode, which made this problem infuriating to chase.

And from the Mac developer:

Quote:The crash looks like an attempt to do a dynamic_cast on an object that contains no runtime type information.

To set this select the project root and click on 'Project/Get Info', select the 'Styles' tab, select 'Common Settings', and check 'Enable C++ Runtime Types'. Do this for both Development and Deployment styles (using the 'Active Build Style' drop-down box).

Sorry for the confusion!

-John

#13 John,

Sorry I didn't get back to you sooner but I spent the weekend digging out of the snow here on the east coast. My Snow Blower is basically a shovel and my back. Had fun with the kids though.

Thanks for this tip and I looked into this. This doesn't appear to be the cause of the problem. I say this because it was checked and I added the compiler flag and it still crashed. The other reason I say this is not the cause is because sometimes it works and sometimes it doesn't. If this was the issue it would always fail. This leads me to believe that it's an initialization issue. I wonder if a class variable is not being initialized correctly. C++ doesn't guarantee the initialized values and so I would bet that there is a pointer where many times it is initialized to zero and other times to junk memory thus failing future is null tests. This is just a guess but the random nature of the failure suggests this as a cause.

On the plus side I think I found out why I get get such low frame rates. Apparently my card is terrible at FSAA and that seems to be enabled, so once I figure out how to disable it I can see for sure if I'm right. But I'm still getting a large frame drop when using your executable and with no lights enabled.

I'm really not sure what to do from here. This is were I am at the moment:

1. When it does work I get a large frame drop.
2. It doesn't always work.

Any suggestions on what to try?

Thanks,
Joe

#14 John,

I just tried to compile the standard 1.3 torque distribution and ran the demo that comes with the distribution. I can't get it to fail. So I don't think it's my system setup it may be something with your pack. I compiled it 4 or 5 times and each time I cleaned the builds before clicking build and run.

#15 John,

I am now trying to get yours to fail and I can't. I'm wondering if I did a system update without rebooting the system. I did a cold boot the other day to move the computer and now I can compile your app and I don't have a loss of frames from what I can tell. Hmm. I'm hope this is true but I'm also sorry if it is.

I will provide you with more information.

Joe

#16 John,

I think all is well now. I'm not sure what happened. I know one problem I had with the frame rate was because one texture that is used a lot was 6x128 not 8 x 128 so that caused a huge performance hit. But the crashes seem to be fixed. I will try to compile it again tomorrow a bunch of times to try and recreate the error. At least you saw the issue I saw and I know I'm not crazy.

#17 Hi Joe,

Cool, I'm glad it's working now.

-John