#445 Bueno muchas gracias por todo, creo que ya está arreglado.
En el input le cambié la comprobación y ahora tiene una condición por si has soltado el espacio demasiado pronto y no has llegado a coger altura, para que vuelva a la animación de Idle.
if (Input.GetKey (KeyCode.Space) && (currentState == ANIM_STATE.AIR) && (Time.time - startJumpForceTime < jumpForceTime + Time.deltaTime)) {
Jump ();
} else if (Input.GetKeyDown (KeyCode.Space) && currentState != ANIM_STATE.JUMP && currentState != ANIM_STATE.AIR) {
InitJumpAnimation ();
}
if (!Input.GetKey (KeyCode.Space)) {
if(currentState == ANIM_STATE.AIR && jumpRealAppliedTime < 0.08f) {
currentState = ANIM_STATE.IDLE;
}
}
A parte en el propio salto cambian algunas cosillas
private void InitJumpAnimation(){
firstJumpClip = true;
currentState = ANIM_STATE.JUMP;
}
private bool firstJumpClip = true;
private float lastCalculatedJumpForce;
private float jumpRealAppliedTime = 0f;
private void Jump(){
if (firstJumpClip) {
firstJumpClip = false;
startJumpForceTime = Time.time;
lastCalculatedJumpForce = jumpForce;
jumpRealAppliedTime = 0f;
} else {
jumpRealAppliedTime += Time.deltaTime;
}
float calculatedJumpForce = Mathf.Lerp (jumpForce, 0f, jumpRealAppliedTime / jumpForceTime);
lastCalculatedJumpForce = calculatedJumpForce;
float clampedDeltaTime = Mathf.Clamp (Time.deltaTime, 0f, Time.time + Time.deltaTime - jumpRealAppliedTime);
calculatedJumpForce = (calculatedJumpForce + lastCalculatedJumpForce)/2f;
mRigidbody.AddForce (transform.up.normalized * calculatedJumpForce * clampedDeltaTime);
...
}
Ahora la fuerza calculada es la media del último frame, por eso aunque vaya más lento ya no calcula una fuerza próxima a 0 para deltaTimes largos sino que saca la que le correspondería haber aplicado en todo ese período.
Por último los parámetros del personaje han tenido que variar y la nueva fuerza de salto es de 44600 y el tiempo en el que la fuerza se desvanece (JumpForceTime) pasa a ser de 0.36s.
Con eso debería ir bien.
#451 justo estaba editando el mensaje anterior con esto:
EDIT: o usar FixedUpdate pero verificar que, si no estás en el bucle de salto no siga en estado Air, y en caso afirmativo forzar a Idle. Pero podría no saltar en equipos justos de CPU en zonas sobrecargadas (por falta de sincronismo en llamadas a FixedUpdate)... como por ejemplo el bosque con las partículas simulando niebla.
A las partículas que simulan la niebla, se les podría bajar el número y combinar con fog dinámico.
PD: en unas horas veo la solución que acabas de poner
#451 vale, ahora va perfect
Para simular el desincronizado de FixedUpdate suelo sobrecargarlo con un for de duración aleatoria y ajustado en función de la CPU.
Y para forzar un dirty framerate... desde el Update con un Application.targetFrameRate = Random.Range (10,30).
Usando esos dos métodos, podrías haber detectado el fallo incluso en tu equipo que por defecto no creaba las condiciones que lo causaban.
PD: en WebGL es crítico.
#453 genial, muchas gracias. La verdad es que como habrás visto el código está todo sucio. Ya ves la "IA" del chuky que caótica es (aunque creo que para cuatro líneas mal contadas que tiene da bastante juego) el input y todo metido a saco en el playerController xd Es porque cuando me pongo a programar esto pruebo ideas que me apetecen sin cuidar nada más.
El target framerate creo que lo había dejado sin límite ni vsynch para probar el rendimiento (me he puesto un objetivo de unos 150fps en ultra con una 680), pero a partir de ahora tendré más cuidado que está claro que a la mínima se puede colar código frame-dependiente.
Thx!
#454 mi experiencia:
Con framerates tan elevados (si el cuello no es la GPU) sobrecargas la CPU innecesariamente, y esa sobrecarga incluso puede desvirtuar la física como efecto colateral (una CPU sobrecargada puede desincronizar FixedUpdate).
Vamos, que llegue a 150fps no significa que sea rendimiento efectivo porque podrías estar desvirtuando la respuesta de la física sin darte cuenta.
Para saber si la física está tocada, en los test de rendimiento comprueba el tiempo entre llamadas a FixedUpdate y verifica que no existan picos.
En el caso de que la CPU no esté sobrecargada no debería haber problema...
Después, en lo que no sea test de rendimiento, lo ideal es forzar el framerate a 60.
Por otro lado, en el caso de que necesites mayor precisión en la física cambiar los parámetros de actualización de la física.
EDIT: el proyecto lo tienes con una final... mejor usar las versiones parche de Unity... AQUI
Hice algunos cambios teniendo en cuenta vuestras aportaciones.... y creo que queda mucho mejor! gracias!!
#458 Pues... no veo que encaje con la propuesta del juego... pero sin problema, así dedico tiempo a pulir el 'engine'... quiero tener bien estructurado para poder aplicar shaders de la forma correcta. De esta no presento.
xDDD pues ya que nadie comenta nada.... ya le hice la refactorización necesaria para poder aplicar shaders de una forma más "eficiente"... estoy trasteando como darle un efecto "bloom"....
bueno, yo dejo el mio ya
https://drive.google.com/open?id=1OHWfW_SSXfFM-e9sTQVcFMH0XoHZ632w
unity c#
xDD
#477 Cierto, lo entregaste tan pronto que me habia olvidado, disculpa x).
Pero bueno, ¿Quereis una semana mas para los que no habeis podido? o directamente me inveno nuevos temas?