vamos por partes.
Resumiendo, hablas sobre el Motor de fisicas de Sonic:
-Supuestamente el Bug, Si ya conozco de ese detalle(cuando coloque esos bloques): Resulta que al estar en una pendiente, empuja el personaje(aplica animacion)... despues choca con la pared del bloque. ¿Por que no se para la animacion de Rueda o de caminar? Por que el motor le indica que DEBE andar/rueda SI o SI. Existe pendiente, no es un suelo llano.
El motor de colision de paredes le frena. pero no elemina la animacion, por que existe inercia del terreno.
Sinceramente en el juego de Sonic, aun no me encontrado con una situacion así... asi que no sabria decirte si debe comportarse asi.
Que quieres, que se pare, y se ponga en modo parado el grafico? seria una solucion...
-Lento??? LOOOOLL!!! LENTOOOO??!!! JODER!!
La Demo del concurso Trabaja SIEMPRE a 60FPS (Velocidad japonesa y americana)
En este juego, por defecto va a 50FPS (Velocidad Europea)
Has entrado en menu de opciones?? caambialo a 60FPS!!! tambien puedes cambiarlo en el fichero SVR.INI
Utiliza los cursores para cambiar las opciones.
Digamos que 50FPS es para gente Tranquila, que quieren jugar mas placidamente.
60FPS es para que quieren jugar a Tope!!
No existe relentizacion ninguna, esta Super optomizado el juego.
-Algoritmo de Salto: Realmente sigue siendo el mismo sistema que de la demo(no esta cambiado)...
no sabria como mejorarlo, pero el algoritmo que presento GINO para Saltos de altura, requiere de algunos FRAMES, para Determinar el salto.
Mi sistema es que cuando dejas de pulsar salto, frena la velocidad de salto... hay un minimo.
No lo considero un fallo, ademas que no va mal.... cuando lo programe por primera vez este sistema... me resulto complejo.
Mejorarlo.... mmmm no sabria como. no soy tan listo en matematicas.
-Frenar!!
xDD si la verdad es un POCO sajerado... pero me gusta apreciar la animacion de frenada con su humillo XDDD
Si lo acorto el efecto de frenada ya seria mas RAPIDO y PRECISO la jugabilidad.
Deje así esa velocidad de frenada para darle un punto de dificultad.
-Cuando subimos una pendiente, al dejar de puslar el boton de mover...
Los calculos son los mismos que le da 1ªDemo, y las considero perfectas.
me guío por esta documentacion:
http://info.sonicretro.org/SPG:Solid_TilesMe atreveria decir que son identicas.
Pero debo advertirte, que hay una parte del motor que no existe.... ya que es la mas compleja.
motor 360º 4 paredes, yo solo tengo el suelo, modo normal.
Moviéndose a los ángulos
Bueno, todo eso está muy bien y es bueno para tener movimiento de Sonic suavemente sobre el terreno con diferentes alturas. Pero de eso no es todo lo que hay en el motor. La velocidad de Sonic tiene que ser atenuada por la baja en ángulo con el fin de ser realistas.
Hay dos formas en las que se ve afectada la velocidad de Sonic en los ángulos. El primero se asegura de que él no atraviesa una colina en la misma cantidad de tiempo como caminar sobre una superficie plana de un ancho igual. El segundo lo hace más lento cuando se va cuesta arriba, y lo acelera cuando va cuesta abajo. Echemos un vistazo a cada uno de ellos a su vez.
Las tres variables de velocidad
Si fuera un juego de plataformas de Sonic simple que no requiere, pero los bloques, sólo se necesitan dos variables de velocidad: velocidad X ( xsp ) e Y la velocidad ( YSP ), las componentes horizontal y vertical de la velocidad de Sonic. Aceleración ( ACC ), la desaceleración ( diciembre ), y la fricción ( FRC ) se añaden a xsp ; la velocidad de salto ( JMP ) y gravedad ( GRV ) se añaden a YSP (cuando Sonic está en el aire).
Pero cuando se trata de pistas, mientras que los movimientos de Sonic a lo largo de una pendiente, se mueve tanto horizontal como verticalmente. Esto significa que tanto xsp y YSP tienen un valor distinto de cero. Simplemente añadiendo según , diciembre , o FRC de xsp ya no funciona, imagínate Sonic fue tratando de correr por una pared - la adición a su velocidad horizontal sería inútil, porque él tiene que moverse hacia arriba.
El truco consiste en utilizar una variable de tercera velocidad (como el motor original lo hace), así que vamos a llamar a que la velocidad baja ( Gsp ). Esta es la velocidad de Sonic por el suelo, sin tener en cuenta el ángulo por completo. según , diciembre , y FRC se aplican a Gsp no xsp o YSP .
Si bien en el suelo, xsp y YSP se derivan de Gsp cada paso antes de Sonic se mueve. Tal vez un ejemplo de pseudo-código es con el fin de:
XSP = Gsp * cos (ángulo);
YSP = Gsp *-sen (ángulo);
X + = xsp;
Y + = Yo sí puedo;
No importa lo que ocurre con el ángulo, Gsp se mantienen, por lo que el motor siempre sabe lo que la velocidad de Sonic es "realmente" se mueve a.
Factor de pendiente
En este punto, Sonic debe ser capaz de manejar cualquier colinas con una velocidad precisa. Pero él todavía tiene que ser frenado cuando se va cuesta arriba, y aceleró al yendo cuesta abajo.
Afortunadamente, esto es fácil de lograr - con algo que se llama el factor de pendiente ( SLP ). Sólo tiene que añadir SLP * sen ( ángulo ) de Gsp al comienzo de cada paso. El valor de SLP es siempre 0,125 ($ 0,020) cuando se ejecuta, pero no así al rodar. Cuando Sonic está rodando cuesta arriba (el signo de Gsp es no igual a la señal del pecado ( ángulo )), slp es 0.078125 ($ 001E). Cuando Sonic está rodando cuesta abajo (el signo de Gsp es igual a la señal del pecado ( ángulo )), slp es 0,3125 ($ 0050).
Nota: En Sonic 1, parece que SLP no se agregan si Sonic se detiene, y en su pie / en espera del ciclo. Sin embargo, en Sonic 3 & Knuckles, SLP parece que se añadirán aún así, de manera que Sonic no puede estar parado en pendientes pronunciadas - que va a obligarlo a caminar hacia atrás abajo de ellos.
Saltos En los ángulos
Salto también se ve afectada por el ángulo de Sonic es menos cuando lo hace. Él simplemente no puede establecer YSP a JMP - que necesita para saltar de distancia desde el ángulo que está de pie. En cambio, tanto xsp y YSP se debe establecer en jmp , usando cos () y el pecado () para obtener los valores correctos.
Más pseudo-código:
XSP - = jmp * sen (ángulo);
YSP - = jmp * cos (ángulo);