OSX performances
by Mathieu · in Torque Game Engine · 11/16/2002 (3:50 pm) · 5 replies
I've build a HEAD version on OSX.
The compilation process was fine.
I've made some tests with the Debug-App and the Release-App.
With all mods and maps I tried (mods FPS & racing) the game is laggy. Most of the time when I go right ahead all work fine but every time I turn the camera I get framedrop. It's like the engine has difficulties to "load" textures on the fly.
MacOS 10.2.2
G4 dual 864
512 RAM
Torque Engine runing in fullscreen at 640*480
- sorry for my english, french frog... -
The compilation process was fine.
I've made some tests with the Debug-App and the Release-App.
With all mods and maps I tried (mods FPS & racing) the game is laggy. Most of the time when I go right ahead all work fine but every time I turn the camera I get framedrop. It's like the engine has difficulties to "load" textures on the fly.
MacOS 10.2.2
G4 dual 864
512 RAM
Torque Engine runing in fullscreen at 640*480
- sorry for my english, french frog... -
About the author
Developer at frogames.com / frogames.net
#2
That's not to imply it isn't really happening... ;)
I'm running a Radeon 8500 64MB, G4 single 866, 256MB ram, generally windowed 800x600 or fullscreen 1024x768.
There might be better ways under Mac GL to update the textures, manage the terrain LODs, etc. I just haven't had any time -- day job takes priority.
d
11/19/2002 (7:29 pm)
Hmmm. Admittedly, I haven't done a long walkabout, but I was playing RealmWars on OSX 10.1 without such issues. Historically, there have been some issues with the way TGE is managing the terrain, but I haven't seen anything more than a minor, unrepro'd hiccup since the start of '02.That's not to imply it isn't really happening... ;)
I'm running a Radeon 8500 64MB, G4 single 866, 256MB ram, generally windowed 800x600 or fullscreen 1024x768.
There might be better ways under Mac GL to update the textures, manage the terrain LODs, etc. I just haven't had any time -- day job takes priority.
d
#3
But it's really annoying :(
We had in focus the Mac market but if Torque doesn't work correctly on 10.2 our project is compromised (making an Indie company...).
Here a message of a developer from a database mailinglist:
For instance, an earlier version of MacOS X (version 1.2) had a problem where free() was not thread-safe. So if you have a multithreaded application you had to make sure to use semaphores around any call to free or there would be almost certain memory corruption. The problem with this is that any system level call which allocated and freed memory (such as sprintf) also needed semaphores. In later OS versions this was fixed so we were able to take the unnecessary semaphores out.
More recently, different dot releases of MacOS X 10.x have had varying behavior with semaphores and locking. One of the earlier versions in particular would lockup if there was too many threads waiting on a semaphore. We had to code around this and make sure not too many threads backed up on the locks. This was fixed in 10.1 and is no longer a problem.
In 10.2 there is an interesting new twist in launching other applications. Previously you could have an application with 10 threads and in each thread start a process using either popen() or system().
The subprocesses would all run simultaneously and could be monitored by the controlling threads. This is no longer the case. They have put some locking into these OS level calls which will only allow one process at a time to be launched and monitored. When the process exits the next one is able to launch. The OS engineers probably have their reasons for making this change. I am not sure if this is a fix to a bug or a bug.
11/20/2002 (1:28 am)
I don't blame you for that, day job must be your priority. It's also my for the moment.But it's really annoying :(
We had in focus the Mac market but if Torque doesn't work correctly on 10.2 our project is compromised (making an Indie company...).
Here a message of a developer from a database mailinglist:
For instance, an earlier version of MacOS X (version 1.2) had a problem where free() was not thread-safe. So if you have a multithreaded application you had to make sure to use semaphores around any call to free or there would be almost certain memory corruption. The problem with this is that any system level call which allocated and freed memory (such as sprintf) also needed semaphores. In later OS versions this was fixed so we were able to take the unnecessary semaphores out.
More recently, different dot releases of MacOS X 10.x have had varying behavior with semaphores and locking. One of the earlier versions in particular would lockup if there was too many threads waiting on a semaphore. We had to code around this and make sure not too many threads backed up on the locks. This was fixed in 10.1 and is no longer a problem.
In 10.2 there is an interesting new twist in launching other applications. Previously you could have an application with 10 threads and in each thread start a process using either popen() or system().
The subprocesses would all run simultaneously and could be monitored by the controlling threads. This is no longer the case. They have put some locking into these OS level calls which will only allow one process at a time to be launched and monitored. When the process exits the next one is able to launch. The OS engineers probably have their reasons for making this change. I am not sure if this is a fix to a bug or a bug.
#4
I'm pretty sure that the framedrops come from the compilation on OSX with PB. The carbon version made by CW on OS9 work much better ! This version isn't perfect but it's playable.
It really need optimization :(
11/22/2002 (3:53 am)
I made some tests.I'm pretty sure that the framedrops come from the compilation on OSX with PB. The carbon version made by CW on OS9 work much better ! This version isn't perfect but it's playable.
It really need optimization :(
#5
And I don't recall any noticeable performance differences between the CW7 and PB10.2 builds running on OSX. (And, aside from optimization differences between compilers, the two apps 'work' pretty much the same...)
What other things have you installed, have running, etc., that might influence the performance on the Mac under OSX? That's the only other thing I can think of at the moment...
d
11/22/2002 (10:00 pm)
Hmmm. OS9 was typically faster, especially windowed (since OSX is doing double-buffering of the GL context through the window manager). X should be pretty competitive when full-screen, last I knew.And I don't recall any noticeable performance differences between the CW7 and PB10.2 builds running on OSX. (And, aside from optimization differences between compilers, the two apps 'work' pretty much the same...)
What other things have you installed, have running, etc., that might influence the performance on the Mac under OSX? That's the only other thing I can think of at the moment...
d
Torque Owner Mathieu
I thinks that the framedrop is related to the terrain calculation (maybe the collisions with it).