How can I make server-side game run the same on every machine, because when I use server's delta time it works different on every computer/phone.
Would something called 'fixed timestep' help me ?
Yes fixed timestep can help you. But also simple movement with a delta can help you.
Fixed timestep commonly using with a physics because sometimes physics needs to be update more often (120-200hz)than game's render method.
However you can still use fixed timestep without physic.
You just need to interpolate your game objects with
lerp(oldValue, newValue, accumulator / timestep);
In your case probably small frame rate differences causes unexpected results.
To avoid that you should use movement depends delta.
player.x+=5*60*delta;//I assume your game is 60 fps
Instead of
player.x+=5;
So last delta will be only difference between machines.And its negligible since delta difference between 60 and 58 fps is only ~0.0005 secs
Related
This is not a duplicate of this question because I need a way to speed up my world without changing deltaTime and have everything happen faster. Why can't I use deltaTime or change it? I'm using the velocity Verlet sympletic integration for the simulation of orbital mechanics and deltaTime is required to be as low as possible for increased precision. Therefore I have it set to Gdx.graphics.getDeltaTime() * 0.001f. I am using LibGDX in Java and if it is necessary, I am using the Game class to have my screens structured.
What have I tried or thought of?
Using higher order sympletic integrators will not require a smaller deltaTime but are difficult to implement and are my plan B for if this is not possible.
The question which you said is not duplicate is actually most likely your solution.
Your goal is to have small time-step of Gdx.graphics.getDeltaTime() * 0.001f. When we use framerate 60fps then it can be writen as 1f / 60f * 0.001f. So your current time-step is about 0.000017. This is the value which you want to use for Constants.TIME_STEP.
Then you will just need to replace WorldManager.world.step with call to your physics function. And the delta time which you pass as parameter will be Constants.TIME_STEP.
But due to your small time-step there will be large amount of calls to the physics function, which means it will have to be fast or you will have to find a way to reduce the time-step anyway.
I've written a basic velocity-based animation engine which iterates over a list of custom Shape objects which hold direction and velocity. When animating more than 500 objects, my application sees significant slowdown, but the actual time it takes to change the positions of the objects is very low.
Results are roughly as follows:
100 objects - <1ms modification time, 60 FPS
500 objects - 2ms modification time, 40 FPS
1000 objects - 4ms modification time, 10 FPS
I am currently using Timer-based animation, and my timer is set to 15ms intervals. The timer is the ONLY thing executing in my program, and the modification times I have listed measure the entirety of the timer's event function which contains only synchronous code. This means (as far as I can tell) that the only thing that could be responsible for the delay between timer events is screen rendering.
All my objects are tightly clustered. Would screen rendering really take four times as long for 1000 objects as 500? There is no opacity, and the only properties being edited are x and y values.
Specifically, I am wondering if there is a more efficient way to re-render content than changing the positions and then calling event.updateAfterEvent(). Any help is appreciated!
I want to rapidly fade out an oscillator in order to remove the pop/hiss I get from simply stoping it. Chris Wilson proposed the technique to set setTargetAtTime on the gain.
Now I don't quite grasp its last parameter 'timeConstant':
What's its unit? Seconds?
What do I have to put in there to get to the target-value in 1ms?
That Chris Wilson guy, such a trouble. :)
setTargetAtTime is an exponential falloff. The parameter is a time constant:
"timeConstant is the time it takes a first-order linear continuous time-invariant system to reach the value 1 - 1/e (around 63.2%) given a step input response (transition from 0 to 1 value)."
So, for every "timeconstant" length of time, the level will drop by a bit over 2/3rds (presuming the gain was 1, and you're setting a target of 0. At some point, the falloff becomes so close to zero, it's below the noise threshold, and you don't need to worry about this. It won't ever "get to the target value" - it successively approximates it, although of course at some point the difference falls below the precision you can represent in a float.
I'd suggest experimenting a bit, but here's a quick guess to get you started:
// only setting this up as a var to multiply it later - you can hardcode.
// initial value is 1 millisecond - experiment with this value if it's not fading
// quickly enough.
var timeConstant = 0.001;
gain = ctx.createGain();
// connect up the node in place here
gain.gain.setTargetAtTime(0, ctx.currentTime, timeConstant);
// by my quick math, 8x TC should take you to around 2.5% of the original level
// - more than enough to smooth the envelope off.
myBufferSourceNode.stop( ctx.currentTime + (8 * timeConstant) );
though I realize this might not be technically correct ( given the exponential nature of the time constant ) but i've been using this formula to "convert" from seconds to "time constant"
function secondsToTimeConstant( sec ){
return ( sec * 2 ) / 10;
}
...this was just via trial and error, but it more or less has been working out for me
I'm developing a software to input a monotonic .wav clip (piano) and show the piano notes which are played in that clip. I'm using FFT to calculate the frequencies but they are giving me values such as 22360 Hz and so on where I want to get around 260 to 600 Hz.
Can someone please help me with this?
Pianos put out a lot of powerful high harmonics or overtones, and thus an FFT should show amplitude in many high frequency bins. Perhaps you should use a pitch detection or estimation algorithm instead of just an FFT?
I think your problem is that you don't have enough samples, so the frequency resolution is poor. All you need to do is to have more samples or just zero-padding. See here and here. That may help.
Hotpaw2 makes an important point about overtone content.
However another thing you will require is a window function to prevent frequency domain artifacts of the sampling interval from contaminating your result. The window function applied to the data before the FFT essentially fades the signal in and out smoothly to avoid this.
[I am doing this work in Java, but I think the question is language-agnostic.]
I have a MIDI Note On volume (called "data2," it's 0-127) that I am adjusting with a fader (0 to 127). The "math" I am using is simple:
newData2 = oldData2 * faderVolume / 127;
Zero works perfectly, and 127 does too, but the volumes close to the bottom of the range are way too loud, especially the louder notes. What might be a different relationship than a linear one (in pseudo-code would be great)? I will have to plug them into the code and try them, of course.
I realize that this question depends on the instrument that is playing the Note Ons (a BFD Kit in Ableton Live, which doesn't inform much), but maybe not and perhaps there's a standard way to adjust a Midi Note On volume with a fader.
Your equation is correct. You are figuring up the note-on velocity relative to the fader in a linear fashion. A couple notes...
The parameter you are adjusting is velocity. This does not necessarily mean volume! The two do have a correlation for most synths (including your drum kit in Ableton) but it might not be as volume related as you might think.
0-velocity is equivalent to note-off and will never play a sound. I say this because if the difference between 0 and 1 is signficant, itmight be that volume isn't affect as much by the velocity parameter as you might think.
Finally, traditional mixer faders use logarithmic law. You might experiment with this, but again I think you are barking up the wrong tree with volume.
There is a MIDI message for channel volume that you should use for volume, and that is CC 7.
As I said on my comment, when playing with sound or audio or any audible technologies, rather use doubles or floats (depending on the hardware or API specifications).
You are returning an integer on newData2. Rather convert it to a double or float (for precision).
e.g.
float newData2 = (float)oldData2 * (float)faderVolume / (float)127;
Hope this helps.