Mojonia 3.0

Bienvenidos a Mojonia!
https://www.mojontwins.com:80/mojoniaplus/

Proyecto juego Churrera. Dudas

https://www.mojontwins.com:80/mojoniaplus/viewtopic.php?f=16&t=1508

Página 3 de 4

Re: Proyecto juego Churrera. Dudas

Publicado: Mar, 04 Feb 2014, 13:09
por elborra
Continuando por aquí he vuelto al tema del uso de tilesets, algo que ya había resuelto con anterioridad (gracias a nathan) pero que el desarrollo del juego a "sufrido" unos cambios y ahora no se que es mejor o peor; e independientemente me gustaría saber un poco el funcionamiento (o el trato) de los tiles en la churrera.

Me explico, nathan propuso que en lugar del proceso por defecto con los tiles: "crear, reordenar, juntar con la fuente y exportar a tileset.h", los exportara a .bin y comprimiera con appack, para luego descomprimir cuando hiciera falta, etc, etc, así mediante un extern podia cambiar de tilesets rápidamente...

Bien mi duda es, en el método tradicional, ¿qué pasa con tileset.h después de compilar?, quizás esto sea una pregunta demasiado vaga y extensa de contestar... A mi principalmente lo que me interesa es el espacio final que ocupa un tileset, o mejor dicho, habría alguna diferencia de tamaños respecto a comprimir el tileset, o a fin de cuentas algo parecido ocurre en la trastienda para el método tradicional?

Re: Proyecto juego Churrera. Dudas

Publicado: Mar, 04 Feb 2014, 13:17
por na_th_an
Ningún dato se puede usar si está comprimido, por tanto hay que hacer sitio para descomprimirlo. Por lo general, el tileset.h están los caracteres que se utilizan en el juego y sus colores, apuntados por el puntero "tileset", ocupando 2304 bytes. Cuando cambias de tileset, lo que se hace es descomprimir un set comprimido (que puede estar en otro sitio de la RAM de 48K, o en alguna página de la RAM extra de los 128K) sobre "tileset", remplazando efectivamente los 2304 bytes originales por otros.

Lo que hacemos nosotros en los juegos de 128K (Goku mal y los que preparamos) es tener en tileset.h el tileset básico que sólo contiene las letras, para poder imprimir textos antes de cargar los niveles. También podrías tener ahí el tileset inicial, si lo que vas a hacer es cambiar el tileset en medio del juego.

El tamaño del tileset comprimido depende de la complejidad del mismo.

No entiendo muy bien tu pregunta :D Cuando compilas el juego, los 2304 bytes con los caracteres y sus colores se ubican en una posición de memoria apuntada por "tileset". Al inicializar el motor gráfico, simplemente se le comunica dónde puede encontrar estos gráficos. Cuando descomprimes un tileset nuevo sobre ese área de memoria, el motor gráfico ni se da cuenta. Sólo sigue usando los datos que tiene para dibujar, y estos han cambiado.

Re: Proyecto juego Churrera. Dudas

Publicado: Mar, 04 Feb 2014, 16:15
por elborra
$this->bbcode_second_pass_quote('na_th_an', '.')..
El tamaño del tileset comprimido depende de la complejidad del mismo.

No entiendo muy bien tu pregunta :D Cuando compilas el juego, los 2304 bytes con los caracteres y sus colores se ubican en una posición de memoria apuntada por "tileset". Al inicializar el motor gráfico, simplemente se le comunica dónde puede encontrar estos gráficos. Cuando descomprimes un tileset nuevo sobre ese área de memoria, el motor gráfico ni se da cuenta. Sólo sigue usando los datos que tiene para dibujar, y estos han cambiado.

Yep, es que cuando tengo dudas con algo soy muuuuy malo explicandome.... Quizás poniendo mi caso concreto es más sencillo.

