[DESARROLLO] remake Dynamite dan Para Megadrive

Pues seguro que recurriendo a imagenesis se puede sacar más rápidamente. Yo es que acabo de ponerme con el tema y "en mis tiempos" hacíamos prácticamente todo a pelo porque ni había librerías, ni herramientas para facilitar nada. Un coñazo del copón, sí.

Para los sprites sí, sácalos en archivos independientes como los que me has pasado de los protagonistas.

Estaba haciéndome un esbozo general a base de código poco funcional de cómo debe funcionar en líneas generales el juego. Trataré de darle caña a los tiles y las herramientas para trabajar con ellos lo antes posible para poder organizarnos cuanto antes mejor.

Tenía en mente trabajar con un mapa completo, pero mejor hacerlo pantalla por pantalla. Lo mejor es ceñirse exactamente al original puesto que más que nada en esta ocasión, de aprender se trata.

...exportálo como archivo C. Acabo de verlo en la página de TheElf, tiene buena pinta y te quita de crear tiles píxel a píxel que es lo que me he llevado un rato haciendo para seguir con las pruebas ^_^U

Por lo que entiendo te genera el mapa de la pantalla, y aparte te crea el tileset de la misma, ¿no?

Ej, por un lado haría falta que sacase un archivo un estilo a esto (más o menos y de 32*20)

00 01 02 00 01 02 00 01 02 00 01 02 00 01 02 00
01 02 00 01 02 00 01 02 00 01 02 00 01 02 00 01
02 00 11 04 04 04 04 04 04 04 04 04 04 05 01 02
00 01 10 03 03 03 03 03 03 03 03 03 03 06 02 00
01 02 10 03 08 08 08 08 08 08 08 03 03 06 00 01
02 00 10 06 00 01 02 00 01 02 00 10 03 06 01 02
00 01 10 06 01 11 05 01 02 00 01 10 03 06 02 00
01 02 10 06 02 09 07 02 00 01 02 10 03 06 00 01
02 00 10 06 00 01 02 00 01 02 00 10 03 06 01 02
00 01 10 03 04 04 04 05 02 00 01 09 08 07 02 00
01 02 09 08 08 08 08 07 00 01 02 00 01 02 00 01
02 00 01 02 00 01 02 00 01 02 00 01 02 00 01 02

y por otro debería sacar otro archivo con los tiles ordenados de manera que el orden se corresponda con el valor de en la lista anterior.

(Estas cosas eran las que yo hacía a pelo) Ya me pasas cuando pueda algún ejemplo para que le eche un ojo. Entre tanto sigo trasteando por otros lados.

Bueno, más o menos. Ya parece que también le empiezo a coger el rollo a los archivos que genera el programa que me dijiste (imagénesis, tengo la cabeza ahora a saber dónde)...

Sí que había visto el archivo con los sprites. Te decía que los sacaras uno a uno como en el bmp que tenía yo con las cuatro frames de la cucaracha consecutivas, pero la verdad es que ahora mismo no estoy seguro de cuál será la mejor forma de hacerlo. Mejor sigue con los mapas ahora que parece que ya consigo darle uso a los archivos que se sacan a partir de él.
* Otra cosa es que salves los bmp a 16 colores, que por ejemplo el negro puro se lo suele pasar el imagenesis por el forro y me toca cambiarlo siempre (la opción "Replace" del CodeBlocks es muy apañada para estos menesteres, pero si me lo ahorro mejor).

Supongo que incluso todos los tiles de fondo se pueden pintar usando una única paleta general, cosa que en principio tampoco sé muy bien en qué podría beneficiar, pero nunca está de mar guardarse opciones en la manga.

La rom es una chorrada. Es lo mismo de antes cargando mapas e implementado el cambio de pantalla, pero después del atasco del quince en que me he metido para aclararme merecía un mensaje chorra.

El salto sé que ahora mismo tiene mas bichos que una charca. Se tiene en cuenta.

De todos modos, me ha servido para ver una cosa: las partes del escenario que deberían de quedar por encima del personaje como las cuerdas que sujetan la cesta, o la propia cesta si mal no recuerdo. Tenlo presente cuando me pases las imágenes de la pantalla si ves que hay elementos que quedan por delante. Esos habrá que pintarlos luego como sprites por encima del personaje. Y nada más. Seguimos al lio.
También sucede que "algunos" (por ser muy crítico) tiles no los ripea tan bién como deberíamos, y ésos sí que habrá que afinarlos a mano toqueteando los valores del array (tampoco es algo demasiado descabellado son 64 pixels por bloque). En todo caso aligera bastante como puedes ver; mi opción inicial - y los que creé para las primeras pruebas - era hacerlos desde cero sin herramientas de ningún tipo.

Por cierto, ¿se te ocurre porqué no me ripea bien los tiles? Lo mismo es problema al cargarlos en el programa. Problema de dibujo no es porque están almacenados así en la memoria de video (se puede ver con el Gens KMod). Pruébalos tú con el basic si acaso y me cuentas.

Planning por mi parte: acabar de repasar qué es lo que he hecho para cargar los mapas, terminar de adecentar el código que lo dejé a medias por curiosear lo de los mapas de tiles, arreglar la rutina de salto, corregir la rutina de dibujo del mapeado que ahora mismo me recoge basurilla de la pantalla anterior por ahorrarme pintar los tiles negros, y ya luego, meter el primer bicho.

Intento aclarar por partes.

Lo de usar un archivo aparte para los que se pueden atravesar, no me trae cuenta porque una vez que sepa cuántos hay entre todas las pantallas (ponte que sean 18) y estando dispuestos de manera consecutiva como "cabecera" del dibujo (ponte que del elemento 30 al 47). En la rutina de colisiones sólo tengo que meter un IF comprobando que el tile sobre el que intente avazar el personaje tenga valores comprendidos entre 30 y 47 para saber que puede atravesarlos sin problema.

