Movimiento de sprites dentro de un scroll de chars

[Laddh]

Una pregunta a los coders del foro, os pongo en situación, tengo un mapa de 4 pantallas en horizontal, hago un scroll izquierda y derecha, y quiero poner sprites enemigos en diversas plataformas y la pregunta es como  sincronizas el movimiento de los sprites para que vaya acorde al movimiento de la pantalla ( se mantengan en su plataforma, desaparezcan cuando esa parte del mapa no este en pantalla, etc ).
Alguna teoría, algoritmo o ejemplos sobre el tema? He buscado y no encuentro nada.

[josepzin]

Es una buena pregunta y tiene que haber tratados sobre eso.

Yo me imagino dos tipos de escenarios:
- Permanente: todos los sprites están vivos, moviendose por el mapa según su programación aunque el mapa esté en memoria
- Efímero: los enemigos se activan cuando están a X pixels de aparecer en pantalla y al salir de ese rango se reinician

[PacoBlog64]

Una pregunta a los coders del foro, os pongo en situación, tengo un mapa de 4 pantallas en horizontal, hago un scroll izquierda y derecha, y quiero poner sprites enemigos en diversas plataformas y la pregunta es como  sincronizas el movimiento de los sprites para que vaya acorde al movimiento de la pantalla ( se mantengan en su plataforma, desaparezcan cuando esa parte del mapa no este en pantalla, etc ).
Alguna teoría, algoritmo o ejemplos sobre el tema? He buscado y no encuentro nada.

Pues es algo que no he hecho nunca (al menos horizontalmente), pero a bote pronto se me ocurre guardar las coordenadas en X de cada sprite y de la pantalla actual de caracteres en formato 16bits, e ir comprobando si cada sprite tiene que mostrarse en la ventana gráfica actual. Con esta solución se debería traducir la dirección en 16bits o "absoluta" a la dirección de lo que se ve en pantalla (relativa al marco izquierdo de la pantalla), cuando un sprite tenga que salir en pantalla. No sé si me he explicado bien...

[SingletonJohn]

Una pregunta a los coders del foro, os pongo en situación, tengo un mapa de 4 pantallas en horizontal, hago un scroll izquierda y derecha, y quiero poner sprites enemigos en diversas plataformas y la pregunta es como  sincronizas el movimiento de los sprites para que vaya acorde al movimiento de la pantalla ( se mantengan en su plataforma, desaparezcan cuando esa parte del mapa no este en pantalla, etc ).
Alguna teoría, algoritmo o ejemplos sobre el tema? He buscado y no encuentro nada.

A las contestaciones de @PacoBlog64 y de @josepzin, que son MUY correctas, te recuerdo además que los sprites se pueden ocultar por detrás del borde, con lo cual su entrada y salida en pantalla es gradual. Es decir, para dibujar sus coordenadas en pantalla tienes que tener en cuenta que salen/se meten 24 pixels antes/después en horizontal y 50 pixels antes/después en vertical. La posición de coordenadas menores con el total de un sprite en pantalla es de (24,50) para la esquina superior izquierda

[josepzin]

De todos modos, seguramente laddh está buscando algo mas técnico y específico.

[SingletonJohn]

