Mojonia 3.0

Bienvenidos a Mojonia!
http://www.mojontwins.com/mojoniaplus/

Proyecto Churrero: AVORCHA - Pentacorn Quest 128K- RELEASED!

http://www.mojontwins.com/mojoniaplus/viewtopic.php?f=16&t=1544

Página 30 de 37

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 11:54
por angel
Joooooderrrrrrr! me encanta! :picha: :picha: :picha:

Jejeje, tiene un aroma toriyama que me encanta! :adore:

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 13:02
por Jarlaxe
$this->bbcode_second_pass_quote('angel', 'J')oooooderrrrrrr! me encanta! :picha: :picha: :picha:

Jejeje, tiene un aroma toriyama que me encanta! :adore:


Gracias Ángel!

Viniendo de ti y sabiendo como te las gastas tú también con los gráficos, es todo un cumplido!!

Sí, tiene Toriyama por todos los costados. Y es que yo soy "fan number one" de Dragon Ball, Profesor Slump y derivados. :picha: :picha:

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 13:02
por na_th_an
Vaya chulada la pantalla de carga :D

$this->bbcode_second_pass_quote('Nightwolf', 'O')tra pregunta :)

Si convierto el único mapa a compressed (como sea que pueda hacerse XD) ¿Ganaría memoria? ¿O únicamente lo que haría sería facilitar su reemplazo?

EDIT: Más o menos he seguido los pasos, pero casca cuando le doy a empezar el mapa. De todas formas, la rom ocupa más espacio :S


La compresión es cosa de A.Villena y me temo que ahí no te puedo ayudar, no sé muy bien cómo funciona. Lo que sí te puedo decir es que dudo que puedas usar mapas de tipos mezclados.

Lo que hemos hecho siempre para juegos de 128K es comprimir los mapas con aplib como si fuesen imagenes y meterlos en la RAM extra. En la RAM de 48K tenemos espacio para un mapa sólo, y descomprimimos el que necesitemos. Por ejemplo, Ninjajar sólo tiene espacio en la RAM básica para 21 pantallas. Ningún mapa del juego tiene más de 21 pantallas. En config.h se define MAP_W y MAP_H para que haya espacio suficiente. Luego en tu gestor de niveles defines el array "mapa" con espacio "vacío" suficiente. Es como hacer un juego con un mapa todo a 0, y sustituir ese mapa por otro comprimido exactamente igual que sustituyes los gráficos ahora mismo.

De ese modo, el motor que está en RAM baja es el de toda la vida (sencillo y rápido, sin buffers ni nada), pero podemos tener todos los mapas que queramos.

La Churrera, lamentablemente, no tiene en el script el "WARP_TO_LEVEL" que tiene MK2, que te permite saltar a cualquier nivel de forma arbitraria - con eso puedes hacer juegos de mundo abierto si te da la gana con cientos de pantallas. Pero si tu juego es lineal (como Goku Mal) no tienes más que partir el mapa en trozos más pequeños, comprimirlos, e irlos requiriendo cuando te hagan falta. Creo recordar que el script de la Churrera tenía un IF LEVEL para saber qué nivel está ejecutándose.

También, en ausencia de WARP_TO_LEVEL, puedes hacerlo a mano como EXTERN.

El problema de esto es que el script crecerá y crecerá, y tenerlo en RAM baja es un problema. Fue una de las cosas que nos hizo desechar la Churrera cuando hicimos Ninjajar. Necesitábamos un motor con soporte nativo a scripts en RAM extra y, sobre todo, poder definir un "sub-script" separado para cada nivel.

$this->bbcode_second_pass_quote('', 'E')dit: Otra consulta. Los tiles tipo 1, que matan, son medio traspasables (insistiendo los atraviesas) ¿Es posible hacerlos sólidos?

Creo que activando FULL_BOUNCE se soluciona el problema que dices, aunque, en rigor, siguen sin ser sólidos. Hacerlos sólidos necesitaría modificar las rutinas de detección de colisiones. En MK2 es muy sencillo, habría que cambiar 4 lineas de código, pero en la Churrera no sé decirte, supongo que será más o menos igual. Luego lo miro, que no me acuerdo.

$this->bbcode_second_pass_quote('', 'E')dit 2: Más consultas! :P ¿Cómo puedo cambiar la configuración de las teclas para que sean los cursores? Para la tecla de abortar, funciona, pero no para las teclas de control del personaje (vamos, las que están en la estructura keys, keys.up, keys.fire, etc...)

