Este es un mensaje de alerta para los que hagais pruebas y desarrolleis usando el OneChip MSX.
Espero que esta experiencia os pueda ser util.
Resulta que me he encontrado con un problemón a la hora de utilizar el bit de colisión de sprites.
He realizado varias pruebas y me atreveria a decir que el OneChip no lo emula correctamente dicho bit.
O eso o hace cosas muy raras.
La cosa viene ya de la RuMSX de junio en Barcelona, donde
Sapphire
se encontró con este bug al poner su Pong en el OneChip de la organización del evento. La pelota empezó a cruzar las raquetas del juego sin rebotarse.
Yo me encontrado con el mismo problema esta pasada RU de diciembre.
Pusimos el Hans Adventure en un OneChip y nada más entrar en la habitación de salida del nivel, daba por pasado el nivel sin tocar la escalera de salida. Es decir, detectaba colisión sin haberlo.
Un Bug parecido ocurrió con una demo de un motor de plataformas: Al posicionar el personaje en unas coordenadas Y en concreto se ponian a parpadear sus sprites y el bit de colisión marcaba que habia. No podia ser, ya que el personaje estaba creado con 2 sprites y no habia más sprites en pantalla. Al principio crei que era un problema de inicialización de sprites, pero lo verifique y todos estaba con un patron en blanco (a ceros) y en otras coordenadas Y. Era imposible que tuvieran colisión ni parpadeo por 4 sprites en linea. Y además en un MSX real no pasaba eso.
Las soluciones para los 2 casos han sido diferentes
Para el Hans, he tenido que pasar a detectar colisión por software, es decir, calculos con coordenadas para verificar que realmente hay colisión. No ha podido ser de otra manera. Saltaba colisión continuamente en el momento que movieras la figura del protagonista. Este esta formado por 3 sprites de pixels colindantes. Deduzco que el OneChip hace saltar el bit de colisión al reposicionar esos 3 sprites. Internamente en algún microsegundo cree que hay colisión al moverlos.
Para el de plataformas ha sido diferente la solución, aunque cuando lo tenga más desarrollado con enemigos y disparos, el calculo de coordenadas va a ser obligatorio tambien. La cosa que más me mosqueba era el parpadeo de sprites teniendo solo 2 en linea. La solución ha sido realizar los cambios de sprites, el volcado a VDP, justo al principio de la interrupción del VPD, antes incluso del volcado de Tiles de cada frame. Esta demo redibuja los patrones de 4 sprites constantemente en función de las teclas que aprietas. Pues parece que mientras se estan subiendo esos bytes al VDP el OneChip da que hay colisión y apaga durante algún rato la visualización de sprites. O al menos eso parece. Con solo ese cambio de orden de hacer las cosas, ha desaparecido el parpadeo y el bit de colisión no se activa.
Bueno espero que os sea util esta experiencia mia y no os rompais la cabeza volviendoos locos del porque no va bien la colisión de sprites en el OneChip.
Si teneis alguna experiencia similar, o solución, o quizás esté equivocado en algo que he dicho, completadlo aquí.
Venga ! A crear !
