Flicker and performance with 1.0.2

#1 Tim, have you read this one?? -> www.garagegames.com/mg/forums/result.thread.php?qt=29298

#2 Thanks for the pointer! Unfortunately that seems to be a DirectX only problem. It would take some testing to tell if the change was an improvement over stock, but it definitely is not as fast as 1.0.0.

#3 Tim, what are you using as your testbed? Eg are you running the shooter demo, or a custom projet? Any more details you can share about what's going on and what the test situation is like will help us figure out what might be wrong.

#4 Up to now I've been using my current project. I'll use the test executable with the shooter demo... ...back again and -- it worked, if anything, faster than previously. So to check my sanity I ran my project with the new executable. Yep, very slow with lots of tile boundary flicker. Note that reverting to the 1.0.0 executable on my project gives the speed I'm accustomed to with only the tile boundary flicker I'm accustomed to (not anywhere near as noticeable).

When I first encountered the problem I figured it was a driver issue, but with both the version of the nvidia driver installed by the SuSE wrapper and with the latest from nvidia the problem persists -- although only with my project it appears. It isn't the DirectX issue, either (aside from the fact I'm running linux I tried it anyway just to see).

What is different between my project and the shooter demo?

1. my project uses the OO resource. However, unless something really funky was done with the handling of objects in script I don't think this would be an issue.

2. my project uses particle emitters that require more computation than those in the demo. If the computational cost of the emitters has gone up that could be an issue -- although I'm not sure why it would cause tile edge flicker. update: the fps of the emitter in question seems to be the same in 1.0.0 and 1.0.2

3. my project uses a tile map you drive over rather than a scrolling background.

Since the problem seems to be related to my project rather than my system or environment I'd be happy to make it available to you -- but I'm far from convinced your limited time is best spent figuring out why this project is unhappy (although I appreciate all your help) -- unless it is a more general problem that other people are having which does not seem to be the case. My reasons for posting were to see if other people were having the same problem and for pointers to where to look (thanks for the pointers I've received!)

I was thinking of running a diff on the engine code to see what had changed and go from there.

#5 Looking at the diff reminded me that there were changes to the physics code. getScenePhysicsMaxIterations() reveals that the default is 3. Setting it lower (e.g., 1) worsens the problem, but setting it higher (e.g., 10) improves the situation -- to a point. As an example, along an initial stretch (the important thing here is that it is a fixed length and so good for comparisons) at max acceleration I managed 28 mph by the speedometer, though visually the car was crawling. At 10 max iterations it was noticeably smoother and I managed 20 mph by the speedometer (because I reached the end more quickly).

Update: Setting the TargetFPS to 70 seems to give a reasonably close approximation of the old behavior. Although my system is not cutting edge I didn't think it was a slouch, either. Is a dual 2GHz Athlon with a 128MB GeForce 4000 really so slow I have to resort to tweaking the physics settings?

#6 Tim, no that system isn't too slow at all. However, if you're using physics, it pays to figure out the best performance settings for them. :)

Another thing to check might be the bin sizes. We changed those in the 1.0.2 update as well. If you have scrolling tiles and some collision going on, maybe it's worthwhile checking what different bin sizes do for your performance.

T2D makes it really easy to tweak parameters like this. In 30 minutes of testing you can figure out settings that work well, and we expose all the stuff so that it's really easy to tweak and customize. You are using the engine's most advanced capabilities, so it's not unreasonable to expect to investigate how best to apply them to your situation. :)

#7 Thanks for the information! I saw the bin stuff but hadn't dug in enough to understand it yet. I will tweak the sizes and see how that goes. Would performance cause horrible flickering at tile boundaries?

I wish I could screenshot it for you, but here goes an attempt to describe: the flicker appears to be caused by gapping between tiles of 2+ pixels. The gap color is generally something relatively close to white? but sometimes is different. For example, the current car is mostly red and I've noticed some of the gaps being filled with red, I believe only when the car is crossing the tile row.

I'm trying to get it compiled under windows to test there, but VC++ 6 has internal compiler errors on the opengl2d3d library which I haven't been able to track down yet (not helped by the fact that I have, for all practical purposes, no experience with Visual Studio).

Quote:T2D makes it really easy to tweak parameters like this. In 30 minutes of testing you can figure out settings that work well, and we expose all the stuff so that it's really easy to tweak and customize. You are using the engine's most advanced capabilities, so it's not unreasonable to expect to investigate how best to apply them to your situation. :)

I appreciate how easy it is to tweak. Messing with the FPS settings was quick and very easy to go from slow to non-functioning to improved. I like having printed manuals to refer to, but having the ability to tweak with realtime response helps the learning curve.

I didn't realize I was using the engine's most advanced capabilities although I did realize I was pushing it in some areas (I did have to drop one of my particle effects because -- just running it -- caused my system to bog down to nearly nothing). I'm assuming that the overhead for doing core objects in script is hurting performance as well (which is one reason I plan for the final version to be implemented in c++) but because 1.0.0 handled it okay I knew there was some change that caused the slow down.

My comment about tweaking was this: I only have two vehicles in the test and if my system can't handle them what about a full game where I expect to have say a dozen vehicles plus extra objects (e.g., missiles) and effects (e.g., flamethrowers). That was why performance-wise I wasn't expecting to have to tweak things at this point. Heck, I haven't even finished the basic car physics (tire modeling was a bit more complex than I thought it would be -- thank heavens for Brian Beckham and his simplification of Pacejka's formula!) so computationally it only goes uphill from here...