Los cursores no existen como tal en un Spectrum. Bueno, sí, pero corresponden con las teclas 5, 6, 7 y 8 (el Spectrum original sólo tiene 40 teclas: 10 números, 26 letras, y 4 de control (SHIFT SYMB SPACE ENTER)... los Spectrum posteriores tienen más teclas, pero internamente lo que hacen es simular combinaciones de las 40 originales). 5 izquierda, 6 abajo, 7 arriba y 8 derecha. Si en el emulador se configura para que los cursores de PC emulen los cursores del spectrum, te funcionará con esto... Pero en la mayoría de los emuladores se pueden configurar para que emulen kempston o sinclair, por ponerte un ejemplo, así que tampoco te puedes fiar al 100%. Y en un Spectrum real de gomas, jugar con 5, 6, 7 y 8 puede ser un coñazo de la leche. Por eso preferimos usar WSAD en nuestros juegos.

Sólo tienes que sustituir los lookup_key que hay en el código del menú por las que quieras.

$this->bbcode_second_pass_quote('', 'E')dit 3: El texto de extern es que ocupa un cohón de memoria! XDD ¿Se podría hacer algún apaño?
Sí. Ponerlo en RAM extra. Tienes que pillarte algo que te empaquete los textos y te los meta en un binario con un índice. Luego en tu extern.h te creas un buffer igual de grande que el más largo de los textos. Cada vez que se solicite un texto, se debe paginar la RAM donde estén los textos, buscar donde empieza, copiarlo al buffer, volver a paginar 0, y luego pintar el texto del buffer.

Puedes pillar el extern.h de Ninjajar! y adaptarlo. Los textos, además, van empaquetados usando 5 bits por caracter con escapes, por lo que ocupan menos. En el paquete de Ninjajar! está el compresor (textstuffer.exe) que pilla text.txt y genera texts.bin listo para colocar donde quieras. Si te animas lo vemos más despacio.

$this->bbcode_second_pass_quote('', 'E')dit 4: Otro problemilla que he visto, al hacer un warp, durante un momento, se quedan un momento de los enemigos de la pantalla anterior y la situación donde estaba el personaje para antes del warp. ¿Se podría poner un comando antes para limpiar mejor los caracteres al hacer el warp?

Sinceramente, no recuerdo como estaba implementado esto en la Churrera. Sé que nos dimos cuenta del problema en Ninjajar! y lo corregimos en MK2 ... Mucho me temo que habría que ponerse a buscarlo y corregirlo - y creo que tiene que ver con cómo se implementan las llamadas al intérprete de scripts, y que el cambio no era moco de pavo.

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 15:06
por Nightwolf
Muchas gracias Na_th_an por las explicaciones :)

Sobre el warp, supongo que haciendo una limpieza antes de pantalla quizás resulte en el script de warp. Tengo que probarlo :) El mapa es más grande que 21 pantallas así que descartado lo de comprimirlo, ocupa demasiado por lo que he estado probando.

Y la compresión de textos tendré que mirar el goku a ver si puedo aclararme, pues ayudaría a librerar memoria, aunque ya a estas alturas, es más bien por si acaso :P

Otra cosa. Haciendo pruebas, he añadido más de una imagen para el ending (antes era una sola, ahora son 3 en la prueba). Entonces, en la library.h me sale algo tal que así:

{3, 49152}, // 0: title.bin
{3, 51551}, // 1: marco.bin
{3, 51551}, // 2: ending1.bin
{3, 58052}, // 3: ending2.bin
{4, 49152}, // 4: ending3.bin
{4, 51788}, // 5: intro1.bin
{4, 57399}, // 6: p_prota1.bin
{4, 57682}, // 7: p_prota2.bin
{4, 57965}, // 8: enems1.bin
{4, 59117}, // 9: enems2.bin
{4, 60269} // 10: enems3.bin

Por lo que he visto, el primer valor, el 3, debe ser algo relacionado con la ram ¿es así? Bueno, ahora intro1.bin y ending3.bin pasan a ser 4. Y veo que no funciona llamarlos a:

get_resource (5, 16384); por ejemplo, para mostrar la pantalla de intro. (Se queda cuajado)

