¡Hola!

Estaba optimizando el código de Pérez the Mouse. Había conseguido una mejora de rendimiento suficientemente alta como para permitirme poner un segundo sprite para el ratón y los enemigos. Después de diseñarlos, añadirlos al código, etc. todo funciona maravillosamente bien: tengo tres sprites dobles moviéndose por la pantalla, se ve de lujo y no se detecta colisión ninguna mientras no te pille ningún enemigo (es decir, los sprites están bien diseñados y no se solapan enrte ellos). No utilizo ON SPRITE; las colisiones las miro, una vez actualizados todos los sprites, con VDP(8 ) AND &H20

El problema es que a partir de determinado punto (concretamente, al entregar una moneda, que se oculta dicho sprite en la línea $D1), se empiezan a detectar colisiones aleatoriamente y no entiendo por qué.
Al principio pensaba que era que los sprites en la $D0/$D1 podían colisionar entre ellos... pero eso no tendría sentido porque me hubiera pasado con la versión anterior del programa (la de 1 sprite por personaje). Estuve mirando todos los valores de la tabla de atributos de sprites a ver si veía algo raro... pero nada. Al final puse un bucle infinito después de la primera detección y ¡bingo! Si me encuentro con un malo (colisión real) el bucle infinito permanece (el bit está siempre a 1)... pero en las colisiones ficticias pasa de 1 a 0 sin que se mueva ningún sprite.

Sabiendo eso, he conseguido filtrar dichas colisiones ficticias metiendo un pequeño retardo y volviendo a comprobar (nota: el cambio de color de fondo es simplemente para ver cuándo va detectando falsas colisiones)...
IF (VDP(8 ) AND &H20) THEN FOR I=0TO9:NEXT:COLOR ,,PEEK(&HF3EB) XOR 15:IF (VDP(8 ) AND &H20) THEN COLISION
...pero me parece "poco serio"; el 9 es el mínimo con el que he conseguido completar una pantalla de juego sin que diera una falsa colisión, pero nada me asegura que en otra partida ese valor no se quede corto. Y además mete un retardo aleatorio que, cuando da de vez en cuando, no se nota mucho, pero cuando empieza a detectar colisiones como si no hubiera un mañana, da al traste con lo que había ganado optimizando.

He leído vaios post al respecto de dicho bit, que está mal emulado o que no funciona como se espera... En ensamblador miraría las colisiones por software y listo, pero en BASIC no puedo hacer eso eficientemente. Yo creo que el problema viene de que el "recálculo" de ese bit coincida entre medias de los cambios de los patrones de un sprite doble (momento en el que algún píxel puede coincidir), pero no entiendo por qué empieza a hacerlo sólo a partir de determinado momento y no antes.

¿Se conoce alguna solución? Si no hay remedio tendré que resignarme a que mis personajes no tengan sombra, ¡con lo bonita que quedaba! snif, snif

P.D.: Todo esto lo he probado con el meisei y el BlueMSX emulando MSX1; no sé si funcionará en un MSX real, pero me gustaría encontrar una solución emulador-friendly.

Si usas varios sprites para dar más de un color al personaje el bit de colisión de sprites siempre te dará problemas. Lo más habitual es ignorarlo y comprobar uno mismo las colisiones mirando las coordenadas de los personajes.


Condicionales no probados, pero creo que deberían ser esos.

Buenas,
Supongo que ya lo debiste leer http://karoshi.auic.es/index.php?topic=1878.0

Yo estoy seguro que tu juego en BASIC en un MSX real funciona perfectamente sin esos apaños de control de colisión.
Con Hans' Adventure, en su versión BASIC "Escape from the dwarves' goldmine" me ocurria algo parecido.
Hans tiene 3 Sprites muy cercanos: Barba,cabeza y gorrito. En fmsx no habia manera. Detectaba colisión tooodo el rato.

A Emu perfecto, no le mires el bit de colisión

Perfecto.
Es que así es como se hace en ASM. O al menos es como lo hago yo.
Todo en RAM como seria en VRAM y luego "vomitada/ subida" a VRAM de golpe.