Planned optimisation for os x?

#1 Hm, I dont think 20 fps is bad at all given your low system specs... 800Mhz and a 32MB card isnt exactly high-end ;)
So I would just be happy that it runs at all - and even better, is playable ;)
I don't think its a MAC "problem" either, cause I'd expect the same performance on a WIN machine with that spec I guess... but then again, I dont even have a MAC...
You could also look for the extended options dialog in the resources, it lets you configure a lot of detail settings, I'm sure you can squeeze out some more fps...

#2 Yes, I'm sure I could tweak a few things to get it up a few frames, but I was just wondering if anyone knew of anything being done to re-write the code to run better.

#3 Leo Altmann

Stefan Beffy Moises already told you that your performance is not anything low for the system youre running and I agree. 32MB video cards are non-existant on the market today, for instance.

There is no point to extend it in OS X when it runs as good as it *should* (or as it does on the other systems, for that matter).

My WindowsXP machine runs at a constant ~45 fps - 1.4 GhZ and 64 MB Video Card. That's not a whole lot of difference and still my system is twice as "fast" as yours, in terms of MHZ.

I would just be happy that it works :)

#4 There still are important performance discrepancies between similar specced PCs and Macs (and no, you don't use Mhz to say a machine is twice as fast : every single component has to be twice as fast to get a theoretical doubling of speed btw)

Mathwise, TGE doesn't take advantage of SIMD on G4 and G5s, through altivec (that doesn't help you or me Leo, since my ibook is also G3 powered) But that's also not where you're going to see that much an increase in speed, if the empirical evidence from industry luminaries is to be believed (ie optimizing math libraries is usually a waste of time in the big picture, unless it was broken to start with ;))

OpenGL wise, there are improvements that could be made that would also benefit windows and linux, but also some MacOS X specific optimizations could be done.

Still in the OpenGL realm, Apple's OpenGL implementation has performance issues that we can't do anything about, although they're working hard to improve it...

On the sound side of things, afaik, you can't have hw accelerated sound in TGE on Macs atm, another source of performance discrepancies... That might change since now Apple is backing the OpenAL effort (they've committed their code to the OpenAL CVS for MacOS X builds. Don't remember the name of that module, but it's in there ;))

I'm sure there is more, but there is room for optimizations.
But don't lie to yourself : most quite recent 3d games are simply not going to be playable on such a Mac : you might be able to play Marble Blast in 800x600, but I have to switch down to 640 on my ibook. Same thing with ThinkTanks, but I have to switch to 16 bit color to boot.
Now, on a desktop G4 or G5, that's another story :)

#5 If I remember correctly the ASM terrain texture blender is only in x86 assembly, so on the mac it has to use the software blender. This could cause a discrepancy in performance in outdoor areas.

No one here at GG has the required knowledge of ppc assembly to write such a thing AFAIK. If someone who does have such knowledge wrote one I am sure that all Mac TGE 1.2 users would rejoice (and get a few more FPS when outside)

However, there will be a revision of the terrain engine with TSE, and blending will be done on the graphics card (for shader enabled cards) so that should speed things up a lot on all platforms, and make the assembly blenders obsolete.

#6 Nicolas Quijano

Quote:That's not a whole lot of difference and still my system is twice as "fast" as yours, in terms of MHZ.

Sigh.. again, read what I actually typed, "fast", not fast.
It's the double in system specs. 100 MhZ more or less.

I know the MhZ isn't showing everything, not even AMD and Intel are the same, MAC alone is not near those. And taking GPU & Memory Speed, you get far from only the CPU's clock.

Concluded; No one did say that you use MHZ to say if a machine is twice as fast. Thanks.

Alex Swanson

I have a question then. If you would to disable this asm blender, would it automatically chose the software one? How much do you think it would decrease performance?

Just curious :)

#7 According to our resident terrain expert "the difference is probably significant, but it would depend a lot on how good your C compiler is"

Also, people who have been using 512 x 512 terrain textures have had to disable the asm blender, as it is built for 256.

#8 One thing that might help (and apologies if it already exists and I just haven't stumbled across it) would be a list of where there are significant x86-optimized pieces. I'm very familar with PPC assembler and Altivec, but so far not terribly familiar with where Torque's performance bottlenecks actually are.

If anyone can list some low-hanging fruit, I'd be happy to take a crack at some of them.

OpenAL is clearly one of them, for example: the Icculus version of OpenAL looks pretty promising in that regard. The stuff I'm working on doesn't require sound, though, so I'm more motivated to work on graphics stuff ;-).

--Amanda

#9 Amanda you can use Torque's built in profiler to see where some optimizations would be useful.

#10 If you want to see where things are optimized for x86, simply grep the source for assembly keywords. You ought to find most of the spots very quickly. :)

The math lib is always good for a few % performance gain, if you can pull it off without messing up data structures (some math code likes to rearrange the matrix layout). Depending on if it's in pure C or not, you might get some very good gains there.

The terrain blender could also use some love. It's in a pretty hairy state at the moment; we've rewritten it in TSE to use the graphics card for blending, which is much faster, but for a TGE game it could be a good speedup.

Beyond that, let the profiler be your guide. :)

If you do get some good optimizations in place, please give me a shout. We're always trying to improve Torque's support for Mac, but sadly with TSE and other projects we're too busy to give it the attention it deserves - some optimized math code could be a real asset.

#11 Ben Garney:

An offtopic question, but since you mentioned the terrain-blender.

IF I buy TSE, can I just use the blender source and get it into TGE? Since the one in TGE is awfully strange :P

#12 Of course you can. You have the source code for both and the licenses don't prohibit mixing code.

#13 @Stefan: but for your users on non-shader hardware, having an ppc asm blender would still be a mjor help :)

#14 The terrain texture blender is in terraformerTexture.cc? If so, merge() certainly looks ripe for some Altivec acceleration.

#15 Alex & Ben: Thanks guys. So I take it the "refined" blender only works on Shader cards? Too bad. Buah. =)

#16 Never mind, I found the correct file (blender.cc). Whew, yes. Both hairy and looks like it could be accelerated. I'll have to study it a bit first, though :-).

#17 Blender.asm is even better. ;)

#18 Yep, well, the new blender is all done on card, so it requires shaders. It'd be interesting to see just how fast an altivec port of the blender ran... could be cool ^^ keep us informed.