[Proyecto] Prince of Persia para Atari

[fcatrin]

Hace un tiempo atrás estaba leyendo un blog sobre Commodore, 6502 y otros, y me encontré con que alguien había creado un port de Prince of Persia para C64. El juego originalmente fue creado para el Apple II que también usaba el 6502, además fue portado a un montón de plataformas, pero no existía para Atari XL/XE así que me puse a ver si efectivamente era así o había alguien trabajando en el tema. Me fui directo a AtariAge y vi que efectivamente había gente interesada en hacerlo, compartieron ideas por unos 2 o 3 años, se pelearon, se insultaron, etc, y al final no pasó nada.

Un proyecto así se veía muy interesante para mi. En mis tiempos del Atari había programado un montón, pero nunca un juego (había hecho uno, pero muy primitivo). Conozco la teoría de cómo hacer un juego, pero en las plataformas actuales es una tarea titánica para mi, y lo más probable es que pase sin pena ni gloria. Un juego para Atari sería completamente diferente, es mucho más manejable, y podría sacarme ese gustito de haber hecho algo bueno en es plataforma. Además que tiene muchos desafíos técnicos, la escasez de memoria, colores, su precario procesador hace que todo sea un desafío. En fin, quería revivir esos tiempos en que me podía pasar una tarde entera tratando de resolver un problema con lápiz y papel, para luego verlo funcionando en mi Atari.

Otro factor importante es que no hay mucho que decidir a nivel de diseño de juego, y en parte también a nivel de diseño gráfico. Además el código fuente está publicado, como para ir a resolver dudas, en general hay extensa información como para no quedarse entrampado, era cosa de sentarse y ponerse a programar.

Este es el primero de una serie de posts sobre el tema en donde quiero compartir con Uds los avances de este juego, y así también poder recordar a futuro cada problema encontrado como para escribir un historial de su desarrollo.

[fcatrin]

Lo primero que hice fue verificar si alguien ya estaba trabajando en el juego, o bien por qué no se había concretado. En el topic de AtariAge sobre el tema se veían buenas ideas, sólo que entre tanta discusión y sin una dirección clara, no se escribió nada de código. Así que eso me daba libertad total por el lado del código!

También encontré algunos mockups muy buenos de cómo se podría ver este juego en Atari, y vaya que me sorprendieron, más bien, me fascinaron! Acá hay un ejemplo de los mockups que me motivaron a poner manos a la obra:

post-6369-1257582555.png (8.28 KiB) Visto 4216 veces

Junto a ese mockup se comenzaron a discutir ideas sobre cómo utilizar las interrupciones por linea y los Player/Missiles para lograr los colores planteados. Yo no participé en esa discusión ya que eran desde mucho antes.

Si bien los gráficos se ven bastante bien, otra cosa distinta es poder hacerlo con las limitaciones gráficas del Atari, con la memoria y velocidad disponible considerando la forma en que Prince of Persia hace render de los gráficos. No es un simple tile render como el de Montezuma o Draconus, sino que es un render tipo isométrico. Más detalles en futuros posts.

[jdhernacl3]

Estimado,

Buena suerte con el desarrollo. Durante el avance del juego si puedes contar que herramientas utilizas.

Saludos!

[Don Uga]

Espectacular proyecto, quedo atento para saber mas detalles

[fcatrin]

Antes de entrar por el lado de las herramientas, me gustaría contar un poco como ha sido la estrategia para abordar esta conversión.

Hay tres fuentes de información principales:

* El código fuente para la versión original de Apple II
* El documento de Jordan Mechner orientado a los desarrolladores de PoP para otras plataformas
* El análisis de ese material que hizo MrSid, autor del port a C64

Los dos últimos ayudan a entender el primero, ya que de buenas a primeras es relativamente complejo. Incluso creo que uno podría hacer el juego sin necesidad del código fuente y así es más o menos como lo he abordado hasta ahora. Solo en caso de dudas muy específicas, sobre todo con las estructuras de datos, voy a mirar el código fuente.

Por otro lado, viene la parte de la programación misma y es aquí en donde hay un cambio abismal respecto a lo que se podía hacer en los años 80/90.

