Lala; 20160228

Bueno, tras las pajas iniciales, en el día de Andalucia, y con las versiones actuales de cc65/neslib, empezamos el proyecto. Voy a ir poco a poco, de hito en hito. No soy capaz de decidir entre hacer esto en pantallas de 512×192 reales, o seguir con pantallas de 256×192 reales pero mostrando dos.

El primer enfoque tiene estas ventajas:

  • Con RLE, las pantallas pueden comprimir más.
  • Hay cierta lógica que se simplifica: no hay que andar cambiando de “Pantalla virtual”.
  • Los fantys quedan naturales porque pueden abarcar toda la pantalla.

Pero tiene estos contras que no me gustan:

  • Ahora prx tiene que ser int.
  • Ahora en_x tienen que ser int.
  • Necesitamos un buffer de pantalla mayor (384 bytes!)

Operar con int es chungow!

No consigo decidirme, mierda. A tomar por culo, lo hago de 512×192 y a cuchillo con todo. Seguro que los int no cargan tanto, y si no, ya me buscaré la vida.

Necesito hacer un split. He colocado el area de juego en el scanline 32. Ese split es bastante más bajo que el de pong pong. Tendré que aprovechar el tiempo colocando más cosas antes del split. Toda la lógica de cambiar de pantallas, por ejemplo, y cosas así.

Para empezar, voy a modificar el conversor de mapas para que cree pantallas de 32 tiles de ancho. Necesito además que las funciones que modifican tiles (durante vblank o con ppu apagado) admitan coordenadas X que cubran ambas pantallas horizontales, seleccionando el nametable correcto.

El primer hito será, por tanto, convertir el mapa y representar las pantallas en los dos nametables.

¡Vamos al lío!

~~

Hito #1 :: Mapa

Modificando rlemap.bas para convertir mapas con pantallas de 32×12 me he dado cuenta de que así el tema de las decoraciones se complica al no poder meter XY en un solo byte (al ser X de 0 a 31 y necesitar cinco bits). Toda esta mierda hará que todo ocupe más, y que no pueda reaprovechar código, así que para empezar los mapas irán por pantallas ya que esto no afecta realmente a la lógica.

  • La función drawscr tiene que pintar la pantalla N en NAMETABLE_A y la pantalla N+1 en NAMETABLE_B.
  • La función que dibuja el tile en la pantalla toma en cuenta en qué nametable escribe para modificar el map_buff
  • Tortilla.

Voy a empezar con esto.

~~

Mapa renderizado. Ahora los enemigos 🙂

Hito #2 :: Enemigos

Aquí puedo jugar con la baza de que los enemigos van por pantallas. Tengo 3 enemigos por pantalla, o sea, 6 en total – pero la colisión solo será con la nésima mitad, con n = prx >> 8 (que valdrá 0 o 1) -> más rápido, la mitad será !!(prx & 256) – pero eso lo dejo para luego. Por ahora tengo que desempaquetar los enemigos en RAM y toda la leche migada del original.

  • Sacar los enemigos de ROM a RAM (los necesarios, con todo el tema de la persistencia). Esto es igual pero teniendo en cuenta que tengo que sacar seis, no 3, a partir de n_pant.
  • Mover los seis enemigos. Ojal! Puedo seguir usando unsigned char para las X lineales durante el movimiento, ya que los enemigos estarán en una de las dos pantallas, y luego actualizar solo este byte – como en pong pong. Los fantis y demás mierdas los dejo para más adelante. Lala es un buen juego para empezar con estas zarandajas porque no tiene prácticamente nada.
  • Mostrar los seis enemigos en pantalla. Si su “x” real >= cam_pos y <= cam_pos + 240 -> dibujar en “x” real – cam_pos. Lo de siemprer.

Vamos al lío!

~~

¡Funcionando! Faltan las colisiones (sobre todo las de las plataformas móviles), pero eso ya lo resolveré cuando tenga al player moviéndose… Porque ahora toca:

Hito #3 :: Player

No paro de darle vueltas al tema de que a lo mejor puedo hacer al player por pantallas tambien, joder. Es que no paro de pensarlo. Voy a ir a por la estufa, que me estoy quedando helao, y luego divagaré aquí un poco para terminar de decidirme. Ya se ha visto mil veces que verbalizando los problemas los resuelvo mucho mejor. Allá vamos…

Creo que no ganaría gran cosa. A fin de cuentas, el grueso de la lógica se hace con enteros, y aunque, tal y como está diseñado el mapa, nunca se va a dar que el jugador se encuentre en el borde de la pantalla y los tiles sobre los que anda sean de diferente comportamiento, creo que estaría introduciendo una capa de complejidad totalmente innecesaria.

Voy a empezar a portar el movimiento poco a poco, teniendo siempre en cuenta las mejoras que he descubierto al hacer Super Uwol y Pong Pong – ante todo, el tema de que los attrs van siempre de dos en dos y que no tengo que estar llamando a una función que devuelva los resultados con todo el overhead que eso implica. Usaré el tema de las globales y la función que calcula dos attrs para los dos puntos de colisión.

Además, aprovecharé y haré que el top-left real del metasprite corresponda con el bounding box.

Pero necesito descansar un rato, voy a hacer otras cosas. Churum debe estar a punto de caramelo también. Creo las variables en zp y me doy un descansou.

~~

A la vuelta, creo que puedo encasquetar pseudodirectamente las rutinas de pongpong, ampliarlas con las plataformas móviles (después) y adaptar lo mínimo – cambiar la rutina que lee los comportamientos de los dos puntos del mapa para las colisiones. Yeh. Creo que esto es suficiente 🙂

~~

Como dice el murciano: me cago y me queda. El código del pongpong, muy levemente modificado, con una nueva función para calcular el comportamiento de los dos puntos para la colisión, un manejo de cámara tonter y… ¡BINGOW! Cómo mola hacer los motores como putos tentes XD

Ahora las colisiones y las plataformas móviles 🙂

Hito #4 :: Player <-> Enemigos

  • Plataformas móviles funcionando. El código es el mismo que en MK1 NES pero con una pequeña optimización (que pienso trasladar a MK1 NES) y usando la constante FIX_BITS (que en este juego vale 4) en lugar del literal 6 para hacer las conversiones de punto fijo.
  • Enemigos funcionando — me hice un poco la picha un lío pero es que no recordaba que las coordenadas de los enemigos funcionan dentro de su “pantalla virtual” y que a la hora de comparar con el prx tenía que añadir el offset de 256 si el enemigo era id >= 3.

Hito #5 :: Cambiar de pantalla

¡¡Hecho!! Un poco de corta pega más y listo. Funciona, parece, porque por ahora no lo puedo probar lateralmente (la primera torre necesita una llave para salir y aun no está hecho eso).

Hito #6 :: El split del scroll

Hostia puta, no había pensado en el maldito split del scroll. A ver cómo me las apaño con las transiciones. Esto va a ser lo que más quebraderos de cabeza de, seguro. Y nunca terminará de quedar bien. Aw.

~

Meh, al final hubo complicaciones, pero las resolví con mi picha, ondeándola al viento como un lazo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s