No creo que vaya a manejar 2 tilesets completos que se alternen, en cambio he llegado a una solución intermedia donde los primeros 32 tiles son fijos y los 16 restantes son "sets" variables, por tanto 80 tiles (48 a la vez, claro). Independientemente de como gestione esto (todo en tileset.h y con offsets), está claro que los datos de los gráficos tienen que estar en algún lado (el gráfico monocromo 1:1 y los atributos por otro lado), ok. Mi duda es si el contenido de tileset.h recibe algún tratamiento especial al compilarse o simplemente habrá X bytes reservados (según el tamaño de la estructura) con una equivalencia 1:1 (que es lo que imagino). Lo cual significa que si exporto el tileset a .bin y lo comprimo me ocuparía menos espacio físico ( Para utilizarlo está claro que tengo que descomprimir la información con la función unpack que ya usais para las pantallas fijas).

Antes de soltar el mismo rollo abajo, al final esto se resume en: ¿ diferentes set de tiles en tileset.h es peor que N tileset.bin comprimidos?

Ahora bien, quizás mi ineptitud técnica del spectrum (hablo del Spectrum48K) hace que no tenga/tuviera claro algunos conceptos:
- La memoria del Spectrum es de 48K: ¿eso significa que cualquier cinta/juego para este sistema no puede ocupar más de 48KB de código? (sin meternos en dobles cargas o como pifostios se llame...si es que existe jajajaja ... y teniendo en cuenta que en esos 48KB tb está el loader y supongo que alguna cosa más)

- Si esto es así, tengo 48KB para todo, ¿ de los cuales splib y/o la churrera tiene si o si reservados 2304 bytes para los caracteres?, los 48 tiles y los atributos de color de todos, esa zona siempre vendrá apuntada por "tileset" dices, pero no veo esto claro (no se si lo dices por no extenderte o es que realmente es así) porque tileset es una estructura (vaaale tileset o tileset[0] apuntará al principio) pero con esto no "dibujo" nada, supongo que en algún lado "alguién" tendrá que decirle a splib que apunte tb a dicha estructura (seguro la estoy cagando por cada palabra que digo...) En cualquier caso, que me pongo a desvariar en cosas que ocurren gracias a la magia y yo con la magia no me meto :P .... volviendo al tema, si tengo 48K para todo y hay una zona de esos 48K de 2304 bytes donde siempre deberan estarán los datos en raw para que así se puedan pintar, en cuestión de espacio siempre vendrá mejor que comprima los datos y cuando me hagan falta los descomprimo en esa zona de 2304 bytes (donde corresponda si no voy a cambiarla entera), cherto'? :cabesa:

Re: Proyecto juego Churrera. Dudas

Publicado: Mar, 04 Feb 2014, 16:36
por na_th_an
El contenido de tileset.h no recibe ningún tratamiento especial. Cuando compilas un array con valores (que es lo único que hay dentro de tileset.h), los valores se van escribiendo en el binario que se carga en RAM en el mismo orden.

$this->bbcode_second_pass_quote('', 'Â')¿ diferentes set de tiles en tileset.h es peor que N tileset.bin comprimidos?


Depende. Por lo general, sí. El problema de comprimir todo un tileset es que primero van 2048 bytes con los 8 bytes de cada uno de los 256 caracteres, y luego van los 256 atributos de estos 256 caracteres. Eso significa que si quieres cambiar, digamos, sólo 32 caracteres, tendrías que hacer dos binarios: uno con los 32x8 = 256 bytes de esos caracteres, y otro con los 32 bytes de sus atributos, y descomprimirlos en los sitios correctos.

Para que te hagas una idea, el caracter "N" (con N de 0 a 255) empieza en (tileset + N * 8) y su atributo está en (tileset + 2048 + N).

Para lo que tú quieres hacer tienes que actualizar los últimos 64 caracteres (16 tiles por 4 caracteres cada uno) y sus atributos. Para ello necesitas dos binarios, uno con los bitmaps y otro con los atributos, por cada set intercambiable. El primero, descomprimido, ocupará 512 bytes, y el segundo 64 bytes.