Mi estrategia se basa en un pequeño módulo de emulación del video del Atari en Java. Es aquí en donde hago las pruebas de los algoritmos, la interpretación de los datos, etc. Esto me permite avanzar MUY rápido ya que tengo debugger, el código es más o menos de alto nivel de abstracción y puedo rápidamente hacer modificaciones e ir empapándome con la forma en que funciona PoP. Para tener una idea, creo que estaba renderizando los gráficos del juego al segundo o tercer día de trabajo. Con todos los cambios que hice, hacer lo mismo programando en ASM del 6502 me hubiese tomado más de una semana como mínimo.

Aqui pueden ver una captura del código de pruebas en Java

Spoiler: MOSTRAR

Una vez que tengo claro el funcionamiento, escribo el código para 6502. Eso sí, el código Java que uso para experimentar está pensado en que después será código de 6502, hay muchas tablas y rutinas muy chiquitas, entonces el paso es bastante directo.

Para programar en Atari uso un ensamblador cruzado. Aquí hay MUCHAS alternativas, al final me quedé con uno que se llama ATASM. Una persona hizo un plugin de Eclipse que integra varios ensambladores y así se puede trabajar en forma relativamente moderna, por ejemplo integrandose con control de versiones y ese tipo de cosas.

Finalmente, el código lo ejecuto en el emulador Atari800 en donde hay un monitor integrado. Si algo sale mal, levanto el monitor y puedo ver la memoria, ejecutar código, etc. A veces, para pruebas específicas pongo un código ilegal a modo de breakpoint, el emulador me dice que hay un código ilegal, abre el monitor y puedo hacer debugging paso a paso.

[Marcelo-Z]

una pregunta tienes pensado hacerlo correr en un atari de 64k, 128k o mas?


Saludos

[fcatrin]

una pregunta tienes pensado hacerlo correr en un atari de 64k, 128k o mas?

Voy a hacer el esfuerzo para que corra en 64KB, como referencia sólo el código del original es de 48KB, así que ahí veremos.

Hay muchas cosas que aun no sé cuanta memoria ocupará, como los sprites, o si voy a requerir double buffer.

[renix]

Que bueno que lo publicaràs acá... Se agradece porque es tremendo proyecto...

[vitoco]

Qué buena! Estaré muy pendiente. Si necesitas ayuda, aquí estamos

[dogdark]

yo algo vi de un video así corriendo ya una parte del juego en un atari y me parece que es tu propiedad Franco. Esperemos que pueda correr de buena manera para poder jugarlo en un atari real, se agradece por tu aporte y que salga todo bien, suerte.

[fcatrin]

Gracias por su feedback, y por la ayuda ofrecida!

Continuando con esta historia (no está sincronizada con los eventos reales), el siguiente paso fue decidir cómo enfrentar el proyecto de forma de detectar tempranamente su factibilidad.

Spoiler: MOSTRAR

Aun no sé si es factible

Las restricciones principales son:

* Memoria. El juego original tiene 48KB sólo de código, los sprites del jugador ocupan 30KB, los de los enemigos, 6KB cada uno, y aun falta el escenario, los mapas, etc. Sí, ya nos pasamos hace rato de los 64K

* Procesador. El procesador por si solo no es una restricción, el juego original y el reciente port para C64 ocupan nuestro querido 6502. En Atari el problema es la forma en que el video interviene en las lecturas y escrituras a RAM, éstas SON lentas a menos que desactivemos el video, lo que no se puede hacer en un juego. Si han visto como en algunos programas desactivan el video y se van a negro para reproducir sonido digitalizado, ahí tienen la explicación

* Gráficos. Los gráficos del Atari permiten usar sólo 4 colores por linea a una resolución aceptable para Prince of Persia. Se pueden obtener más colores a través de los PMG, pero ahí la cosa se pone truculenta.

Decidí que lo primero que se debería trabajar era el lado del procesador y los gráficos, ya que por el lado de la memoria hay flexibilidad, simplemente podemos hacer el juego para 130XE o bien algún sistema de expansión de memoria (no quiero llegar eso). También se pueden usar estrategias de compresión, eliminar algunas cosas, etc

Luego definí las siguientes etapas en el desarrollo (en la mente, primera vez que las escribo):