Veo que ahora se genera un ram4.bin, pero si lo agrego al make.bat, el juego cruje sin llegar siquiera a la pantalla de carga. Si no lo agrego no pasa nada. Aquí hay algo que no veo :___( Porque puedo hacer llamadas con el get_resource a todo aquello que no esté en 3 sin problemas (y a los enemigos en 4, pero no ending ni intro) ¿Qué podría estar haciendo mal?

EDIT: He estado revisando los valores de

// Para 128K descomenta la 24099 y comenta la otra
#pragma output STACKPTR=24099
//#pragma output STACKPTR=61952
#define AD_FREE 60655

En Goku, está puesto:

// Para 128K descomenta la 24299 y comenta la otra
#pragma output STACKPTR=24299
//#pragma output STACKPTR=61952
//#define AD_FREE 60655
// Y este cambio ha sido necesario para tener un disparo más.

Pero tampoco funciona con 24299.

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 15:37
por alxinho
$this->bbcode_second_pass_quote('Jarlaxe', 'V')amos que nos vamos!!!

Que ahora ya si que está a punto de caramelo... 8-)


No veas qué calidad nenes! :o :wan:

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 15:51
por Nightwolf
Si es que el Jarlaxe es genial. Además, ¡nunca pensé que tendría de invitado especial al explorador del Pang! :D ¡Le queda de muerte!

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 15:58
por Davidian
$this->bbcode_second_pass_quote('Jarlaxe', 'V')amos que nos vamos!!!

Que ahora ya si que está a punto de caramelo... 8-)

Image


Jojojo. ¡Menudo crack!

Eso sí, no esperaba menos viniendo de quien viene :gay:

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 16:02
por na_th_an
$this->bbcode_second_pass_quote('Nightwolf', 'M')uchas gracias Na_th_an por las explicaciones :)

Sobre el warp, supongo que haciendo una limpieza antes de pantalla quizás resulte en el script de warp. Tengo que probarlo :) El mapa es más grande que 21 pantallas así que descartado lo de comprimirlo, ocupa demasiado por lo que he estado probando.


21 Son las que lleva Ninjajar. En Goku Mal son 25, creo. Depende de lo que necesites. Tampoco es algo que hacer a un juego ya empezado. Es para planteárselo. Partir un juego en niveles más cortos da buenos resultados. También puedes hacer un único nivel partido en trozos de X pantallas e ir cambiando mapa/enemigos/hotspots dependiendo de donde estemos, dejando espacio vacío en RAM baja y llenándolo con niveles comprimidos en RAM extra. Al igual que ahora cambias los gráficos, sería cambiarlo todo. Detectas que vas a salir del mapa (por ejemplo, tocando tal tile del extremo de la pantalla cual) y ejecutas un extern que cambie todos los datos y mueva al personaje al sitio adecuado.

Pero ya te digo que no es algo que plantearse con el juego ya montado. Implica un rediseño. Y para eso, mejor pasar de la Churrera y hacerlo con MK2, que está más preparado.

$this->bbcode_second_pass_quote('Nightwolf', 'Y') la compresión de textos tendré que mirar el goku a ver si puedo aclararme, pues ayudaría a librerar memoria, aunque ya a estas alturas, es más bien por si acaso :P


La compresión está en Ninjajar! y en Leovigildo (es algo de MK2, Goku Mal es aún Churrera). No es complicado, una vez que tienes montado el sistema. Para añadir un texto añades una linea a texts.txt. Tal y como tengo montado mi función extern, "EXTERN N" mostrará la linea que ocupa la posición N en texts.txt, pero tú puedes apañártelo como mejor te venga.

$this->bbcode_second_pass_quote('Nightwolf', 'O')tra cosa. Haciendo pruebas, he añadido más de una imagen para el ending (antes era una sola, ahora son 3 en la prueba). Entonces, en la library.h me sale algo tal que así:

{3, 49152}, // 0: title.bin
{3, 51551}, // 1: marco.bin
{3, 51551}, // 2: ending1.bin
{3, 58052}, // 3: ending2.bin
{4, 49152}, // 4: ending3.bin
{4, 51788}, // 5: intro1.bin
{4, 57399}, // 6: p_prota1.bin
{4, 57682}, // 7: p_prota2.bin
{4, 57965}, // 8: enems1.bin
{4, 59117}, // 9: enems2.bin
{4, 60269} // 10: enems3.bin

Por lo que he visto, el primer valor, el 3, debe ser algo relacionado con la ram ¿es así? Bueno, ahora intro1.bin y ending3.bin pasan a ser 4. Y veo que no funciona llamarlos a:

get_resource (5, 16384); por ejemplo, para mostrar la pantalla de intro. (Se queda cuajado)

Veo que ahora se genera un ram4.bin, pero si lo agrego al make.bat, el juego cruje sin llegar siquiera a la pantalla de carga. Si no lo agrego no pasa nada. Aquí hay algo que no veo :___( Porque puedo hacer llamadas con el get_resource a todo aquello que no esté en 3 sin problemas (y a los enemigos en 4, pero no ending ni intro) ¿Qué podría estar haciendo mal?

El primer número es la página de RAM. Librarian va metiendo cosas en los binarios pero cuando no tiene más sitio empieza otra página. Te has pasado de lo que cabe en 16K y ha pasado de RAM3 a RAM4 (por cierto, si reordenas las cosas en list.txt, puedes aprovechar mejor el espacio, si te ves apurado como nos pasó en Ninjajar!). Esto implica que hay que hacer cambios en varios sitios:

- Tu script make.bat que te crea la cinta con el juego debe incluir ahora instrucciones para meter ram4.bin también. Basta con duplicar lo que tengas para ram1 y ram3 (si tienes dudas pon tu make.bat y te ayudo).
- Hay que modificar loader.bas para que cargue el bloque nuevo y lo ponga en su sitio. Lo mismo: es repetir el código que haya para RAM3. Pon aquí tu loader.bas si no te aclaras.

Si todo esto lo tienes bien hecho habrá que mirar más despacio qué pasa.

$this->bbcode_second_pass_quote('Nightwolf', 'E')DIT: He estado revisando los valores de

// Para 128K descomenta la 24099 y comenta la otra
#pragma output STACKPTR=24099
//#pragma output STACKPTR=61952
#define AD_FREE 60655

En Goku, está puesto:

// Para 128K descomenta la 24299 y comenta la otra
#pragma output STACKPTR=24299
//#pragma output STACKPTR=61952
//#define AD_FREE 60655
// Y este cambio ha sido necesario para tener un disparo más.

Pero tampoco funciona con 24299.

Ahí hay dos cosas que puedes toquetear para optimizar mejor.

1.- La pila (el pragma STACKPTR). Esto hay que colocarlo en un sitio que esté libre y que esté disponible siempre. Por eso en 48K se coloca en 61952 y en 128K hay que ponerlo en otro sitio, porque 61952 cae en la zona de la RAM que se cambia al paginar y que de repente desaparezca la pila a la CPU no le mola NADA :lol: (recuerda que la CPU no entiende de páginas de RAM, ella siempre ve 48K de RAM seguida). Lo mejor es colocarla justo por debajo del binario, o donde haya sitio. Si tienes Churrera supongo que compilas en 24200 así que habría que ponerla de ahí para abajo, o sea, en 24199 (crece hacia abajo).

2.- Espacio para que splib2 cree las estructuras de los sprites (AD_FREE). Esta es una dirección de memoria donde splib2 creará los tiestos que necesita para mover los sprites. Esto se puede optimizar un montón, y de hecho así lo tenemos en MK2:

$this->bbcode_second_pass_code('', '// Define where to store and how many sprite descriptors are needed.
#define NUMBLOCKS 50
#define AD_FREE 61440 - NUMBLOCKS * 14')

Así hacemos sitio JUSTO para lo que necesitamos. En 61440 empiezan las estructuras de splib2. Nosotros vamos a reservar espacio para NUMBLOCKS bloques. Cada bloque ocupa 14 bytes, de ahí la multiplicación.

Ahora tienes que ajustar el número de NUMBLOCKS - y esto depende de tu juego. Dependiendo de cuántos sprites haya definidos para coexistir en pantalla a la vez, habrá que reservar más o menos memoria.

Si te fijas, un sprite de 16x16 ocupa en realidad 9 celdas de caracter. Si te metes en sprites.h lo verás: hay tres columnas de 24 filas, o sea, 3x3 caracteres. Cuando un sprite no está alineado a coordenadas de caracter, en efecto, ocupa 3x3 caracteres (imagínatelo, o píntalo en una hoja de cuadritos para verlo).

Un sprite necesita tantos bloques como caracteres ocupa, más uno. O sea, un sprite de 16x16 necesitaría 9+1 bloques. Si tienes 4 sprites a la vez en pantalla, y nada más, necesitarías 10 bloques por sprite, o sea, 4*10 = 40 bloques. Por tanto definirías NUMBLOCKS como 40, y así tu programa podría ocupar desde 24200 hasta 61440-40*14 = 60880, o sea, 36680 bytes en total.

Si, por ejemplo, tienes puesto que el personaje dispare, y que dispare dos balas como máximo, entonces necesitas más bloques. A los 40 que necesitan el prota y los enemigos hay que sumarle los que pillen las balas. Las balas son sprites de 8x8, que pueden ocupar 2x2 caracteres en pantalla si no están alineadas, por lo que necesitarán 4+1=5 bloques cada una. Al tener dos balas, hacen 10 bloques entre las dos, y a sumar con lo que ya tenías, te sale que necesitas 50 bloques. En este caso, tu programa podría ocupar desde 24200 hasta 61440-50*14 = 60740, o sea, 36540 en total.

En la Churrera se reservaba espacio suficiente para el peor de los casos. Si sólo usas el prota y los tres enemigos, y no tienes disparos, puedes ganar algo de espacio ajustando bien el valor de AD_FREE cambiando la definición que tienes en tu código por la de MK2.

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 16:05
por na_th_an
Otra cosa que puedes hacer para ganar 150 bytes es mover map_buff a un hueco que deja por ahí arriba splib2 :lol: Si necesitas esos 150 bytes te explico qué tocar.

Re: Proyecto Churrero: AVORCHA - Pentacorn Quest

Publicado: Lun, 09 Feb 2015, 16:21
por Nightwolf
Guay, sí... ¡cuanto más memoria libre mejor, más cositas para retocar! :)

Este es el make poniendo lo de ram4. Mmm tras leer lo que dices, entonces hay que toquetear el loader.bas (este sí que no lo veo muy claro, sí pediría ayuda para ver cómo duplicar qué valor)

$this->bbcode_second_pass_code('', '@echo off
C:\dev2\try\utils\sprcnv.exe C:\dev2\try\gfx\sprites.png ..\dev\sprites.h

echo ### COMPILANDO SCRIPT ###
cd ..\script
..\utils\msc_arkos.exe dogmole.spt msc.h 32
copy *.h ..\dev
cd ..\dev

cd ..\map
..\utils\mapcnv mapa.map 8 4 15 10 15 packed
copy mapa.h ..\dev
cd ..\dev

echo -------------------------------------------------------------------------------
echo ### GENERANDO BINARIOS ###
echo * Building reubica
..\utils\pasmo reubica.asm reubica.bin
echo * Building RAM3 AND RAM4 AND RAM6
cd ..\bin
librarian.exe
copy RAM3.bin ..\dev\ram3.bin
copy RAM4.bin ..\dev\ram4.bin
copy librarian.h ..\dev
echo -------------------------------------------------------------------------------
echo ### COMPILANDO ARKOS PLAYER ###
cd ..\mus_arkos
..\utils\pasmo musicas.asm ram1.bin musicas.lst
copy ram1.bin ..\dev
cd ..\dev
echo -------------------------------------------------------------------------------
echo ### COMPILANDO GUEGO ###
zcc +zx -vn dogmole.c -o dogmole.bin -lsplib2 -zorg=24200
echo -------------------------------------------------------------------------------
echo ### CONSTRUYENDO CINTA ###
..\utils\bas2tap -a10 -sLOADER loader.bas loader.tap
..\utils\bin2tap -o reubica.tap -a 25000 reubica.bin
..\utils\bin2tap -o ram1.tap -a 32768 ram1.bin
..\utils\bin2tap -o ram3.tap -a 32768 ram3.bin
..\utils\bin2tap -o ram4.tap -a 32768 ram4.bin
..\utils\bin2tap -o screen.tap -a 16384 loading.bin
..\utils\bin2tap -o main.tap -a 24200 dogmole.bin
copy /b loader.tap + screen.tap + reubica.tap + ram1.tap + ram3.tap + ram4.tap + main.tap dogmole.tap
rem copy /b loader.tap + screen.tap + reubica.tap + ram1.tap + ram3.tap + ram4.tap + main.tap dogmole.tap
echo -------------------------------------------------------------------------------
echo ### LIMPIANDO ###
del loader.tap
del screen.tap
del main.tap
del reubica.tap
del ram1.bin
del ram3.bin
del ram4.bin
del ram1.tap
del ram3.tap
del ram4.tap
del dogmole.bin
del zcc_opt.def
echo -------------------------------------------------------------------------------
echo ### DONE ###')
Todos los horarios son UTC+02:00
Página 30 de 37
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/