Las pantallas sólo tendrán ese tamaño al pasárselas al imagenesis para conseguir que esos tiles queden identificados con los mismos valores en las 48 pantallas, con esto se consigue que a la rutina de comprobación de colisiones le de lo mismo la pantalla activa. Si por ejemplo se intenta avanzar sobre un tile de valor 36 se puede y sobre uno de valor 59 no (compruebo rangos de valores). También unifica la paleta para los fondos, que es otra cosa que interesa.
Al exportar el mapa de tiles de cada pantalla sólo me quedaré con los datos correspondientes a la pantalla de juego en sí. Ignoraré los datos correspondientes a las cuatro líneas superiores. Pero sin embargo sí se usará el tileset íntegro aunque algunos tiles incluídos en él no aparezcan en la pantalla. Cuando te despejes trata de aclararte con la idea del funcionamiento. El tileset contiene los tiles de la pantalla. Y el mapa de tiles, empezando desde la esquina izquierda-arriba una ristra de valores (640 para nuestras pantallas de 32 x 20 tiles en el juego) que identifican que tile ha de dibujarse en cada una de esas 32x20 posiciones. Nuestras pantallas "con cabecera" ya sabes que serán de 32x24 tiles pero sólo en el BMP. Al estar ordenados igual los tiles importantes en todos los BMP (otro ejemplo), la primera vez que el imagenesis encuentre en el dibujo los tiles de la plataforma-arbusto le asignará los valores que le toquen (va
asignando valores tal como va encontrando tiles distintos), pongamos que 34 y 35. Si más adelante los vuelve a encontrar, esas posiciones del mapa de tiles con los mismos tiles (podrían ser sprites efectivamente, pero como tiles es MUCHO más práctico y cómodo) tendrán también valores 34 y 35. Al mismo tiempo, en el tileset se almacenan las dos imágenes correspondientes a estos tiles en la posición 34 y 35.
Aclárate bien con esto que es casi primordial. Los sprites los dejaremos para enemigos e ítems, cosa que vendrá luego. Y con respecto a la pantalla de los tubos déjala de momento que le tengo que echar un ojo pero con tiles se resuelve también el tema.
Píllate las imágenes generales de los mapas de Worldofspectrum para trabajar con ellas.

Los tiles que rotan color, me da que son todos bloques de tipo sólido, pero como aún no he decidido como colorear el área de los transportadores, por si las moscas voy a concederme la posibilidad de validarlos en un caso dado. (función valorTile al final).

Los #define irían tal que así suponiendo los valores puestos de ejemplo

#define TILE_NINGUNO 0
#define TILE_CARACTER 1
#define TILE_PLATAFORMA 38
#define TILE_ESTETICO_A 58
#define TILE_ESTETICO_B 68
#define TILE_ROTACOLOR 78
#define TILE_ESCALERA 88
#define TILE_SOLIDO 89

Tienes que compilar main.c, los demás archivos los llama desde ahí:

main.c: funcionamiento "genérico" del juego. Bucle principal y cambio de pantallas entre otras cosas.
defines.h: a nivel de código no afecta pero ayuda tela a clarificarlo. Palabras que sustituyen valores o expresiones.
enemy.h: de momento sin nada. Los datos y funciones destinadas a los enemigos irán aquí.
map.h: mapas y funciones encargadas de cargarlos y pintarlos.
player.h: (esta no me ha dado lugar a adecentarla) todas las funciones relativas al jugador incluyendo las de colisiones con escenario, enemigos y objetos.
tile.h: incialización y carga de tilesets.

resource.rc se usa para generar los sprites con el genres (de momento sólo está ahí para ir probando). En la carpeta data están las imágenes que el tal genres convierte en datos de sprites.
En out se crea el binario.
res está ahí porque también empecé a probar con otro método de carga de imágenes que requiere que estén en esa carpeta.
Y scr no pinta nada. Ésa la puedes ignorar.

Por cierto que el compilador es algo puñetero y a veces se atasca. Lo mismo te tira un error, vuelves a compilar y no te da ninguno o directamente pasa de generarte el binario. Es cosa de insistirle dos o tres veces y ya está.

Justo después de los tiles de los caracteres he empezado a colocar todos los que cumplen estos dos casos:
* Se pueden atravesar desde cualquier lado
* menos desde arriba
(plataformas convencionales)

En un vistazo a todas las pantallas he encontrado todos esos tiles pero en algunos que he visto me he quedado en duda. Como tú te conoces bien el juego dale un repaso y pega las demás que encuentres o me indicas cuáles son.

También he buscado los tiles que cumplen esos requisitos:
* Se pueden atravesar desde debajo y lateralmente
* No se atraviesan desde arriba (son plataformas)
* Y ADEMÁS SON UNA SUPERFICIE ELÁSTICA (He encontrado la cama elástica, el cable punteado y algo que parece ser una goma roja. Lo mismo, ¿alguno más?)

En realidad en el juego original las camas elásticas no se pueden atravesar, pero me moló que se pudiese pasar por delante En todo caso, se implementen las camas elásticas como barrera lateral o no, por diferir su comportamiento de los bloques normales hay que tener localizado sus índices (para poder hacer la pertinente comprobación en el código).

Si intentas pegar algún nuevo tile en el BMP que te he pasado y ves que le altera los colores, reduce los colores del original a 16 y cámbiale la paleta por la de éste. El Paint Shop Pro 4 permite guardar y cargar paletas.

En resumen.
TAREA: revisa todas las pantallas para tener sacados todos los tiles-plataforma del tipo que te he indicado sin que se nos escape ninguno.

- De la plataforma que tiene un aspecto "en plan floreado" no estoy seguro del todo de que los bordes -los dos tiles de los extremos- sean plataforma. Aunque casi seguro que sí.
- En esa misma plataforma (al igual que una amarilla parecida que tengo ahí puesta tres posiciones más atrás) lo que he colocado es la parte superior del dibujo de la plataforma -los tiles de arriba-. Esto es porque, obviamente, no nos interesa que el personaje pueda subirse "en el medio vertical" del objeto.


Aparte:
Ya medio he conseguido sacar una paleta conforme a lo que me interesa. No te rayes con los colores del teletransportador que sigo de pruebas.

Ya he conseguido salir del atolladero del principio y creo que estamos en situación de meterle mano al mapeado entero (sin mucha interactividad de momento, paso a paso).
La culpa sí la tenía el imagenesis que exporta bien los tileset en basic pero NO en C. He tenido que hacer un programa que transforme el archivo basic en uno en C sin corromper el tile.

Te cuento lo que me interesaría que fueses haciendo cuando vayas teniendo tiempo y ganas (a tu ritmo, unas cuantas cuando te apetezca, luego otras... ya te aviso de que es un coñazo) para seguir yo con la programación implementando más detalles del juego.