Yaaa....yo es por no estropearle la "peleilla".
Las ideas principales son:
- El sprite tiene que tener una velocidad horizontal de la misma magnitud que la pantalla, pero en dirección opuesta. Por lo tanto, la velocidad del sprite en x es Vxsprite - Vxpantalla. Hayq ue tener en cuenta el signo de la velocidad, por supuesto, ya que si ambas velocidades tiene la misma dirección las maginitudes SE SUMARÁN y si son opuestas se restarán. Eso ya te lo da la fórmula. Para los enemigos estáticos, cuya Vxsprite = 0, su velocidad en PANTALLA será -Vxpantalla por lo tanto. Es lo que se llama una velocidad relativa a la pantalla. La velocidad en y del sprite será la propia del sprite, ya que NO HAY SCROLL VERTICAL
- Con esa velocidad, la coordenada del sprite sera X=X+Vx e Y=Y+Vy...eso como siempre
- Para situar las coordenadas del Sprite "en el mundo" yo empezaría por asignarle coordenadas del Tile correspondiente a la esquina superior izquierda del sprite. Para que aparezca en pantalla antes o después hay que tener en cuenta su tamaño. SI tienes sprites de diferentes tamaños, yo no me liaría y usaría siempre las mismas dimensiones, las estandar:24x21. Como el scroll es horizontal, tienes que tener en cuenta el borde de la pantalla(los sprites se representan por debajo de él) y ponerlos con una X=0 cuando queden 3 tiles para que "salgan" (3 tiles x 8 pixels/tile = 24, que es la anchura estándar del sprite y de los bordes derecho e izquierdo). No tienes que pensar nada parecido en vertical.
-Como los sprites se "PINTAN" debajo del borde, hay que tener en cuenta que desaparecen con una coordenada 0(por la izquierda, que es el "borde izquierdo bajo el borde izquierdo) o 24+40*8+1= 345, (que es cuando su esquina superior izquierda queda bajo el borde derecho). En ambos casos no hay ningún pixel del sprite en pantalla (salvo que no tengan puesto el x2 en X o en Y...o que no sean multisprite....en cualquiera de estos casos especiales, dinos y te ayudamos
-Las buenas prácticas con sprites de C64 te dicen que NO apagues el sprite...que los dejes bajo el borde y lo recicles para evitar ciclos perdidos y tirones
-Cómo se traducen las coordenadas del sprite desde coordenadas de tiles?Pues teniendo en cuenta el sistema diferente de coordenadas de los sprites (ya que su cero es distinto y se mueven al pixel).Las fórmulas serían Xsprite=24+8*Xtile Ysprite=50+8*Ytile(ya que los bordes superior e inferior son de 50 pixels.Una vez "conectado" el sprite, es más fácil ir operando con la velocidad de la pantalla, que es unica para todos, y la velocidad del propio sprite(que será cero si está "anclado al suelo"), que traducir las coordenadas, que es más lento. el sprite quedaría "desactivado" si su x se sale del rango [0,344). En Y su rango visible es desde 50-24 = 26 hasta 26+25*8+1 = 227, es decir [26, 227)

[SingletonJohn]

cómo se traduce "cuando queden 3 tiles para que salga el Sprite"? Pues fácil. pongamos que las coordenadas de la pantalla en el mundo son (20,0) (la coordenada Y de la pantalla SIEMPRE SERÁ cero en tu caso, porque la altura del mundo es de 1 pantalla).En pantalla se pintarán las columnas 20 a 59 del mundo.si hay sprites en los tiles de la columna 20-3 = 17, deberán asociarse a un sprite con una X=0 y su Y correspondiente -> Ysprite=50+8*Ytile (ya que los bordes supeior e inferior tienen 50 pixels de anchura en lo que a sprites se refiere)...et voilá!

Esto es más lío de explicar que de hacer....cualquier duda que vayas teniendo cuenta

[Laddh]

Vaya.., gracias por todas estas anotaciones, me las apunto y a ver si las puedo aplicar.
El tema tiles sigue siendo una de mis asignaturas pendientes, aún no ha caído en mis manos un source que me explique claro (no soy bueno con la teoría, solo aprendo cuando veo un ejemplo práctico que expone y se ve lo que hace)
Voy con la "peleilla" 

[SingletonJohn]

Para las multiplicaciones en ensamblador. Lo vemos con las fórmulas de las coordenadas del sprite en funcióna de las del tile:
Xsprite = 24 + 8*Xtile => Xsprite = 8*3 + 8*Xtile ; Xsprite = 8*(Xtile + 3); Xsprite = 3ASL(Xtile + 3).
Es decir en ensamblador

LDA Xtile
CLC
ADC #$3
ASL
ASL
ASL

y ya tienes la X del sprite!
(NOTA: Multiplicar por dos equivale a una rotación de 1 BIT a la izquierda en binario. Por eso 8*=2*2*2=3ASL

(estamos hablando de tiles de 8x8 pixels, of course. Si fueran de 2x2 chars, sustituir el 8 inicial por un 16 ,esto es Xsprite=24+16*Xtile, y ver cómo simplificar la operación en ensamblador)

[SingletonJohn]

Vaya.., gracias por todas estas anotaciones, me las apunto y a ver si las puedo aplicar.
El tema tiles sigue siendo una de mis asignaturas pendientes, aún no ha caído en mis manos un source que me explique claro (no soy bueno con la teoría, solo aprendo cuando veo un ejemplo práctico que expone y se ve lo que hace)
Voy con la "peleilla" 

El tema Tiles está tirado. EL C64 en modo "normal" está preparado para textos, luego puedes definir un juego de caracteres que sean los tiles del juego(256 diferentes simultáneos). La pantalla será entonces una matriz de 25*40 bytes (1000 bytes) y en cada uno de esos bytes te cabe un número entre 0 y 255, que es la posición del tile en el charset: posición 0->@, posición 1->A, etc ,etc...este número es el ScreenCode del Char

Es decir, aunque suene ANTINATURAL, para escribir una Z en la esquina zuperior izquierda de la pantalla tienes que pokear:Poke1024,26. La pantalla estándar está en $400->1024 y la Z es el screen code 26

Los colores de cada char están en $D800 y también son 1000 bytes porque la correspondencia es 1 a 1 con la pantalla....es un "gemelo" de la pantalla con el valor de sus colores (colores de pixels sólo, no de fondo). Es decir, el byte cero de la pantalla tiene un color representado en el byte cero de la ColorRam($D800 o 55.296). Vamos, que si quieres pintar la Z de antes de color blanco, tienes que poner POKE55296,1

Esta es la base de los tiles...pero puedes tener diferentes modos de tile además del "por defecto"....tienes el tile multicolor y el modo "con color de fondo extendido" que básicamente funcionan igual, pero con "ciertas peculiaridades"

[Laddh]

El tema Tiles está tirado. EL C64 en modo "normal" está preparado para textos, luego puedes definir un juego de caracteres que sean los tiles del juego(256 diferentes simultáneos). La pantalla será entonces una matriz de 25*40 bytes (1000 bytes) y en cada uno de esos bytes te cabe un número entre 0 y 255, que es la posición del tile en el charset: posición 0->@, posición 1->A, etc ,etc...este número es el ScreenCode del Char

Es decir, aunque suene ANTINATURAL, para escribir una Z en la esquina zuperior izquierda de la pantalla tienes que pokear:Poke1024,154. La pantalla estándar está en $400->1024 y la Z es el screen code 154

Huumm, esto que explicas es para el manejo de chars normales, no? Los tiles son grupos de chars (2*2,3*3,etc) que es lo que aun no se aplicar

[SingletonJohn]

Es lo mismo, pero tienes que definir el TileSet de 2x2(por ejemplo) con la misma filosofía del charset.
Es decir, defines en memoria un lugar para esos tiles y los pones todos seguidos (lo mismo que el charset). Apuntarás por ejemplo, que el tile 0 es "abcd"....bueno, mejor dicho"1,2,3,4"...y así con todos uno tras otro
Tu pantalla de tiles tendrá ahora un tamaño de 20x12=240 bytes (procura no tener MáS de 255 tiles diferentes), que es MUCHO menos de 1000 bytes....es decir, se comprime la imagen

También tendrás que tener unas rutinas de pintado que cuando vean un cero, vayan a la tabla de tiles y lean"1,2,3,4"...y pinten en pantalla
AB
CD
...y tengan en cuenta que la pantalla de tiles tiene ahora 20 columnas y 12 filas

Esto es la base....pero puedes modificarla a conveniencia....por ejemplo....imagina que sólo tienes 16 tiles diferentes de 2x2. En cada Byte te caben 2 tiles, por lo que la definición de cada pantalla ahora será de 240/2 = 120 bytes, aunque la operativa de la "recuperación" se complica algo (no demasiado, para el espacio que se gana)

[SingletonJohn]

un tile de 3x3 yo JAMÁS lo definiría.....porque un ordenador "piensa" y almacena en binario, que es la matemática del 2,4,8,16, etc

Un 3x3=9 es MUCHO MAS complicado de gestionar porque los datos quedan totalmente "desalineados"...o si no, pierdes memoria metiendo ceros para "alinearlos"...y multiplicar por 3 o por 9 es mucho más complicado que por 2 o por 4

resumiendo..haría tiles de 1x1, 2x2, 4x4, 8x8, 4x2, etc

[SingletonJohn]

Es lo mismo, pero tienes que definir el TileSet de 2x2(por ejemplo) con la misma filosofía del charset.
Es decir, defines en memoria un lugar para esos tiles y los pones todos seguidos (lo mismo que el charset). Apuntarás por ejemplo, que el tile 0 es "abcd"....bueno, mejor dicho"1,2,3,4"...y así con todos uno tras otro...

Una vez que tienes claro esto y lo manejas con soltura (y siguiendo el ejemplo del tileSet de 2x2), YA CREAS EL CHARSET con el orden correcto: para el primer tile, el cero, defines en los 8x4=32 bytes el "dibujo de la A, la B, la C y la D"....y ya no tienes por qué tener un charset y un tileset "en paralelo"....tu programa en ensamblador verá el charset de 32 en 32 bytes y lo  pintará en el orden y coordenadas correctas con los scripts definidos antes, ya que para la rutina de pintar, los chars son de 32 bytes y la definición de pantalla es de 20x12

Esto son ideas...si te interesa tener a la vez tiles de diferentes tamaños, no te queda otra que definir un tileset por tamaño....aunque el tamaño de 4x4, es en realidad de 2x2 de tiles de 2x2....jejeje...parece un trabalenguas, pero ahorras MUCHO espacio

Con varios tilesets de diferentes tamaños, ahora sólo te queda idear una manera de marcarlos de alguna manera en la definición de la pantalla para poder recuperarlos....para esto hay muchas técnicas diferentes y dependerá del número de tiles en cada tileset, de cuantos bits te quedan libres en cada byte para poder usarlos de FLAG o de marcador de tamaño de tile, etc...o quizás uses un criterio POSICIONAL, es decir, los 20 primeros tiles son de 2x2, los 20 siguientes de 8x8, etc

En esto de la informática, yo te aconsejo que vayas de lo fácil a lo difícil, es decir, intenta probar a definir un tileset de 2x2 sobre el charset estándar del C64 (para empezar)  y vas creando poco a poco las rutinas y las vas complicando a medida que entiendes y dominas la base...yo te puedo soltar el chorizo de ensamblador y de fórmulas y de timings y no te enterarás de nada si te dan eso de salida

Aquí te podemos ayudar bastante en el proceso si vas sacando las dudas

[Laddh]

Pues muchas gracias, haré mis pinitos en cuanto a los tiles con tus indicaciones, aparte de seguir con lo que estaba, me has dado faena