Running Really Slowwwwww

#1 arreeee youuuu iiiiinnn sssslooowwww mmmootttiiiioonnnggggg? ??????

#2 Heh, very funny Javier....

I wish it was that simple. Since I can't profile on the xBox I am doing some profiling on the Windows version. It appears that the DTS rendering is what is taking so long. I just don't know what to do about it. I would be very surprised if this was a general problem. Aren't there several games out there with many objects in them using Torque X? Do they run really slow when you have several objects in them?

#3 Have you set SimulateFences to true?

#4 Isn't that a Windows thing? I am having a problem on the xBox. For the xBox what should it be set to?

#5 It was false and I set it to true and that didn't help. It is still slow.

#6 I don't think its platform specific. I've seen lots of people have slowdown issues (including myself) that are solved with SimulateFences. If you have an xbox (and you obviously do) then you should just try these things regardless. I don't understand the concept of simulating fences so I assume it has to be something to do with the way Torque is written.

#7 It looks like we posted at the same time, heh.

Do you have any other ideas?

#8 Not off the top off my head, but its something I need to consider as I'm thinking about getting a 360 when my game progresses at little further.

#9 Do you know much about the profiler? Even though I can't profile on the xBox I am using it on the windows version of my game just to see if I see something weird. I think I am. I added some more profiler calls inside of the ShapeInstance.Render and Mesh.Render calls.

Do you know what the numbers in the profiler mean? Is the Invoke # the number of times it is called? If I am looking at the indented part of the profile output (at the bottom) if a parent method is called 48 times and a method indented to the right of that one (called by it?) says 328 does that mean the parent is calling the child more times than the parent itself is being called?

If that is true then there is a problem because the ShapeInstance.Render is being called 48 times (in the snapshot I took) and it is calling the ShapeInstance.RenderMesh 328 times. Not only is that not an even divide, but I can't see in the Render call where it could call the RenderMesh method that many times. The loop in Render is based on the number of meshes and in this case there are only 3, but 48 to 328 is a factor of almost 7???

#10 I haven't used the profiler yet, but I've seen it sprinkled around the place. I'd suggest that Invoke does mean the number of times its called, but I can't explain the call counts you're seeing, except for maybe different models with different material counts?

It's hard to understand why it would be slow on the 360 and not on windows. it's not like the 360 has low end hardware in it! but I don't have a 360 to test on yet.

#11 Well, I will keep pounding on it. Let me know if you think of something.

If anyone else has any ideas, please jump in!

#12 Can someone tell me what a good polycount is for a shape to get good performance? How about texture sizes? Does anyone know a good rule of thumb for total memory available on the xBox 360 for textures and such?

I am starting to wondering if I am just asking too much of my xBox. My Zombie model is about 5513 polygons. My buildings have at least one texture of 1024x1024 and some of them have more than one and I have 8 buildings.

My Zombie texture is also 1024x1024. My ground texture is 2048x2048 because it is a city scape and has detailed roads and such on it.

#13 As far as I know the XBox 360 has 512 MB of shared GDDR3 memory.
Suppose you have 12 textures of 1024x1024 and one 2048x2048,
that would be at most 65 MB of RAM needed for the raw image data (32bit per pixel assumed), so that really shouldn't be a problem.

How many polygons you can use really depends on lighting, shaders and stuff. But there is a blog post by Rick Stirling that might interest you: www.rsart.co.uk/2007/08/27/yes-but-how-many-polygons/

#14 That is a really cool post he has. From what I see on his site, if polygons or textures are an issue, it has to be that Torque X doesn't deal well with a lot of polygons or something like that. Since I don't believe that is true, then it must be something else.

Tonight I am going to make a very low poly version of my zombie and see if the problem goes away. If it doesn't then I know that is not the problem.

#15 You have to be careful when using lots of materials on your models. Every switch of material or vertex data hurts. The more different models with different textures you have, the worse it will get. I know you see all these cool games but if you analyse them a lot of the time you find only 10 or so models on screen at any one time and that includes the terrain. It's not so much how big one model is itself, its how many times you switch, or the number of DrawPrimitive() calls you make. DrawUserPrimitives is a lot slower too, and I know TorqueX uses DUP a lot, as well as dynamic vertex buffers, which are essentially the same thing.

#16 That is the other thing I was going to try. I was going to try removing the buildings and seeing if it sped up.

I have 8 buildings and some of them have 2-3 meshes with textures on each on. The main building that the user is in has 25 balconies on it. I made them separate so that I could have a higher control over the texture.

Could this be the problem? Some I don't think so because if I have a single Zombie the frame rate is smooth. It is only when I add more zombies that the frame rate goes south.

#17 I would try removing the buildings definitely. When you're debugging, you need to try everything. All the time. Programming is all about problem solving. Doesn't matter if it doesn't look like it will work, you just have to try it. It's to know or remember how all sub systems are linked, and even then you never know what effect one thing will have on cache usage and cause cpu or gpu stalls unless you're an expert in that field, and even then...

Having seperate meshes per object will cause more draw calls, but I would hope that the TX rendering engine was optimised to draw by material, and I would hope that the 25 balconies have the same material, in which case they should be lumped into one mesh by either the modelling program or the dts exporter. So you have 16-24 draw calls in buildings, which isn't that many but I was able to slow my pc to a crawl with 400 draw calls on my GF7900 (not a TX app, just plain XNA).

#18 Well, it is not the polygon count of the zombies. I just created a brand new zombie model as a simple cube. I created the same animation sequences (though they dont really move). and used the same texture.

I still get the slow down when I have more than one of them.

I guess I will try removing all the buildings now.

#19 Did you try the zombies in their own game on their own?

#20 Ok, I have figure out what is going on. It is 2 different things. The first is that my zombie just has too many polygons. I finally figured out how to reduce them in Houdini and get it exported correctly. As stated above I was trying a simple cube and got the same slow down, well, that leads us to the second slow down issue.

Part of my object are some mounted objects (spheres) that I use for collision detection because I want to be able to detect hits on different parts of the body. I had a total of 4 of these. I reduced that to 3. I am not sure whether it was the number of them or the fact that the one I removed overlapped 2 of the others. I may look into that more. For now I have the speed up to acceptable levels.

This I did with 2 things: reducing the polygons of the zombie and removing one of my mounted collision spheres.

Now I have a new problem. I will start a new thread for it. It is about setting the detail level and the Field of View FOV of the camera....