I appreciate your input and hopefully I'll get it sorted out this evening. Thanks for taking the time.

#8 @Tim: To compile and run T2D with Visual C++ 6, open the vc6 folder within your SDK folder and double click the "VC6.cc compiling.reg" icon and click "yes" on the dialog that appears and accept any others that may appear as well. You should have absolutely no problems after this!:)

#9 Tim,

You seem to be having lots of problems here at the same time so it's getting very confusing so let me try to get a handle on some of this to see if I can provide some help here.

Just to assure you, T2D compiles with VC++6/7 right out of the box without problems. Check that you've run the "VC6 .cc compiling.reg" file and are compiling all the libraries, not just the executable. If you just build the executable, you'll get complaints about the libraries not being there.

You talk about tiles flickering but then I see in your later post that you might actually be talking about pixels in tiles flickering, not tiles? If so, then this is probably because of filtering errors. Does this happen with a tile that is a FULL mode imageMap? No? If so, it's a filtering problem you're seeing. We can't fix the filtering errors because they are part of the graphics card but we can make changes to the way that T2D sections imageMaps into textures and that'll be work we've got planned already so that ones covered.

I think when Josh said you were adjusting some of the advanced stuff in T2D, he was referring to the physics iterations etc. You shouldn't really adjust the physics iteration code unless you know exactly what it does; that goes for the bin-system as well. Just tweaking parameters without really understanding what they do will get you into a world of hurt. Changing the physics iteration settings won't make any difference unless you activate it. If you want to mess with this then I would suggest reading the reference doco on "setScenePhysicsFPSActive()", "setScenePhysicsLimitFPS()", "setScenePhysicsTargetFPS()" and "setScenePhysicsMaxIterations()" to get a better understanding. If you're seeing changes when you adjust the interation setting then you must have activated this system yourself. If so, you should understand that the iteration setting is for systems that go below the limit-FPS which is a pretty bad situation. Running more iterations will cause the system to go much slower as it spends more time CPU crunching. Getting to this point can only be because there's just too much going on really.

You mention that you've got a single particle-effect that bogs your system down, what about similar aspects of your script? At this point, it's practically impossible to see what's going wrong to be really helpful. Is there some hefty script running, possibly each frame? Lots of schedules launching code? Perhaps you could run the internal profiler? There haven't been any real major performance changes from the two versions at all and to be honest, if T2D was running badly, we really should have seen this.

Perhaps a dump of the debug-banner would help to illustrate what's going on in the worst point of your app? We could see the bin-swaps, bin-collisions, scene-physics, particles, objects etc.

Hopefully, this may help a little. Sorry I couldn't suggest more.

- Melv.

#10 Don't mind the graphics (the original mockup map used all stock graphics and after quickly sketching the pavement I went to coding). I could have cropped the image, but its not like I have anything to hide. Notice the staggering of tiles and some of the shifting of entire blocks. Ugh. Not sure why that's happening...

screenshot

#11 Tim, this looks really funky. Would it be possible for you to post some of your code? Or, even better, could you spend a little time and get the problems (performance and tile flickering / shifting) to reproduce on a simple example script?

It would be really helpful if we could see exactly what your scripts are like so we can identify problems. What would be even more helpful is to have a simple, bare-bones example script that reproduces the problems (or each problem individually) without having a bunch of other gameplay code in there. Posting it here would be better than sending it to one of us, so other people besides just Melv and I can try figuring out the problems here too.

Thanks, this'll be interesting to see what exactly is happening.

#12 I can see about narrowing things down. The simplest approach is probably to get an old piece of code and see if it has the problem (I may not be using CVS, but there is a nightly snapshot). It'll be easier to go chopping code looking for minimal cases with it.

Update: It isn't nearly as dramatic, but still there. On this map driving straight up into the wall gives a final speed of about 36mph in v1.0.0 and 50mph in v1.0.2 with flickering and such. In fact I had a really nice still of the flicker, but by the time I realized it I had caused the camera to move and lost it. I managed to get another still. Not nearly as impressive, but here's a screenshot. I should be able to concoct some sort of minimal case from this, but as it doesn't show the problem to nearly the same extent it seems to be a matter of scale so a minimal case will likely have a minimal effect.

#13 It's okay, as long as it's detectable and reproducable, and it's not too much or too complicated code to go over, we should be able to help figure out what's up.