TGB Beta 4 + MacOS X (PowerPC)

#1 Is there supposed to be particles in the demos? If there is supposed to be particles then I have the same problem is you because I don't see any and I also run OSX.

EDIT: I mean the demos that come with TGB not the demos for TGB.

#2 This isn't an OS X problem, it's in all the builds of Beta 4. The solution is in this thread:

www.garagegames.com/mg/forums/result.thread.php?qt=44773

#3 Of course this isn't OS X problem :D But it is not exists for MS Windows version.

Anyway, thanks for the link, I am checking it now.

#4 The solution works OK. I think, that GG will make a great job if they will upload the fixed TGB for both MacOS and MSW.

I am still having problems with the big backgrounds in MyFishDemo project. I have made a screenshot so you can see how they looks under MacOS X. I don't have the same problem under MS Windows.

The screenshot is here:
http://www.emotionrays.com/tgb_bug.jpg

Take a look at the scrollers at the right, the normal background pictures must be there. :(

#5 Just to add to the corrupted backgrounds on OS X, on a freshly downloaded build it only seems to corrupt the background images if I change the resolution of TGB. If I stay at 800 x600 or switch back to that resolution the images are fine.

Edit: Well I worked my way through the fish demo tutorial. It seems that every time I restart TGB I need to switch the resolution from either 640x480 to 800x600 or vice versa as the background images are corrupt every single restart. Switching the resolution temporarily provides a fix. However, when the image is not corrupt (displaying normally) I get a huge performance hit, to the point where it is difficult to work with the editor.

#6 Sorry, but this isn't helpful :(

In fact, when I had LOTS of applications running on background and all my video memory was taken by them, the background pictures for fish demo were OK, but everything was slow because they was cached in system memory. When I have closed all those applications, the everything works fast, but the background images are corrupted.

And console log also shows something strange:
--
Unknown Getstalt value for processor type: 0x113
platform layer should be changed to use sysctl() instead of Gestalt() .
Unknown Processor, assuming x86 Compatible, 1416 Mhz
--
In fact, the processor is PowerPC, and I run everything on mac mini which is just 1 year old.

Any ideas?

#7 The fix for the particles not showing up works nicely in OS X with a recompile. It's nice to be able to see and edit particles now!

The background images / preferences bug remains. It makes working with the new tuts a little difficult! Either you can't see the background images, but performance is fine; or you can see the background images and performance is so bad that you can barely drag the mouse and the poor fishy stutters across the ocean!!!

I'm also getting the odd console message (PPC Mac mini) :
Unknown Getstalt value for processor type: 0x113
platform layer should be changed to use sysctl() instead of Gestalt() .
Unknown Processor, assuming x86 Compatible, 1250 Mhz

So... Does anybody know what "sysctl" or "Gestalt" might be?

Just to add a little more to the mix... Now that I've converted a largish game I've been working on for months to Beta 4, there's a long wait during startup; displaying a white screen for several seconds, before the splash screens and main menu kick in. It seems as if the engine is thinking really hard about something before it ever gets around to my own scripts. [Perhaps it's really busy 'assuming' that my nice little PPC is really an x86!!!]

#8 I did a little searching about sysctl and Gestalt; and discovered that they are methods for determining the type of processor being used.

On CocoaDev::
"ADC recommends the sysctl method for mach-o executables, Gestalt for Classic or CFM Carbon. That makes sense. The sysctl interface should be more stable than Gestalt."

In the TGB Beta 4 engine/source/platformMacCarb/MacCarbCPUInfo.cc::
// The Gestalt() API will no longer be updated, so this code should migrate to
// the unix sysctl() and sysctlbyname() API. This is the current doctrine from Apple, dec 2005.
And then it goes on to use the Gestalt() command in a list of switch/cases; with the default being that the program assumes that the processor is an unknown x86 Compatible (whoever wrote this code was being forward-looking, by assuming that it should default to Apple's new lines of x86 processors).

I don't know why my computer (7455 G4 Mac mini) doesn't catch the case:
case gestaltCPUApollo:
Platform::SystemInfo.processor.type = CPU_PowerPC_G4_7455;
Platform::SystemInfo.processor.name = StringTable->insert("PowerPC G4 7455");
break;

The code does, however, catch that my processor is Altivec enabled and accurately gives the Mhz rating.

I have no idea how to modify the code to correctly identify my processor using Gestalt. I also don't know how to switch to using sysctl(). The examples on the web quickly went way over my head! Actually, this whole discussion is beyond my abilities; since I'm one of those annoying 'artistic' types, rather than a hard-core coder!!!

#9 Well, I have made some simple changes to make Torque correctly identify my processor as PowerPC G4, but it didn't fix the bug :( I did not made further searches yet, probably will make them later. If I'll find something, I'll let you know. But I must say that I have no experience in mac programming, so I don't promise that it will be quickly :)

#10 *bump* - Just wondering if some of TGB developers have seen this thread, and they can give some suggestions of where to look at to remove this bug. Seems that it appears on PowerPC mac mini, and not only on my own. I believe it related to the video memory management or so.

#11 FYI for those people who are having problems with Beta 4 on a Mac...

Josh Williams (GG employee) pointed out (in another thread) that this discussion should really be in the Report Bugs section - he's right, of course. He also said that a new version of TGB is coming out very soon; so we should all wait to see if the problems are solved.

#12 Reporting the correct name of the processor is not really that high on the priority list guys -- this is because it really doesnt affect much of anything. The processor's capabilities, such as altivec, mhz speed, etc, are what we really care about here. At the moment, it's not a very high priority.

That said, if you want it fixed, I'll need the hex code reported by the gestalts system, for your processor.

As for migrating to sysctl() : yes, this should happen. If anyone feels like submitting code on this, I'd be more than happy to take a look at it.

/Paul

#13 Paul:

The hex number is 0x113.

And you are right, its not the major problem.