Changing Levels Slow

#1 1. Open your game project settings
2. In the Build tab, add the following "Conditional compilation symbol" TORQUE_PROFILE
3. Re-Build a DEBUG version of your game
4. Run your Debug game
5. Press the F2 key to capture the a profile
6. Press the F1 key to view the profile results
7. Look over the profiler results, press PgUp & PgDown to scroll through the details

I typically start looking at the second (indented) list at the bottom. It's a call stack that the profiler captred. The 4th column of numbers show the amount of seconds spent on each method, so you should be able to pinpoint which method is eating the most time.

John K.
www.envygames.com

#2 I am guessing that this only works on the Windows build and that you have to have the source code, right? I have the XNA release of Torque X, so I don't have the source code.

Is there a way to turn this on in the non-source version?

Also, on Windows it is not slow. It is only slow on the xBox.

#3 Are you including a lot of materials in your levels? The more materials loaded, the longer it will take to load a level.

#4 Sorr Tony, this only works with the full source version of Torque X. Profiling the game is going to be pretty difficult without the engine source.

John K.
www.envygames.com

#5 I thought so.

I will have to take some cash from the next check from Microsoft and get the source.

#6 Besides that, what do you consider a "long time" to load? How many objects and materials are you loading. How large are your materials, etc.?

#7 Well, long enough that XNA testers have noticed it. The first level that comes up is my instructions page. It has 3 bitmaps and that is it. It creates a simple input map that watches for all controllers A and B buttons. This page comes up after muy splash screen. I implemented the splash the way that GG recommends in their samples by showing a GUI bitmap and fading it in and then out on a timer.

From the time the bitmap is done fading out to loading complete of the instructions page is at least a second. I would expect almost instant.

The second page that comes up is the player join page. It has 4 sections all the same. Each section has 1 animated bitmap object and a none animated one. The input map looks for Back and Start on any controller and then A and B for each controller tied to each section mentioned above.

It takes about 2 seconds to go from the instructions page to the player join page.

One tester said that kept smashing the A button to try to go to the next page because he didn't think he was hitting it because of the delay.

#8 Yeah, a lot of those reviewers are real PITAs. How many times can you really smash the A button within a two second window? I'd say there are a couple of ways to tackle this: try to speed up processing or accept it.

The next release of Torque X does have a lot of rendering performance improvements. I've been looking into creating a new XNA content pipeline assembly for Torque X. It would pre-compile .txscene, .ter, and .dts files into native .xnb binary files for faster loading and presentation. I'll know more in a few days if it's going to be ready in time for the 3.1.4 release.

The 'accept it' option is not bad either. Live with the two second delay, but communicate to the player that something is happening. Make an invisible bitmap that says "Loading" visible when the button is pressed. Also, playback a sound at the same time to provide the player with an audio cue that something has happened. These little UI changes should help alot with the delay.

John K.
www.envygames.com

#9 I actually do have a bonk sound that I play, but for some reason it has a 1 second or so delay itself, LOL.

I also thought about the Loading bitmap and may do that after all.

I might also just accept it :-)

#10 I'm actually a bit optimistic about the content pipeline extension. As you know, XML is slow to parse and then instantiate new class instances from each line of XML. That's why when you start the FPS Demo (3D Kit), you might as well head out for lunch once the load starts. But... What if you can parse the XML and create all the object instances at compile time and then take the memory image of that scenedata and persist it to a binary file? Then, loading a level file is only a matter of loading that memory blob and sticking it into memory. That would be really fast. In a nutshell, that's what the content importer/procesors are all about. I'm close to having something working and will know better soon.

In case I forget to post back, check back with me in a few days. I have a lot on my plate these days.

John K.
www.envygames.com

#11 That will be great. You get all the benefits of XML (ease of development and updating) and all the benefits of fast (binary). I love it!

So quit posting here and get your butt to work then :-)

#12 Thanks for the input on this John - can't wait for the next version to come out!

