TGB 1.7.4 to iTGB 1.0.1 physics

#1 Hmmm...collisions with those objects don't seem to be working either. Maybe I'm missing a setting that turns on physics in iTGB?

#2 That's not good. I'll have to pass this along to the iTGB devs tomorrow. Have you checked the iPhoneTest project yet? It actually has the actions you need working. Maybe we should compare your project to that one?

#3 I'll take a look. Thanks.

#4 It looks like the initial velocities of the balls in the iPhoneTest example are set in BounceBehavior.cs and the wall collision bounces are also set in that behavior. What I'm trying to do is set those values in the Level editor. I'll keep looking, but it appears to work in TGB, but not iTGB.

#5 It looks like it might just be a problem with running the code under iTGB. When installed on the iPhone Simulator, things move around as they should.

Found another oddity though...more research on that tomorrow.

#6 Bizarre results indeed. Thanks for catching this Bryan

#7 Well, until someone else can verify it, it might just be me being stupid. :) We'll see!

#8 I'm also getting a lot of strange inconsistencies moving from TGB 1.7.4 to iTGB 1.0.1
I'm adapting my shooter Go Beryllium for iPhone, and so far I've got it running fine in TGB 1.7.4 using mouse input, however when I run the same script in iTGB 1.0.1 I get the following strange features:

No audio.

Some objects don't move. Some of my player's bullets fire normally, some just stay still. Sometimes the player's electrons rotate correctly, sometimes they don't. Some of the background features scroll, and some of them don't. Very few enemies make it onto the screen. They're spawning off-screen and staying there. Some of them behave normally.

The only error that's showing up in the console is a an 'unable to find object' error due to the game running out of player bullets (as most of them are staying on screen and not getting recycled back into the bullet list when they leave the screen). Apart from that there are no errors in the console.

Am I right in assuming that script will eventually behave exactly the same in iTGB and as it does in TGB 1.7.4 or will I have to re-write the game for iTGB?

I haven't tried it on the simulator yet, still reading the documentation on how to get that working. I'll update later on how that goes.

#9 @Bryan - I don't think you are stupid. You have most likely stumbled upon a true bug which has to be passed on to the iTGB devs.

@Conor - I'm very glad you are trying to test Go Beryllium in iTGB. This is the PERFECT opportunity to iron out the wrinkles and bughunt the new platform. I can't get into details now, as I'm pretty much done for tonight. I'll be back again tomorrow morning, with lots of information and feedback.

Glad to see ya in the iTGB area, btw =)

#10 Just tested it in the simulator and most of the problems are gone. Mouse input is working fine and all the objects were moving properly. There was still no sound at all.

The framerate wasn't too bad on the simulator, it looked like about 10 to 15fps, not exactly pretty, but it was playable. I haven't heard back from Apple yet so I don't think I can run it on my iPod. That will be the real framerate test.

@Michael - thanks for the extra effort you and the rest of the GG team are putting in to make this work. I wouldn't be able to make my games without these great tools. If all goes well, this will be my first self-produced commercial title!

#11 Update - tried my game on an iPod Touch, 2.1 firmware. It takes a long time to load (38 seconds from when Xcode says the app is running) during which the screen is black apart from the title bar, then the screen flashed white and the game started. It appeared to be running correctly, however it was running at around 1 frame every 2 to 3 seconds.

There was no sound.

Touch input appeared to be working as I could move the player around, although it took about 10 seconds to see the change after touching the screen.

#12 @Conor - Thanks for the benchmark report. Have you made any modifications to your game or assets to optimize? It's been mentioned that making your raw images smaller, using tilemaps instead of large backgrounds, and converting the file formats help improve the speed.

I don't think this will get you back up to the glorious full speed as the PC version of Go Beryllium, but it might get you past the 1-3 fps. The iTGB devs are still working on optimizing the engine.

I've linked this thread in a bug report, so someone will be looking into this soon.

#13 Update!
I just talked to Paul Foster. He informed me there is a ConsoleMethod you can call on your objects. As part of the optimizations, physics are somewhat disabled.

t2dSceneObjects have a new ConsoleMethod:

//-----------------------------------------------------------------------------
// Set UsesPhysics.
//-----------------------------------------------------------------------------
ConsoleMethod(t2dSceneObject, setUsesPhysics, void, 3, 3, "(bool update) Enables or disables the object's physics.\n"
                                                      "@param update Whether to enable or disable the object."
													  "@return No return value.")
{
    // Set Enabled.
    object->setUsesPhysics( dAtob(argv[2]) );
}

The binary we ship with iTGB was built from a project that uses a preprocessor definition: PUAP_OPTIMIZE. When that is defined, the above ConsoleMethod is activated. Also, the t2dSceneObject member variable mUsesPhysics default value is false.

From script, you will want to active it similarly to this:

%object.setUsesPhysics( true );

If you check into the BehaviorShooter_components scripts, you can see an example in the ShooterControlsBehavior:

function ShooterControlsBehavior::onBehaviorAdd(%this)
{
   %this.owner.setUsesPhysics( true );
   if (!isObject(moveMap))
      return;
    ...

#14 As a side note Apple said they'll not publish applications who take more than 20-30 seconds to load.

#15 I've confirmed the same problem here. Why is physics disabled by default? What is the logic here? Is this for TGB bulder or for iTGB games? Should we undefine the preproc?

#16 Various optimizations were developed to make games run faster on the iPhone device. When the new TGB binary was compiled, it had these turned on. This is compiled from the standard xCode project you find in the SD. If your game does not need networking, you can disable it. If you do not need physics applied to an object, or all objects, it can be disabled.

This would cause the internals of the engine to skip calling functions to increase overall speed. Should you undefine the PUAP_OPTIMIZE? That depends on what features you need for your game

#17 Thanks for the info. I was just wondering if it was a temporary thing or something...how can you disable networking?

#18 ..but also, if by default physics is turned off..why does is still work on the sim/device but not in TGB? what I'm saying is that I don't think the sim/device has physics turned off by default...am I correct on that?

#19 That depends on which compiler you are using. If you are using the xCode_iPhone, you would have to see if the preprocs are the same as they are on the xCode.

#20 They aren't.

xCode_iPhone does not make that #define; thus then does build physics into the executable...

I thought this isn't what you want by your above comments?