YouTube version also has english subtitles (CC)
Otros enlaces del vídeo:
Vídeo demostrativo donde se pueden ver los primeros progresos de mi ultimo proyecto para Commodore 64. Se trata de mi versión particular del clásico "Space Invaders". De momento estoy tratando de ser fiel al desarrollo de la máquina original, pero tengo planeado incluir bastantes mejoras y "Power ups", algunas de las cuales, bajarán rodando, como en el clásico Arkanoid, al eliminar al ovni misterioso que aparece aleatoriamente de vez en cuando.
Entre las mejoras que tengo pensadas incluir se encontrarían misiles que tengan área de efecto al explotar, escudos para la nave, naves nodrizas GRANDES (jefes final de fase), lásers que eliminan una fila entera (con munición limitada), cápsulas que hacen que vayan mas rápidos o más lentos (los invasores, o tu propia nave...) ¡Y muchas más que se me vayan ocurriendo! (se aceptan sugerencias)
Por supuesto, habrá la posibilidad de elegir entre el modo CLÁSICO o el modo AVANZADO, para los más conservadores.
Entre todos los invaders que he podido observar que se hicieron para Commodore 64 (algunos muy buenos e interesantes), ninguno ofrece la posibilidad de luchar contra la formación completa de 55 invasores, como en la máquina arcade original de Taito. Me estoy esforzando para que esta versión ofrezca esta característica, optimizando al máximo el código de mi programa, que de momento está bastante avanzado, y ya permite el movimiento de todos los invasores (5 filas de 11 invasores)... aunque todavía estoy trabajando en optimizarlo para que el recorrido de las tablas sea mínimo y gaste el menor numero de ciclos del procesador posible.
Podréis descargar la imagen del juego, una vez finalizado, desde este mismo blog. También está previsto incluir aquí, un completo tutorial explicando como se hizo todo esto, paso a paso.
Juego basado en en Space Invaders II Deluxe (Taito)
Programado con Kickassembler.
Editor: Ultraedit-32 con colores de sintaxis del ensamblador del 6502
Graficos: Cuneiform y Photoshop
23 comentarios:
Ole, Lobogris!!! Una gran noticia ver que siguen saliendo coders en España para el c64. Y por las capturas que he visto, tiene una pinta genial.
Pues eso, q animo con el proyecto, espero q pronto lo podamos disfrutar!!
Gracias por tu aliento Bo!! :D estoy metido en 3 proyectos para c64! uno de ellos es TOP SECRET, y el otro lo estoy haciendo con Raúl de Los Burros del Soft (el otro proyecto a parte de la Carretera...) Este de los invasores, me he puesto a hacerlo para refrescar mis conceptos de programación aun más (¡hacia tanto tiempo que no programaba!) y me decidí por este, no solo por que es simple, sino por que en C64, como digo en el articulo, no he encontrado ninguna versión decente, con los 55 invasores a la vez. Seguro que muy pronto podreis disfrutar de este jueguecillo en vuestros commodores... Algo muy chungo, se avecina desde el espacio exterior ....
Mo-nu-men-tal!!
Tenemos telepatia,..dentro de poco vereis un video/tutorial mio de una Bitmap que alguno se va a quedar con la boca abierta!!
Ostras... me tomo unos días de vacaciones y a la vuelta me encuentro con esto!!! Un juego dedicado a Retroinvaders!!! :O
Por lo que se ve será un juegazo, y será un placer que sea el "Juego oficial de RetroInvades" :P
Me estoy poniendo al día con las retronovedades, todavía estoy dando los últimos ajustes al calendario!
Felicidades, Lobogris. Esto si que es noticia. y felicidades para Zanny por lo que le pertoca.
@Rulas, @Jose Zanni y @Bieno Gracias por vuestro feedback amigos! me alegra saber que os gusta ;)
-Con la Demo de RGS volvi al Basic despues de 20 años
-Con La Carretera aprendi a hacer graficos
-Con lo siguiente (que por cierto has soltado como Novedad) me empiezo a soltar en Programación (ya que será el primer juego en el que aparezca como programador)
-Con lo proximo que tengo en la cabeza quiero empezar a MOVER "Churufletas" (y perdon por la expresion) por la pantalla
Con esto quiero decir que el aprendizaje es una escalera de peldaños, que tiene que basarse en proyectos y en cada proyecto se va mejorando...
Tambien es importante saber que un buen Desarrollador debe de ser equilibrado tanto en Programacion como en Gráficos,..yo ya he llegado donde queria en lo segundo,..ahora quiero equilibrarme en lo primero..
En definitiva, que no soñeis ni penseis, que todo es ponerse Al Hierro poco a poco y subiendo y subiendo, porque lo que un Commodore puede dar de sí es impresionante,.es una herramienta crativa como pocas y que puede canalizar muy bien nuestra dinámica en este sentido..
Así que todos a animarse!!
Por otro lado también en relación a Lobo comentar que la Participacion (Aunque en realidad es un Burro)en el siguiente de Los Burros ha sido un regalo de Dios, marcando una nueva Etapa.
Gracias!!
Me ofrezco Publicamente a Concurso para hacer la Pantalla de Presentacion!! del proyecto RetroInvaders C-64 de Lobo!!
jeje pues sí soy un lobo burro! ejem un lobo de los burros, esto... parte del equipo de Los Burros del Soft, ahora sí jeje
Excelente, @Rulas: Adjudicado! queda públicamente dicho:¡¡tu serás quien haga la pantalla de carga del juego!!
Para mi tambien ha sido una bendición haberte conocido Raúl :) gente buena así no abunda en este pequeño planeta
Viendo que no recibes los comentarios desde el FB, sigo por aquí.
******************************************
Mi pregunta:
Veo que en el código tienes cosas como esta: sta #d800+[yc*40]+xc, x
¿Cómo resuelve el ensamblador todo eso? Lo pregunto porque ahí tienes una multiplicación.
******************************************
Tu respuesta:
sta $d800+[yc*40]+xc,x lo resuelve el compilador interpretando la operación matemática, o sea que en realidad queda por ejemplo sta sta $d800,x si xc=0 y yc=0 o sta $d841,x si xc=1 y yc=1. O sea que es un valor constante. Las variables son definidas con .var, por lo que no son variables propias del codigo ensamblado si no facilidades para el código fuente (para el kickassembler)... En este caso con inx moveria el bicho 1 byte a la derecha (en un offset de pantalla constante predefinido).
******************************************
Sigo con dudas :P
¿yc y xc son variables?
si, son variables, pero no variables del código obj generado, sino para el preprocesamiento de éste.
es parecido a lo que pasa con la macros
un ejemplo claro:
.var x=5
.for (var x=0;x<5;x++)
{
lda #0
sta variable+x
}
variable: .byte 255
esto queda generado (una vez compilado con kickass) asi en el c64:
lda #0
sta $1000
lda #0
sta $1001
lda #0
sta $1002
lda #0
sta $1003
lda #0
sta $1004
las .var son variables que se usan para el pre-procesamiento.
y las variables de etiqueta (las que se finalizan con ":"), el compilador les otorga una posición de memoria (según el puntero de programa (PC) en el que se encuentran definidas.
en el anterior ejemplo, sobra .var x=5
Entonces por lo que veo, ¿usar este tipo de facilidades genera montones de códigos duplicado?
Porque en el ejemplo del for, son solo 5 pases y es solo un lda sta, pero si fueran 200 y adentro del for hubiera muchas instrucciones... ¿me equivoco?
Bueno, el bucle ".for" puede generar codigo duplicado (la cantidad que necesites) para no tener que teclearlo tu ... es ideal si tenias que teclearlo, si no hay que estar atento y no confundir que kickass no es C/C++, por lo que kickass no te va a convertir el bucle escrito en un "script" de alto nivel a un eficiente código máquina 6510 (código objeto).
Dicho de una forma, el ejemplo de antes ES TAN SOLO una forma cómoda (y queda compacta y elegante a la vista) de no tener que teclar 10 lineas, pero nada te impide usar Cut&paste en tu editor y cambiar la direccion de memoria de cada STA a mano...
mira como uso .for para crear la tabla que me guarda el tipo de invasores, en mi juego:
// color del invasor (según fila) 55 registros (bytes)
INV_COLOR:
// color (según numero de fila)
{
.for (var f=0;f<5;f++) {
.for(var c=0;c<11;c++) {
.if (f==0) .byte LIGHT_GREEN
.if (f==1) .byte GREEN
.if (f==2) .byte GYAN
.if (f==3) .byte YELLOW
.if (f==4) .byte LIGHT_RED
}
}
¡Imagínate, tener que teclear 55 registros y acordarte que cada 11, empieza el color para una nueva fila! Y esta es una tabla que guarda un BYTE, la de offsets de pantalla y offsets de color contiene un WORD (2 bytes) por registro (110 registros).
Mira que elegante y cortito queda con la ayuda de .for :)
esta es la tabla de offsets, como curiosidad:
INV_OFFSET_PANT:
{
.const cx=8
.var x=cx .var y=3 .var offset=0
.for (var f=0;f<5;f++) {
.for(var c=0;c<11;c++) {
.eval offset=[y*40]+x
.word offset+virtual
.eval x=x+2
}
.eval y=y+2
.eval x=cx
}
}
.eval es para evaluar una variable definida anteriormente con .var
esta tabla te genera los 110 registros con los offsets de pantalla de los 55 invasores, y podría haberse tecleado manualmente así:
INV_OFFSET_PANT: .word $c800,$c801,$c802 (...) ¡asi hasta los 110 registros!
asi programaba yo, en assembler, antes de conocer a kickass ;)
bueno para generar tablas serias, me hacia un programa en basic que me generaba un fichero ascii, para incluir en la fuente, ya con la estructura TABLA DB 23,23,0,234,255,...
Gracias por tanta respuesta!
Ya entiendo la diferencia entre el código generado por el ensamblador y el compilador de C (cc65)
De hecho, pensé que al poner x*40 eso se convertía en el código de una multiplicación (que es lo que hace el CC65) con la consiguiente ralentización del 6510.
Aunque igual me pregunto que usar estas operaciones (sta $d800+[yc*40]+xc,x) tambien deben ser para casos puntuales ya que se generan cosas en plan "tocho de codigo"... ¿no?
eso es, lo que queria decir se puede resumir en que x*40 no se convierte en código, si no que el compilador evalua la expresión y pone el resultado a continuación.
Bueno yo uso mucho esas expresiones, por que es mas facil leer eso que un numero ya calculado, al pasar el tiempo... por que asi ves la lógica de ese numero, el por qué de ese número.
Son cosas personales, claro.
las que te generan "tochos de código" hay que usarlas puntualmente y con cuidado sí :D
Ahora lo entiendo perfectamente :)
¡Estupendo! ;)
Publicar un comentario