BLASTARDO (o Cutridium II si Cutridium I hubiera nacido)

...updated!

Ay omá que bonico

La música mola mas en estereo, por cierto.

Todavia falta mucho, pero ahi va la primera imagen de BOSS FLOPPOTATO.

Otia qué chulo. Si parece un boss de esos tipo Gunstar Heroes de la Megadrive.

Jooorl

No se de donde sacar memoria: NO TENGO SITIO PARA LA LOGICA DEL BOSS!
El compresor no es solucion, todos los datos, menos un puñado minimo de tiles, deben ser accesibles.
Y reducir el tamaño del codigo a costa de enrollar rutinas , tampoco: aun necesito ganar scans de tiempo, no puedo perderlos.
Voy a cargarme una rutina, pero asi todo...

Quita la música, ponle solo FX XD

No se de donde sacar memoria: NO TENGO SITIO PARA LA LOGICA DEL BOSS!
El compresor no es solucion, todos los datos, menos un puñado minimo de tiles, deben ser accesibles.
Y reducir el tamaño del codigo a costa de enrollar rutinas , tampoco: aun necesito ganar scans de tiempo, no puedo perderlos.
Voy a cargarme una rutina, pero asi todo...

Bueno digamos que ahí está gran parte de la diversión

De todas formas mirando la última versión para descargar, aunque no va a corresponder con la actual tuya, pero de todas formas lo comento por si acaso. En la zona baja de la RAM, a partir de $003A (bueno si luego pones un JP a una rutina de gestión de interrupciones, entonces podríamos empezar en $003B) parece libre, ya que sigo viendo el programa cargador basic a partir de $0170, y después todavía sigue habiendo hueco en RAM... puede ser una "tontada" pero quizás antes de que empiece la poda de las rutinas, deberías revisar el mapa de memoria por si acaso tienes marcada como usada alguna zona que luego no tocas.

De todas formas, voy a soltar algunas ideas generales, todas bastante obvias, pero como a veces solemos tener la cabeza a las 3 de la tarde, y yo el primero

Por supuesto, el consejo de la otra vez de reducir el uso de los registros índices, sigue siendo igual de válido. Otra posibilidad es revisar tu código automodificable, pues a veces es un arma de doble filo.

De todas formas esto último no te va a ahorrar gran cosa, las grandes ganancias las vas a encontrar siempre en mejorar la codificación de los datos, por ejemplo, si solo tienes 32 patrones distintos, pues procura codificar el mapa usando solo 5 bits, será solo algo más lento obtener el patrón del mapa (pero aquí no suele estar el cuello de botella de una rutina de pintado de mapas), pero habrás ahorrado un 40% de la ram consumida por el mapa.

Una de las últimas opciones, aunque está es más bien una costumbre mía, sería el reducir el espacio reservado para la pila, normalmente cuando empiezo un desarrollo suelo tirar por largo y le doy 256 bytes, espacio que luego puedo reclamar en caso de que me encuentre bastante "asfixiado"

Lo de la musica ni de coña, pierde el encanto!

Reduje tres rutinas a una, y elimine otra. Eso introduce un mini-bug en determinadas circunstancias, pero son dificiles de reproducir... y si pasa, no es nada grave. Como andamos con el espacio-tiempo!

@Syx: existen algunos bytes por esa zona, pero no tantos: recuerda que la zona baja de memoria la uso para buffers (y para un sistema de reinicializacion patatero), y si los sprites estan sobre "0", hay alberga "0". Algunos si se pueden recuperar, pero aun faltan estructuras que irian a esa memoria... la tendre que tocar, pero esa memoria ya la tenia "acutada"!

Es verdad, que ya lo habías comentado... es que me puse a mirar y ha dao la casualidad de que solo encontraba ceros por allí, jejeje.

Mira eso que he añadido en el comentario anterior (es que me has pillao editándolo, jejeje), lo de "recodificar" los datos, creo que ahí es donde tienes más opciones de recuperar bastante ram.

Y ANIMO!!!

A cinco bits recuperaria 462 bytes, no irian mal , aunque parte se fueran en las modificaciones al codigo para acceso-reconstruccion del byte.
Revisare mas rutinas, algunas provienen de las primeras versiones, igual las puedo minimizar reutilizando otras partes del codigo.
Pena de la memoria libre de cada buffer de pantalla, pero no me vale para codigo ni sonido, y cualquier referencia para otro tipo de datos, TENDRIA QUE SER DINAMICA! (el origen de esos bloques de memoria libre se "desplaza" con el scroll) Me temo que usarla consumiria un tiempo de proceso demasiado alto para Blastardo, y ademas, imposibilitaria cualquier split de pantalla futuro.

El Floppotato mola un huevo, a ver cuando se puede probar !