#13 I seem to have had a similar slow loading issue to the one described. Parsing the scene xml was not the bottleneck for me as it turned out though. I traced it back to the fact that when TX loads a scene it loads ALL the art referenced in the .txscene file regardless of whether that scene needs the art or if the art has already been loaded.

So scenes were loading basically the entire game art (due to TXB saving all the art refs to a scene file when you save it) every time and this was slowing down level loading to a noticable degree and getting worse as more art was added.

The reason this was happening was because TorqueSceneData::Load() creates a new XNA ContentManager for each scene rather than just having all scenes load their art into a single shared ContentManager. A ContentManager knows not to load art that it has already loaded, but does not know about the art that has been loaded by another ContentManager instance - hence the fact that TX was loading all the art every time a scene was loaded even when another scene had already loaded that art in another ContentManager.

I solved this by commenting out the code in TorqueSceneData::Load() that creates a new ContentManager and I now create the ContentManager myself - just once. My levels now load instantly once the art has been loaded the first time.

(Having more than one ContentManager can be useful [e.g. load/unload blocks of resources easily], but in my case a single instance is all I need at the moment)

#14 Duncan, that's a very clever solution, smart thinking! It's true that the Torque X Builders save all imported textures as material definitions within the levelData.txscene file. I think the builder should have a "Compress" option that first checks for all the materials referenced in the <Objects> region, then removes those material definitions not referenced. This still needs to be an option as some developers may want to create objects dynamically in code.

Your code change should definitely speed up re-loading, but not the initial load. I think the reason behind multiple content managers is to support loading resources dynamically from different assemblies. But that whole system can definitely be optimized.

I've been experimenting with a custom Torque X content pipeline that includes a content importer, processor, and serializer for the TorqueSceneData. The basic idea is to have a content processor that loads the .txscene XML into a new TorqueSceneData object, then serialize that object to a .XNB file and then later load the game's load from the .XNB file. That should speed up the loading of long .txscene files (like the demo level). The same would be true for DTS models and Terrain objects (for the 3D developers).

John K.
www.envygames.com

#15 Well, yet another reason for me to get the source code as some point. For now I can't afford it.

John, in this new processing method that you are designing will you make it so that if resources are not needed by a certain level the conversion strips them out so that they are not loaded?

I will plan on releasing an update when the new stuff comes out.

Duncan, thanks for pointing this out. I hope the next release has a solution for this. I am sure it is the problem because each level has a large bitmap in it and that is probably why it is so slow because all 16 level bitmaps are being loaded for each level, ug!

#16 I'm not sure yet. I'm not comfortable blindly stripping out material definitions from a level file, just because they aren't referenced within the level file itself. Someone may very likely have game code that will reference a material definition that would be stripped out by this process. I think it needs to be more of an explicit 'cleanup' or 'compact' function that the developer invokes - probably within the 2D Builder itself.

Anyone have thoughts/preferences about this?

John K.
www.envygames.com

#17 I like the explicit cleanup. Obviously you would have to have a way to "mark" entries for each level as being part of the level so that they don't get added back in automatically. That happens now. If I add a texture in one level and then go to edit a previous level, that texture is automatically added to the one I am editing. Obviously this is something you will have to figure out as well.

#18 John - yes that is a good point about the loading speedups; it won't speed up the initial load.

So I handle this by explicitly loading the art resources at the time of my choosing. In this particular case art is loaded during a good old fashioned 'loading...' screen [1]. If all the art for the game can fit into memory at once then only a single startup loading screen is required, else if the game is big then a loading screen can be displayed when a player chooses a level to play.


[1] in fact I actually load the resources in parallel to the game's splash screens and the loading animation screen only displays if the loading hasn't finished in that time. (the resource pre-loading is done on a separate separate hardware thread and uses the ContentManager directly rather than using a TX scene to load the art indirectly - the splash screens have also had all the unnecessary art references stripped out).

#19 Very cool, Duncan. I really like that solution.

John K.
www.envygames.com