Diario de un desarrollo (Mega Drive)

Archivado
Aquí iré colocando algunas cosas relacionadas con un nuevo proyecto, pero también apuntes y diferentes efectos gráficos que se me ocurran.

Empiezo con algo sencillo.

MAPA DE COLISIONES (los gráficos del sprite y el plano frontal son de prueba para el test)


He montado un sistema de colisiones en diferentes formatos: 16x16, 32x32 (el del vídeo), etc.. con tal de reducir un poco el espacio del mapa en la rom, aunque por defecto será 16x16, luego ya se aplicará compresión o otros métodos.

Se hacen 2 comprobaciones de un máximo de 3 puntos, para el eje vertical y horizontal, altero el orden de la comprobación con tal de poder deslizar los objetos libremente en todas las direcciones. (y para otras cosas como andar por el techo)

Obviamente solo se comprueban colisiones cuando hay movimiento del personaje (el del scroll no afecta), por otro lado, no hay multiplicaciones ni divisiones en todo el programa.

Para el desplazamiento del scroll he montado una función propia, no me gusta demasiado la de MAP que trae la SGDK, nota: No hay atributos en este test, la cascada debería estar por delante del sprite.

El fondo tiene un par de detalles más interesantes, el agua usa deformación de tipo S (112 líneas), uso una tabla precalculada... intenté calcularlo en tiempo real con una función que usaba en otros proyectos y se fue a los 4 fps [mad] , luego de pensar en un código más adaptado a las características de la consola lo dejé en un 1% de uso de CPU (aprox. en base a diferentes mediciones), usa un semáforo (30 fps), en el par se refresca la VDP, en el impar se prepara la tabla para el siguiente frame.

Al no moverlo verticalmente puedo omitir las partes de colores únicos y no actualizarlas, pero la idea es moverlo todo, la cascada es material básico, se rotan los colores.

Las nubes pasan por detrás de la montaña (plano fondo), pero seguro que es fácil adivinar el truquillo que usé ;)

El tipo de juego en el que estoy trabajando es un Metroidvania.
Pilló sitio
Como aún no puedo poner imágenes os dejo algunos detalles y contenido que tendrá el juego:

RESUMEN
- Avance no lineal
- El personaje principal es un soldado con exoesqueleto (afortunadamente no un cubito de hielo [360º] )
- 5 planetas, cada uno con ambientación y mecánicas distintas
- Portales interconectados para acortar zonas, escape del planeta en zonas despejadas (en lugar de puntos de recogida)
- Hub para acceder a los planetas desde el exterior
- Mapa accesible mediante pausa, porcentaje de completado por planeta y global, objetivos, etc
- Menú para gestionar powerups y mejoras, seleccionar, activar/desactivar..
- 3 slots de guardado, no podrá completarse en una sentada
- Contenido extra, un poco marca de la casa para quién conozca mis proyectos anteriores
- Modo Boss Rush
- Otro modo de dificultad (se desbloquea al completar)
- 4MB de espacio, en principio, más si es necesario, cada planeta tendrá diferentes secciones, múltiples fondos por planeta

Y aquí otro mini test, nota: el desarrollo lo tengo más avanzado, pero iré posteando poco a poco nuevo contenido.

TEST RGB
https://i.imgur.com/NtXKx4L.gif

La Mega solo tiene una paleta de 512 colores, lo cual equivalen a 8 valores por cada componente RGB, he creado una simple función para añadir o restar un valor por componente a cada paleta o rango de colores por separado, sin voltear los topes.

Es material básico pero permite:
- Fundidos a negro, o de negro a pantalla cuando se aplica a las 4 paletas sin congelar la acción (no me convencía la que viene en la SGDK)
- Respeta las rotaciones de paleta existentes (ej. la cascada animada)
- Brillos para explosiones, a blanco, rojo..
- Efectos de alarma, pantalla a rojo en escala RGB
- Efectos en sprites, como cuando hacen dash, dejan replicas del sprite en diferente tono
- Atardecer y otros, pero no me convence para eso, prefiero configurar a mano como cambian los colores en cada tramo

