8BP Programado juegos profesionales desde Basic

[jjaranda13]

hola amigos

hace tiempo que no entraba en el foro, perdonad mi ausencia (las vacas, el verano, yo que se)

he visto que algunos teneis dudas con la sustitucion de comandos por el correspondiente CALL
Pues bien, esto es un tema delicado, sencillo pero delicado.
Por ejemplo frogger fue programado con 8BP v36. Eso significa que si reemplazamos un comando por un call debemos hacerlo por el call correcto, el que se corresponde con el comando en la V36.
En la version actual (la V41) los CALL son diferentes a los call de V36, por ejemplo

en v36 PRINTSP era CALL .... ya no lo se, tendria que re-ensamblar el v36 para saberlo
en V41 PRINTSP es CALL 0x6C8e

en conclusion: el manual de 8BP siempre esta actualizado con la version actual de 8BP, y desde que existe el wrapper de C ademas teneis el fichero 8bp.h que precisamente contiene al final ese "mapeo" de comandos a direcciones CALL.

en versiones mas antiguas de 8BP, las direcciones de memoria de cada comando eran diferentes y es necesario re-ensamblar 8BP para conocer dichas direcciones. Es sencillo, desde winape hacemos run del fichero make_all.asm y despues en la pestaña "symbols" de winape podemos consultar la direccion en la que ha quedado ensamblado cada comando.

Y eso es todo. El problema o la confusion surge cuando usamos la documentacion de la version actual de 8BP (o de otra) y un ejemplo o juego creado en una version mas antigua.

[jjaranda13]

Aun siendo por falta de memoria continua el misterio de por qué funciona con un comando 8BP y no con su equivalente CALL. Alguna diferencia tiene que haber.

hola ivan. He posteado una respuesta a este tema recientemente. Espero que sea clara. Pero si no he logrado aclararlo, hazmelo saber y ayudaré mas

[jjaranda13]

Pues no sé, esto sigue dando error.




A ver si JJAranda ve esto, quizá sea un bug de la librería.
Igualmente lo reporté en github.

hola shao

he puesto una explicacion del problema que comentais. Basicamente creo que estais tratando de reemplazar comandos de un juego creado con la v36 con direcciones CALL de la V41

[shao]

Hola Aranda, pues gracias por la información, yo pensaba que era algún bug pero ya queda claro que no.

[jjaranda13]

Hola Aranda, pues gracias por la información, yo pensaba que era algún bug pero ya queda claro que no.

gracias a ti

me alegro de haberlo aclarado. De verdad siento haber tardado tanto en contestar. Normalmente miro esto con mas frecuencia.
Ademas, es una duda muy interesante. Voy a meter un parrafo o algo en el manual explicando este asunto , seguro que a mas de uno le resulta util

[Ivan]

Pues a ninguno de nosotros se nos había ocurrido que fuera un problema de incompatibilidad de versiones

[shao]

Paco el hombre (ejecutado en el modo 1, ya que tiene 4 modos) no gana prácticamente nada de velocidad aunque las llamadas a 8bp se reemplacen por CALL y todo el código se optimice, sus fps continuan en 13~14, ¿es esto posible?.

Aunque veo que el código original ya usa CALL para casi todo pero siguen existiendo llamadas a 8bp.

Por otra parte en el modo 3 no se puede manejar ya que en cuanto aparece y pulsas una tecla se le elimina una vida sin ninguna razón.

[jjaranda13]

Paco el hombre (ejecutado en el modo 1, ya que tiene 4 modos) no gana prácticamente nada de velocidad aunque las llamadas a 8bp se reemplacen por CALL y todo el código se optimice, sus fps continuan en 13~14, ¿es esto posible?.

Aunque veo que el código original ya usa CALL para casi todo pero siguen existiendo llamadas a 8bp.

Por otra parte en el modo 3 no se puede manejar ya que en cuanto aparece y pulsas una tecla se le elimina una vida sin ninguna razón.

hola shao
en efecto, reemplazar comandos 8BP por sus correspondientes CALL ahorra tiempo y aumenta la velocidad pero hay que tener en cuenta cuantas veces se ejecuta el comando que estas reemplazando. Por ejemplo un tipico comando PRINTSPALL que se ejecuta en cada ciclo de juego tiene sentido reemplazarlo por CALL y la velocidad se incrementará un poco pero si hablamos de un comando que se ejecuta cana varios ciclos o en circunstancias especiales (por ejemplo cuando paco gira en una bifurcación del laberinto) no va a aumentar apenas la velocidad. Por hacer numeros, imagina un comando que se ejecuta cada ciclo y con el CALL ahorras 1 milisegundo y comparalo con un comando que se ejecuta de vez en cuando (por ejemplo cada 64 ciclos) . En 64 ciclos el primer CALL habria ahorrado 64 milisegundos mientras que el segundo solo habria ahorrado 1 milisegundo. Es decir, sustituir comandos por CALL que no se ejecutan todos o casi todos los ciclos, apenas tiene impacto.

