iTGB 1.2 Speed increase

#1 Neither did I

#2 Definitely not with loading time, I have done no tests with frame rates yet however.

#3 Loading times can be downright atrocious. Framerates can be slightly better when you fix a misspelled flag (TORQUE_DISABLE_MEMORY_MANAGER missing the R at the end).

#4 maybe all testing was done on the simulator?

#5 I've actually seen a little bit of a speed increase. Some scene of one of my projects was averaging around 35fps at idle, but is now getting about 45fps at idle.

#6 @Dave - Do you convert everything to C++? Script Only? Or Hybrid?

Then again I haven't really spent a lot of time in 1.2, a little busy on other things atm. I just loaded my old prototypes and I haven't seen any noticeable increase.

@Ronny - Nice tidbit there Ronny, I'm going to check that out. Report it as a bug lolz.

#7 the memory manager fix hasn't had any impact here. For example the behavior shooters FPS didn't change at all on an itouch 1st gen (OS 3, built against Framework 2.2.1)
Guess its of more importance on the iPhones or itouch 2nd gen

#8 It would matter more on a 1st generation iPod touch, because it's a tad slower. The 33% faster bus on the 2nd gen. speeds up loading quite a bit, and the CPU helps some.

I think that flag is correctly spelled in all but one of the targets - going to check it out carefully later.

#9 @Ee - I mostly use TorqueScript, but I am guilty of hybriding it in a few points. Anywhere that has poor performance or cycles really often I tend to move into C++.

The Behavior Shooter for me has terrible performance, fyi... under 10fps in most cases. Though I think they are creating and deleting objects very frequently, which I've found to hit the FPS pretty hard - it works better to create a cache of objects then dynamically re-purpose them as needed.

#10 Dave,

Can you please further explain "create a cache of objects then dynamically re-purpose them as needed"

Does this mean copy objects, or just reposition to look like one is many?

#11 @Johnny - Let's say you will have a need for lots of static sprite objects in your game - such as enemies you will be creating and deleting often. Instead of doing that, create, say, 10 - 20 static sprite objects and keep them off to the side of the level - out of view. Then, when your game needs one, have your code grab one from off to the side, use it, and instead of deleting it when you're done, put it back so it can be reused. This way the device only needs to create all the objects once - something that can be a time-consuming process for the device - and then reuse them. I shaved at least 3 seconds off loading time in some parts of my game by doing just that.

#12 Definitely not seeing any performance increase, not even on older devices. On a side note I find it odd that optimized release profile doesn't build for Thumb, instead it uses arm compilation. just by compiling for thumb I managed to shave off some 300K off the binary and 1.5-2 s off load time.

#13 Thumb instructions are a 16-bit subset of the ARM instructions, so you might save something in some circumstances, but you should also profile it and see how much CPU is actually used with Thumb. In one somewhat math-heavy test project I did (non-TGB), the ARM code used half as much CPU.

#14 @Dave,

Thank you!

#15 I'm seeing a little bit of one, actually... unless I fixed something in script. In 1.1, a mount-and-move combo caused the mounted object to trail its parent for a bit. I'm not seeing that in 1.2.

#16 that sounds more like a fix for a bug in the physics system

#17 You'll still see the mounted objects trail it's parent in 1.2 if you don't enable their physics.