La lista es más larga, pero se entiende que quiero hacer buen uso de bastantes efectos.
Vamos ahi joderrrr!!! [beer]

Ya era hora que salieras del armario [jaja]
Habrá que comprar esto no?
@BoMbErLiNk

Te lo pongo pa que lo vean, que como eres nuevo me imagino que de momento no puedes poner la captura:

Imagen
BoMbErLiNk escribió:TEST RGB
https://i.imgur.com/NtXKx4L.gif

La Mega solo tiene una paleta de 512 colores, lo cual equivalen a 8 valores por cada componente RGB, he creado una simple función para añadir o restar un valor por componente a cada paleta o rango de colores por separado, sin voltear los topes.

Es material básico pero permite:
- Fundidos a negro, o de negro a pantalla cuando se aplica a las 4 paletas sin congelar la acción (no me convencía la que viene en la SGDK)
- Respeta las rotaciones de paleta existentes (ej. la cascada animada)
- Brillos para explosiones, a blanco, rojo..
- Efectos de alarma, pantalla a rojo en escala RGB
- Efectos en sprites, como cuando hacen dash, dejan replicas del sprite en diferente tono
- Atardecer y otros, pero no me convence para eso, prefiero configurar a mano como cambian los colores en cada tramo

La lista es más larga, pero se entiende que quiero hacer buen uso de bastantes efectos.
otro que pilla sitio por aqui y aprovecha para pedir version para snes !!
Es impresionante @BoMbErLiNk !
Con ganas de probarlo ya!
Saludos!
Mucho ánimo, ese resumen pinta muy bien.
Muy interesante! Animo y que no decaiga.
Gracias por los ánimos [360º], el progreso va bien, pongo 2 cosas más que añadí recientemente:

ZOOM
https://i.imgur.com/0nzlyH3.gif

Un test de scaling sobre sprites, hay un jefe que lanzará bolas de energía desde el fondo (un enano con un propulsor, que a veces lo desmonta y usa como cañon de energía), en una intro también quiero hacer zoom pero quizás usando un plano de scroll, viniendo de Fenix/Bennu es algo que se he echa en falta [boing]

La función consume muchos sprites, así que como mucho saldrán uno o dos a la vez, dependiendo del tamaño, el cubo por ejemplo llega a 72x72, cambiando el tamaño de 2 en 2 se camufla un poco la falta de precisión, a partir de 2 muestras de tamaño 2X y 3X se consiguen 48 transiciones.

BOTÓN RESET
https://i.imgur.com/vyfoqHa.gif

Cuando pulsas el botón reset no se borra la memoria, solo se reinicia el programa, he creado 2 modos, uno es un reinicio normal y el otro lo he estructurado para ser capaz de retomar el punto actual dentro del juego, es un atajo que hice para ver que el scroll arranca bien desde cualquier punto de la pantalla.

Para encontrar uno de los secretos del juego, una de las formas será pulsar reset en un sitio concreto, pero habrá pistas sobre donde hacerlo.
BoMbErLiNk escribió:Gracias por los ánimos [360º], el progreso va bien, pongo 2 cosas más que añadí recientemente:

ZOOM
https://i.imgur.com/0nzlyH3.gif

Un test de scaling sobre sprites, hay un jefe que lanzará bolas de energía desde el fondo (un enano con un propulsor, que a veces lo desmonta y usa como cañon de energía), en una intro también quiero hacer zoom pero quizás usando un plano de scroll, viniendo de Fenix/Bennu es algo que se he echa en falta [boing]

La función consume muchos sprites, así que como mucho saldrán uno o dos a la vez, dependiendo del tamaño, el cubo por ejemplo llega a 72x72, cambiando el tamaño de 2 en 2 se camufla un poco la falta de precisión, a partir de 2 muestras de tamaño 2X y 3X se consiguen 48 transiciones.

BOTÓN RESET
https://i.imgur.com/vyfoqHa.gif

Cuando pulsas el botón reset no se borra la memoria, solo se reinicia el programa, he creado 2 modos, uno es un reinicio normal y el otro lo he estructurado para ser capaz de retomar el punto actual dentro del juego, es un atajo que hice para ver que el scroll arranca bien desde cualquier punto de la pantalla.