A) Proof of concept
1. Background rendering
2. Background Animations
3. Sprite rendering
4. Sprite masking
5. Sprite animations
6. PMG overlays
7. PMG masking
8. Sound effects

B) Full game
1. Collision detection
2. Enemies
3. A) for the full game
4. Special/Edge cases
6. Cinematics
7. Presentation

A la fecha me encuentro en la etapa A5 a nivel de código Java, y en A1 a nivel de código Atari.

En los próximos posts les contaré acerca de cada una de esas etapas (sujeto a cambio)

[josepzin]

Pregunta: ¿no es mejor usar el código ya escrito para 6502 y adaptar sólo las partes relacionadas al Atari, o sea lo visual?

[fcatrin]

Pregunta: ¿no es mejor usar el código ya escrito para 6502 y adaptar sólo las partes relacionadas al Atari, o sea lo visual?

Para eso primero hay que entender el código actual para separar lo que es parte del juego y lo que es parte del Apple II, y en esos tiempos no se programaba de esa forma. Por ejemplo toda la parte gráfica está diseñada en base a los gráficos para AppleII, esto es, 280/140 pixels por linea variando entre 1 o 2 pixeles por bit, 7 bits por byte. Toda la parte más compleja, que es la que dibuja los fondos, ya no tiene sentido.

Hay otras cosas que no están bien optimizadas, por ejemplo en vez de ajustar convenientemente los gráficos a bytes, estos pueden estar ligeramente desplazados y los ajustan en base a rotaciones... de 7 bits. El masking también es excesivamente complejo, y aun no le veo justificación. La parte del sonido no se puede aprovechar, salvo el código que genera los sonidos que está amarrado al código de animación, etc.

Hay algunas cosas que si se pueden usar, pero es lo mínimo, por ejemplo las tablas de secuencia de animación, las tablas que describen los bloques y... no mucho más que eso.

En adaptar el código, ver por que no funciona en el Atari, entender las partes que están de más, etc, sería demasiado tedioso en mi opinion. Partiendo el código de cero, siguiendo mi estrategia, en 3 días ya estaba dibujando los gráficos del fondo, en comparación, al autor del port para C64 le tomó un mes llegar al mismo punto.

Hay también un factor motivación/recompensa. Tomar un código que no te sirve (ya dije que sólo el código para Apple ocupa 48KB?), y tratarlo de ajustar para que funcione un poco, no es lo mismo que pensar tu mismo en los mejores algoritmos del punto de vista 2015, y verlo funcionar en cosa de minutos.

[josepzin]

Quedó clarísimo

[vitoco]

Hace un tiempo alguien preguntó: ¿cómo hacer un juego? Para eso hay muchas respuestas posibles, sobre todo dependiendo de la arquitectura a utilizar. Sin embargo, a pesar que usamos la misma arquitectura, tu estrategia difiere bastante de la que yo utilicé para mi juego de swap, yo partí con la lógica del juego y posteriormente le agregué la gráfica... la tenía pensada, pero no era relevante sino hasta que viera funcionando los algoritmos. Bueno, después de todo, son juegos muy distintos...

Respecto de usar java para prototipar, shuatas... tendría que verlo para entender por qué haces ese paso previo. ¡Y hay demasiada información en el pantallazo de eclipse!

No me he dado el tiempo para buscar los fuentes originales ni para mirar el tópico en AtariAge, pero por lo que comentas, más que un port, éste sería un remake. Supongo que en los fuentes están los bitmaps necesarios para los sprites y para las pantallas. ¿Entendí que usarías player/missiles? ¿Cuántos elementos animados (sprites)es necesario presentar simultáneamente en una pantalla? Imagino que para puesrtas y trampas animarás elementos del background. ¿ANTIC 4?

Espero ir viendo pantallazos de los avaces.

[fcatrin]

Hace un tiempo alguien preguntó: ¿cómo hacer un juego? Para eso hay muchas respuestas posibles, sobre todo dependiendo de la arquitectura a utilizar. Sin embargo, a pesar que usamos la misma arquitectura, tu estrategia difiere bastante de la que yo utilicé para mi juego de swap, yo partí con la lógica del juego y posteriormente le agregué la gráfica... la tenía pensada, pero no era relevante sino hasta que viera funcionando los algoritmos. Bueno, después de todo, son juegos muy distintos...

