Mi enhorabuena por el juego! Dio mucho que hablar el hecho de que alguien se hubiera animado a hacer cositas para el Vic-20. La verdad que el juego entretiene. He podido ver la pantalla del Draco de Cidelsa y está muy conseguido. Que no decaiga!!

Si que le veo cosillas interesantes. Es un formato muy molón para temas retro... eso de que tenga el típico aspecto de ordenador de 8 bits me gusta....

Ah. en la msxdev. Ya. Pues la verdad que no lo sé. En principio según sus propias reglas no permiten juegos con derechos de autor (de otro autor que no sea el que presenta el juego).
Nosotros por nuestra parte no ponemos pegas. Otra cosa es que la dev según sus normas lo descalifiquen. Ese asunto no sé como está...

Ok.

Nuestro buen rollismo en la respuesta también tiene que ver con la vagancia.... ponerse ahora a currar pa arreglar el juego uffff. Sigamos nuestro camino y que cada uno solucione sus problemas.

Encomiable en todo caso la disposición tanto de Narcisound como de Toni para meterle mano al tema.
Son unos cracks!

Es que Josepzin es un blando... yo los hubiera crujido pero me calmó ofreciéndome una jugosa comisión de las ventas de la versión MSX. No se que oscuro pacto tiene firmado con los msequiseros ;-P

Yo uso otro "truquillo"....no me hace falta ver si hay algún CHAR bajo la totalidad del collider, sólo lo que entra por cada cara del collider en la dirección del avance.
Es decir, si el collider es rectangular, sólo necesito saber lo que entra por el lado derecho cuando voy a la derecha, el de abajo cuando voy hacia abajo, etc....
Como esto no es una operación demasiado pesada, me guardo sólo las coordenadas de la esquina superior izquierda del collider y aplicando la anchura y la altura, no es complicado hacer la conversión para dos vértices.
Además de los dos vértices a calcular, sólo necesito tres datos (ya que al ser el collider rectangular comparten una coordenada).Calculando la fila/columna común y restando la fila/columna distinta, ya tengo unas coordenadas de INICIO de la VRAM a rastrear y luego voy en un loop en saltos de 8 (tantos saltos como el resultado de la resta de fila/columna distinta)...
...jajajajaa!!! Esto es más difícil de explicar que de ver

mmmm. Muy interesante. Me lo apunto para probar. Parece más óptimo que lo que yo hago. Ya te contaré 

Para el tema Sprite con el fondo, la cosilla la tengo más elaborada....

-Hay que hacer como se comenta por aquí una traducción entre las coordenadas de sprite y las de Caracteres.
-Como era una operación relativamente compleja y multiplicada por cuatro (cuatro puntos de colisión) por cada ciclo de gameloop tengo un par de truquillos.
   
      1-Precalculo y almaceno los valores de la conversión en dos vectores. Uno para X y otro para Y de manera que luego se pueda hacer una simple suma para la conversión
                       Sprite.CharPos=(P0Y[E0.Y])+P0X[E0.X];
     2.-Y en vez de hacer 4 cálculos con 8 tablas (4 para x y 4 para Y) Avanzo o retrocedo uno o dos caracteres (Dependiendo del tamaño del sprite) en la memoria de pantalla para calcular los 4 puntos de colisión
  Sprite.P0=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos);
  Sprite.P1=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos+1);
  Sprite.P2=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos-40);
  Sprite.P3=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos-39);

Esto tiene una pequeña pega y es que el diseño del sprite no puede ser de cualquier manera. Cuanto mas se ajuste el tamaño a múltiplos de 8, más precisa será la colisión.

Ufff. vaya mierda de explicación... Cualquier cosa me decís e intento aclararlo con más ejemplos

Tened en cuenta que tengo que recurrir a estos trucos por la lentitud de "C". Quizás en ensamblador no hace falta tanto lío.