Para encontrar uno de los secretos del juego, una de las formas será pulsar reset en un sitio concreto, pero habrá pistas sobre donde hacerlo.


Lo segundo que comentas me parece bastante interesante, no recuerdo ningún juego de MD que hiciera un uso similar. De hecho, creía que sí se borraba la memoria al pulsar reset [Ooooo]
@BoMbErLiNk (¿Bombergames anteriores trabajos?) pinta bien lo que comentas... Podrías enseñar algo más, diseño de algún sprite, captura de escenario real, etc? Por hacernos una idea más concreta, no tengo claro si los test son sólo ejemplos de pruebas o gráficos sacados directamente del juego, ya que de venir de parte de uno de los creadores del SOR Remake, me llama la atención la diferencia de estilos entre ambos [carcajad]
Juaki escribió:Lo segundo que comentas me parece bastante interesante, no recuerdo ningún juego de MD que hiciera un uso similar. De hecho, creía que sí se borraba la memoria al pulsar reset [Ooooo]


El X-Men así que recuerde, pero estás obligado a presionarlo para poder continuar.


AtomicRobot-nik16 escribió:@BoMbErLiNk (¿Bombergames anteriores trabajos?) pinta bien lo que comentas... Podrías enseñar algo más, diseño de algún sprite, captura de escenario real, etc? Por hacernos una idea más concreta, no tengo claro si los test son sólo ejemplos de pruebas o gráficos sacados directamente del juego, ya que de venir de parte de uno de los creadores del SOR Remake, me llama la atención la diferencia de estilos entre ambos [carcajad]


Es un popurrí para pruebas, el fondo si que pertenece al juego, el primer planeta es tropical/acuático, el plano principal es de un editor de tiles que he adaptado para Mega Drive, es de hecho el mismo mapa

El estilo gráfico creo que no decepcionara, mi intención es ir colocando cosas, dale algo de tiempo al hilo [oki]
BoMbErLiNk escribió:Es un popurrí para pruebas, el fondo si que pertenece al juego, el primer planeta es tropical/acuático, el plano principal es de un editor de tiles que he adaptado para Mega Drive, es de hecho el mismo mapa

El estilo gráfico creo que no decepcionara, mi intención es ir colocando cosas, dale algo de tiempo al hilo [oki]

Me lo figuraba [oki] Pues ánimo con el juego, falta un exponente de ese estilo en MD y lo que has explicado apunta alto, y parece lo tienes muy claro, además viniendo de Bombergames, a mí el hype ya se me ha activado. Eso sí, ahora en Mega hay competencia y se están desarrollando buenos juegos, espero llegue a puerto y sea un referente entre los proyectos indie. Yo también pillo sitio en el hilo [beer]
BoMbErLiNk escribió:Gracias por los ánimos [360º], el progreso va bien, pongo 2 cosas más que añadí recientemente:

ZOOM
Imagen

Un test de scaling sobre sprites, hay un jefe que lanzará bolas de energía desde el fondo (un enano con un propulsor, que a veces lo desmonta y usa como cañon de energía), en una intro también quiero hacer zoom pero quizás usando un plano de scroll, viniendo de Fenix/Bennu es algo que se he echa en falta [boing]

La función consume muchos sprites, así que como mucho saldrán uno o dos a la vez, dependiendo del tamaño, el cubo por ejemplo llega a 72x72, cambiando el tamaño de 2 en 2 se camufla un poco la falta de precisión, a partir de 2 muestras de tamaño 2X y 3X se consiguen 48 transiciones.

BOTÓN RESET
Imagen

Cuando pulsas el botón reset no se borra la memoria, solo se reinicia el programa, he creado 2 modos, uno es un reinicio normal y el otro lo he estructurado para ser capaz de retomar el punto actual dentro del juego, es un atajo que hice para ver que el scroll arranca bien desde cualquier punto de la pantalla.

Para encontrar uno de los secretos del juego, una de las formas será pulsar reset en un sitio concreto, pero habrá pistas sobre donde hacerlo.