Así es, en este caso la lógica del juego y la gráfica ya están. El desafío va por otro lado, principalmente en sacarle provecho al hardware de Atari respecto al Apple II.

Respecto de usar java para prototipar, shuatas... tendría que verlo para entender por qué haces ese paso previo. ¡Y hay demasiada información en el pantallazo de eclipse!

Porque prototipar en asm de 6502 sería demasiado esfuerzo para muy poca ganancia. Como decía anteriormente, leer el código gráfico de la versión original es muy tedioso y no sirve porque son formas muy distintas de tratar el video. Cual es la alternativa? Entender cómo funciona el juego en un nivel de abstracción alto y programarlo desde esa perspectiva.

Java es uno de mis lenguajes más fluidos, pude armarme un entorno simulado en unos minutos y ya estaba probando cosas. Si tengo errores, puedo depurar tranquilamente, etc. Una vez que tengo claro cómo interpretar los datos del PoP original, el dibujado y todo eso, ahí recién comienzo a escribir código de 6502 pero ya a esa altura es poco lo que se debe experimentar, lo escribo casi directamente. Si algo falla, no es por la lógica, es error de programación simplemente (o de assembler como ya me pasó)

No me he dado el tiempo para buscar los fuentes originales ni para mirar el tópico en AtariAge, pero por lo que comentas, más que un port, éste sería un remake.

Para mi es un port. Estoy haciendo lo mismo que hizo la gente que trabajó en los ports de PC, Amiga, etc.
Sería un remake si ya existiese una versión para Atari

Supongo que en los fuentes están los bitmaps necesarios para los sprites y para las pantallas.

Así es, están todos los bitmaps necesarios, pero no son llegar y usar ya que están diseñados para Apple, 7 bits por byte, 1 o 2 bits por color, 6 colores, 140 bytes de ancho cada scan

Esos gráficos los estoy usando solo como referencia, para saber que significa cada valor, por ejemplo 1 = piso izquierdo, 2 = piso derecho, etc.

Hasta ahora lo que he hecho ha sido tomar el screenshot que puse arriba como base, luego a medida que voy necesitando gráficos los tomo desde la versión PC que tienen un aspect ratio similar al del atari (320x200), los divido por dos horizontalmente (160x200) y luego voy pintando con los 4 colores disponibles.

Para los sprites, hay una persona dedicada al tema (José Pereira, PT). Él esta tomando los gráficos de la versión de Mac como base, y los de la versión de PC como referencia de tamaños.

¿Entendí que usarías player/missiles?

Sí, se usarán sólo para obtener colores adicionales en el personaje, los enemigos, las llamas y las pociones.

¿Cuántos elementos animados (sprites)es necesario presentar simultáneamente en una pantalla?

Sprites como tales son dos como máximo: kid + enemy en jerga PoP.
Hay otros elementos animados como pisos que tambalean, pisos que caen, puertas que se abren, etc.

Imagino que para puesrtas y trampas animarás elementos del background

Sí, todo eso es de background. El background tiene dos partes que yo le llama "back" y "front". Por ejemplo las cuchllas, las "puntas" (spikes) y otros, tienen una parte de fondo y una parte de frente respecto a la capa de los personajes animados (kid+enemies)

¿ANTIC 4?

No, Antic $0E. Este juego es "imposible" de hacer en base a redefinición de caracteres por su enfoque isométrico. Son demasiadas combinaciones posibles.

[fcatrin]

Continúo con este relato...

Según mi plan, lo primero a realizar era el render del background y mi ambiente de emulación para ir haciendo pruebas.
Mi ambiente de emulación es básicamente una aplicación en Java que levanta una ventana en donde tengo un canvas con las mismas características de video del atari: 160x200 a 4 colores con pixeles en proporción 2x1.

Inicialmente usé un bitmap de 2bpp igual que el Atari, pensaba hacer código escribiendo los pixeles igual que en el atari, esto es, armando "bytes", pero al final decidí hacer un simple "setPixel(x,y,color)" y usar ese. Esto es porque es posible que más adelante quiera emular los player/missile y ahi tendría que reescribir todo el código si éste operara directo con los bytes.