- Las pantallas que has sacado hay que pasárselas con la cabecera de los tiles especiales al imagenesis. Para lo cual lo suyo es coger una de las que estén hecha (alguna de las que te paso) y pegar la pantalla en la zona que corresponde. Antes de hacer esto, acuérdate de reducirle los colores a la pantalla "normal" a 16. Luego ya la pegas. Si ves que algún color no sale como debiera puedes usar la herramienta de reemplazar color del editor. Lo importante es que no meta píxels a boleo donde le parezca (que como te descuides lo hace). Copias, pegas en su sitio y salvas. Paint Shop Pro 4, con ése va que chuta.

- Abres el imagenesis. Cargas la pantalla. Le das a lo de Optimize, 16 colores... (la segunda opcion). Y a Quantize.

- Salva el tileset como basic con el nombre tileset.bex. Mi programita basic2C.exe tiene que estar en la misma carpeta. Lo ejecutas y te generará un archivo llamado tilesC.h que contiene el array con el tileset en nomenclatura de C. Posiblemente haya que borrar algún espacio al principio, cosas de hacer un programa a la carrera que no contaba con tener que hacer.

- Utiliza los que ya están hechos en tile.h para ver cómo usar el contenido de tilesC.h. No hay más que copiar y pegar dentro de un procedimiento con el nombre adecuado. En C es tal que así: void nombredelafunción(void) { el contenido }.

* TILESETs listos

- Ahora volvemos al imagenesis a que nos genere el mapa. Le das a exportar mapa. Esta vez EN C.

- El archivo generado tendrá información correspondiente a 24 líneas y obviamente nosotros sólo queremos la parte correspondiente a la pantalla. ¿Qué hacer?, pues mandar a tomar viento las cuatro primeras, fácil.

- Ahora te vas a map.h (el archivo de nuestro código) y otra vez oriéntate con el resto.