Cito para que se vean los gifs ;)
Para el zoom puedes usar 4 sprites para el fondo del muñeco, juntarlos, y al hacer zoom separarlos. El contenido del muñeco, ojos y boca, si que puedes usar un solo Sprite e ir cambiándolo a conveniencia.
SALA DE TEST
https://i.imgur.com/YwNsA34.gif

Pues aquí traigo una sala de test al desnudo, todo lo que se ve mientras se diseña la jugabilidad y mecánicas del juego, el mapa de colisiones tiene diferentes tiles, cada uno corresponde a una función distinta:
1 - Pared (lo único que se había mostrado hasta ahora en el resto del hilo)
2 - Plataforma (se traspasa menos hacia abajo)
3..6 - Línea diagonal de 1 pixel
7 - Cuerdas, escaleras..
8..11 - Cintas deslizantes, hay 4 para diferentes tipos de velocidad, en muchos juegos antiguos las cintas son flotantes y terminan en caída, el origen está en simplificar el código, porque cuando combinas cinta con otro tiles hay que evaluar, en el juego he creado una función que evalúa el conjunto de lo que estás pisando y saca una conclusión
12 - Puertas, hay puertas que teletransportan a diferentes partes del escenario (como en este caso) o que acceden a diferentes zonas, en ese sentido estoy procurando que los tamaños exterior/interior coincidan, por otro lado no me gustan demasiado los laberintos o las puertas trampa que hacen perder tiempo, así que las puertas que teletransporten en un mismo mapa no serán muy numerosas y estarán destinadas a zonas místicas, o muy concretas.
13..16 - Línea diagonal de 2 pixel
17 - Suelo deslizante, hielo principalmente, habrá un planeta de hielo/fuego, con un núcleo inestable (lo cual invierte la física de forma intermitente y andamos por el techo).
18..22 - Daño configurable, porque a veces hay espinas que traspasan y golpean, o pinchos que solo dañan si caes encima, pero hacen de pared si vas en horizontal, veneno, lava, electricidad, puede que algunos simultáneos en un mismo nivel
23..26 - Segundo piso de la diagonal de 2 pixel

Y así hasta 255.. imagino que no rellenaré todos, pero va a haber mucha variedad, supongo que iré poniendo más salas de tests, siento no poder poner imágenes reales del proyecto aún.

En el gif también se aprecian algunos movimientos del "personaje":

- Bajar de una plataforma (me he encontrado juegos que no tienen suelo, usan plataformas de este tipo y cuando bajas te tiras al barranco [Ooooo] )

- Salto, salto prolongado (mantener) y buffer de salto, nota: El cubito salta como una catapulta, el movimiento del soldado es más pausado, controlado y suave, lo que yo llamo "buffer de salto" es que cuando estás cerca del suelo si pulsas salto lo efectúa al tocarlo, es una forma de ayudar de forma inconsciente a que los controles sean más responsivos, sí, también lo llevaba el SORR.

- Agarrarse a cornisas, aquí también me he encontrado algo peculiar, porque este tipo de acción es bastante incompatible con las plataformas, que no llevan colisión, en juegos como Jurassic Park de MD meten 1 bloque solido al principio y al fin de la plataforma, como solución barata, el resultado es que si saltas por debajo de ese bloque chocas y no subes como se supondría, es raro pero funcional, aquí no podrás agarrarte a este tipo de plataforma, ni en salientes que terminen en inclinación, ni a daños, cintas deslizadoras, hielo, etc solo en paredes sólidas.

- Deslizarse por paredes, cuando te pegas a una pared puedes deslizarte durante un corto periodo de tiempo, además de poder encadenar saltos (a lo Ninja Gaiden), todas estas habilidades obviamente se irán consiguiendo, así que al principio empezaremos resolviendo puzzles, activando interruptores, moviendo bloques para subirse y llegar más alto.. hasta poder desbloquear una nueva habilidad que no solo permita llegar a nuevos sitios, sino que agilice la exploración, por el tema del backtracking y el propio diseño de un Metroid.


