Hola,
de momento voy a intentar trabajar 'imitando' el movimiento en el juego Shounen Mike, aunque no me gusta nada saltos tan grandes
En AGD, si tenemos un enemigo a 16 pixels y estamos quietos, tardará 8 movimientos (frames) en alcanzarnos mientras que en este juego
en solo dos movimientos nos alcanza!
Y si nos movemos uno hacia el otro, en AGD se requieren cuatro movimientos para chocar mientras que en este juego en un solo
movimiento ya chocamos!
Ya discutiremos este tema en el hilo de "AGD", aquí vamos a hablar de estructura de datos para sprites
El juego guarda todos los bitplanes necesarios juntos, o sea, 4 para 16 colores o 6 para 64 colores. El byte indicador de cuales bitplanes
deben ser llenados contiene $0F para 4 bitplanes o $3F para 6 bitplanes. Cada bit a uno hace que se copien datos al bitplane
Dicho byte indirectamente nos dice cuantos colores maneja: 2 elevado a numero de bits a uno. 2^4=16, 2^6=64
Los Patrones/Tiles siempre son a 64 colores en el juego, pero en las demos SHOWSCR9 y SHOWS91 solo admiten 16 colores y con la
restricción AGD de mostrar solo dos colores en cada tile (papel, tinta), pero como son pequeños, 8x8 pixels en lugar de 16x16, pues dan
el pego bastante bien aunque si alguien se lo currara podrían ser mucho mas espectaculares. La definición de los Tiles lo permite ya que
se guardan en cuatro bitplanes permitiendo 16 colores en cada pixel de los 64 que tiene.
Para los sprites, en V9958 permito 16 colores distintos en las 16 filas que ocupa un sprite, o sea cada dos bytes horizontales, un color
Sin embargo, mirando los juegos que ya he convertido, veo que la mayoría de veces el jugador usa cuatro colores mientras que muchos
enemigos solo usan uno o dos colores. Como además cada 'instancia' de una clase de sprite podría tener asignados distintos colores, esto
no permite definirlos como cuatro bitplanes, sinó simplemente su forma en un bitplane y guardaremos los bytes de color en la estructura
que controla los sprites que hay en pantalla (añadiendo hasta 16 bytes si hace falta)
Esto permitiría usar las definiciones de imáges y frames directamente de AGD sin conversión alguna
Los datos de colores serían como mucho 16 bytes, que podrían ser bits indicadores de bitplanes a llenar ($01-$03-$07-$0F para 1-2-3-4)
pero como sobran bits (el nibble alto siempre seria cero) podríamos guardar los bitplanes para el byte de la izquierda en el nibble alto
y el de la derecha en el nibble bajo. Así cada par de bytes en la definición de forma del sprite podría recibir dos colores distintos
Me temo que esto complicará un poco la programación del pintado del sprite, pero podría intentarse como experimento. Realmente
no creo que cambie mucho ya que un sprite 16x16 no permite 'ver' con detalle cambios de color en pixels vecinos ...
¿Qué opináis al respecto?
Cualquier idea será bien recibida
saludos
. 
(aunque lo suyo seria o paleta a negro o parar el CRTC de mientras)
PC 386 
