A modest 100-200 updates per sec improvement

Nov 9, 2007 at 6:24 AM
So I noticed that the BackgroundScreen class had the SpriteBatch.Draw call commented out. I tried commenting it back in and saw a loss of a 1000 updates per second on my machine. That was very puzzling. Then I noticed that the ScreenManager class is not functioning correctly. By the time you get into one the demos, you have like 17 or so "screens" stacked up.

As a temporary hack - I modified the LogoScreen Update function to only add the "BackgroundScreen" and "MainMenuScreen" once. Leaving the code as is otherwise, this gave the demos about a 100-200 update improvement on my machine.

There are other problems with the ScreenManager, however, and you'll start accumulating more screens then you should after going back and forth between demos and the main menu...
Coordinator
Nov 9, 2007 at 12:31 PM
Hmm, guess I better take a look at that.

-jeff
Nov 9, 2007 at 2:28 PM
Is this just related to the demos, or are these classes part of the physics engine itself as well?
Coordinator
Nov 9, 2007 at 4:03 PM
Edited Nov 9, 2007 at 4:14 PM
I noticed this bug the first day of release. I don't have my development env with me, i'm sitting on another old laptop, so i can't test it.
But I seem to remember that the problem was in the LogoScreen inside the update loop. It add's screens inside the loop and the loop runs a lot of times.

I'm downloading Xna express right now to test it.

michael_brooks11 - This is only affecting the demoes, and not the physics engine itself.

EDIT: It was indeed the LogoScreen.cs update loop:

if (ScreenState == ScreenState.TransitionOff && TransitionPosition > .9f) {
ScreenManager.AddScreen(new BackgroundScreen());
ScreenManager.AddScreen(new MainMenuScreen());
}

The solution is to remove the LogoScreen before adding the BackgroundScreen and MainMenuScreen like this:

if (ScreenState == ScreenState.TransitionOff && TransitionPosition > .9f) {
ScreenManager.RemoveScreen(this);
ScreenManager.AddScreen(new BackgroundScreen());
ScreenManager.AddScreen(new MainMenuScreen());
}

This is, by the way, not the only bug in the demoes, I found serveral others, but they are non-critical. The only reason i'm not bugging crashlander with bugreports, is that he has a lot of work to do and I see the demoes as examples of usage, and not the only way of using farseer physics.
Coordinator
Nov 9, 2007 at 4:15 PM
Edited Nov 9, 2007 at 4:16 PM
Oh, and when we are at it.

Here is the second bug I remember at the top of my head:

Inside Spider.cs:

rightShoulderRevoluteJoint = JointFactory.Instance.CreateRevoluteJoint(physicsSimulator, spiderBody, rightUpperLegBody, spiderBody.Position + new Vector2(spiderBodyRadius, 0));
rightShoulderAngleJoint = JointFactory.Instance.CreateAngleJoint(physicsSimulator, spiderBody, rightUpperLegBody);
rightShoulderAngleJoint.TargetAngle = .4f;
leftShoulderAngleJoint.MaxImpulse = 300;

should be:

rightShoulderRevoluteJoint = JointFactory.Instance.CreateRevoluteJoint(physicsSimulator, spiderBody, rightUpperLegBody, spiderBody.Position + new Vector2(spiderBodyRadius, 0));
rightShoulderAngleJoint = JointFactory.Instance.CreateAngleJoint(physicsSimulator, spiderBody, rightUpperLegBody);
rightShoulderAngleJoint.TargetAngle = .4f;
rightShoulderAngleJoint.MaxImpulse = 300;

A common copy&paste mistake.
Nov 9, 2007 at 4:44 PM
Yeah - I should have clarified this wasn't really an issue with the physics. Sorry about that.

Well, I'm not at my dev-machine, but I remember thinking that the issue went a little further than the logo screen... I remember thinking that the behavior should change so that the ScreenManager is used like a "stack"... ie, you "pop" off screens instead of removing them by name... and the other thing was, if you wanted the demos to have a background screen for the main menu, you would need some mechanism for turning off the background when you "push" (add) a demo screen....

Anyway, non of this is that important for the engine.... I came across it and just thought it was useful info.


Coordinator
Nov 9, 2007 at 6:13 PM
Thanks guys.

I'll make the fix per genbox's posts.

I just used the the Screen Navigation system in the XNA Tutorials. I obviously flubbed some things. I didn't put much time into the demo infrastructure so I'm not suprised there are some bugs.

I'll fix any bugs that are easy to fix or that impact performance. If they are low impact then I'll probably just let them ride.

-Jeff
Coordinator
Nov 9, 2007 at 7:04 PM
Edited Nov 9, 2007 at 7:05 PM
Jeff - No problem.

sonofdaedalus - The screens are removed by object reference, but they could also be removed by index. To remove the gamescreen by name, you would have to make a property in each gamescreen with the name of the screen. This is redundant in my eyes.

Useing a stack collection could properly be done. But there would be some problems: First off, a stack is LIFO, that means you you would need to remove screens in the correct order. You can no longer just use an object reference or index.
Another problem is that Stack is not type safe, this means that a lot of boxing and unboxing occurs. I don't know if the speed improvement by using a Stack would overule this.
Nov 9, 2007 at 11:30 PM
Ah - I didn't mean to say "removing by name" --- I was thinking by reference but said by name.. Anyway, LIFO seemed to me what you really what.... at least as far as what I was seeing. You start off with the MainMenu. You push the DemoScreen followed by the PauseScreen. If you "quit", you pop twice. If you return to game, you pop once.... From the MainMenu, you "push" on another demo-screen... etc. That said, I haven't really looked at the code much - it was just a thought.