@danibus
Para bolas de energía o cosas con colores planos eso que comentas sería genial [360º]

@John3d
Gracias por ir poniendo las imágenes, me olvido de quotear [oki]

@AtomicRobot-nik16
[beer]
Vaya maravilla.
DESTRUCCIÓN DE TILES Y RAM
Otra nueva entrada, en esta ocasión ya aparecen disparos, el cubito sigue rocoso a pesar de la ola de calor:
https://i.imgur.com/GzeD2vb.gif

En el juego habrán paredes, suelos y otras estructuras de diferente tipo que serán vulnerables a determinados ataques, permitiendo acceder a nuevas zonas o powerups solo al tener determinadas armas o habilidades, aquí el tile 34 se derrumba con disparos básicos.

Aunque a priori parece sencillo la SGDK no da ninguna facilidad para modificar tiles al vuelo y mantener un rendimiento razonable, así que ha tocado reescribir todas las funciones de gestión de tiles.

En que consiste la nueva implementación:
- Más rápido, un 1% de carga de CPU, en lugar de 10-20%, mi idea es tratar de garantizar 60fps estables
- Facilidad para crear tiles animados sin mermar el rendimiento, hojas de los arboles, palmeras, fuego.. y el resto de detalles del escenario que no requieran sprites
- La información de los mapas es de solo lectura, así que para destruir algo hay que llevarlo a la memoria RAM para poder actualizar los cambios, solo disponemos de unos 54KB usando la SGDK
- Bien, lo primero es la información del tile, lo segundo es la lógica del tile, ese es el que nos llevaremos, al hacer un copia a RAM podríamos comprimir los mapas a partir de ahora sin comprometer el rendimiento, calculo que todos los mapas de colisión podrían llegar a ocupar 500KB sin comprimir, así que es un detalle a tener muy en cuenta
- Matando varios pájaros de un tiro, el mapa de colisiones ahora no solo sirve para crear la lógica del nivel sino que también da instrucciones sobre que tiles han cambiado y como deben dibujarse, además al ser dinámicos ahora también pueden llamar a items o enemigos
- Ya que estábamos añadimos soporte para usar las 4 paletas simultáneas en el plano principal, aunque es una técnica que existe no es muy habitual, lo normal es ver 1 paleta por plano, o aplicar cambio de paleta en zonas rectangulares completas, creo que cuando empiece a enseñar escenarios es algo que se va a notar
- Limitaciones, como el mapa de colisiones está simplificado a 16x16 (en lugar de 8x8), las propiedades se aplican siempre sobre esa precisión de superficie

Notas:
- Leer de RAM parece más lento que de la ROM, lo cual presenta un reto cuando la lista de tiles es muy amplia, he tenido que crear tiles de "grupos", en base a su funcionalidad
- Algunos juegos estilo Metroid no cargan el mapa entero en memoria, sino por la región que vamos pisando, alguna vez te has preguntado porque los tochos que destruyes se vuelven a reconstruir al poco tiempo? Bien, cuando no es intencionado puede ser para maquillar lo que pasa cuando te mueves, al perder algo de vista la información se renueva y el tocho vuelve a aparecer, pero ah, si se regenera solo de por si lo encuentras más natural
- Tras revisar todos los mapas de Super Metroid, mapas de sala (pantalla), no de zonas completas, el más amplio horizontalmente es de 3072 pixel (192 tiles) y de alto sería inferior a 2560 pixels (160), así que el mapa en las peores condiciones posibles nos ocuparía cerca de 30KB, en mi juego habrán mapas de un tamaño similar
BoMbErLiNk escribió:DESTRUCCIÓN DE TILES Y RAM
Otra nueva entrada, en esta ocasión ya aparecen disparos, el cubito sigue rocoso a pesar de la ola de calor:

Imagen