- Creas una función map_elnumeroquetoque y usas los datos obtenidos del imagenesis para el array de datos de la función.
La primera línea la ignoras que es otra cosa que el imagenesis no hace bien. Esto: unsigned short tiledata_5[5088] = {. Copia el resto y lo pegas usando de plantilla cualquiera de las que están en nuestro código.

--------

Obivamente no espero que consigas "cogerle el truco" enseguida. Haz tus propias pruebas cambiando y volviendo atrás... Y ve familiarizándote con esa parte del código.

El tileMAP no es otra cosa que información almacenada en arrays (series de datos) sobre (para cada pantalla) QUÉ tile corresponde pintar. Ej castellanizado ("un suponé"):

Array_de_la_pantalla_3[numero_de_elementos] = { tile12, tile32, tile32, tile32, tile6, tile71, tile32, tile12, tile12 ...

Y el tileSET es la información gráfica del tile: los tiles son de 8 por 8 píxels. Los datos de los tilesets son de 32 bits (los colores de megadrive de 4 bits), ergo en un dato se almacena información de 8 pixels. 8 datos de 8 pixels = 1 tile.
Si te fijas en los elementos, las cifras varían del 0 a F, es notación hexadecimal. Cuando llegamos al 9, el siguiente es A, después B, C, D, E y F (que tiene valor 15). 16 colores por tile tiene la megadrive -cada cifra corresponde con el valor de un píxel-.

La explicación viene al caso de que puedas tener una idea de lo que estás toqueteando, cosa que hace bastante más fácil salir de los atolladeros si te atascas.

-------------------------------------

El tutorial para configurar el sgdk en el codeblocks es éste:

http://code.google.com/p/sgdk/wiki/SGDKTutorial

--------------------------------------

Los teletransportadores ponlos como en la pantalla de muestra que te paso. No hace falta animar nada a base de sprites para esos casos. Es la paleta la que está cambiando de colores en cada iteración del programa (bueno, cada cuatro para que diera tiempo a ver cada color un instante). Todo lo que aparezca en el dibujo con un color distinto a los ocho básicos de pantalla aparecerá rotando.

---------------------------------------

- Ten presente que en relación a como tú las has numerado, en el código la pantalla A5 es la cero, A6 = 1, A7 = 2 etc... Me guié por este mapa global:

ftp://ftp.worldofspectrum.org/pub/sincl ... iteDan.gif

La segunda fila serán pantalla08 hasta pantalla15

---------------------------------------

El código del (proyecto de) juego es lo de la carpeta TEST. Dentro he metido "_BMP-Plantillas" con las imágenes de las pantallas tal como las he pasado por el imagenesis. (Luego hay que usar el basic2C.exe con el tileset.bex y eliminarle al tilemap las cuatro primeras líneas).

---------------------------------------

De momento y por hoy hasta aquí. No te agobies si ves que te lía mucho lo de meter más pantallas. Prueba al principio a sustituir las que hay por otras y ver los resultados. Repásate el tutorial del CodeBlocks, siguiéndolo al pie de la letra se deja todo preparado, lo más delicado es lo de acordarse de crear las dos variables de entorno.

----------------------------------------

Trataré de implementar el cambio de pantalla vertical a continuación para que si vas avanzando con el mapeado lo puedas ir viendo completo.

----------------------------------------

Taluego, ánimos y a tu ritmo/rollo; que esto no ha de ser más que un hobby. Y pregunta lo que sea.

Si has estado haciendo pantallas, para un momento.

Se nos ha pasado al menos un elemento de los traspasables por abajo (espero que sea el único) con lo que puede ser que las pantallas sacadas de momento no nos valgan :S

Miro qué puedo hacer y vuelvo en un plis...

Revísalo cuando puedas y me cuentas. Están colocados:

(Tile 0): el tile vacío o negro
(Tile 1-2): tiles con los colores que contendrá la paleta
(Tile 43-64): tiles estéticos (se pueden atravesar por todos lados; el tile todo color crema es con el que se dibuja el área con rotación de colores del teletransportador - lo que te dije de que lo que esté en el dibujo con algún color distinto de los ocho primeros, en el juego sale rotando colores. El tile todo azul es el del agua).
(Tile 69-77): tiles plataforma, que se pueden atravesar por todos lados menos por arriba.
(Tile 81-83): escaleras (sólo la parte que se pisa)
(Tile 85-89): superficies elásticas
(Tile 92 en adelante): bloques sólidos del escenario, he colocado los que me han parecido más comunes para que se haya que cargar luego por cada pantalla los menos adicionales posibles.

Los bloques marrones moteados son huecos que he dejado por si hace falta meter alguno más que no me descuadre otra vez el resto.

La numeración exacta ahora es lo de menos, lo importante es que no se escapen ninguno de los de las categorías por detrás de la última.

* ¿Las escaleras se pueden atravesar por debajo?

Taluego otra vez.

Empiezo:


- (Desactivados los teletransportadores que son la raíz de mis problemas de cuelgues y aún no me ha dado lugar a miarlo con el tiempo que requiere :|)

- Todas las pantallas de las filas A y B hechas más la 25 (que no caigo cuál es ahora en la numeración letra-cifra).

- Lo primero es salir de la cabina del principio. El dichoso salto. Es más fácil hacia la derecha. Para salir por la parte izquierda sólo pégate al lado y salta dándole al botón a lo loco hasta que se escape.

- Empezarás a ver cuadros azules cada vez que recojas una comida. Eso es porque de principio aparecen pintadas y si son recogidas toca borrarlas y no volver a pintarlas más (por haberlo resuelto con tiles en lugar de sprites). Como una tarea que exige el código es ubicar el lugar donde borrar, mientras se especifican todas las coordenadas correctas, un cuadrado negro (que será el definitivo) es imposible de ver para saber dónde está si no está tapando lo que queremos que tape. Las funciones en cuestión están en ITEMS.H y son:
--> cargaItemsComida: hay que indicar las coordenadas en tiles. Si en una pantalla ves que sale un cuadrado azul en medio de la nada es que hay que corregir los valores. El índice del array corresponde a la pantalla de modo que items_comida[4].tipo = ITEM_HELADO; indica que en la pantalla 4 (según la numeración que le doy en el código - A1 según la de los barquitos -) el ítem de comida disponible es de tipo helado.
--> en recogeComida(), la instrucción encargada de pintar el recuadro negro se encuentra comentada (precedida de // lo que hace que el compilador la ignore). Es ésta:
//ocultaTiles(items_comida[id_pantalla].h, items_comida[id_pantalla].v, ancho, alto);
Si quieres probar a que oculte los ítems al recogerlos, descoméntala y comenta las dos de abajo
VDP_fillTileMapRect(APLAN, TILE_ATTR_FULL(PALETA_BASICA, 0, 0, 0, TILE_AGUA),
items_comida[id_pantalla].h, items_comida[id_pantalla].v, 3, 3);

- Mi chusquero basic2c.exe para convertir el tileset exportado en basic en nomenclatura de C puede meter algún espacio después del 0x del primer elemento de array (Ej. 0x 00124400) y eso hace que el compilador de error lógicamente. Si tiene espacios el primer elemento después del 0x, los espacios fuera. TILES.H El archivo en basic tiene que llamarse tileset.bex

- Al tilemap, que ése sí se exporta en nomenclatura C, elimínale las siete primeras líneas correspondientes a los tiles que se usan como "generales" y que ya están cargados permanentemente en memoria. MAP.H
Cada vez que añadas un mapa, declara la función arriba mapNUMERO(); (si no lo haces el compilador te saca un aviso de "implicit declaration") y en el case de la instrucción switch cambia el map07 que lo puse como genérico/defecto por el mapa que corresponda.
* El valor que sale en la esquina superior izquierda es el número de pantalla


- Puedes trastear con los valores de MACROS.H (antigo defines.h) como PANTALLAINICIO, GRAVITY o JMP_PWR (los dos últimos afectan al salto y el primero es obvio). Lo de cambiar el valor de PANTALLAINICIO es interesante para probar las nuevas pantallas sin tener que recorrer todo hasta llegar a ella.


- La mayoría de las veces hay que insistirle al compilador para que compile. Con dos o tres suele ir que chuta.


* Me doy cuenta que casi que tenía que haber dejado el salto como en la revisión anterior, perdón ^_^U Procuraré arreglarlo pronto para que no sea tal suplicio moverse entre pantallas.

Luego si acaso me vuelvo a pasar ya sin pretensión de soltar tochos. Hasta luego.

Sólo he cambiado en map.h las funciones

>>> cargaTransportadores()
y
>>> actualizaTransportador()

aparte de descomentar la línea

>>> actualizaTransportador();

que está en el bucle principal de main.c

Sigue habiendo que pulir más las colisiones y el salto pero ya no resulta tan insufrible moverse por los escenarios lo que desanima menos a la hora de probar pantallas.
Ya me parece que sí que hay que meterle mano a los sprites. Hay dos o tres detallitos más que se pueden hacer con tiles, pero se quedarán pendientes (ahora mismo caigo, por ejemplo, en poner gris y parpadeando el último icono de la energía cuando sólo queda uno). Seguramente empiece por los ítems especiales, vida, dinamita, etc.
Las pantallas con escalera te las mando seguramente ya mañana.
No desesperes, que esto es muy engorroso pero se sale adelante a base de trompicones y más trompicones. Ya hemos pasado el ecuador si te sirve de consuelo

La cabecera que has usado en todos es la que improvisé para usarla con las pantallas que tienen la escalera de mano ésa.

Si por ejemplo te fijas en la pantalla D3, segunda fila al final, los tiles de la parte superior de la escalera están pisando dos correspondientes al ¿tronco? de madera sobre el pozo. De usarla con esa pantalla ya no detectaría esos dos tiles como traspasables y no permitirían caer al pozo a través de ellos.

Entonces:


PANTALLAS
__________________________________

- Si NO sale en la pantalla la escalera de marras --> la cabecera anterior (la que he usado cuando te envié todo el código comprimido el otro día)
- Si sale la escalera --> La que has usado en todas las pantallas que me has mandado esta última vez.

* Los teletransportadores TIENEN QUE aparecer dibujados como en las pantallas que he usado yo (en la carpeta "preparadas" me parece que las dejé). Copia uno, el cuadradote feo más las luces de arriba, y ve pegando donde corresponda. Las pantallas que tengo yo en la carpeta "preparadas" ya están listas del todo a excepción del apaño de la escalera para las que sea necesaria. La razón es que el programa al leer el mapa, si detecta que el personaje está sobre un tile de ése color crema raro, pues ya sabe que está en un teletransportador y actúa en consecuencia; además de que ése color lo lee pero no lo dibuja, en su lugar pinta el área de negro o rotando colores según corresponda. Las luces dibujadas, tres cuartos de lo mismo y permiten que tenga lugar la animación de cambio de color sólo con rotar la paleta (una función cortita que está casi al final del main.c), sin usar tiles ni sprites adicionales. Tal como está hecho en la 10-B7.bmp
que además de comida (que hay en todas), también tiene un teletransportador.

* La comida TAMBIÉN tiene que aparecer. Ya el programa se encarga luego de borrarla cuando se recoge y de sumar los puntos y la energía. Esto es más coñazo pero atendiendo a las coordenadas en el programa de edición gráfica y teniendo presente que siempre se sitúan en posiciones de tiles (multiplos de 8) se hace más leve. Las coordenadas de las comidas y sus tipos tienen que indicarse en items.h.


En la pantalla del zepelin, los huecos de la pantalla tal como está en el programa ahora se taparán con sprites. Está dibujado sólo lo que actúa como paltaforma o como barrera de éste.

En la pantalla de la muerte podemos prescindir de la cabecera porque bien mirado no se utiliza ningún tile de ella y no es necesario detectar suelos ni historias, no es más que una animación predefinida.


DE LAS PANTALLAS QUE TENGO YO HECHAS sólo es necesario cambiar las que tengan la escalera de la que hemos hablado sustituyéndole la cabecera. Las demás están listas del todo y la mayoría ya están integradas en el programa. La comida dibujada y el teletransportador si lo hay en esa pantalla. Habría que cambiar la cabecera por la que has usado tú en la 25-D6.bmp y la 46-F3.bmp. De las pantallas en el archivo imagenes_listas.zip la mayoría ya están añadidas al programa (las de la fila F no) y no hace falta tocarlas. Puedes empezar a probar insertando en le programa las de la fila F y cambiando en macros.h el valor de PANTALLAINICIO para que de salida el personaje aparezca en alguna de ellas cuando estén metidas.

RESUMEN:

- De las que ya están sólo hay que cambiar las de la escalera (sustituyendo la cabecera)
- La comida debe aparecer en la posición exacta (indicar datos de la comida en items.h)
- Los teletransportadores deben aparecer en la posición exacta (indicar datos de los teletransportadores en map.h)

[Las coordenadas se indican en tiles (superficie de 32 horizontales por 20 verticales)]

* Ya de paso --> Datos de los rayos en map.h también

_____________________________________

Los dos archivos con datos del tileset y el mapa de tiles casi también:

- Al tilemap.c quedaría eliminarle las siete primeras líneas de datos: desde la que empieza por el valor 0x0000 hasta la que empieza por 0x00BE (inclusive), nos quedaríamos con el resto. Mira los demás en map.h y así No hay más.

- En tileset.c tendrías que borrarle el espacio que ha quedado después del 0x del primer elemento "0x 20222222", tiene que aparecer como "0x20222222" si no salta un fallo. Y otra cosa ¿te sale así usando el último basic2c.exe que te pasé? Es que debería de sacar los tiles a partir del tile 222. A partir del 127, que es como te sale a ti, era cuando en la cabecera tenía sólo 4 líneas. Prueba con el que te adjunto en este correo.

Las demás de la carpeta "preparadas" son todas válidas.

Revisa la E6 (la original que tengas) que creo que está tres píxels desplazada hacia arriba o hacia abajo y no terminé de aclararme si tenía que rellenar con una fila arriba o una fila debajo.

Espero que hoy no te haya cundido mucho el día porque volví a cambiar la cabecera ^_^U

En el rar van algo más de la mitad de las pantallas para hacerle el proceso de:

- Pasarlas por el imagenesis (opción 15 color Optimized): tileset y mapa.
- Usar el basic2c.exe para convertir el contenido del tileset.bex en el array pertinente
- En el mapa de tiles, se eliminan ahora las 8 primeras líneas y el resto se pega en la función correspondiente.

Compilar y probar a saco.

Tengo sólo listas del todo en el programa la 4(A-1) y la 25(que es a la que conduce el teletransportador). Con eso me basta para seguir implementando cosas. Llegará un momento en que me haga falta tener las del ascensor y la planta baja, pero de momento me pongo con los bichos. Tómatelo con calma porque ya se me han acumulado un porrón de cosas por ir puliendo.
Si te da problemas al compilar pero aparentemente no te indica errores, inisiste dos o tres veces. En caso de dudas, pregunta lo que sea.

Yo voy a dejar de toquetear en los siguientes días el archivo map.h (salvo en las pantallas A1 y la 25) e items.h. Ve haciendo pruebas cuando puedas y tengas gana y trata de ir completando el mapeado poco a poco. Preparas una pantalla, la insertas al código, compilas a ver qué sale... Puedes machacar el contenido de todas salvo las dos ésas que están bien (o tal cual se necesita que estén). Cuando te vuelva a pasar el código unificamos.

Yo para las colisiones utilizo el propio mapa original, si en el mapa original el tile es negro, es que se puede avanzar en todas direcciones sobre él, si es un tile del teléfono, se puede traspasar, etc... por eso hago lo de la cabecera. Para que en todas las pantallas los mismos tiles tengan los mismos valores y comprobándolos ya sé que efecto causan sobre el personaje, si lo bloquean, si lo hacen rebotar, etc. Lo mismo que hicistéis con dos mapas se puede hacer con uno perfectamente en este caso. Son dos formas de hacer lo mismo, pero la mía es más eficiente en cuanto a economizar memoria aunque no nos haga falta

"Variables de entorno" se llama eso que hay que crear y que te está dando guerra.
- Creas una que se llame GDK y como valor escribes la ruta donde tengas instalado el sgdk CON FORMATO UNIX (barras invertidas). El mío es D:/Bru/sgdk
- Creas otra que se llame GDK_WIN y también pones la ruta a donde hayas instalado pero esta vez con las barras normales (ejemplo D:\Bru\sgdk).

El radiador ya lo tenía metido. Estuve dándole un buen repaso a todas las pantallas la última vez.

Lo de las colisiones me refería a colisiones con los enemigos (colisiones entre sprites). Estoy en ello. Me está dando un poco más de problemas de los que pensaba pero casi casi lo tengo. Prácticamente todo lo gordo que había que programar está ya hecho. Quedan tres cosas esenciales por implementar que son las dos plataformas móviles y los ítems (aparte de los menús, que es más coñazo que otra cosa) y luego mucho pulir.

Te mando el binario que tengo ahora para que veas que cada vez se parece más al original

Sigo con los enemigos (ahora no, sino cuando puedo), un poco enredado a la hora de borrar los que toca borrar, pero sigo por buen camino.

Entre tanto consigo dejarlo tal como quiero antes de volver a enviártelo a ver si puedes ir completándome esta función (asignar valores). Te paso un ejemplo en el gráfico de cómo obtener los valores que hacen falta (la coordenada donde se encuentra la comida de cada pantalla).

Hay que indicar también el tipo de comida que es.

A partir de dentro de poco (quitando la parte de sonido que a ver qué tal se presenta) lo que quedará será mucha tarea coñazo como esto. Tómatelo con calma nuevamente. A ratos y cuando tengas ganas ve completando los valores según te vaya apeteciendo ponerte con ello un rato.

Taluego.

Cuando te pille aburrido, date alguna vuelta por el mapa y apunta todo lo que veas. Las pantallas en las que prácticamente no detecta ningún tile como debería (como la del pozo), es muy posible que el BMP estuviese desplazado algún píxel arriba o abajo y hay que rehacerla de cero.
Si ves que desaparecen las vidas porque sí, es porque he desactivado el dibujo de los enemigos aunque sigan activos para que el personaje se mueva con soltura, ya que ahora mismo el dibujo de enemigos "buggea" el juego cosa loca.
También puedes ir, si eso, anotando las coordenadas donde deben salir los rayos y la longitud de éstos (la función está en map.h creo, cargaRayos(), el proceso es el mismo que con la comida).
Aviso de que me empiezo a saturar un pelín de ponerme casi casi a diariocon el juego y lo mismo en un momento dado me dejo ir un poco ^_^U Para este año digo yo que seguro que está (más que nada porque lo que me comentó Pocket_lucho de sacar algunas copias en formato físico para la próxima retroencounter mola un cojón).

Saludos one more time.

Por partes:

Tomo nota de lo de la puntuación por matar enemigos. Por lo visto es bastante simple pero a mí ya me fallaba la paciencia para ponerme a hacer pruebas jugando al original. 20 mas uno progresivamente. OK.

Si has cacharreado poco con programación la verdad es que sí puede ser trabajoso configurar todo tal como se necesita. La versión que te decía era de las librerías del kit de desarrollo para la megadrive, otra cosa además. Así que por esta vez mejor seguimos yo con el código y por tu parte rascando toda la información y datos necesarios del juego original.
Más que agobio es un punto al que se llega si se programa con demasiada cabezonería en el que te embotas un poco-bastante y te cuesta resolver cosas que son evidentes cuando tienes la cabeza fresca. Aunque he dedicado poco tiempo por razones varias en estos últimos días a la programación en sí, llevo atascado con el borrado de los sprites que me interesa borrar. Por ejemplo, salto sobre un enemigo y se borra ése y el dibujado justo anteriormente. O en lugar de borrarse se queda el último frame estático en la pantalla. Seguro que es una chorrada pero tengo que ponerme con tranquilidad y hacerlo bien. Entre tanto hice el paréntesis para meter las pantallas y seguramente cuando pueda hoy y/o mañana haré lo mismo incluyendo las funciones correspondientes para la carga de cada uno de los bichos que me faltan. Por cada bicho, en la propia función se indica la coordenada en donde aparece inicialmente y el número de tiles máximos que se puede
alejar de esa posición inicial. La colocación de los bichos es posible que te toque, ve buscando cuaderno y boli para tomar notas a mansalva
Ejemplo de la carga de dos de los bichos de la pantalla inicial:

enemigo_cucara(26,10, SPEED3, 6, PALETA_SPRITES2, COPIA);
enemigo_torped( 5,11, SPEED2, 4, PALETA_BASICA, NUEVO);

Los dos primeros parámetros son las coordenadas horizontal y vertical donde aparece inicialmente, la velocidad (desde SPEED1 a SPEED5), el número de tiles que se puede alejar antes de dar la vuelta (si encuentra un barranco o se choca con una pared también lo hace automáticamente -aunque creo que estableciendo correctamente el valor anterior no harían falta esas dos comprobaciones). Luego la paleta usada (que hay que retocarlas; de momento es posible cuatro colores distintos para el mismo tipo de bicho por pantalla) y el último parámetro es para indicar al programa si es un bicho que aparece por primera vez, por lo que debe mandar el gráfico a la memoria de vídeo, o si por contra es un clon de otro cargado anteriormente y usará entonces el gráfico que ya está en la VRAM. De todos modos lo de situar los bichos, si te tienes que poner con ello, es para un poco más adelante.

------------------------

La inicialización de las comidas por pantalla se hace en base a asignar tres valores por cada una (sí, el numerito se corresponde con el número de la pantalla siendo la A5 la númrero 0 y la F4 la última, la 47):

items_comida[0].tipo = ITEM_FRUTA;
items_comida[0].h = 19;
items_comida[0].v = 15;

Los posibles valores para "tipo" son éstos:

TEM_HUEVO
ITEM_COCKTAIL
ITEM_FRUTA
ITEM_QUESO
ITEM_TARTA
ITEM_HELADO
ITEM_TE
ITEM_SOPA

Cuando tengamos eso ya podré quitar los cuadrados azules feos ésos que sólo sirven de ese modo para saber dónde se está pintando el bloque encargado de tapar la comida (ya te conté que como siempre aparecen en la misma posición los integré como parte del fondo y lo que hago es borrarlas dibujando tiles negros encima - azules provisionalmente - cuando se cogen).

--------------------------

De los ports... a saber. Trataré de dejar el código lo más limpito posible cuando esté acabado, pero obviamente sí habrá que hacer cambios en mayor o menor grado. Y saber cómo se programa para las otras plataformas también

La pirmera está bien (casi), vertical 17 y horizontal a mí me sale 13; hay que contar el primer tile como cero. El segundo h=20, v=5. Pero mientras el error sean de uno o dos tiles es sencillo verlo cuando se esté probando la pantalla y a ojo ya se sabe si hay que modificar ligeramente los valores. Vamos, que así vale. Si el editor gráfico que utlilices tiene opción de mostrar rejilla (que supongo que sí), si se configura a 8 pixels horizontal y verticalmente es fácil sacar las cuentas.

Lo de identificar las pantallas en plan numeración del juego de los barcos dentro del código, como poder se puede. Ahora que en lugar de resultar práctico sería todo lo contrario, a la hora de hacer cálculos se me iba a formar una marimorena del copón En cualquier caso tomando como referencia el mapa que me pasaste y contando de izquierda a derecha y de arriba a abajo creo que no tiene pérdida (la primera fila de la 0 a la 7) y la última pantalla es la 47 (porque el cero cuenta).

Como te comenté de que estaba un poco saturado, he andado con otros temas para darme tiempo a despejarme antes de meterle mano a conciencia de nuevo (de obras por casa principalmente) En estos últimos días he tenido el juego parado aunque intercambiando un par de correos con Pocket_lucho me he aclarado con respecto a la trabajera que me estaba dando el borrado de sprites. A ver si ya puede ser que me pueda poner con el elevador solucionado eso.

Lo dicho, lo de las comidas (ítems) me vale, mientras sea aproximado, a ojo se puede ver luego rápido si hay que modificar sumando o restando uno o dos tiles. Si es exacto mejor

A ver si a no mucho tardar puedo mandarte un nuevo binario que se vaya pareciendo más al original de Spectrum. En eso estamos.

llevo un ratillo liado con el código, bastante más rato que en los últimos días pero para nada tanto como los primeros y el borrado de sprites ya parece que va marchando. Estuve repasando los ítems de las comidas y me dio lugar a tomar algunas notas, por cierto que a casi todos tuve que restarle uno tanto a la h como a la v (el cero cuenta )


APUNTES REVISANDO LOS ITEMS DE TIPO COMIDA (el numerito es el de la pantalla en la nomenclatura 0 a 47 del código)

2 revisar borrado (¿código?) <-- Esto es cosa mía
28 falta por comprobar
30 mal hecha (revisar el BMP ¿descuadrado?)
29 falta por comprobar
32 mal hecha (revisar el BMP ¿descuadrado?)
33 no está pintado el ítem
35 falta por comprobar
36 mal hecha (1 pixel arriba-abajo)
39 falta por comprobar
41 mal hecha (revisar el BMP ¿descuadrado?)
44 huevo mal colocado en el BMP, (1 pixel arriba)

Échale un ojo a las que he marcado como "mal hecha", tiene pinta que hay que echarlas un píxel arriba o un píxel abajo; se nota por ejemplo en que el personaje anda ligeramente por encima o debajo del suelo y detecta todos los tiles del escenario como bloques no traspasables.

Lo de la hélice se tuvo en cuenta. Dejé la parte del centro como escalera y lo que viene a ser las hélices en sí, eso lo pinto luego por encima del personje usando sprites (lo mismo que para la parte que ahora se ve "mellada" en la cabina). Controlado de esa parte.

No te asustes con el parpadeo que aún queda ajustar bien las paletas para conseguir algunas cosillas pendientes (ahora, que una cosa así para la inmunidad -dado que no tenemos los bordes del spectrum- yo lo veo bastante resultón)

Y hasta aquí el empujoncito de hoy. Aguanta un poco más antes de anunciar que estamos con esto; ya está más o menos presentable pero quiero también anunciarlo en el foro de fasebonus.net. Lo repaso entre mañana y pasado y ya damos el toque al personal en los respectivos sitios.

PD: sí, los bichos siguen "haciendo el Michael Jackson" cuando les da la gana, de momento les voy a seguir dando cuartelillo que me interesa más avanzar por otros lados.

PPD: como he cambiado y creado un par de archivos nuevos... la función cargaTransportadores() está en map.h Échale un vistazo a tilemap.h para que veas como se inicializan los bichos correspondientes a cada pantalla. Están casi todos implementados (a falta de una docena más o menos), si te atreves puedes probar también por ahí y me mandas cualquier cosa que pruebes. Los nombres de las funciones que cargan a los enemigos no son lo más clarificadoras que se pudiese esperar, pero es que hay a cada cosa rara...

Me siguen faltando unos cuantos, puedes si acaso, sustituirlos por algunos de los que sí están hechos y que se comporten del mismo modo tomando nota de que ésas pantallas habrá que modificarlas:

u8 enemigo_afroma(u8, u8, s16, u8, u8, u8); //Gnomo con pelo a lo afro
u8 enemigo_antena(u8, u8, s16, u8, u8, u8); //Parabólica maligna
u8 enemigo_arana1(u8, u8, s16, u8, u8, u8); //Araña maligna
u8 enemigo_aros00(u8, u8, s16, u8, u8, u8); //Aros malignos
u8 enemigo_arosca(u8, u8, s16, u8, u8, u8); //Especie de tornillo vertical que vuela
u8 enemigo_balon0(u8, u8, s16, u8, u8, u8); //Balón con hélice
u8 enemigo_barman(u8, u8, s16, u8, u8, u8);
u8 enemigo_bicefa(u8, u8, s16, u8, u8, u8); // Dragon bicefalo
u8 enemigo_bicho9(u8, u8, s16, u8, u8, u8);
u8 enemigo_bielas(u8, u8, s16, u8, u8, u8);
u8 enemigo_bipedo(u8, u8, s16, u8, u8, u8);
u8 enemigo_blitze(u8, u8, s16, u8, u8, u8);
u8 enemigo_buzo00(u8, u8, s16, u8, u8, u8);
u8 enemigo_cabeza(u8, u8, s16, u8, u8, u8); //Cabeza de la pantalla A7, creo
u8 enemigo_cannon(u8, u8, s16, u8, u8, u8); //Cañón
u8 enemigo_caraco(u8, u8, s16, u8, u8, u8);
u8 enemigo_carro1(u8, u8, s16, u8, u8, u8); //Carretilla como las de las vías de trenes a tracción manual
u8 enemigo_chirin(u8, u8, s16, u8, u8, u8);
u8 enemigo_chispa(u8, u8, s16, u8, u8, u8); //Sprite chico, birrioso, que parece una chispita
u8 enemigo_comput(u8, u8, s16, u8, u8, u8);
u8 enemigo_cosa01(u8, u8, s16, u8, u8, u8);
u8 enemigo_cosa03(u8, u8, s16, u8, u8, u8);
u8 enemigo_cucara(u8, u8, s16, u8, u8, u8);
u8 enemigo_diaman(u8, u8, s16, u8, u8, u8); //Gemas de la pantalla A4, creo
u8 enemigo_donna0(u8, u8, s16, u8, u8, u8);
u8 enemigo_girosc(u8, u8, s16, u8, u8, u8);
u8 enemigo_hang01(u8, u8, s16, u8, u8, u8); //Bicho colgante del techo de la pantalla 1
u8 enemigo_helico(u8, u8, s16, u8, u8, u8);
u8 enemigo_jetpac(u8, u8, s16, u8, u8, u8); //He puesto jetpack, porque el enemigo vuela, pero tiene toda la pinta de una lancha con turbina
u8 enemigo_libelu(u8, u8, s16, u8, u8, u8); // Libélula
u8 enemigo_manodo(u8, u8, s16, u8, u8, u8); // Mano doble creepy
u8 enemigo_marcia(u8, u8, s16, u8, u8, u8);
u8 enemigo_medusa(u8, u8, s16, u8, u8, u8);
u8 enemigo_oni000(u8, u8, s16, u8, u8, u8); // Cara de demonio oni
u8 enemigo_pato00(u8, u8, s16, u8, u8, u8);
u8 enemigo_plumbe(u8, u8, s16, u8, u8, u8); // Robot con patas de desatascador
u8 enemigo_poseid(u8, u8, s16, u8, u8, u8); // Poseidon
u8 enemigo_r2d200(u8, u8, s16, u8, u8, u8); // R2D2 venido a menos
u8 enemigo_rabano(u8, u8, s16, u8, u8, u8); //Es un rábano que vuela, no hay vuelta de hoja
u8 enemigo_saturn(u8, u8, s16, u8, u8, u8); // Saturno bonsai
u8 enemigo_sirena(u8, u8, s16, u8, u8, u8); // Sirena
u8 enemigo_soldad(u8, u8, s16, u8, u8, u8); // Soldadito de plomo / guardia británico
u8 enemigo_tijera(u8, u8, s16, u8, u8, u8); // Tijeras
u8 enemigo_torped(u8, u8, s16, u8, u8, u8); // Torpedo
u8 enemigo_pelica(u8, u8, s16, u8, u8, u8); // Pelícano
u8 enemigo_rabano(u8, u8, s16, u8, u8, u8); // Rábano mecánico volador
u8 enemigo_volado(u8, u8, s16, u8, u8, u8); // Artilugio volador

Por cada pantalla se hace de la siguiente forma. Ejemplos:

PANTALLA A1 (4):

enemigo_cucara( 3, 8, SPEED3, 6, PALETA_BASICA, NUEVO);
enemigo_cucara(16, 8, SPEED3, 6, PALETA_SPRITES1, COPIA);
enemigo_cucara(26,10, SPEED3, 6, PALETA_SPRITES2, COPIA);
enemigo_torped( 5,11, SPEED2, 4, PALETA_BASICA, NUEVO);
enemigo_torped(10,13, SPEED2, 4, PALETA_SPRITES2, COPIA);
enemigo_torped(15,12, SPEED2, 4, PALETA_SPRITES3, COPIA);
enemigo_torped(20,14, SPEED2, 4, PALETA_SPRITES1, COPIA);
enemigo_hang01(26,18, SPEED2, 2, PALETA_BASICA, NUEVO);
nomasEnemigos();

Puedes hacerlo directamente sobre tilemap.h.

Los atributos de las funciones son

nombre_de_la_funcion(posicion_horizontal, posicion_vertical, velocidad, numero_de_tiles_que_puede_moverse_antes_de_girarse, una_de_las_cuatro_paletas, si_es_el_primer_bicho_de_esa_clase_o_es_un_"clon")

Si no te aclaras con algún nombre (que vendrá a ser lo más comprensible del mundo), invéntate tú el nombre que te parezca para la función y después ya se hace una búsqueda y un "replace" para poner el nombre que corresponda según las funciones implementadas.


Empecé con el ascensor, pero llevo unos diítas que llego a la casa reventado y encima con una migraña la mar de porculera que me tiene un tanto apartado del Code:block. El primer piso lo baja bien, al bajar otro se me descalabra el pobre Dan :S Ahí estamos. Para el próximo mensaje ya meto las pantallas nuevas y te comento.

Acabo de ver la wiki. ¿Te animas tú a ponerle los nombres? Yo es que tengo una inventiva un poco abstracta (o no) y por ejemplo el último de la lista se inicializa en el código con la función enemigo_rabano(). El planeta con enemigo_saturn(), el pato enemigo_pato00()... si tenemos la lista esa con los nombres ya te puedo hacer la relación entre los nombres que tengan en la lista y los nombres de las funciones en el código (he estado usando seis caracteres para los nombres, pero sólo por comodidad a la hora de programar, no tiene ninguna otra razón).

Hace nada me encontraba sustituyendo el sgdk último con el que no tenía webs de compilar mi código por el anterior con el que no me daba problemas. Pues ahora ni con el anterior. Tirándome de los pelos (más canas que pelos porque a uno le ha tocado ser precoz capilarmente hablando). Como para que te funcionase a ti, cuando en mi propio ordenador me hace estas cosas.
Pues nada, a ir trocito a trocito, pegando de nuevo para localizar los fallos. Por lo menos más pulido va a estar. Mi deseos (aparte de que para la Retroencounter estuviese sí o sí) es tenerlo listo para liberarlo en navidades que son unas fechas propicias para estos temas. Los últimos progresos era con el ascensor a medio hacer que se volvía fantasmagórico en el tercer piso además de que tenía a Dan dando saltitos todo el rato.
Pues eso, que noticias no especialmente buenas. Otra vez tengo el último sdgk instalado y bien instalado porque los ejemplos compilan bien. Toca ir pasito a pasito recomponiendo el código anterior par que funcione de nuevo. Menos mal que "lo gordo" (la mayor parte de las comeduras de cabeza) ya estaban solventadas.
A ver si se me da rápido. Hasta la próxima, con mejores noticias por descontado.