La última versión es la de la firma ?
Por ahora sólo he visto algun mini-bug gráfico de quedarse los pixels de blastardo con algúna línea de fondo, quedándose píxeles de fondo parpadeando, que a veces se convierten en líneas rectas si continúas moviendote de izquierda a derecha. Me ha pasado en alguna de esas plataformas cerca del suelo largas. Si te elevas y pasas la pantalla y vuelves ya se vuelven a dibujar bien. No sé si tendrá que ver con lo de:

Reduje tres rutinas a una, y elimine otra. Eso introduce un mini-bug en determinadas circunstancias, pero son dificiles de reproducir... y si pasa, no es nada grave. Como andamos con el espacio-tiempo!

A ver si puedo escuchar alguno de los desvaríos músicales de Mcklain, que no puedo ponerme el sonido ahora mismo ! (Mira que ponernos formadores de noche en el curro..)

Por cierto, el texto de historia de la intro, me parece brutal no, lo siguiente !

Ánimo !!

Por cierto, el texto de historia de la intro, me parece brutal no, lo siguiente !

Va un pelo rápido, ¿no?

@Metr:
No Metr, ese bug es el GRAN BUG, controlado y avisado en el primer post: sucede por como cambia la memoria de video del CPC al hacer scroll: para evitarlo, hay dos pasos:
a) calcular si estamos ANTES o DESPUES de ese "char de la muerte". Si estamos antes, no hacemos nada, si estamos despues, el offset a memoria de video que corresponderia por coordenadas debe ser recalculado restandole &800, y si estamos en medio...
b) IMPRIMIR CON UNA RUTINA ESPECIAL QUE DEBE COMPROBAR BYTE POR BYTE EL MOMENTO EXACTO DONDE LA MEMORIA SUFRE EL CAMBIO (wrap). Esa rutina es tan lenta, MUUUUCHO, que hace inviable que el juego corra a 50hz.
Si te das cuenta, el mapa ha cambiado, para que la zona con pupa aparezca debajo de la tierra. Como en breve, si tocas el suelo te daras una gran leche, nunca notaras el "bug". En esa zona baja de la pantalla, si puedo meter enemigos, en posiciones seleccionadas.

Solo retocare la impresion de los proyectiles, para evitar ser dibujados cuando caigan en el "GRAN BUG"
El scroll si puede permitirse la comprobacion del "memory wrap" por el gran numero de valores que puedo dar por supuestos al pintar la tira de datos nuevos: por eso las manchas "desaparecen" cuando repintas la pantalla moviendote.

@6128
si te refieres a rapido como "tan rapido y suave como el de "Jet-Set-Willy" "Prohibition" o "Arkanoid"", entonces si, todo va bien y esa es la idea (no es mas que un scroll "byte per frame" osease medio caracter mode1 por frame... recordar mi obsesion con los 50fps

... recordar que ademas de los problemas de velocidad, (que aun tenia pendiente recuperar scans para que en momentos "Invader+Beam+Bomb+Computer+Bullet+Scroll" caigan las frames a 25 hasta que uno de los tres proyectiles desaparezca), ahora se suman a lo bestia los problemas de memoria (la logica del BOSS es mas compleja, mucho, que la del Invader o los Computer, y no me cabe todo el codigo sin ir recuperando memoria)
No va a ser cuestion de horas, sino dias ver al BOSS operativo (tiempo+espacio+crear los graficos+pensar los ataques+implementarlos+... no doy pa mas)

NOTA: que listos eran "los antiguos"... aunque el scroll esta parado, el dibujado del BOSS consume mucho tiempo (6 sprites de 16*16, mas Invader mas municion)
Como hacer que el BOSS pueda atacar con "oleadas impresionantes de proyectiles" y que todo entre en un frame????
Ahora recuerdo como en muchas maquinas arcade, en esos momentos de "fuego a discreccion", el BigBoss se quedaba estatico (con cara de mala leche y concentrado, como si se estuviera tirando el cuesco de su vida)... esa es la clave, en esos momentos, NO HACE FALTA ACTUALIZAR LOS SPRITES DEL BOSS, queda pintado "estatico" en pantalla, el jugador esta demasiado ocupado esquivando balas! Y todo este tiempo de proceso, se desvia a la municion que nos lanzo!

EDITO: Imprimir 6 sprites consume mucho mas que uno "bestia" (se gasta mas tiempo en las rutinas asociadas, como mover o detectar colisiones... que solo se dañe en el punto "debil" implica que las partes inertes del Boss detecten colisiones para absorver las balas, o el punto debil SIEMPRE seria atacable... muchos calculos!), pero era la unica manera de hacer algo animado y vivo... imaginaros que uso un "megasprite", calcular el tamaño de sus datos graficos y multiplicarlo por los cuadros de animacion que necesitaria para hacer algo bonito! Si tengo problemas de memoria para el codigo, donde meter tanto gfx... pero la solucion actual hace aun mas critico el problema del tiempo de proceso...

... airomem sammmmm... airomem sammmmm... necesito airomem sammmmmm