[plas]
Lo que veo raro es que leer de la RAM sea más lento que se ROM.
Tiene muy buena pinta todo lo que vas contando, solo diré que lo del botón reset si lo hiciera Kojima estaríamos hablando de ello eternamente. Me parece una fantástica idea [tadoramo]
niggaqueentraentiendaysacaraboencimadelmostrador.gif
Es genial que vuelvas a meterte en un embolao y ver con que pasión y conocimientos lo haces. Una grandisima noticia! Seguro que va a salir un juegazo.
Gracias [beer] , la cosa va lenta pero va tomando forma (a falta de concretar el equipo), el juego lo estoy montando a forma de engine para que permita más juegos de MD en un futuro, o portabilidad.

danibus escribió:Lo que veo raro es que leer de la RAM sea más lento que se ROM.


Según vi, el cambio estaba en el comportamiento de switch, en ROM acceder al tile 34 es tan rápido como hacerlo con el 1, en RAM parece que no crea esa tabla de saltos, así que he buscado alternativas temporales, pero tengo algunas ideas para mejorarlo... a falta de mirar las opciones del compilador [risita]
@BoMbErLiNk manejas algún tamaño máximo de ROM? Ya sé que no se puede pedir milagros, pero estaría bien que funcionase en el flashcard chino que lo máximo que acepta son 7 Mbyte.
SuperPadLand escribió:@BoMbErLiNk manejas algún tamaño máximo de ROM? Ya sé que no se puede pedir milagros, pero estaría bien que funcionase en el flashcard chino que lo máximo que acepta son 7 Mbyte.


Intentaría mantenerme en los 4MB, ahora mismo el juego funciona en la mayoría de emuladores, hasta en el Picodrive de N-Gage del año catapum.

También me gustaría lanzar una versión física (sin dejar de lado la digital, la ROM), me haría ilusión vaya, aunque eso ya requeriría tener éxito en un Kickstarter o algo similar, pero podría ser un punto de inflexión, por otro lado sería necesario para conseguir algunos artistas o músicos que conozco.
BoMbErLiNk escribió:
SuperPadLand escribió:@BoMbErLiNk manejas algún tamaño máximo de ROM? Ya sé que no se puede pedir milagros, pero estaría bien que funcionase en el flashcard chino que lo máximo que acepta son 7 Mbyte.


Intentaría mantenerme en los 4MB, ahora mismo el juego funciona en la mayoría de emuladores, hasta en el Picodrive de N-Gage del año catapum.

También me gustaría lanzar una versión física (sin dejar de lado la digital, la ROM), me haría ilusión vaya, aunque eso ya requeriría tener éxito en un Kickstarter o algo similar, pero podría ser un punto de inflexión, por otro lado sería necesario para conseguir algunos artistas o músicos que conozco.

Por intentarlo no pierdes nada y MD tiene una comunidad fuerte. El juego parece muy bueno así que seguro que consigues financiación en kickstarter
BoMbErLiNk escribió:También me gustaría lanzar una versión física (sin dejar de lado la digital, la ROM), me haría ilusión vaya, aunque eso ya requeriría tener éxito en un Kickstarter o algo similar, pero podría ser un punto de inflexión, por otro lado sería necesario para conseguir algunos artistas o músicos que conozco.


No necesariamente puede ser necesario recurrir a un Kickstart (creo yo), como hay bastante escena de megadrive y salen juegos en cartuchos fisico también hay tiendas con las que puedes hablar para lanzar version física (PlayOnRetro, 1985Alternativo, etc) además que ya tienen experiencia en toda la logística de lanzamiento.
@John3d pero se lo hacen gratis asumiendo ellos el riesgo de perdidas o piden una inversión inicial?
SuperPadLand escribió:@John3d pero se lo hacen gratis asumiendo ellos el riesgo de perdidas o piden una inversión inicial?

Me has pillao, ahí me dejas en fuera de juego...

Lo he comentado porque en alguna de esas tiendas han vendido juegos que no han desarrollado ellos mismos y tampoco han tenido un kickstart detras. Así que eso seria hablar con el responsable de alguna tienda para ver como funcionan las cosas.

