Question about timing, animations, etc.

Hello, this is my first post.

I’ve been playing with Unity indie whenever I have some spare time, but I found some issues that can be deal breaking for me, so I’d like some advice on how to get around them:

1 - Timing - I’m primarily an animator, so precise timing control is extremely important. Having a stable, predictable frame rate is actually more important for me than having it as high as possible (but at a completely different rate than the monitor). I understand that users with different hardware make this difficult, but now that Unity can publish on Iphone and Wii, it seems like it could be addressed, since you know exactly what to expect. So… my question is: how do I limit the frame rate, and ensure the game will run as much as possible close to that frame rate (delta timing will make the necessary correction if the rate falls momentarily, of course)

2 - Performance - This ties into the first question. Whenever I make a REALLY simple scene, like a cube crossing the screen against an empty background, the motion always “stutters”, it is never really smooth. I believe some of it is related to timing (having the game running at, let’s say, 50 fps on a 60 hertz monitor will duplicate one frame every 5 frames, causing the motion to stutter). But it may have some other explanation… the reason I ask is that I’ve been playing with Python / Pygame, and I managed to get “console-like”, really silky smooth motion on the first try, without even using hardware acceleration! And that’s on an interpreted language, running on the same machine…is there a way to improve results on Unity?

3 - Last but not least, can I use animated 2D sprites (with multiple movement sequences) on 3D planes inside Unity? How? The project I’m planning now would look so much better (from an artistic standpoint) with 2D characters over a simple 3D background! Modeling and rigging it all in 3D is not a big challenge, since that’s what I’ve been doing for a living for years, but would make me so sad inside! :frowning: I actually got that working great with Pygame and my own code to handle it, but on unity I don’t know how to use just a section of an image as a texture, and update that section on every frame… also sounds like it would be slow.

4 - Oh, oh, one more! I’ve read that with Unity Pro you can trim down unnecessary libraries that you know you’re not gonna use in order to cut down the final file size. Is this true? If yes, is it a relatively painless process? Does it make a significant difference if I could remove, let’s say, support for physics, shaders and scripting languages other than Jscript? (yes, my games will use very basic tech!.. :-D)

Any help is appreciated!

It’s trivial if you use vsync; then the update is tied to the monitor refresh. I think this is automatically used on the iPhone. That should also answer your question 2.

Yes, by putting a texture on a plane and using a script like this.

It’s just changing UV offsets, so it’s the fastest possible way of doing animation.

No, that’s only for Unity iPhone Advanced.

–Eric

Thanks for the reply!

Vsync would help (with screen tearing, I think), but wouldn’t fix the stuttery motion caused by irregular frame rates (like 45 fps instead of 30 or 60 fps on a 60Hz monitor). I guess my question is: how do I put a limit on the framerate, so that if the machine cannot render at 60 fps, I’d rather aim at 30 fps instead of something in between.

The UV offset trick looks good, I’ll take a deeper into it when I get home!

Well, you can’t have everything, I guess!.. I was actually thinking of eventually acquiring the Iphone license anyway, so I’d like to know how effectively that can cut down the file size (and possibly startup time?) for a simple app.

Thanks!

If a game can’t render fast enough at the refresh rate with vsync, it drops to half, so you won’t see 45 fps on a 60Hz monitor. It would be possible to see fluctuations between 60 and 30 fps though…if the framerate happened to be hovering right around 60, it would drop to 30 when going below 60 and then back up when possible. You can use a script like this to limit framerate to an arbitrary amount, although I think vsync is the better option most of the time.

–Eric

Ok, now it worked.

For some reason, the monitor was going to 75Hz when I tested it in full screen. It is an HDTV, so my guess is that it was taking a 75 Hz input and displaying it at 60Hz, causing the jerkiness…

One thing still intrigues me, though: in the editor, the FPS is around 100, instead of using the Vsync like I told it to (in the “quality” preferences). That way, it runs jerky - despite the high frame rate - in the editor, but fine when I publish it. Any way to fix that?

Big thanks for the help!
Leo.

Vsync only works in full-screen mode, so it won’t work with the editor.

–Eric