I'm creating a rhythm game in C# and Unity, and I haven't been able to find a direct correlation between the problems some of my players are having and their hardware but some of them are having problems with the gameplay gradually desyncing from the music over time. It usually takes a couple minutes before it's noticeable, but it definitely happens and ruins the feel of the game.
I'm keeping track of the elapsed time by using a double and adding Time.deltaTime (the time between frames) to it, and I'm assuming that there's just very small precision errors associated with doing that and that's what's causing the gradual desyncs.
Is there a better way to do this that's more accurate? I'm thinking that getting the time that the gameplay started, and then on each frame subtract that from the current time might make it more accurate? I've tried syncing the gameplay time to the audio time (Bass.NET provides a way to get song position in seconds), but while that works for me and quite a few others it ends up making others with decent hardware stutter (my game generally runs just fine on even 8-10 year old PCs).
Depending on your needs, you can use Time.timeSinceLevelLoad, Time.realtimeSinceStartup (although you are advised to use Time.time instead), or most likely Time.time. If you use Time.timeScale to pause your game, you can use Time.unscaledTime.
The difference between Time.realtimeSinceStartup and Time.time is that Time.realtimeSinceStartup will keep on counting even if you pause your game with Time.timeScale. Assuming that users might pause your game, which may or may not stop your audio from playing, would help you strategize whether you are going to use which property. You may want to set Application.runInBackground to true to get most reliable results, depending on your game logic.
Related
i was trying to duplicate this solar system simulation project and i have a question:
What is "Universe.physicsTimeStep"? i searched in unity manual and scripting API but i didn't found anything. Can someone explain me? Thanks
Historically, when games simulated physics, they did so by updating the physics simulation once every frame. For example, to find distance travelled they would use velocity * timeStep, where timeStep is the time between frames.
Nowadays, especially with multithreaded game engines, the physics simulation runs (somewhat) independently of other simulations and rendering. For example, the rendering could be done at 60 frames per second but the physics is only updated every other frame (i.e. 30 FPS). The more frequently the physics simulation is updated (i.e. the lower the time step), the more accurate the physics simulation is.
Sometimes, the time steps of various systems are adjusted so that the game rus 'properly' even when the hardware is a limiting factor. Typically this is done by 'dropping' (i.e. skipping) render frames, but update frames could be dropped as well. Some games, especially platformers and other games where physics is very important, will always run the physics simulation with the same time step so that running it on a slower CPU (which would result in a higher time step) doesn't affect gameplay, such as by making difficult jumps easier.
In your case Universe.physicsTimeStep seems to be the time step used for updates in the game. It also appears to be a fixed time step, so it will always be the same. If the game is running slowly, it will drop render frames but keep updating the physics.
That is a public constant in the class Universe(You should see Sebastian Lague's Solar System Github repository.
It's clearly mentioned there
I've put together a little Git repo to share with you some scripts from the Unity 2D platformer I've been working on. I have written some basic WASD movement control in the Movement.cs script (under Scripts/Character in the repo) and it is working really well. It does everything I need it to do, and while it is basic, I intend to polish it up a bit over the course of the development of the game. However, I've been noticing that every time I build the game, every moving entity moves at a faster speed. The "AI" (yes I use the term very loosely) that I programmed into enemies like the Chompas and BadBirds seems to be far too fast or far too slow, as are user-controlled movements and animated powerup bubbles.
Now, I believe I've traced it back to the way I create translations; I add vectors to Transform.Position whenever I need to move an object or entity. These vectors accept float values as their parameters, and seeing as I'm not entirely clear on what those values represent, I feel that may be where the issue lies. Are these distance values representative of some dynamic system of measurement that might be changing between builds? If so, how might I standardize my distances? Am I totally off the mark? Lol. Any and all help is greatly appreciated.
To be perfectly clear, this issue occurs every time I hit play, regardless of whether or not changes have been made. Thanks again!
Git repo
Try multiplying your movement by Time.deltaTime.
If you don't do this (which it doesn't look like you are), then all your GameObjects will move at inconsistent speeds. The reason for this is that void Update() get's called once every frame, and the amount of frames that get drawn every second is variable (sometimes your game will run a little faster than at other times), and so your speed will be variable if you don't multiply it by Time.deltaTime (Time.deltaTime is the amount of time that has passed since the last frame, see the documentation)
Another option is to use Unity's built in physics system with FixedUpdate(), which get's called at a fixed rate.
I would strongly recommend to follow online tutorials for how to make a platformer controller etc., such as this one. Doing this will help teach you good practices and how to avoid common errors.
Aim: I'm developing a turn-based game that heavily relies on Unity's 2D physics. It's important for me that all bodies go to sleep as soon as they stop moving, because I'm waiting for it to start next turn.
Issue: Unfortunately, it happens quite often that bodies never go to sleep. I tried tweaking Physics2D settings for days, thus improving stability and/or performances, but this issue still occurred. I figured out that this problem is related to HingeJoint2Ds: when they try to enforce a constraint (both angle limits or motor force), they won't allow their connected bodies to sleep.
I also tried to manually set really slow moving bodies to sleep, but (and this sounds quite weird to me) it seems that calling .Sleep() on a body causes other bodies to wake up, thus preventing the whole world to ever be able to fall asleep.
Question: Is anybody facing a similar situation? Any clue or workaround on how to solve it?
Thanks!
Have you tried grouping them under a sleeping parent game object then removing the ones you want to be awake from this object?
Good day,
I wasn't sure if I should post this on the software or hardware stack; I apologize in advance if this is an invalid question.
I wrote a little application that I am using to make time lapse videos - currently it only takes the pictures using a webcam. I know there are already a few available for download, but none of them did 100% what I wanted, and some of them were a little buggy, so I decided I'd rather create my own.
The interval at which the pictures are taken can be configured anywhere from 5 seconds up. Version 1.x would activate the camera and keep it on while in "Time Lapse Mode" and save images to disc at the specified intervals. This approach proved to be very memory intensive - understandably, in retrospect.
I decided to start from scratch - Version 2.x. This version would keep the camera off and only switch it on when it needed to take a picture, and switch it off again. This approach proved much more efficient. The reason for the minimum limit of 5 second intervals is because the camera takes about 1 second to switch on and then roughly the same amount of time to switch off. Perhaps in the future I could change it to keep the camera on when the interval < 5. For now, however, for what I actually want to use it, this will do perfectly.
When I was little we, as children, were told that switching an incandescent bulb on and off and on and off is not good for the bulb - according to a colleague of mine, reliable in that field, this is true.
This got me thinking. Could it be harmful to my webcam if I switch it on and off at, say, 10 second intervals for, let's say, a day or two? And how would switching on and off compare to keeping the device on for a few days? I don't understand what happens on a hardware level so I can't say.
I suppose I have a couple of options:
Switch the application on and off as required to take the pictures. This could result in the camera being switched a few thousand times a day.
Keep the camera on. This could mean the camera might be active for very long periods of time. What if I want to create a time lapse video over a month? Or even a year? Not to mention the memory problem.
Switch between the two modes. When interval < 2 minutes ? keep on : switch. This seems like the best of both worlds but now I'm faced with the memory problem when interval < 2 minutes
Thank you in advance for any and all comments and suggestions - much appreciated.
Kind regards,
me.
Could it be harmful to my webcam if I switch it on and off at, say, 10 second intervals for, let's say, a day or two?
Switching the camera on and off will have no affect on it's lifespan.
How about keeping it on for long periods of time?
Well that really depends on the camera but for something as low powered as a webcam you should be able to run it for many many years before it begins to fail.
Not sure how you are getting frames from your camera but it should not be extremely memory intensive. Using AForge.NET you can pretty simply grab frames from you camera. Tutorial If you could post your code I could better see how to point you in the direction of optimizing it.
I just noticed today, that when I compile and run a new XNA 4.0 game, one of CPU threads is running at 100% and the framerate drops to 54 FPS.
The weird thing is that sometimes it works at 60 FPS, but then it just drops to 54 FPS.
I haven't noticed this behaviour before, so I don't know if this is normal. I uninstalled my antivirus and reinstalled XNA Game Studio, XNA Redistributable and .NET Framework 4.
If I set IsFixedTimeStep to false, the game runs at 60 FPS and CPU usage is minimal (1-2%). but as far as I know, this requires me to do velocity calculations using ElapsedGameTime, but I don't know how to do it, since I'm fairly new to XNA. But some say that setting it to false reduces jerky animations.
I already checked this forum thread, but no one has found a good solution.
Has anyone experienced this problem?
EDIT:
I did some more research and I implemented a FPS counter (until now, I measured it with Fraps), and my counter shows the game running at 60 FPS (with IsFixedTimeStep = true), so this solves the FPS issue, but the high CPU usage remains. Is it possible that this happens to everyone?
According to this discussion on XBox Live Indie Games forum , apparently on some processors (and OS-s) XNA takes up 100% CPU time on one core when the default value of Game.IsFixedTimeStep is used.
A common solution (one that worked for me as well) is to put the following in your Game constructor:
IsFixedTimeStep = false;
What does it mean?
The Game.IsFixedTimeStep property, when true, ensures that your frame (Update(), Draw(), ...) is called at a fixed time interval specified in Game.TargetElapsedTime. This defaults to 60 calls per second.
When Game.IsFixedTimeStep = false, the calls to the next frame will happen when the previous one is finished. This is illustrated in the time graph below:
How does this change affect my code?
All fixed time calculations (movements, timings, etc.) will need to be modified to accommodate variable time steps. Thankfully, this is very simple.
Suppose you had
Vector3 velocity;
Vector3 position;
for some object, and you are updating the position with
position += velocity;
On default, this would mean that the speed of your object is 60 * velocity.Length() units per second. You add velocity 60 times each second.
When you translate that sentence into code, you get this simple modification:
position += velocity * 60 * gameTime.ElapsedGameTime.TotalSeconds;
To put it simple: you're scaling the values you add based on how much time has passed.
By making these modifications in places where you perform moving (or timing, etc.), you'll ensure that your game acts as it would back when it was fixed time step.
High CPU usage (100% on one core) is a non-problem for games. In other words, it's expected. The way you're using the CPU when you write a game demands you do this.
Open the code environment and write a simple program
void main(){
while(1) puts( "aaah" ) ;
}
Open the CPU monitor and see that 100% of one core is used.
Now your game is doing this:
void main(){
while(1){
update() ;
draw() ;
while( getTimeElapsedThisFrame() < 1.0/60.0 ) ; // busy wait, until 16ms have passed
}
}
So basically you call update() and draw(), and that takes up most of the 16ms you have to compute a frame (which you will take up most of when your game has a lot of stuff in it).
Now because O/S sleep resolution is not exact (if you call sleep( 1ms ), it may actually sleep for 20ms before your app wakes up again), what happens is games don't ever call the O/S system function Sleep. The Sleep function would cause your game to "oversleep" as it were and the game would appear laggy and slow.
Good CPU usage isn't worth having an unresponsive game app. So the standard is to "busy wait" and whittle away the time while hogging the CPU.