Solo intentada dar alguna idea como alternativa. Tal vez esté mas puesto en el tema @aranya que parece que conoce algo a Ichigo, quien tiene una tienda de juegos de Master System donde vende sus propios juegos y se ha ofrecido a publicar juegos de otros desarrolladores.
@John3d con el tema de Master, Ichigo tiene su propio studio, y si hace un juego que él considera bueno, te lo publica. Con alguna gente ha contactado el mismo para hablar de publicar. Él tiene todos los medios para publicar.

No hace falta campañas.
aranya escribió:@John3d con el tema de Master, Ichigo tiene su propio studio, y si hace un juego que él considera bueno, te lo publica. Con alguna gente ha contactado el mismo para hablar de publicar. Él tiene todos los medios para publicar.

No hace falta campañas.


Eso proponía yo para el juego de Bomberlink pero al revés, hablar con gente que tenga los medios para publicar juegos de megadrive y preguntar si publicarían este cuando lo finalice. Pero todo esto lo digo sin estar muy puesto en el tema...

Offtopic: Por cierto, sabes si el mini Paprium lo publicará Ichigo tambien en su tienda (como third party de Watermelon o algo asi)? En ese caso muchos no tendrán que sufrir la logística de Fronzie.
@BoMbErLiNk Yo estoy dentro de playonretro, cuando quieras, contactame por mp y te cuento, aunque este año la cosa está complicada...
@John3d no tengo ni idea, pero desde luego sería fantástico. Ichigo hace las cosas muy bien y es muy serio. Espero que pueda venderlo desde allí.
BoMbErLiNk escribió:- Ya que estábamos añadimos soporte para usar las 4 paletas simultáneas en el plano principal, aunque es una técnica que existe no es muy habitual, lo normal es ver 1 paleta por plano, o aplicar cambio de paleta en zonas rectangulares completas, creo que cuando empiece a enseñar escenarios es algo que se va a notar

Esto me ha llamado la atención, entiendo que lo utilizas "in game", lo había escuchado alguna vez pero más para imágenes estáticas. Si es así, seguro que se nota, claro, a ver si van saliendo pronto imágenes del juego.

Una duda, si no me equivoco, no habías hecho nunca antes para MD, quería preguntarte qué facilidades e incovenientes crees que tiene el SGDK, ya que se suele comentar que ha agililizado mucho la programación en MD, pero también he escuchado a programadores, normalmente de fuera del entorno de la consola, que todavía tiene cosas que se pueden mejorar bastante.
Igual fue algo precipitado comentar lo del formato físico, el juego no saldrá este año, pero agradezco todos los consejos para ir mirando [oki]

AtomicRobot-nik16 escribió:Esto me ha llamado la atención, entiendo que lo utilizas "in game", lo había escuchado alguna vez pero más para imágenes estáticas. Si es así, seguro que se nota, claro, a ver si van saliendo pronto imágenes del juego.

Una duda, si no me equivoco, no habías hecho nunca antes para MD, quería preguntarte qué facilidades e incovenientes crees que tiene el SGDK, ya que se suele comentar que ha agililizado mucho la programación en MD, pero también he escuchado a programadores, normalmente de fuera del entorno de la consola, que todavía tiene cosas que se pueden mejorar bastante.


Claro, no suele ser común porque necesita otra tabla de datos para consultar y eso ocupa bastante espacio en el cartucho, yo añadí esos datos dentro del mapa de colisión, creo que será interesante cuando empiece a enseñar los escenarios, lo importante es que es un juego diseñado a consciencia para ser de MD, para lucir bien con los colores que se utilicen.

En MD lo primero que hice fue portar el SudoQ (lo tienes en otro hilo), aunque este proyecto ya lo llevaba cocinando desde antes.

La librería está muy bien, hace lo que promete, convierte los gráficos y el sonido, monta la ROM y no tienes que preocuparte por nada, los ejemplos y ayuda en internet menos de lo que esperaba, pero ya venía vacunado de N64.

El soporte de audio bien, el manejo de scroll no demasiado contento, con los sprites veo también algunas limitaciones, las funciones de la SGDK depende, algunas son genéricas y podrían funcionar mejor si se adaptan a las necesidades del juego, en mi caso reescribo todo aquello que considero que puede tener una ventaja.
37 respuestas
Archivado
Volver a Consolas clásicas