respecto de tu segunda duda (lo del nivel 3) no se por que te puede estar pasando eso. A mi no me ocurre y tambien he visto gente jugando (y que han grabado su partida en youtube) que tampoco les pasa. Te sugiero que descargues el juego (el archivo .dsk) de nuevo porque es la primera vez que alguien me comenta ese error y lo mismo tienes una version antigua de paco o algo asi. Recuerdo que corregí un bug en paco a los pocos dias de subir el juego pero no tenia ese efecto. Dime si al hacer eso te sigue ocurriendo y si el error persiste, intentaré reproducirlo. Lo he probado en winape y en caprice32 sin problemas

[shao]

Ok, entiendo, he bajado la última versión de 8bp, yo tenía la anterior pero, aún así, sigue produciéndose el error.

Lo que hago es lo siguiente:
- Compilo el "make_all_mygame" de Paco el hombre de la carpeta "Demo Games" en winape.
https://github.com/jjaranda13/8BP/tree/ ... RE_V41/ASM

- Copio y pego el código Basic de "cocos_046.bas" en winape.
https://github.com/jjaranda13/8BP/tree/ ... _V41/BASIC

- Ejecuto y selecciono el modo 3.

Y lo hago así porque de ese modo puedo editar y ejecutar el código desde notepad++.

[jjaranda13]

Ok, entiendo, he bajado la última versión de 8bp, yo tenía la anterior pero, aún así, sigue produciéndose el error.

Lo que hago es lo siguiente:
- Compilo el "make_all_mygame" de Paco el hombre de la carpeta "Demo Games" en winape.
https://github.com/jjaranda13/8BP/tree/ ... RE_V41/ASM

- Copio y pego el código Basic de "cocos_046.bas" en winape.
https://github.com/jjaranda13/8BP/tree/ ... _V41/BASIC

- Ejecuto y selecciono el modo 3.

Y lo hago así porque de ese modo puedo editar y ejecutar el código desde notepad++.

hola Shao
ya se lo que te pasa. Eres un usuario muy avanzado y por eso has encontrado ese "problema". En realidad no hay ningun bug. Lo que te esta pasando es debido a que paco es un juego que contiene codigo C compilado. Ahora entenderas la problematica:

Al ensamblar desde winape estas llenando la memoria con la libreria de 8bp, graficos y musica pero TE FALTA el binario correspondiente a las funciones C compiladas que se usan en los niveles 3 y 4. Ese binario no se puede generar desde winape, porque es un binario fruto de la compilacion del fichero ciclo.c.
El fichero 8bp.bin que puedes encontrar en el .dsk ya trae ese binario incluido, de modo que el fichero 8bp.bin es la suma de lo que produce winape + el ciclo.bin que produce compila,bat. Por ese motivo no te funciona el nivel 3 ni el 4

En cuanto al nivel 2, tampoco puede funcionar porque Paco el hombre usa una tecnica de logicas masivas avanzada, en la que hice un "precalculo" de las decisiones de los fantasmas y lo almacené en un array en memoria, el cual lo salvé a binario directamente (no hay un fichero asm con todos esos datos). Es decir, el fichero 8bp.bin que se encuentra en el dsk contiene:

8bp.bin = lo que produce make_all + lo que produce compila.bat + los precalculos para que funcionen los niveles 2 y 4

Por ultimo, una cosilla sin importancia: he comprobado que el fichero basic cocos_046 es ligeramente distinto al que viene en el dsk. Realmente solo tiene una instruccion PRINT extra, pero he corregido esto en github y he subido un fichero llamado cocos_047.bas que no tiene esa diferencia.

La solucion general para estos casos es cargar el 8BP.bin desde el dsk y con eso ya tienes todo en memoria sin necesidad de ensamblar. Si quieres modificar graficos o cualquier cosa, puedes ejecutar despues make_all.asm pues las partes extra (el c compilado y los precalculos) ya se encuentran en memoria y make_all.asm no va a machacarlos

[shao]

Ok, creo que entiendo, simplemente el código en C no se estaba llevando a la memoria y cuando se intenta leer esa parte sucede ese comportamiento de perder una vida, quizá experimente un poco más tarde.
Como siempre, gracias por la información.

[shao]

¿Alguien aquí usa Aseprite?.
Tengo el plugin para exportar para 8BP listo, falta testearlo.

Este es el output para una animación de dos frames.
Se puede obtener también la paleta, como se muestra al final.

[shao]

Ok, el plugin está publicado aunque veo que aquí no hay usuarios de Aseprite.
Te aseguro que si pasas a usar una tableta + aseprite, no querrás volver atrás.

+

viewtopic.php?t=6244

[XeNoMoRPH]

Nueva versión !!!

http://8bitsdepoder.blogspot.com/2023/0 ... de-la.html

[jjaranda13]

Nueva versión !!!

http://8bitsdepoder.blogspot.com/2023/0 ... de-la.html

gracias xeno!
retomo mi actividad en este foro , que hace tiempo que no me conecto
cualquier duda sobre la nueva version, aqui me teneis!