Una vez con eso listo, necesitaba probarlo. Lo natural fue tomar los gráficos del PoP original de AppleII por dos motivos principales: a) El formato del archivo estaba bien documentado, b) En aspecto se parecían a lo que puede hacer el Atari.

WRONG!!

Como he adelantado, la forma en que funcionan los gráficos en el Apple son muy poco programmer-friendly. Tanto así que después de leer varios artículos y viendo el código del emulador... aun no entendía como funcionaba.

Pueden pensar que exagero, pues aquí está el código del emulador JS de ese modo de video para AppleII

Spoiler: MOSTRAR

AppleII video emulator

Si bien el código está minimizado, con los nombres de variable legibles, la matemática es la misma.

Y aquí viene una anécdota. Logré entender cómo funcionaba a groso modo, pero aun me quedaban algunas dudas por lo que puse la consulta en AtariAge. Me respondió una persona que me explicó cómo funcionaba... en sólo 3 párrafos. Pensé "oh el loco seco", y luego vi que era... de Viña del Mar. Quién podrá ser? Alguien seco en Atari/Apple y de Viña? No puede ser otro que Daniel Serpell, y claro, era él.

http://atariage.com/forums/topic/152500 ... ?p=3215117

Luego me puse a mirar sus posts y vi que estaba participando en un concurso de programación para Atari, el desafío era hacer un juego en solo 10 lineas de código, y el hizo un juego de autos. Y no.. no es un juego de 1 carácter que se mueve como un auto, es un juego con perspectiva Pole Position.

http://atariage.com/forums/topic/234337 ... ?p=3213670

Está de más decir que ganó el concurso!

Volviendo a PoP, con su ayuda pude comenzar a pintar los gráficos del AppleII en Atari, y éste fue el primer resultado

pop_apple2_colors.png (118.71 KiB) Visto 3762 veces

Comprobado el render, lo siguiente fue examinar todos los gráficos del background Dungeon, para familiarizarme con su diseño. Luego vino la duda si me serviría usar esos gráficos o no, finalmente decidí no usarlos porque la proporción es diferente y después surgirían otros problemas para hacerlo calzar con el Atari.

Una forma rápida de avanzar entonces era tomar como base los gráficos que publicaron en el mockup, convertirlos a un tamaño y diseño similar al de AppleII, mapearlos a sus respectivos IDs, escribir la rutina de render de PoP en mi entorno de emulación y correrla contra esos gráficos. Fue así como obtuve el primer render usando la lógica de PoP y los gráficos de Atari.

Esta fue la primera aproximación con algunos elementos gráficos mapeados.

En el proximo post explicaré a mayor nivel de detalle cómo funciona este render.

[vitoco]

Normalmente uso variables cortas (de una letra) en programas desechables, los que tienen un fin específico y cuyo código nunca más volveré a mirar, pero lo que vi en tu rutina en java me dejó perplejo, como el siguiente extracto:

Código: Seleccionar todo

M = o ? k ? v : G || J ? C : q ? N : p : k ? e : q && J && G ? G ? ...........

¡¡¡Eso es demasiado branch en assembler!!!

Si fueran variables con nombre descriptivo, probablemente todo eso tendría sentido para mí... ¿Algún diccionario de datos a mano?

Fui a mirar en AtariAge y veo que estás bastante avanzado... así que mejor no meto más la cuchara y espero resultados... y más capítulos de esta sabrosa historia.

[fcatrin]

Ojo que ese código JavaScript del emulador de Apple II no es mío, solo lo puse como referencia de lo que estaba leyendo para tratar de entender cómo trabajaba el video.

Esa es la version "minimizada", con una herramienta automática toman e código original y lo reducen al mínimo. Nadie en su sano juicio trabajaría con código así.. a menos que sea por motivos de fuerza mayor (http://www.fulcrum-demo.org/2015/8k-reality/)

Aquí encontré el código en formato "legible"

Spoiler: MOSTRAR

[vitoco]

Ya ha pasado un mes sin saber si hay avances en este proyecto. ¿Alguna posibilidad de ver algo en vivo en la junta express?