Mira que sabía que lucho iba a salir con ésas... yo no fui el de la propuesta en todo caso :P
Bueno, esto para jordigahan. Qué te parece que pidas reabrir el hilo que creaste para dejar ahí colgado el "diario de desarrollo". Si lo puede pillar una tercera persona (que es lo que me gustaría XD) posiblemente le sea útil. Y a quien se aburra también.
Diario de desarrollo (correos/instrucciones realbrucest->jordigahan):
Los tiles y las herramientas Jueves 28 de julio de 2011
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.
Lo que saques del imagenesis Jueves 28 de julio de 2011
...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)
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.
Sudando píxels Sábado 30 de julio de 2011
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.
Tiles e imagenesis Domingo 31 de julio de 2011
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.
Minirevisión de la última función Martes 2 de agosto de 2011
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
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á.
Tarea observadora Miércoles 3 de agosto de 2011
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 :P 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.
Tareas (empieza la faena) Sábado 6 de agosto de 2011
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é"):
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:
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:
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.
Mierder! Sábado 6 de agosto de 2011
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...
Creo que ahora sí Domingo 7 de agosto de 2011
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.
Al lío marinero Jueves 11 de agosto de 2011
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.
Transportadores funcionando Jueves 11 de agosto de 2011
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
Colisiones no tan tan pencas Sábado 13 de agosto de 2011
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 ;)
Casi XD Sábado 13 de agosto de 2011
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 XD --> 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.
Pantallas con escaleras Domingo 14 de agosto de 2011
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.
Pantallas y bichos en proyecto Martes 16 de agosto de 2011
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.
Viento en popa, o casi Sábado 20 de agosto de 2011
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 XD
"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 :P
Tareas sin compilador Lunes 22 de agosto de 2011
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.
Casi todo el mapeado Martes 23 de agosto de 2011
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á XD (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.
El atasco con los bichos y algunas cosillas más Viernes 26 de agosto de 2011
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 :P Ejemplo de la carga de dos de los bichos de la pantalla inicial:
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):
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 XD
De break Jueves 1 de septiembre de 2011
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 XD 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 :P
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.
A poquito a poco Sábado 3 de septiembre de 2011
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 XD) :P
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 XD (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...
Enemigos Sábado 10 de septiembre de 2011
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:
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.
¿Los nombras tú? Lunes 19 de septiembre de 2011
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).
Ojú! Sábado 8 de octubre de 2011
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.
Vamos, esto ni los de Rockstar con el Max Payne 3 ^_^U
Felicidades! Puedes comentar un poco por encima como lo has hecho ? Un poco tu experiencia (que herramientas has usado, dificultades que te has encontrado, etc.).
Pues problemas todos los que se te puedan pasar por la cabeza, desde aprender la arquitectura del sistema en si, como programarlo... la dificicultad en si de hacer en juego, no es solo mostrar graficos y controlar el pad, eso es lo de menos, hay muuuuucha tela logica detrás con miles de cosas que pueden fallar. No las he contado para no asustarme, pero las 20000 lineas de codigo no me las quita nadie!
Lo que he usado... las librerias son las sgdk aunque he acabado un poco harto de ellas, photoshop para los graficos, algo el imagenesis para la creación de los mapas gráficos... y ya, poca cosa la verdad.
El sgdk le tengo un poco de mania... ahora estoy modificandolas y haciendome unas mas personificadas, de esas serán los tutos y con eso se hará lo próximo que haga, si hago algo xD
pocket_lucho escribió:El sgdk le tengo un poco de mania... ahora estoy modificandolas y haciendome unas mas personificadas, de esas serán los tutos y con eso se hará lo próximo que haga, si hago algo xD
ya que bruce se ha rajado, tengo un juego que te esta esperando
Buenas, hoy me di cuenta, q tengo dos tutoriales que habia echo para mi web, que no estan en este hilo, a ver si este domingo tengo tiempo, y los cuelgo
saludos
Zetilla escribió:Joder! Que gran hilo!
Que lastima que muchas de las fotos estén caídas.
Pero genial genial!!!
Gracias, y gracias por avisar de las fotos, no me habia dado cuenta
Arregladas todas
Saludos, y disculpen por no entrar al hilo seguido
theelf escribió:Buenas, hoy me di cuenta, q tengo dos tutoriales que habia echo para mi web, que no estan en este hilo, a ver si este domingo tengo tiempo, y los cuelgo
Básicamente he traducido el original de la web de sgdk aportando poco más de cosecha propia. Como soy yo el que lo ha hecho no sé hasta que punto resulta o no autoexplicativo, por lo que cualquier comentario, sugerencia, edición o lo que sea será bien recibido.
Gracias por los tutos, está muy curioso programar para la Mega y me habéis enganchado.
Tengo una duda que me tiene muy atascado: estoy con el SGDK y no sé cómo meter los sprites, en este caso un bmp con todos los sprites del jugador al igual que en el tutorial de la web, el de los sprites de Sonic. Necesito alguna herramienta para convertir las imágenes a 16 colores (con Gimp no lo encuentro y el MSPaint me lo deja muy cutre) y demás características compatibles con la Mega. Además necesito editar su paleta para las transparencias. He probado con el imaGenesis pero aunque ponga 4bpp el compilador me dice que no es 4bpp...
He puesto un post similar en su foro pero espero que me puedan ayudar mejor aquí en el idioma de Cervantes. Saludos.
Hola tio! ¿con que sistema lo intentas meter? Yo te recomiendo convertirlos con imagenesis, para que sean compatibles, yo uso photoshop, tienen que ser color indexado, 16 colores y grabarlo como 4 bits, con eso te deberia ir.
pocket_lucho escribió:Hola tio! ¿con que sistema lo intentas meter? Yo te recomiendo convertirlos con imagenesis, para que sean compatibles, yo uso photoshop, tienen que ser color indexado, 16 colores y grabarlo como 4 bits, con eso te deberia ir.
Buenas colega. El imagenesis ya te digo, lo pongo a 4bpp y el SDGK me lo rechaza por que no es 4bpp. El photoshop no lo tengo, he probado con Gimp a 16 colores y el compilador me dice que el header del bmp no es compatible o algo así...
EDITO: ya he resuelto el problema gracias a la ayuda en el foro oficial. Cuando lo tenga un poco más currado lo pondré en el hilo del SGDK o en este, por si le sirve de ayuda a alguien. Por cierto el hecho de que haya 2 hilos tan parecidos y con cosas tan comunes me está liando un poco, no sé donde postear las cosas
muy interesante el tuto, yo no tngo nidea de programar, ¿me recomendais algun libro para aprender lo basico para luego intentar hacer alguna cosilla en la mega?
Despues de muchos quebraderos de cabeza, y aunque algunos ya lo sabran dejo aqui la info por si a alguien le sirve de algo...
Si queremos usar fuentes propias (tiles) con paleta de colores y poder escribir como si fuese la fuente que ya trae en memoria:
- "ABCDEFGHIJKLMNOPQRSTUVWYXZ" 26 tiles que van alojados en la posicion 65 que se solapan encima de las mismas letras que ya trae por defecto en memoria.
loadtiles text26,26,65
- la paleta que usa para la fuente siempre es la 0, asi que podemos reservarla para esto si no utiliza un color plano.
- "0123456789" 10 tiles que van alojados en la posicion 48
¡¡Pues me acaba de dar un ánsia enorme por volver a casa y empezar a probar esto!!
Os iré siguiendo. Muchas gracias por el esfuerzo, los tutoriales y demás. Yo he programado algún jueguecillo que otro con la librería SDL para PC, y alguna cosa en Flash, y tenía pendiente buscar cómo se hacían cositas para la Megadrive.
Ahora ya, visto lo visto en este hilo, no tengo excusa.
¡Sólo daros las gracias por el curro que os pegáis!
jebiman escribió:¡¡Pues me acaba de dar un ánsia enorme por volver a casa y empezar a probar esto!!
Os iré siguiendo. Muchas gracias por el esfuerzo, los tutoriales y demás. Yo he programado algún jueguecillo que otro con la librería SDL para PC, y alguna cosa en Flash, y tenía pendiente buscar cómo se hacían cositas para la Megadrive.
Ahora ya, visto lo visto en este hilo, no tengo excusa.
¡Sólo daros las gracias por el curro que os pegáis!
Si ya controlas en C con SDL, veta a por el SGDK de cabeza, ánimo!!
O´Neill escribió:muy interesante el tuto, yo no tngo nidea de programar, ¿me recomendais algun libro para aprender lo basico para luego intentar hacer alguna cosilla en la mega?
A mi en una ocasion me recomendo theelf el libro BASIC BASICO
Buenas por estos lares gente, a ver si alguno me podéis ayudar. La cosa es que quería usar el mando de 3 botones de la mega con una fpga, tengo el pinout y tal, pero en la fpga necesito configurar la tasa a la que tiene que recibir esta, sin embargo no encuentro por ningún lado la del mando. ¿Alguien la sabe o algo? Saludos
AkrosRockBell escribió:Buenas por estos lares gente, a ver si alguno me podéis ayudar. La cosa es que quería usar el mando de 3 botones de la mega con una fpga, tengo el pinout y tal, pero en la fpga necesito configurar la tasa a la que tiene que recibir esta, sin embargo no encuentro por ningún lado la del mando. ¿Alguien la sabe o algo? Saludos
Los sitches de los mandos SEGA se conectan a la consola en paralelo, creo que era cruceta+B+C sin multiplexar, con el mando de 3 botones + Start va multiplexado.
Que necesitas saber, el timing, cuantos ciclos maquina ocupa el "scaneo" del puerto de mando?
Cual es el escenario que quieres simular? si se puede saber si pretendes emular el comportamiento de la Megadrive, te recomiendo revisar codigos fuente de emuladores
El pinout lo tengo, lo que tengo que hacer es un jueguecillo con una fpga spartan3, de manera que para configurar la recepción necesito la tasa en baudios o similar a la que se mandarian los datos del mando a la fpga, para así poder recibir todo sin problemas. Eso es lo que me falta, aunque lo mismo uso una palanca arcade de recre y un par de botones y me monto un mando arcade y utilizó los puertos de la fpga, que sería más sencillo, ya que puesto que necesito una alimentación de 5V voy a necesitar tener que tocar una plaquilla o montar una de prueba igualmente
Eso he pensao, pero como tengo que recibir los 16 bits que me mande el mando y configurar el puerto de la placa, pues los profesores de la asignatura me la están pidiendo. De todas maneras el puerto que viene con la spartan no me sirve por la dichosa alimentación de 5V, creo que al final usaré un stick y las entradas de los puertos de expansión y programo un bloque de control de errores y ya está
Aqui hay algo de información sobre como leer los joypads a bajo nivel (como se hace en la MD en assembler):
Tomando como referencia esta imagen (no pude encontrar una mejor): tienes que tener las líneas D0-D5 configuradas como entradas y SEL como salida. Para empezar a leer, solo pon un 0 en la línea SEL, espera*, y de los datos que leas, solo D5 y D4 (Start y A, respectivamente) te servirán (los datos vienen invertidos, recibiras un 0 si están pulsados). Luego cambia a 1 a SEL, espera*, y podras leer todos los datos restantes (de D5 a D0: C, B, Derecha, Izquierda, Abajo y Arriba, nuevamente invertidos).
*la espera es de dos NOPs en la MD (unos 8 ciclos de reloj)
Yo he hecho varios juegos en una spartan 3e y en uno de ellos le metí un musicbox y el mando de la snes que tiene una comunicación tipo SPI. Por lo que veo el mando de la megadrive es mucho más sencillo de implementar aquí tienes como funciona el protocolo de 3 botones y 6, espero que te sirva de ayuda.
P.D. Ten cuidado con los botones que por lo visto no tienen nigún sistema antirebotes (not debounced), y te pueden dar varias transciones 0-1, mira esto:=> http://www.stanford.edu/class/ee183/han ... amepad.pdf Para evitar eso, cuando obtengas la primera transición, espera varios ciclos de reloj sin aceptar nuevas transiciones.¿cuantas? depende de tu clk
Pues lo que me has puesto tiene muy buena pinta, y voy a comentarlo, que se me han cegao con los baudios y no se lo quitan de la cabeza. Muchísimas gracias
Es que no entiendo el porqué de los baudios, no es una comunicación síncrona, en ningún momento introduces un CLK al mando como por ejemplo se hace en el de la snes. La comunicacion es asícrona, así que simplemente puedes "mirar el estado" de las líneas cuando quieras. Por lo que veo el típico juego muestrea a 60z ( o más rápido, com veas), así que, asumiendo que usas vhdl, haz un proceso que divida el reloj principal hasta los 60Hz, y este reloj lo usas como control en otro proceso que sea para comprobar el estado de las líneas y listo.
Si necesitas más ayuda dímelo, la verdad que me has picado el gusanito lo mismo lo hago yo tb cuando tenga tiempo
Buenas a todos, soy el compi de AkrosRockBell, los que vamos a hacer el juego en la fpga con el mando de la megadrive. Entre que no podíamos conectar el mando directamente al puerto rs232 y luego que nos hemos liado tela con la transmisión, ya teníamos decidido usar un pad normal pero gracias a vosotros ya lo vemos claro.
soyjavy escribió:Es que no entiendo el porqué de los baudios, no es una comunicación síncrona, en ningún momento introduces un CLK al mando como por ejemplo se hace en el de la snes. La comunicacion es asícrona, así que simplemente puedes "mirar el estado" de las líneas cuando quieras. Por lo que veo el típico juego muestrea a 60z ( o más rápido, com veas), así que, asumiendo que usas vhdl, haz un proceso que divida el reloj principal hasta los 60Hz, y este reloj lo usas como control en otro proceso que sea para comprobar el estado de las líneas y listo.)
Eso es lo que decia, que no hay ningun timing de acceso al puerto de mandos, solo hay que leer estado en el instante que el programa "mire" ahi.. Otro tema es el de los 5v del mando, lleva un CI TTL y los necesita... siempre puedes substituirlo por el equivalente Low Voltage y ya te sirve o si solo vas usar 2 pulsadores, usar un mando de SMS que no lleva multiplexor, son solo contactos
Yo tampoco entiendo lo de los baudios, pero esta gente estaba erre que erre, pero como qué se lo voy a tener que explicar de otra manera... Mando de MS no tengo, si encontrase uno en el cash estaría bastante bien, pero nunca he visto uno por esos lares De todas maneras gracias a los dos, nos estabamos ahogando un poco en un vaso de agua la verdad.
Welcome. Una aclaración sobre los baudios. Baudios realmente es una unidad de medida. Cuando decimos 9600 bauds estamos diciendo que mandamos 9600 símbolos por segundo. Pero hay que tener en cuenta que estos símbolos pueden estar compuestos por 1 solo bit o quizás más. Resumiendo, aunque sea posible que 9600 bauds sean 9600 bits/s (rs-232), en otros muchos casos no. El mando de la megadrive no tiene nada que ver con rs232 quizás el conector parecido De todas maneras google es siempre tu amigo cuando quieres desarrollar algo.
P.D. tener cuidao con el rs232 que suele funcionar con tensiones superiores a 5 v, normalmente entre 5-15v
En sentido de hacerma una simple foto como esa, pero que se me vea a mi o con amigos. Es como curiosidad. Da igual que los gráficos se vean a 16 bits, me llama la atención. Si hay que recurrir a Photoshop CS6 a manejar ciertas imágenes para adaptarlo, se hará.
En sentido de hacerma una simple foto como esa, pero que se me vea a mi o con amigos. Es como curiosidad. Da igual que los gráficos se vean a 16 bits, me llama la atención. Si hay que recurrir a Photoshop CS6 a manejar ciertas imágenes para adaptarlo, se hará.
¿Hay posibilidad de hacer lo que quiero?
Saludo.
Pues no te has leido el tuto...
Porque es el primer paso del tutorial mostrar graficos en pantalla, eso en unos minutos lo tienes hecho
![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