Los caracteres de los tiles empiezan en el 64, por lo que estamos hablando de sustituir a partir del caracter número 192, o sea, tendrías que descomprimir los bitmaps en (tileset + 192 * 8), y los atributos en (tileset + 2048 + 192).

En tu situación, creo que ahorrarías bastante memoria comprimiendo los trozos que necesitas. Lo ideal sería programarte un conversor, pero creo que no es muy complicado hacerlo a mano. Con ayuda de un ensamblador puedes conseguirlo. Si recortas tus 64 ultimos caracteres y haces dos archivos así:

bitmap1.asm
$this->bbcode_second_pass_code('', 'defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 4, 42, 0, 0, 0
defb 0, 0, 0, 0,160, 0,128, 0
defb 10, 4, 0, 4, 0, 0, 0, 0
defb 168, 0, 8, 0, 42, 0, 8, 0
defb 7, 24, 39, 88, 83,166,173,171
defb 224, 24,228, 26,106,213,181,101
defb 166,173,163, 86, 88, 39, 24, 7
defb 213,181,101,202, 26,228, 24,224
defb 0, 0, 0, 0, 32, 32, 33, 32
defb 0, 16, 16, 16, 18, 16, 18, 16
defb 49, 50, 49, 50, 49,122,120,213
defb 18, 49, 58, 57, 60, 92,186, 85
defb 0, 0, 1, 16, 32, 1, 49, 49
defb 0, 0, 0,128, 0,132,128, 12
defb 33, 48, 3,121, 49, 31, 0, 1
defb 136, 12,192,158,140,248, 0,128
defb 1, 1, 1, 1, 1, 0, 3, 0
defb 0,128, 0,128, 0, 0,192, 0
defb 1, 1, 1, 1, 1, 1, 1, 1
defb 0,128, 0,128, 0,128, 0,128
defb 0, 0, 0, 0, 0, 32, 65, 42
defb 0, 0, 0, 0, 0, 0, 65, 42
defb 0, 69,171, 69, 0, 62, 94, 42
defb 0, 69,234,197, 0, 63, 86, 42
defb 0,243, 90,177, 0, 63, 95, 43
defb 0,231,245, 98, 0,127, 95, 42
defb 0,231,171, 69, 0, 62, 94, 42
defb 0,197,235,197, 0, 63, 86, 42
defb 0,122,125,106, 0,109, 37, 0
defb 0,126,125,106, 0,182,150, 0
defb 0,162, 20, 0, 0, 0, 0, 0
defb 0,162, 20, 0, 0, 0, 0, 0
defb 0, 0, 10, 23, 47, 95, 42, 21
defb 0, 0, 0, 64,132, 74,132, 0
defb 0, 0, 0, 1, 16, 0, 0, 0
defb 0, 80,186,116,170, 84, 0, 0
defb 161,122,209,187, 61,127,125, 58
defb 22,173,255,255,223,190, 15, 30
defb 116, 58,116, 40, 48, 32, 0, 0
defb 76,174, 68,226, 96, 64, 64, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 0, 0, 0, 0, 0, 0, 0, 0
defb 62,115,115, 78, 75,127, 54, 4
defb 0, 0, 64, 48,168, 42, 40,202
defb 7, 56, 71, 95, 95, 95, 95, 95
defb 224, 28,162,194,226,194,226,194
defb 95, 95, 47, 47, 22, 9, 6, 1
defb 162,194,132, 68,136, 16, 96,128
defb 3, 0, 1, 1, 65, 94, 94, 65
defb 192, 0,128, 0,130,114,106,130
defb 1, 1, 1, 1, 1, 1, 0, 7
defb 128,128,128, 0,128, 0,128, 96
defb 3, 6, 5, 1, 5, 5, 1, 34
defb 224, 36, 84, 68, 84, 84, 68, 36
defb 237,102, 35, 0, 41, 64, 40, 68
defb 213, 53,228, 4,192, 31, 0,142
defb 3,231,115,117, 50, 40, 26, 4
defb 230,244,224,208, 32, 16, 32, 16
defb 12, 14, 12, 14, 6, 34, 58,124
defb 24, 56, 56, 56, 48, 34, 46, 31')

attrs1.asm
$this->bbcode_second_pass_code('', 'defb 7, 7, 7, 7, 7, 7, 7, 7
defb 71, 7, 7, 7, 71, 71, 71, 71
defb 71, 7, 71, 7, 71, 7, 71, 7
defb 7, 7, 7, 7, 71, 71, 71, 71
defb 7, 7, 7, 7, 6, 6, 6, 6
defb 71, 71, 7, 7, 7, 7, 7, 7
defb 7, 7, 7, 7, 71, 7, 71, 7
defb 71, 7, 71, 7, 7, 7, 7, 70')

Con esto generas los binarios:
$this->bbcode_second_pass_code('', '../utils/pasmo.exe bitmap1.asm bitmap1.bin
../utils/pasmo.exe attrs1.asm attrs1.bin')

Luego los comprimes con apack...
$this->bbcode_second_pass_code('', '../utils/apack bitmap1.bin bitmap1c.bin
../utils/apack attrs1.bin attrs1c.bin')

y los introduces en algún sitio de tu código, por ejemplo al principio del propio extern.h:

$this->bbcode_second_pass_code('', '
extern unsigned char bitmap1 [0];
extern unsigned char attrs1 [0];

unsigned char *bitmaps [] = { bitmap1 };
unsigned char *attrs [] = { attrs1 };

#asm
._bitmap1
BINARY "bitmap1c.bin"
._attrs1
BINARY "attrs1c.bin"
#endasm

void load_new_subtileset (unsigned char n) {
unpack (bitmaps [n], tileset + 192 * 8);
unpack (attrs [n], attrs + 2048 + 192);
}')

Para cambiar el subtileset llamas a load_new_subtileset. Para añadir más, repite los pasos, crea las etiquetas en el código y no te olvides añadir los que vayas poniendo a los arrays bitmaps y attrs.

Sé que es espeso, pero con paciencia puede hacerse.

Re: Proyecto juego Churrera. Dudas

Publicado: Mar, 04 Feb 2014, 16:45
por na_th_an
$this->bbcode_second_pass_quote('', '-') La memoria del Spectrum es de 48K: ¿eso significa que cualquier cinta/juego para este sistema no puede ocupar más de 48KB de código? (sin meternos en dobles cargas o como pifostios se llame...si es que existe jajajaja ... y teniendo en cuenta que en esos 48KB tb está el loader y supongo que alguna cosa más)


El loader da igual, una vez que se ejecuta el juego tomamos posesión del Spectrum y toda la memoria es para nosotros. Sí, son 48K en total, a lo que hay que restar los 7Kb que ocupa la pantalla y lo que se llevan las estructuras internas de splib2. Nos quedan unos 36.5Kb para nosotros.

Las cintas ocupan más, porque pueden contener diferentes bloques que se van sobrescribiendo.

$this->bbcode_second_pass_quote('', '-') Si esto es así, tengo 48KB para todo, ¿ de los cuales splib y/o la churrera tiene si o si reservados 2304 bytes para los caracteres?, los 48 tiles y los atributos de color de todos, esa zona siempre vendrá apuntada por "tileset" dices, pero no veo esto claro (no se si lo dices por no extenderte o es que realmente es así) porque tileset es una estructura (vaaale tileset o tileset[0] apuntará al principio) pero con esto no "dibujo" nada, supongo que en algún lado "alguién" tendrá que decirle a splib que apunte tb a dicha estructura (seguro la estoy cagando por cada palabra que digo...) En cualquier caso, que me pongo a desvariar en cosas que ocurren gracias a la magia y yo con la magia no me meto :P .... volviendo al tema, si tengo 48K para todo y hay una zona de esos 48K de 2304 bytes donde siempre deberan estarán los datos en raw para que así se puedan pintar, en cuestión de espacio siempre vendrá mejor que comprima los datos y cuando me hagan falta los descomprimo en esa zona de 2304 bytes (donde corresponda si no voy a cambiarla entera), cherto'? :cabesa:


Sí.

Salvo en el caso complejo que tengas que descomprimir trozos muy pequeños que compriman mal y el propio código que tienes que meter para que se vayan descomprimiendo y colocando los trocitos ocupe más que lo que te ahorras comprimiendo.

Pero no es tu caso.

Sobre lo de tileset, te están fallando los punteros :) tileset [0] no es un puntero, es un acceso a memoria. Cuidao con esto. tileset es el puntero al principio del array, tileset [0] es una forma de decir "*(tileset + 0 * sizeof (unsigned char))", pero sin tanta mandanga.

De hecho, el concepto de arrays en C es una mera abstracción. En realidad, al definir un array, lo que estás haciendo es definir un puntero a un area fija dentro del binario generado. Cuando tú haces:

$this->bbcode_second_pass_code('', 'unsigned char array [] = {1, 2, 3, 4, 5, 6, 7, 8}')

El compilador, que va creando el binario del programa, simplemente escribe esos números en orden en el binario y se acuerda donde empezó a hacerlo, para que cuando en el programa se acceda a "array" sepa que se tiene que acceder a ese punto. Por ejemplo, pongamos que es "38888". Cuando tu accedas a "array [2]", en realidad el código máquina generado estará leyendo de "38890". Ya no hay arrays, ni punteros, ni hostias. Sólo hay direcciones de memoria.

Re: Proyecto juego Churrera. Dudas

Publicado: Mar, 04 Feb 2014, 19:04
por elborra
$this->bbcode_second_pass_quote('na_th_an', 'S')obre lo de tileset, te están fallando los punteros :) tileset [0] no es un puntero, es un acceso a memoria. Cuidao con esto. tileset es el puntero al principio del array, tileset [0] es una forma de decir "*(tileset + 0 * sizeof (unsigned char))", pero sin tanta mandanga.

De hecho, el concepto de arrays en C es una mera abstracción. En realidad, al definir un array, lo que estás haciendo es definir un puntero a un area fija dentro del binario generado. Cuando tú haces:

$this->bbcode_second_pass_code('', 'unsigned char array [] = {1, 2, 3, 4, 5, 6, 7, 8}')
El compilador, que va creando el binario del programa, simplemente escribe esos números en orden en el binario y se acuerda donde empezó a hacerlo, para que cuando en el programa se acceda a "array" sepa que se tiene que acceder a ese punto. Por ejemplo, pongamos que es "38888". Cuando tu accedas a "array [2]", en realidad el código máquina generado estará leyendo de "38890". Ya no hay arrays, ni punteros, ni hostias. Sólo hay direcciones de memoria.
Mejor imposible, esto es lo que necesitaba como el pan para aclararme del todo. Efectivamente tileset[0] no es un puntero, nomenclatura nula, queria decir que a fin de cuentas con tileset y tileset[0] colocarias el puntero en el mismo sitio, o algo así. XD

Aparte, thxs por dejarme el trabajo casi hecho, no había caido todavía que al descomprimir tenía que hacerlo en bloque y por tanto separar los graficos de los atributos (me hubiera dado cuenta tarde o temprano, sguramente tarde y por las malas jejejeje), pero ya no :P. Si tengo que echarle mano al tema de compresión lo haré así. :dalefran:

Re: Proyecto juego Churrera. Dudas

Publicado: Mar, 04 Feb 2014, 21:15
por elborra
$this->bbcode_second_pass_quote('na_th_an', 'P')ara que te hagas una idea, el caracter "N" (con N de 0 a 255) empieza en (tileset + N * 8) y su atributo está en (tileset + 2048 + N).

Para lo que tú quieres hacer tienes que actualizar los últimos 64 caracteres (16 tiles por 4 caracteres cada uno) y sus atributos. Para ello necesitas dos binarios, uno con los bitmaps y otro con los atributos, por cada set intercambiable. El primero, descomprimido, ocupará 512 bytes, y el segundo 64 bytes.

Los caracteres de los tiles empiezan en el 64, por lo que estamos hablando de sustituir a partir del caracter número 192, o sea, tendrías que descomprimir los bitmaps en (tileset + 192 * 8), y los atributos en (tileset + 2048 + 192).

Esto ya lo tengo hecho, creo que no se me entendió el "independientemente de como gestione esto" con que ya estaba hecho simplemente que no queria pararme a explicarlo. Mi proceso es el siguiente: la estructura tileset contiene el tileset normal de 2304 bytes (para los caracteres, los 48 tiles, y los atributos de ambos). Aparte en extern declaro en otra estructura los distintos sets de 16 tiles + atributos (512 bytes + 64 por cada) y dentro de void do_extern_action (unsigned char n) gestiono según n el cambio de set de una manera rudimentaria:$this->bbcode_second_pass_code('', ' unsigned int i;
switch ( n ) {
case 0:
case 1:
case 2:
for (i=0;i<512;i++) {
tileset[1536+i] = tileset_sets[n*576+i]; // <- 1536: posición tile 32 (Los sets cambian los últimos 16 tiles)
// <- n*576: posición en estructura definida en extern para el set n
}
for (i=0;,i<64;i++) {
tileset[2240+i] = tileset_sets[n*1088+i]; // <- 2240: posición atributos tile 32
// <- n*(576+512): posición en la estructura definida en extern para los atributos del set n
}
draw_scr_background();
break;
}')Esto implica tener en tileset_sets una copia de los 16 últimos tiles de tileset.h (llamemoslo set 0, para no "perderlos" al machacarlos) o intercambiar los datos entre tileset[] y tileset_sets[] aprovechando los bucles y gestionar que sets hay en cada momento en tileset_sets (que es lo que estoy cambiando ahora).

En cualquier caso quizás pruebe la forma comprimida cuando termine esto último ya que mi objetivo era "tocar" lo menos posible la churrera (quitado pequeños mods) y hacerlo en sets comprimidos y separados cambia "bastante" la forma en como funcionaría la churrera a la hora de crear los gráficos y su inclusión en ella, pero mi hermano no da cuartel (y yo más contento que unas pascuas) y al final tenga que usarla (aunque la tendré lista por si las moscas). Como anécdota hoy me llama:
- ¡oye! lo de los enemigos como era? cuantos frames tenía para cada enemigo.?
- pues tienes 2 frames para cada uno..
- Pero 2 para cada dirección? (vista cenital -> 8 frames)
- ¿como el prota? no,no, no tienes 8 frames para cada enemigo, los ocho frames se reparten entre los 4 posibles enemigos, 2 frames por cada.
- %$&, como pensaba jajaja, es que me he flipado y le he puesto al enemigo las 4 direcciones!
- pues ya tienes prota para otro juego XD

Re: Proyecto juego Churrera. Dudas

Publicado: Vie, 07 Feb 2014, 17:29
por elborra
Bueno chicos, ahora viene una pregunta chunga ya que le he estado dando vueltas pero no acabo de dar con la tecla.

Tenemos plataformas móviles para perspectiva lateral ;) ... pero ¿y plataformas en vista cenital? como digo le he estado dando vueltas, modificado el engine.h y otros menesteres pero no he conseguido el resultado esperado. Se que no existe hoy por hoy algo así para este modo, es exclusiva de la vista lateral, pero como soy así de guay :roll: no puedo parar hasta conseguirlo o me digáis que hay que tocar el motor demasiado.

La idea es tener el cuarto sprite (o uno más, ¡total! :shock: ) que basícamente lo que haría es moverse como un enemigo cualesquiera (con colocator le pondriamos su movimiento vertical u horizontal), sin embargo sería un sprite completamente relleno (es suelo al fin y al cabo) que al posar nuestro personaje este se movería con el (a fin de cuentas es detectar si colisionamos con él y en caso afirmativo la velocidad del personaje sería += la velocidad de la plataforma, supongo que será igual para la vista lateral) en cambio si que tendría un par de repercusiones que habría que controlar, como desarrollaré a continuación:

Supongamos un caso válido para querer plataformas móviles en juegos en dicha vista: Un abismo (tiles de tipo 1, para que hagan pupa y no se puedan traspasar) nos separa de la llave que al otro lado de la habitación nos llama con insistencia:¡¡coooogeme, estoy aquíííííííí!! -no puedooor, pero.... ¡ohh my good! hay una plataforma majisima de la muerte que me lleva al otro lado :cafe: .

- El personaje al posarse sobre la plataforma se moverá junto con ella.
- Puede ser que no estemos justo dentro de la plataforma (los dos son de 16x16 así que de hecho lo más probable que suceda)
- Por tanto en cuanto se mueva la plataforma vamos a ir por encima del abismo y el personaje va a colisionar con el abismo -> tile 1 -> daño -> pequeño rebote = ya la estamos liando.

Así que básicamente lo que hay que hacer son 2 cosas:

- incrementar la velocidad del personaje cuando pise una plataforma en su misma dirección y velocidad.
- y en caso afirmativo mientras estemos colisionando con ella "desactivar" el proceso por el cual al tocar un tile no walkable no recibamos daño.

A mi me pareció sencillo ya que salvo un par de código extra lo demás está implementado para el otro modo (copy-paste)... hasta que lo intenté :cry:

Re: Proyecto juego Churrera. Dudas

Publicado: Vie, 07 Feb 2014, 17:43
por na_th_an
Lo más problemático es añadir un sprite más. ¿No hay suficiente con 3 en pantalla? Añadir un sprite más precisa reservar más memoria dinámica. Cada sprite gasta 10 bloques de 14 bytes que se reservan en el add_memory que hay al principio de mainloop.h. Si necesitas más bloques, tendrás que bajar el valor de ADD_FREE que hay en churromain.c para hacerles sitio.

Aparte de eso, hay que modificar otras cosas. En teoría no parece complicado. Si hay colisión entre la plataforma y el protagonista, hay que desplazar éste, teniendo en cuenta que las coordenadas del protagonista están en puto fijo de 6 bits y una unidad representa a 1/64 de pixel (o sea, para ver su coordenada en pixels hay que dividir entre 64) y las de los enemigos son enteros y una unidad representa 1 pixel.

Además, lo que dices: la colisión contra los tiles que matan (que ocurre cuando la variable hit se pone a 1) hay que desactivarla.

He cambiado completamente la rutina de movimiento y la implementación de las plataformas para la siguiente versión. Tal y como está hecho en la nueva versión, hacer lo que quieres sería más fácil y cómodo. Pero pueden faltar meses para que salga.

Re: Proyecto juego Churrera. Dudas

Publicado: Vie, 07 Feb 2014, 17:52
por elborra
nu nu... ni por un momento pensaba en más de 3 por pantalla, de hecho lo que proponía era añadir un sprite más (que no tendría ni que tener máscara) a los gráficos, pero yo con los 4 tipos de enemigo en vista cenital estoy perfect. Realmente con tener una plataforma con ese comportamiento en lugar del 4 enemigo estaría más que agradecido. Le seguiré dando vueltas ^^
Todos los horarios son UTC+02:00
Página 3 de 4
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/