DESARROLLO SOFTWARE - Proyectos de JduranMaster [a.k.a. DarkRyoga]

[jduranmaster]

Hola a todos. Después de un tiempo me he decidido a abrir este hilo para compartir con vosotros los videos acerca de mis proyectos personales. De esta forma dejo de usar el hilo ------>>> [HILO OFICIAL] GameBoy Advance & GameBoy Development <<<------ (http://www.gp32spain.com/foros/showthread.php?74549-HILO-OFICIAL-GameBoy-Advance-amp-GameBoy-Development) para postear estas historias y se queda para el uso original que ese hilo tenía y que era el desarrollo de software para las GB/GBC/GBA de forma especifica. Por otro lado, tengo pensado abrir un blog donde ir posteando estos videos con algo más de información al respecto, así que cuando este listo lo pondré por aquí.


GBA4J-v.0.87:

Los videos que os pongo a continuación son acerca de mi emulador de los sistemas GameBoy/GameBoy Color y GameBoy Advance realizado en lenguaje de programación JAVA. En el video se aprecian las características del mismo. Como puede apreciarse para la emulación de GameBoy he diseñado un elemento gráfico JAVA-SWING [SWT] que se integra en el resto de la aplicación. Sin embargo debido a la dificultad de realizar ese mismo objeto para GBA he optado (de momento) por que la emulación sea a pantalla completa lo cual da muy buenos resultados. El CORE de emulación de GB/GBC es totalmente original y escrito desde cero por mi, mientras que el CORE de emulación de GBA está basado en el código fuente del emulador VBA. En este último caso me he dedicado a portar (de C/C++ a lenguaje JAVA) el CORE original de VBA añadiendo fragmentos de código necesarios para la correcta emulación del procesador ARM7TDMI original de la GBA en JAVA. Los añadidos al código original del VBA que luego he incluido en mi CORE de emulación escrito en JAVA eran necesarios para mejorar el rendimiento del procesamiento de las instrucciones de los juegos de GBA. Como sabeis, la GBA maneja dos sets de intrucciones en su procesador, por un lado el set Thumb de 16 bits, y por otro lado el set de 32 bits, bueno pues esos añadidos propios son precisamente para mejorar el procesamiento por parte del emulador de las instrucciones del set Thumb dentro del CORE escrito en Java. El objetivo principal de realizar un proyecto como este en el cual utilizo un lenguaje de programación interpretado como JAVA, es demostrar que en cierta medida dicho lenguaje es aceptable para la emulación en cuanto a rendimiento se trata. Decir que este proyecto lo ínicié allá por 2005 y no fué hasta 2008 cuando lo medio finalizé. Todo ello en mis ratos libres. A día de hoy aún necesita algunas mejoras, pero la cosa marcha bastante bien.

GBA4J-v.0.87-M1: este video tiene bastante tiempo, y está grabado con un programa llamado HyperCam que no me permitía capturar el sonido generado por el emulador.


http://www.youtube.com/watch?v=YoUpflJMM10

GBA4J-v.0.87-M2: este video ya es más reciente. Grabado con fraps que permite capturar todos los detalles del emulador. Os recomiendo que veais cualquiera de los dos videos a pantalla completa o bien usando "el reproductor grande" de YT para apreciar bien los detalles. Utilizar resolución 720p añade un plus. En este video aparecen juegos emulados como Wario Land 3, MegaMan V, Super Mario Land 3 - Wario Land ,MegaMan II,Shadow Warrios, Wario Land 4, etc...


http://www.youtube.com/watch?v=-LPMqImBNsU

GBA4J-v.0.87-M3: este otro video ya es más reciente. También está grabado con fraps que permite capturar todos los detalles del emulador. Os recomiendo que veais cualquiera de los dos videos a pantalla completa o bien usando "el reproductor grande" de YT para apreciar bien los detalles. Utilizar resolución 720p añade un plus. En este video aparecen emulados juegos como RESIDENT EVIL GBC (la beta liberada a la cual se le ha aplicado el BugFix para poder llegar hasta el final), R-Type DX, PROBOTECTOR, Wario LAnd 2, etc...


http://www.youtube.com/watch?v=d4Z8JyQrjAQ

Por otro lado comentaros que a día de hoy el emulador no está para su descarga. Estoy terminando de pulir algunos aspectos generales de la emulación, así como la generación de una nueva interfaz gráfica SWING con más opciones que ya iré enseñando en videos posteriores. Más adelante, una vez esté todo terminado subiré el emulador a Google Code para compartirlo con vosotros. También tengo pensado abrir un blog donde postear entradas con explicaciones más técnicas al respecto de estos proyectos de emulación, así más adelante y si las reglas generales del foro lo permiten añadiré a este post inicial del hilo la URL de dicho blog. Actualmente, estoy terminando de desarrollar otros emuladores escritos en lenguaje JAVA. Entre ellos el GBC4J que será un emulador exclusivo de la plataforma GB/GBC y el NES4J, un emulador escrito en JAVA del sistema NES y con soporte para la mayoría de MAPPERS de memoría que existen para los juegos de dicha consola. En el futuro iré subiendo nuevos videos comentando los progresos de estos proyectos y sus respectivas versiones para Android.

Saludos.

GBC4J-v.0.87:

Los videos que os pongo a continuación son acerca de mi emulador de los sistemas GameBoy/GameBoy Color realizado en lenguaje de programación JAVA. En el video se aprecian las características del mismo. Como puede apreciarse para la emulación de GameBoy he diseñado un elemento gráfico JAVA-SWING [SWT] que se integra en el resto de la aplicación. El CORE de emulación de GB/GBC es totalmente original y escrito desde cero por mi. Este emulador es una especie de spin-off del GBA4J, solo centrado en la emulación de los sistemas Gameboy y GameBoy Color.

GBC4J-v.0.87: Terminator 2 Judgment Day (GameBoy) :


http://www.youtube.com/watch?v=M_C9A6QV1tU

GBC4J-v.0.87: TETRIS DX (GameBoy COLOR) :


http://www.youtube.com/watch?v=QKauAFQ-rnU

GBC4J-v.0.87: Ninja Gaiden - Shadow Warriors (GameBoy) :


http://www.youtube.com/watch?v=HpPhV5mtJRM

GBC4J-v.0.87: Kirby´s Dreamland - PARTE 1 (GameBoy) :


http://www.youtube.com/watch?v=gMk9YyYo4EE

GBC4J-v.0.87: Kirby´s Dreamland - PARTE 2 (GameBoy) :


http://www.youtube.com/watch?v=8RAF1ZelvVM

GBC4J-v.0.87: GHOSTS´N GOBLINS (GameBoy COLOR) :


http://www.youtube.com/watch?v=OBCGVKJelWc

GBC4J-v.0.87: Kirby´s Dreamland (GameBoy) - COMPLETO! :


http://www.youtube.com/watch?v=ZS6km35qL04

GBC4J-v.0.87: WARIO LAND (GameBoy) - COMPLETO! :


http://www.youtube.com/watch?v=2WOllzDl-A0

Neon Genesis Evangelion - Rei Demo 1 (PD) (GameBoy)


https://www.youtube.com/watch?v=ycXDYzUKHSk

Ganbare Goemon Hoshizorashi Dynamites Arawaru!! (GameBoy Color)


https://www.youtube.com/watch?v=afZ0z7r3a8g

GBC4J-v.0.87: BATTLE BULL (GameBoy) :


http://www.youtube.com/watch?v=YVgLNoVaMqc

GBC4J-v.0.87: OPERATION C (GameBoy) :


http://www.youtube.com/watch?v=y_XIZUWHnfo

GBC4J-v.0.87: Metroid II - Return of Samus (Color Patch Hack) (GameBoy) :


http://www.youtube.com/watch?v=hpf7f6BjscI

GBC4J-v.0.87: MegaMan Dr.Willy´s Revenge (GameBoy) :


http://www.youtube.com/watch?v=Gr-TTzLIvsU

GBC4J-v.0.87: STREET FIGHTER ALPHA (GameBoy COLOR) :


http://www.youtube.com/watch?v=QHGZH13WnNk

Ganbare Goemon Hoshizorashi Dynamites Arawaru!! - Ebisumaru (GameBoy Color)


http://www.youtube.com/watch?v=Biqi8kTyy-0

GBC4J-v.0.87: Qi Tian Da Sheng: Sun Wu Kong - Unlicensed (GameBoy COLOR) :


http://www.youtube.com/watch?v=jGmYyfyjA5c

NES4J-v.0.89:

Aquí os traigo el primer video de mi nuevo emulador de NES/FAMICOM escrito integramente en lenguaje JAVA y para la plataforma PC. Al igual que el resto de proyectos (GBA4J y GBC4J) este emulador tiene por motivación demostrar que usando el lenguaje JAVA y con las optimizaciones oportunas se puede obtener un emulador decente y de alta compatibilidad con los títulos originales que aparecieron en su día para este sistema. Al igual que con los emuladores anteriores (GBA4J y GBC4J) la idea es una vez este pulido del todo hacer un port para teléfonos móviles Android. El emulador tiene por núcleo "un paquete" o "módulo" que se encarga de la emulación del procesador Ricoh 2A03 (o RP2A03) usado en Norteamérica y Japón (NTSC), que funciona a 1,79 MHz, y además incorpora también la emulación del Ricoh 2A07 (o RP2A07) usado en las versiones distribuidas en Europa, Australia y algunos países asiáticos (PAL A y PAL B), que es idéntico al modelo 2A03 excepto por el hecho de que funcionan a una frecuencia de reloj más lenta (concretamente a 1,66 Mhz). Respecto al conjunto de mappers de memoria que soporta el emulador, la lista es la siguiente:

- UNROM: usado en juegos como Ikari Warriors, Mega Man, Contra, etc.
- MMC1: usado en juegos como Metroid o The Legend of Zelda.
- MMC2: usado únicamente en Mike Tyson's Punch-Out!!
- MMC3: usado en juegos como MegaMan 3, SuperMario Bros 2, SuperMario Bros 3, etc
- MMC4: usado en juegos como Fire Emblem, Fire Emblem Gaiden, etc.
- MMC5: usado en juegos como Castlevania III: Dracula's Curse(NA/EU), Just Breed, Kirby´s Adventure o Metal Slader Glory, etc. (El Metal Slader Glory es a día de hoy el único juego que usa el MMC5 que me da problemas en el emulador. Espero resolverlo).

- MMC6: usado en los juegos StarTropics, Zoda's Revenge: StarTropics II.
- AOROM: usado en los juegos Battletoads, Wizards & Warriors, etc.
- VRC2: usado en juegos como Gryzor (Contra JAP), Kid Dracula, etc.
- VRC4: usado en juegos como Crisis Force.
- VRC6: usado en juegos como Akumajou Densetsu, etc.
- VRC7: usado en juegos como Lagrange Point, Tiny Toon Adventures 2, etc.
- NAMCO106: usado en juegos como Final Lap, King of Kings, Mappy Kids, etc.
- FME-7: usado en juegos como Batman: Return of the Joker, Hebereke.
- SUNSOFT 5B: usado en el juego Mr. Gimmick!. A día de hoy este es el mapper cuyo sorporte tengo menos trabajado, pero todo se andará.

Adicionalmente he incluido el soporte para algunos mappers que usan varios cartuchos multijuegos de origen ruso, chino, etc. Cuando Termine de abrir el blog de desarrollo ya daré más detalles al respecto.

Crisis Force - Mapper VRC4 [Konami] (NES/FAMICOM)


http://www.youtube.com/watch?v=YV7SMCOT2KE

Emulador de NES/FAMICOM en Java - NES4J-v.0.89-M1 - Programmed By DarkRyoga (a.k.a. jduranmaster)


http://www.youtube.com/watch?v=Vdv3ZGhuNP8

NES4J-v.0.89-M1 - FAMICOM Emulator [JAVA] - Rev.b1 - Programmed By DarkRyoga (a.k.a. jduranmaster)


http://www.youtube.com/watch?v=8XTMDHt9Tu0
Saludos!.

[tSuKiYoMi]

Mola. Así queda todo junto.

[^OMAP-Cranck^]

Brutal macho. Me encanta como luce el Crisis Force en el emulador de nes/famicom. Mi enhorabuena.

[Solo]

Así queda todo junto en el mismo hilo. No conocía ese juego para famicom y eso que me encantan los shoot em ups

[jduranmaster]

Aquí os traigo un nuevo video de mi emulador NES4J (emulador del sistema NES/FAMICOM) escrito integramente en lenguaje de programación JAVA. En este video podeis apreciar la emulación de los juegos Burai Fighter, Kirby´s Adventure, Mega Man 2 y Castlevania III.

Emulador de NES/FAMICOM en Java - NES4J-v.0.89-M1 - Programmed By DarkRyoga


http://www.youtube.com/watch?v=Vdv3ZGhuNP8

[amok]

gran trabajo hamigo :) aunque personalmente odio java :P

[jduranmaster]

gran trabajo hamigo :) aunque personalmente odio java :P

no es mi lenguaje predilecto, pero usando optimizaciones se puede conseguir un buen rendimiento.

Saludos.

[jduranmaster]

Aquí os traigo un nuevo video de mi emulador NES4J (emulador del sistema NES/FAMICOM) escrito integramente en lenguaje de programación JAVA. En este video podeis apreciar la emulación de los juegos Chouji Sentai JetMan, Blue Shadow, Shadow Warriors y Chip n`Dale: Rescue Rangers

NES4J-v.0.89-M1 - FAMICOM Emulator [JAVA] - Rev.b1 - Programmed By DarkRyoga (a.k.a. jduranmaster)


http://www.youtube.com/watch?v=8XTMDHt9Tu0

[jduranmaster]

Vuelvo de nuevo a la carga. En este caso os traigo un video de mi emulador GBC4J (emulador escrito en lenguaje de programación JAVA de los sistemas GameBoy y GameBoy Color) en el cual se puede apreciar la emulación de un juego de GameBoy. En este caso os traigo un video jugando al Zelda Link´s Awakening para GameBoy Color.

GBC4J-v.0.87: Zelda Link´s Awakening (GameBoy) :


http://www.youtube.com/watch?v=A-eWd-CWtjU

[JoJo_ReloadeD]

O_o

No hay sistema que se te resista eh? La virgen :)

Parece perfecta la emulacion no? Hay algo que le falte?

[jduranmaster]

O_o

No hay sistema que se te resista eh? La virgen :)

Parece perfecta la emulacion no? Hay algo que le falte?

Todos estos emus tienen hasta soporte para partidas multijugador al número de players que soporte el juego en cuestión...xd. El emulador de GBA [GBA4J] aún no está terminado a falta de algunos retoques en la interfaz gráfica, pero emula todos los juegos con los que he probado. En el caso del emulador de NES/FAMICOM [NES4J] lo único que me falta por meterle es el soporte completo para el mapper SunSoft-5B del Mr.Gimmick! y el emulador de Game Boy/Game Boy Color (GBC4J) emula también prácticamente todo el romset aunque hay algún juego que presenta fallos gráficos como el RoboCop de GameBoy, aunque según tengo entendido ese juego da problemas con todos los emuladores pues parace que hay un bug fatal a partir de la cuarta pantalla.

[3XCL4M4t10N]

¿Soporta cable link el de GB?

[jduranmaster]

¿Soporta cable link el de GB?

Emula la función del cable link para poder jugar partidas a varios players.

[bulbastre]

Y si son java, significa que se podrían encasquetar en una página web y jugar online con cualquier SO que soporte java?

[jduranmaster]

Y si son java, significa que se podrían encasquetar en una página web y jugar online con cualquier SO que soporte java?

Ahora mismo la interfaz gráfica de los emuladores está desarrollada en JAVA-SWING como aplicaciones de escritorio. Lo que tú dices sería viable si en lugar de estar desarrollado como un aplicación de escritorio se cambiase el código para que fuese un APPLET, cosa que no sería muy complicada pues el core de emulación es independiente de la interfaz gráfíca.

[jduranmaster]

Vuelvo de nuevo a la carga. En este caso os traigo un video de mi emulador GBC4J (emulador escrito en lenguaje de programación JAVA de los sistemas GameBoy y GameBoy Color) en el cual se puede apreciar la emulación de un juego de GameBoy. En este caso os traigo un video jugando al Wario Land 2 para GameBoy.

GBC4J-v.0.87: WARIO LAND 2 (GameBoy) :


https://www.youtube.com/watch?v=jkTwrwqxB6M

[^OMAP-Cranck^]

Que bien se mueve ese Wario Land 2.

[jduranmaster]

ACTUALIZACIÓN:

Os traigo dos nuevos videos demostrativos del emulador de GameBoy/GameBoy Color.

En el primer caso se trata del emulador rulando un juego de GameBoy...el BATTLE UNIT ZEOTH.

GBC4J-v-0.87-M1 - GameBoy Color Emulator [JAVA] - Battle Unit Zeoth [CARTRIDGE: ROM+MBC1]


https://www.youtube.com/watch?v=Fy1Hl95-I8g

...en el segundo caso se trata de un juego de GameBOY Color, el RESIDENT EVIL de GBC que fué dumpeado hace relativamente poco (año y medio de así). En este último caso se trata de una ROM de 4 megas con lo que doy por finalizado el soporte para este tipo de juego (WARIO LAND 3, SHANTAE...) que además incluyen opciones de salvado de partidas y que a día de hoy son totalmente funcionales.

GBC4J-v-0.87-M1 - GameBoy Color Emulator [JAVA] - RESIDENT EVIL GameBoy Color [CART I BugFixed]


https://www.youtube.com/watch?v=vZKixAE7usU

[<aSaCo>]

Me parece impresionante lo del RESIDENT EVIL para GBC.

[jduranmaster]

Castlevania II: Belmont´s Revenge AWESOME Edition es un hack del Castlevania II: Belmont´s Revenge de GB de toda la vida...aunque para ser más exactos, es un hack del KONAMI COLLECTION VOL 4 que ha sido modificado para "auto-arrancar" dicho cartucho multijuegos con la rom coloreada del Castlevania II: Belmont´s Revenge a la cual se le han aplicado algunos añadidos extras para mejorar algo la jugabilidad. El hack fué realizado por el usuario de YT "TheDrakon" y en este video enseño un poco del mismo rulando en el emulador GBC4J.


https://www.youtube.com/watch?v=8YTbTJKJ8ks

Actualmente estoy mejorando en algunas cosas el emulador. Una de las mejoras es la posibilidad de poder activar "esquemas de color custom" para los juegos de la gameboy tocha o lo que es lo mismo, poder colocar las míticas paletas de color que se podían seleccionar mediante combinación de botones en la GBA o en el SGB. Otra de las mejoras es que el emulador podrá funcionar integrado en una página web como un APPLET.

[jduranmaster]

!!!NUEVA ACTUALIZACIÓN¡¡¡:

Este es el primer video grabado usando el nuevo emulador J_GB (versión avanzada del emulador GBC4J que incorpora la corrección de varios errores y nuevas funcionalidades) que emula los sistemas GameBoy y GameBoy Color. Una de las novedades de este emulador es su capacidad de aplicar esquemas de color a los juegos de GameBoy clásica al igual que se podía hacer con el Super Gameboy, una GameBoy Color o una GameBoy Advance cuando en ellas se introducía un cartucho de GameBoy clásica. Ahora mismo hay implementados 8 esquemas de colores diferentes (entre los que están incluidos el "verdoso" de la GameBoy tocha y otro por defecto en blanco y negro con escala de grises típico de los emuladores más conocidos). El esquema de colores utilizados en esta partida al Terminator 2: Judgement Day es el siguiente:

Background Plane Palette:0xFFFFFF40, 0xFF00C000, 0xFF008000, 0xFF004000
Sprite Plane Palette-1: 0xFFC0C0FF, 0xFF4040FF, 0xFF0000FF, 0xFF000080
Sprite Plane Palette-2: 0xFFFFFF40, 0xFFC0C000, 0xFFFF4040, 0xFF800000

TERMINATOR 2: Judgment Day (Custom Scheme Colors) - GameBoy Longplay - NO DEATH RUN (J_GB EMULATOR)

https://www.youtube.com/watch?v=ROnIw4fVS3s

Como comentaba más arriba he implementado 8 paletas de colores diferentes...otras pruebas que he llegado a realizar serían las dos siguientes:

Esta para el Castlevania II: Belmont´s Revenge...
https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-xpf1/t31.0-8/10465353_320466264775277_8152692627013579402_o.jpg

Y esta otra para el Kirby´s Dreamland, que no es más que una modificación del anterior, pero sacando el color rosa para el sprite de Kirby tal y como si se tratará del Kirby´s Adventure de NES

Background Plane Palette: 0xFFC0C0FF, 0xFF4040FF, 0xFF0000FF,0xFF000080.
Sprite Plane Palette-1: 0xFFFFC0C0,0xFFFF4040, 0xFFFF00FF,0xFFFF8080
Sprite Plane Palette-2: 0xFFFFFF40, 0xFFC0C000,0xFFFF4040, 0xFF800000

La segunda paleta dedicada a sprites (en el caso del Kirby) se corresponde con un tono amarillo que en el caso de este juego en concreto sólo se aprecia en los sprites parpadeantes (es decir no hay una separación clara entre sprites primarios y secundarios). En otros juegos que aparecieron a posteriori al lanzamiento del "Super GameBoy" está separación es clara y se puede apreciar perfectamente como los sprites secundarios adquieren en todo momento los esquemas de colores definidos en la "Sprite Plane Palette-2".

https://scontent-a-cdg.xx.fbcdn.net/hphotos-xaf1/t31.0-8/10463763_321488648006372_8441400674259739974_o.jpg

PD: aún queda integrar el módulo para controlar el DEBUGGER en la GUI, pero ya está casi terminado.

Saludos.

[tSuKiYoMi]

Impresionante curro tio. Cada vez tiene mejor pinta.

[Solo]

Impresionado me hayo. Como mola ese belmont de color rojo, y el kirby no se queda lejos.

[<aSaCo>]

Gran trabajo. El tema de las paletas de colores personalizadas para los juegos de gameboy clásica es una opción que siempre ha estado disponible en la mayoría de emuladores convencionales como el bgb o el vba. Tengo de ganas de probarlo. ¿Al final será posible incrustar el emulador en una web como si fuese un applet?

[SplinterGU]

no habia visto este hilo! muy bueno! felicitaciones!

[jduranmaster]

Bueno dejo por aquí este video de como programar un clón del PONG para Game Boy. Últimamente me ha dado por volver a tocar cosas de este sistema y he completado algunos programas de ejemplo que he ido compartiendo a través de un subforo de desarrollo en EOL. Así que actualizo también por aquí aunque las explicaciones propiamente dichas sería mejor mirarlas en dicho subforo.


https://www.youtube.com/watch?v=KFk-uQbqQKk

PD: actualizo también un poco el hilo dedicado a este menester: HILO-OFICIAL-GameBoy-Advance-amp-GameBoy-Development (http://www.gp32spain.com/foros/showthread.php?74549-HILO-OFICIAL-GameBoy-Advance-amp-GameBoy-Development/page59) aunque lo suyo sería meter todo el material de EOL también aquí. Si tengo tiempo terminaré hacíendolo.

Saludos.

[otto_xd]

Hazte una wiki, me parece super interesante toda esta informacion!

Yo a ver si con el analizador logico me pongo a sacar como se comunicaban los juegos usando el link cable.
Se que la informacion esta por ahi, pero me hace ilusion sacarlo por mi mismo :D

[jduranmaster]

A comienzos del próximo año estará disponible un nuevo blog que estoy creando donde estarán disponibles todas las entradas relacionadas con la programación de software para Game Boy y Game Boy Advance que estoy haciendo (todo es material nuevo) además de otros temas que de momento no han visto la luz.

Saludos.

[jduranmaster]

Video de la versión Beta del juego HomeBrew para GB - "Tetris: The Soviet Mind Game". El juego ya es completamente jugable pero faltan detalles. Entre ellos los efectos de sonido (que ya están de camino) y la música (que no sé si al final tendrá). Por lo demás la versión actual presenta el modo típico en el que debemos hacer líneas sin parar sin que se acumulen las piezas evitando que toquen el techo. En este caso falta por meter también la puntuación. ¿Echasteis de menos algún modo de juego en el Tetris original de GB que si estuviese en otros juegos de la saga en ARCADE o SNES? Lo pregunto porque dado que tengo otros proyectos en mente, sino es muy difícil de implementar lo puedo meter en este título cómo modo de juego extra. Además también estoy pensando en meter alguna sorpresa en la ROM en caso de alquien lo pruebe en un Super GameBoy. El juego se puede jugar tanto en emuladores cómo en sistema real.

Trailer:

https://www.youtube.com/watch?v=DzAnpQb_5G4

(Beta-gameplay)

https://www.youtube.com/watch?v=lUUcIghRsts

PD: el juego está picado integramente en C usando el GBDK.

[enkonsierto]

Además también estoy pensando en meter alguna sorpresa en la ROM en caso de alquien lo pruebe en un Super GameBoy.
PD: el juego está picado integramente en C usando el GBDK.

GBDK tiene las funciones para hacer los marcos de sgb?

[jduranmaster]

GBDK tiene las funciones para hacer los marcos de sgb?

No directamente. Lo que si tiene es una macro que te dice si el juego se está ejecutando en un SGB o no. Pero para los marcos de SGB y otros efectos relacionados con este dispositivo hay que tirar de ensamblador. En principio se pueden incluir rutinas en ensamblador en GBDK para poder usar la funcionalidad del SGB. Hay gente lleva tiempo trabajando en la forma de exponer un API a través del GBDK que permita hacer cosas con el SGB fácilmente.

SGB-functions (http://bgb.bircd.org/pandocs.htm#sgbfunctions)

[enkonsierto]

No directamente. Lo que si tiene es una macro que te dice si el juego se está ejecutando en un SGB o no. Pero para los marcos de SGB y otros efectos relacionados con este dispositivo hay que tirar de ensamblador. En principio se pueden incluir rutinas en ensamblador en GBDK para poder usar la funcionalidad del SGB. Hay gente lleva tiempo trabajando en la forma de exponer un API a través del GBDK que permita hacer cosas con el SGB fácilmente.

SGB-functions (http://bgb.bircd.org/pandocs.htm#sgbfunctions)

Justo eso es lo que tenía entendido. Me interesaba lo de hacerle un marco pero no había visto nada específico en la librería.

[jduranmaster]

Hoy se ha hecho público un API que complementa al GBDK que permite programar juegos de GameBoy con las funcionalidades compatibles con el Super GameBoy incluidos los marcos para los juegos. A si que seguramente mi clón de Tetris llevé incluido un bonito marco por si alguien decide jugarlo alguna vez en el hardware original y concretamente en un SGB.

[GameMaster]

link porfa

[ElRana]

link porfa

46961
Que manía con el Zelda, ya pongo yo el link para GameMaster, pero últimamente el personal se ralla muuucho con el Zelda...

[GameMaster]

46961
Que manía con el Zelda, ya pongo yo el link para GameMaster, pero últimamente el personal se ralla muuucho con el Zelda...

no quiero ese link, rana fea

46962

[jduranmaster]

Ya he estado haciendo pruebas y parece que funciona el tema del marco en la rom. Cuando pueda subiré algunos resultados.

[jduranmaster]

Después de terminar "el jogo" de GameBoy Color (del que ya pondré algo por aquí) y de unas semanas de descanso hace poco me puse a rescatar algunas cosillas para GBA. Ahora estoy desarrollando un "motor 2D" para juegos tipo "Run & Gun" que en principio es para la GBA pero que me gustaría exportar a otras portátiles de Nintendo más modernas. Tras hacer algunas pruebas ya he conseguido mover con el PAD de la consola los sprites animados de un objeto:

Color Palette Issue With PCX Format {06/01/2016} - (GameBoy Advance Homebrew) (DEVKITADV)

https://www.youtube.com/watch?v=chBwiQ-_45s

Pero cómo podéis apreciar en el video hay algo que falla en la paleta de colores del objeto en movimiento. Para la conversión de las imágenes que forman parte de la "sprite-sheet" he utilizado el mítico PCX2GBA. Este programa recibe como entrada imágenes en formato PCX de 256 colores. Las sprite-sheets que estoy usando originalmente están en formato PNG de 24 bits, de ahí las paso a BMP (24 bits), de ahí a BMP otra vez (256 colores) y por último a PCX antes de usar el PCX2GBA. Seguramente no sea el mejor proceso para hacer la conversión pero con eso me he ido apañando para los ejemplos. El tema es que no consigo definir bien las transparencias en los sprites. Al tratarse de PCX hay que tener en cuenta que este formato no soporta "canal alpha" cómo otros más modernos por tanto para las transparencias cómo tal en PCX se fijan a través de la paleta de colores. En la siguiente imagen se puede ver cómo es la paleta de colores de la última imagen donde aparece el "tanque-mecha" del "Metal Slug 5":

47307

El programa es el Paint Shop Pro. En este programa el color que se toma como transparencia en la imagen aparece el primero por lo que de la imagen se deduce que el color "transparente" es el negro, de ahí que después de todo el proceso en la ROM el objeto se vea con secciones transparentes, ya que esa secciones que transparentan el fondo son de color negro en origen. El tema es ¿se puede modificar de alguna forma el orden de la paleta de colores para que el color "transparente" que aparezca el primero (en la imagen es el RGB --- 224,32,192) sea el fucsia de la imagen?. Si alguien conoce alguna forma de hacerlo con Paint Shop Pro o bien con GIMP sería de agradecer que lo pusiese por aquí.

Saludos.

[Solo]

A pesar de los problemas con la paleta de colores la animación se ve fluida, y para haber hecho un rebaja en los colores no se no ta tanto cómo me imaginaba. No soy ningún experto pero a lo mejor esto te ayuda:

Paint Shop Pro - PCX Format with Transparency (http://www.fishsim.net/cmanual/pcxfiles.htm)

A ver si te sirve.

[jduranmaster]

A pesar de los problemas con la paleta de colores la animación se ve fluida, y para haber hecho un rebaja en los colores no se no ta tanto cómo me imaginaba. No soy ningún experto pero a lo mejor esto te ayuda:

Paint Shop Pro - PCX Format with Transparency (http://www.fishsim.net/cmanual/pcxfiles.htm)

A ver si te sirve.

Gracias, le estuve echando un ojo y probando a ver si funcionaba pero no dí con la tecla. No se si es porque la versión del programa es diferente o que. De todas formas sigo buscando una solución así que si alguien tiene alguna idea al respecto es bien recibida. Creo que el problema sigue estando en la definición de la transparencia en el formato PCX. Cuando se pasa de una imagen con calidad en 24 bits a otra con 256 colores para el PCX por lo visto se toma por defecto cómo color de la capa de transparencia el negro (0,0,0) y creo que es de ahí de donde viene le problema. Seguro que hay alguna forma de modificar la transparencia en la paleta de colores del PCX para que en lugar del negro sea otro color cómo el fucsia de la imagen o cualquier otro definido.

De momento voy a probar a ver si encuentro un método para cambiar el color negro puro (0,0,0) de la sprite-sheet por un negro menos negro (11,21,16) a ver si de esa forma al hacer la conversión a PCX de 256 colores lo mantiene este último cómo no transparente ya que de esa forma el (11,21,16) se seguirá viendo una vez que se monte la animación sin transparencias.

[tSuKiYoMi]

Acabo de ver lo del Super GameBoy. ¿En qué quedó eso? ¿realmente funciona?

[jduranmaster]

A pesar de los problemas con la paleta de colores la animación se ve fluida, y para haber hecho un rebaja en los colores no se no ta tanto cómo me imaginaba. No soy ningún experto pero a lo mejor esto te ayuda:

Paint Shop Pro - PCX Format with Transparency (http://www.fishsim.net/cmanual/pcxfiles.htm)

A ver si te sirve.

Gracias, le estuve echando un ojo y probando a ver si funcionaba pero no dí con la tecla. No se si es porque la versión del programa es diferente o que. De todas formas sigo buscando una solución así que si alguien tiene alguna idea al respecto es bien recibida. Creo que el problema sigue estando en la definición de la transparencia en el formato PCX. Cuando se pasa de una imagen con calidad en 24 bits a otra con 256 colores para el PCX por lo visto se toma por defecto cómo color de la capa de transparencia el negro (0,0,0) y creo que es de ahí de donde viene le problema. Seguro que hay alguna forma de modificar la transparencia en la paleta de colores del PCX para que en lugar del negro sea otro color cómo el fucsia de la imagen o cualquier otro definido.

De momento voy a probar a ver si encuentro un método para cambiar el color negro puro (0,0,0) de la sprite-sheet por un negro menos negro (11,21,16) a ver si de esa forma al hacer la conversión a PCX de 256 colores lo mantiene este último cómo no transparente ya que de esa forma el (11,21,16) se seguirá viendo una vez que se monte la animación sin transparencias.

Al final probé la solución que comenté en mi anterior post y ha funcionado correctamente. El sprite animado de Marco (que tenía menos ptos en negro) ahora se ve sin transparencias y perfectamente integrado con el fondo. En el caso del "tanque-mecha" del "Metal Slug 5" también se nota la mejoría aunque sigue habiendo alguna transparencia porque no apliqué el cambio del RGB (11,21,26) en todos los puntos de color negro puro. Pero vamos con este truco lo he arreglado fácilmente.

Color Palette Issue Solved With PCX Format {06/04/2016} - (GameBoy Advance Homebrew) (DEVKITADV)

https://www.youtube.com/watch?v=2-Ei4imH6-Y

-----Actualizado-----


Acabo de ver lo del Super GameBoy. ¿En qué quedó eso? ¿realmente funciona?

Si que funciona el nuevo API (en realidad es una librería) en el GBDK para usar las funcionalidades del Super GameBoy, entre ellas el marco. Cuando tenga algo de tiempo lo enseñaré por aquí.

Saludos.

[tSuKiYoMi]

Muy buena pinta tiene tras el arreglo.

[jduranmaster]

He avanzado algo con el engine-2D y me he dado cuenta de que hay una parte común que se puede utilizar para cualquier tipo de juego, no sólo de tipo Run & Gun, y dado que siempre me ha molado la idea de hacer un beat´em Up tengo en mente hacer un juego de este estilo pero no para GBA, sino para DS (algún avance tengo pero hasta que no haya nada más concreto no lo enseñaré). La movida es que me gustaría que el juego pudiese rular también en una 3DS más moderna, pero cómo estoy desconectado de la scene de 3DS no se si alguien me podría indicar si el SDK de NDS permite desarrollar roms compatibles con 3DS.


Muy buena pinta tiene tras el arreglo.

Tal y cómo comentaba en el caso del mecha se me quedaron algunos puntos en negro por sustituir con el nuevo valor RGB. Pero si, no quedó mal del todo.

[jduranmaster]

47543

Volviendo al desarrollo para Gameboy...estoy intentando trasladar lo aprendido para GBA a la GB/GBC para hacer un esqueleto de programa que permita a un sprite animado scroll en la pantalla con un fondo. En el video se puede apreciar el proceso de cómo crear el fondo y cómo añadir la lógica de programación para hacer el scroll. NOTA: se me olvido recompilar el fichero .c con los tiles definidos y en el programa final sólo se ven los tiles del background de un único tipo.


https://www.youtube.com/watch?v=sWG2AGZK8eY

[josepzin]

Me imagino que conoces este proyecto: http://imanoleasgames.blogspot.com.ar/2016/06/rocket-man-demo.html


https://www.youtube.com/watch?v=jAUgdxCghyM

[Solo]

Volviendo al desarrollo para Gameboy...estoy intentando trasladar lo aprendido para GBA a la GB/GBC para hacer un esqueleto de programa que permita a un sprite animado scroll en la pantalla con un fondo. En el video se puede apreciar el proceso de cómo crear el fondo y cómo añadir la lógica de programación para hacer el scroll. NOTA: se me olvido recompilar el fichero .c con los tiles definidos y en el programa final sólo se ven los tiles del background de un único tipo.


La verdad es que he visto bastantes juegos homebrew hechos para sistemas portátiles más avanzados que la gameboy original. Estaría bien que por fin alguien hiciese un tutorial de cómo animar sprites para esta consola. A ver si te animas y lo traes pronto.

[josepzin]

En Fasebonus me suena que hay uno tutorial de programación para GB.

[jduranmaster]

Video en el que muestro cómo crear el engine 2D de un juego básico tipo Snake para GameBoy Advance usando el DevKit-ADV y lenguaje de programación C. Es todo programación a pelo sin usar librerías externas (ya sean menos recientes {tonc} o más recientes {smgbalib}) que facilitan la vida para manejar sprites, backgrounds, sonido, entrada de botones del pad, etc.

47704


https://www.youtube.com/watch?v=4-b_JJQzx20

La idea con estos videos es ir subiendo en la dificultad de los juegos hasta llegar a algo más complicado tipo run & gun o beat´em up de cuyos engines llevo trabajando desde hace meses ya sea para GB, GBA o NDS.

Saludos.

[SplinterGU]

muy buen trabajo jduranmaster, si todavia queres saber como cambiar la paleta de colores en el gimp avisame y te digo

[jduranmaster]

Pronto subiré el enlace de descarga de la ROM.


muy buen trabajo jduranmaster, si todavia queres saber como cambiar la paleta de colores en el gimp avisame y te digo

Gracias Splinter, lo resolví usando el Paint Shop Pro, aunque aprender a hacerlo también con gimp no está de más.

[SplinterGU]

es medio rebuscado, luego me fijo como lo hice y te paso la formula...

[jduranmaster]

He añadido el link de descarga de la ROM. Está en la descripción del video por si a alguien le interesa probar la ROM en un amulador o en hardware real.

[SplinterGU]

con gimp

vas a Imagen->Modo->Indexado...

y convertis segun lo que quieras, yo solo deje 256 colores y luego todo desactivado y ningun suavizado de pixel

ahi ya tenes el mapa de 8bits

luego vas a Ventanas->Dialogos empotrables->Mapa de colores

ahi ya tenes la paleta de colores, le das doble click al color que queres editar, en este caso el pixel 0 es el primero que aparece, entonces dobleclick, le das a R = 255 y a B = 255, le das "Aceptar" y ahi tenes tu grafico con el color transparente que se vera en magenta.

[swapd0]

https://www.youtube.com/watch?v=4-b_JJQzx20

¿Estabas copiando el código de un listado? Lo digo porque se me hace raro ver programar algo todo del tirón, sin ir copiando, moviendo código, renombrado variables, etc.

[jduranmaster]

¿Estabas copiando el código de un listado? Lo digo porque se me hace raro ver programar algo todo del tirón, sin ir copiando, moviendo código, renombrado variables, etc.

No. Es un bot de teclado que hice en otro lenguaje. Le paso el fichero o los ficheros que componen el programa, en este caso los .c y .h (aunque podría ser cualquier fichero de texto) y el solito va línea a línea tecleando lo que hay en los ficheros originales. Así evito equivocaciones...

[jduranmaster]

Creating a Raycaster Engine for Game Boy Advance using C Programming Language (DevKitAdv Dev. Kit)


https://www.youtube.com/watch?v=A-RhY39kg1Y

Se trata de una versión algo optimizada del intento de raycaster para GBA publicado en el hilo correspondiente hace ya unos cuantos años. La idea ahora es portarlo a NDS/NDSi a ver que tal se porta. De momento sólo tengo está versión "poco mejorada" para GBA.

[jduranmaster]

Video en el que muestro cómo crear el engine 2D de un juego básico tipo Frontenis para GameBoy Advance usando el DevKit-ADV y lenguaje de programación C. Es todo programación a pelo sin usar librerías externas (ya sean menos recientes {tonc} o más recientes {smgbalib}) que facilitan la vida para manejar sprites, backgrounds, sonido, entrada de botones del pad, etc.

47981


https://www.youtube.com/watch?v=2hRvNeMT4cA

La versión avanzada de este juego es el clón de PONG para GBA que ya tengo hecha y que dejaré caer por aquí dentro de poco. De hecho me ha quedado tan bien estructurado que lo puedo aprovechar para hacer una versión con motivo de las elecciones de EEUU. En la descripción del video podréis encontrar el enlace de descarga de la ROM.

Saludos.

[tSuKiYoMi]

Que bueno. Esa versión de Pong tengo que verla, jejeje.

[jduranmaster]

Video en el que muestro cómo crear el engine 2D de un juego básico tipo PONG para GameBoy Advance usando el DevKit-ADV y lenguaje de programación C. Es todo programación a pelo sin usar librerías externas (ya sean menos recientes {tonc} o más recientes {smgbalib}) que facilitan la vida para manejar sprites, backgrounds, sonido, entrada de botones del pad, etc.

48083


https://www.youtube.com/watch?v=ZhmOZaAOSeo

El juego permite seleccionar entre dos jugadores: República Popular China o EEUU. En función de esto los finales que el jugador varían tanto cuando gana cómo cuando pierde. Ahora mismo no recuerdo en cuanto estaba el número de puntos para considerar que un jugador ha ganado la partida (me suenan que eran 30 aunque en el video se ve que son menos).

En la descripción del video he añadido el enlace de descarga de la ROM para que la gente interesada lo pueda probar. Al igual que con otros juegos, la ROM funciona también en hardware real.

Saludos.

[tSuKiYoMi]

Pasote. Lo he bajado y está bastante chulo. Siempre me saltaron las dudas, pensaba que el devkitadv era muy básico.

[jduranmaster]

Pasote. Lo he bajado y está bastante chulo. Siempre me saltaron las dudas, pensaba que el devkitadv era muy básico.

Es básico en el sentido de que no da muchas facilidades para hacer casi nada y prácticamente tienes que montarte tus propias librerias para hacer cosas. Por ejemplo está la librería "tonc" que ofrece un montón de opciones para manejar gráficos y modos. Esa librería me gusta bastante. Luego tienes el devkitpro que es un SDK más completo que el devkitadv ya que este se quedó un poco descontinuado. Además DEVKITPRO permite sin muchos cambios desarrollar ROMs compatibles tanto para GBA cómo NDS.

Algún que otro juego con devkitpro traeré por aquí.

[Solo]

Yo había oido también en su momento que el devkit-adv era bastante limitado, pero ahora gracias a tu explicación entiendo que a pesar de estar descontinuado desde la salida del devkitpro es más una cuestión de "do-it-yourself" lo cual no es malo, porque así te empapas del desarrollo para la consola desde el principio y si luego quieres cambiar a un devkit que te da más facilidades o utilizar una librería externa para ayudarte eso ya son cosas de cada uno. Lo que no sabía es que con devkit pro se podían sacar roms ejecutables para gba y la DS a partir de los mismos fuentes o compartiendo muchas cosas.

[jduranmaster]

Video en el que muestro cómo crear el engine 2D de un juego básico tipo TETRIS para GameBoy Advance usando el DevKit-ADV y lenguaje de programación C. Es todo programación a pelo sin usar librerías externas (ya sean menos recientes {tonc} o más recientes {smgbalib}) que facilitan la vida para manejar sprites, backgrounds, sonido, entrada de botones del pad, etc.

49114


https://www.youtube.com/watch?v=HeGxAH5ejv4

En la descripción del video he añadido el enlace de descarga de la ROM para que la gente interesada lo pueda probar. Al igual que con otros juegos, la ROM funciona también en hardware real.

Saludos.

PD: el motor beat´em up en el que estoy trabajando para DS/3DS va bastante bien. El año que viene será momento de ir mostrando el desarrollo del juego, aunque antes de eso haré algún video más animando sprites en GBC y GBA.

[tSuKiYoMi]

Lo he estado probando y va muy suave no como otros clones de Tetris que he probado en donde las piezas van a trompicones.

[jduranmaster]

Lo he estado probando y va muy suave no como otros clones de Tetris que he probado en donde las piezas van a trompicones.

He intentado sobre todo que el control no fuese un impedimento para jugar. XD.

[GameMaster]

gracias crack

[OscarBraindeaD]

Enhorabuena, muy buena versión. Se juega muy bien.
Si decides continuarlo (sé que una vez terminado un juego da pereza meterte a hacer modificaciones) además de incluir sonido, miraría la posibilidad de rotar las piezas desde el inicio. Me ha parecido que sólo puedes rotarlas una vez que han salido 2 cuadrados o hileras de las que componen la ficha. Poder rotarla desde que aparece el primer cuadrado o hilera de ésta en pantalla, puede ayudar en los niveles más avanzados o cuando ya hay muchas fichas en pantalla y poco tiempo para reaccionar. No sé si mi he explicado bien. También estaría bien que metieses niveles con algunas fichas de 1x1 ya creadas en él, para dificultar un poco la cosa, como en el arcade.
Pero vamos, muy buena versión. Gracias por publcarla.

Saludos.

[jduranmaster]

Enhorabuena, muy buena versión. Se juega muy bien.
Si decides continuarlo (sé que una vez terminado un juego da pereza meterte a hacer modificaciones) además de incluir sonido, miraría la posibilidad de rotar las piezas desde el inicio. Me ha parecido que sólo puedes rotarlas una vez que han salido 2 cuadrados o hileras de las que componen la ficha. Poder rotarla desde que aparece el primer cuadrado o hilera de ésta en pantalla, puede ayudar en los niveles más avanzados o cuando ya hay muchas fichas en pantalla y poco tiempo para reaccionar. No sé si mi he explicado bien. También estaría bien que metieses niveles con algunas fichas de 1x1 ya creadas en él, para dificultar un poco la cosa, como en el arcade.
Pero vamos, muy buena versión. Gracias por publcarla.

Saludos.

Gracias. Estoy pensando en meterle efectos de sonido, pero el tema de músicas ya es más jodido porque una de las librerías que tenía pensado usar "apex-sound" no la encuentro por ningún lado y me da pereza tener que currarme alguna melodía a pelo usando los registros. Lo que dices de poder rotar la pieza antes para poder tener mayor de tiempo de reacción se puede cambiar fácilmente igual que lo de meter niveles con piezas 1x1 ya creadas de antemano. Sólo que en este último caso no me dió por meter opciones en de "dificultad" y así se ha quedado, pero si finalmente hago una versión 1.0.1 lo meteré.

[OscarBraindeaD]

Por si te decides a meter música, yo usaba el MusicWave, iba bastante bien y funcionaba en GCC y Arm SDT. Aquí tienes su web: http://codewaves.com/gba/tools.php
y puedes descargarla, directamente, de: http://www.codewaves.com/files/GBA_MusicWave12.zip, he probado el link y aún funciona!

[jduranmaster]

OK. gracias. Probaré MusicWave a ver que tal va.

[Solo]

Bajando. Gracias por compartirlo.

[jduranmaster]

Bueno después de un mes o así sin postear nada, dejo por aquí una captura del motor (en acción) de juegos plataformas 2D hecho en JAVA que siempre quise hacer y que ahora en vacaciones de navidad me dió por fin por empezar. No utilizo nada de librerias tipo libgdx para el manejo de gráficos ya sean sprite-sheets o backgrounds, está todo hecho a pelo usando Java 1.8. Para la manipulación de los sprites y demás estoy utilizando una herramienta que permite modificar gráficos para desarrollar en GBA/NDS llamada "Usenti" que es una maravilla y me permite generar las transparencias cómo yo quiero y deforma muy sencilla. Para el tema del audio si que uso una lib externa llamada "mp3spi-1.9.5-1". La escogí porque ocupa muy poco (25 Kb) y además permite manejar fácilmente ficheros de audio en formato MP3 y WAV.

49684

La mayoria de sprites de los objetos de esta demo están sacados del "Wario Land 4" (sprites-resource(dot)com). Cuando esté más avanzado haré una release que se pueda probar en PC.

Saludos.

[Zoltar]

Están chulos los gráficos, ¿de dónde los has sacado?

[jduranmaster]

Están chulos los gráficos, ¿de dónde los has sacado?

sprites-resource(dot)com

[tSuKiYoMi]

Que maravilla. ¿No ibas a hacer un tutorial para animar sprites en GBA / NDS? ¿es más compliado que en el caso de este engine 2d para java?

[Zoltar]

sprites-resource(dot)com
Supongo que querrás decir:

https://www.spriters-resource.com/

[jduranmaster]

Que maravilla. ¿No ibas a hacer un tutorial para animar sprites en GBA / NDS? ¿es más compliado que en el caso de este engine 2d para java?

Si, lo tengo pendiente. A ver si saco un poco de tiempo y lo hago. El caso es que usando la herramienta que comentaba ("Usenti") todo el tema de modificar gráficos y demás es un paseo, ya ves que usar los sprite-sheets de Wario Land 4 no cuesta nada a la hora de usar estos gráficos en un juego para PC y es gracias a esa herramienta, para el caso de GBA / NDS es igual de simple. Respecto al tema de programación ahí la cosa cambia ya que para GBA/NDS hay que usar los registros que te da el hardware de las consolas, no es como el engine-2D hecho en Java que no deja de ser un lenguaje de alto nivel. De todas formas no es muy complicado animar sprites y moverlos cómo "un objeto" único en GBA o en NDS.

-----Actualizado-----


Supongo que querrás decir:

https://www.spriters-resource.com/

Si, esa es. De hecho no sólo tiene sprites "robados" de juegos oficiales sino que tiene una sección de "sprites-custom" rica rica...

[jduranmaster]

Hace poco me preguntaron por twitter acerca de las mierdas que estaba haciendo para consolas modernas y retro (GBA/GBC/NES/NDS) así que pongo algo de eso por aquí. Falta el proyecto "gordo" para NDS/3DS pero ya se andará. Todo irá saliendo poco a poco este año y a comienzos del que viene.

49682

[OscarBraindeaD]

Lo de la segunda fila, primera columna... tiene pinta de quake para GBA?
Se puede ver en movimiento?

[jduranmaster]

Lo de la segunda fila, primera columna... tiene pinta de quake para GBA?
Se puede ver en movimiento?

Es un port del motor Yeti3D-PRO (la última versión que hay) que se portó a Pandora no hace mucho (dos años máximo) y si, es para GBA, pero el proyecto ahora mismo es multi-plataforma. Lo puedo compilar para GBA y NDS/3DS. La idea es hacer un first person shooter con él aunque se podrían hacer otro tipo de juegos 3D también. Ya tengo una buena colección de modelos MD2 de armas y enemigos así que es sólo cuestión de tiempo que vaya generando los nuevos mapas porque esos de la imagen son de prueba para ver cómo importar texturas de otros juegos. La rom generada para GBA va muy fluida eso te lo aseguro, el problema es que ahora no tengo a mano nada para grabar un video rápido, pero ya iré subiendo los avances.

[pakoito]

Bueno después de un mes o así sin postear nada, dejo por aquí una captura del motor (en acción) de juegos plataformas 2D hecho en JAVA que siempre quise hacer y que ahora en vacaciones de navidad me dió por fin por empezar. No utilizo nada de librerias tipo libgdx para el manejo de gráficos ya sean sprite-sheets o backgrounds, está todo hecho a pelo usando Java 1.8.
¿Qué usas para gestión de eventos, ventanas, y pintar entonces? ¿Directamente contra OGL, o Swing/JavaFX?

[jduranmaster]

Java AWT / Java Swing.

Te pego unos imports para que te hagas una idea.



import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import java.awt.image.BufferedImage;

import javax.swing.JPanel;

[jduranmaster]

Lo de la segunda fila, primera columna... tiene pinta de quake para GBA?
Se puede ver en movimiento?

Aquí tienes el Yeti3D-PRO en movimiento en el VisualBoy Advance. La versión del motor que tengo portada para GBA es la última release para PANDORA y es de 2013. Ya casí tengo todos los elementos que necesito para la construcción de niveles. Ahora mismo me estoy pegando con "las puertas". Una vez tenga eso ya es cuestión de usar las herramientas para modelar los escenarios y meter por código la lógica del "First Person Shooter" que quiero hacer. Hace poco encontré un montón de modelos MD2 de enemigos/personajes de Quake 2 / DOOM / DOOM 2 / HEXEN 2, etc... así que utilizaré estos para el juego.

49743

PD: espero que el GIF animado se vea bien. Si no tira probad con Chrome o con FireFox.

EDIT: creo que no se ve bien, porque al pinchar en la imagen aparece un JPEG, WFT?¿?!? y eso que he subido un GIF. Bueno luego cuando llegue a casa lo cambio.

[jduranmaster]

Bueno después de una temporada sin postear nada nada, os dejo un video nuevo ene l que muestro como crear un engine de raycasting bastante básico para GBA en el que meto algunos personajes de DooM. Seguí un tutorial bastante bueno de esta web ( Ray-Casting tutorial (http://www.permadi.com/tutorial/raycast/rayc1.html) ) y el rendimiento mejora bastante con respecto a otro motor de raycasting para GBA que desarrollé hace cosa de año y medio.



https://www.youtube.com/watch?v=WobrKQHfe9Y&t=927s

Para las texturas de las paredes he usado algunas de las texturas originales de DooM 2 reconvertidas a la resolución de GBA y aplicando otra paleta de colores diferente así como algunas texturas "custom" para dicho juego realizadas por algunos "modders". Los sprites (sin animación de los personajes) están sacados de un juego 2D tipo plataformas que tiene temática DooM (no recuerdo el nombre del juego). La velocidad de movimiento del juego una vez que se ha cargado la ROM es tal cual se ve en el video.


50880




SCREEN-SHOT {1} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25353725_947315768756987_1158541987652356821_n.jpg ?oh=2662248504ca0c621a2c601c20b5a682&oe=5AD46E45)

SCREEN-SHOT {2} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25498014_947315772090320_383456574385654507_n.jpg? oh=11a5fcace4f569124ad1b15e7e948d1d&oe=5AC28400)



SCREEN-SHOT {3} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25399144_947315765423654_7204471813988630431_n.jpg ?oh=bcd7dbb94984c169f96c9c899d83d454&oe=5AC7E9D8)

SCREEN-SHOT {4} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25398885_947315788756985_3628098073317815614_n.jpg ?oh=926dd6fad1789100dd6fb4ced7f0cd5e&oe=5ABCE7B2)



SCREEN-SHOT {5} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25398646_947315798756984_6160080167936169062_n.jpg ?oh=c7ede17384f8eb4c683f0ce7c1dabe06&oe=5AC01C60)

SCREEN-SHOT {6} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25399057_947315802090317_2960097453674340225_n.jpg ?oh=214cd96e76c17f10dc8bf945f546686b&oe=5AB9AFB4)



SCREEN-SHOT {7} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25443308_947315832090314_6865328176138329075_n.jpg ?oh=c9fd0d5c2a1a7c8bc5a59c2cc8d07636&oe=5AD1CE35)

SCREEN-SHOT {8} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25398971_947315838756980_540614190639558052_n.jpg? oh=190e64743aa61a476ebe79d100e80152&oe=5AD06924)



SCREEN-SHOT {9} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25442897_947315855423645_4428913094405074212_n.jpg ?oh=b128e92cc374daac557d0973a668038d&oe=5AB437D0)

SCREEN-SHOT {10} (https://scontent-mad1-1.xx.fbcdn.net/v/t1.0-9/25399144_947315765423654_7204471813988630431_n.jpg ?oh=bcd7dbb94984c169f96c9c899d83d454&oe=5AC7E9D8)

[SplinterGU]

excelente! felicitaciones...

el link al tutorial da "Page not found"

[jduranmaster]

excelente! felicitaciones...

el link al tutorial da "Page not found"

Arreglado.

[tSuKiYoMi]

El tutorial del enlace está bastante chulo. Va desde lo más sencillo del proceso a lo más complejo.

[jduranmaster]

Estoy avanzando bastante con el tema del juego 3D basado en Yeti3D-Pro para las portátiles de Nintendo. Ya tengo montado el proyecto para devkitPRO que me permite compilar todo y generar la ROM para 3 targets diferentes GBA, NDS y 3DS (además de generar el binario para la plataforma de origen, el PC de desarrollo) aunque en principio se podría portar a más sistemas (cómo se hizo en su día por ejemplo GP2X Wiz / Caanoo) e incluso se puede utilizar para desarrollar juegos 3D para Android. Lo que me está gustando de Yeti3D-Pro es lo versátil que es para hacer juegos 3D de diferente temática. Supongo que al principio de los tiempos estaba pensado para desarrollar "shooters en primera persona" (FPS) pero se puede perfectamente utilizar para realizar juegos tipo "survival horror", juegos de lucha, plataformas 3D o incluso juegos de carreras.


50932

Además el editor de niveles del Yeti3D-Pro es mucho más completo que el de la versión anterior que era más "tosco". El admite comandos a través de la consola lo que hace que sea también más fácil de añadir los elementos al "mapeado" y diseñar el entorno, además de permitir probar los cambios que se programan en el entorno / nivel directamente sobre el editor sin tener que recompilar la ROM ya que el editor incorpora una función que carga el mapa "in-situ". Y luego las herramientas de modelado para generar los "objetos" (enemigos, items, etc...) que se pueden utilizar son muy variadas, la única pega es que hasta la fecha sólo se admiten modelos en formato MD2 (el formato que usaba Quake 2) pero aún así hay muchas herramientas que permiten modelar y hay bastantes repositorios con modelos ya construidos incluyendo personajes clásicos como Mario o Sonic, pero los hay de muchas y variadas temáticas (no se ciñen sólo a desarrollar modelos y "Skins" para juegos tipo FPS).


El tutorial del enlace está bastante chulo. Va desde lo más sencillo del proceso a lo más complejo.

Si, y lo bueno de ese tutorial es que expone los principios básicos de forma independiente del lenguaje con lo que luego lo puedes aplicar y realizar la implementación real en el lenguaje que mejor controles.

[swapd0]

No sabia que aun se usase este motor, yo pensé que se quedo en algo a medias.

[jduranmaster]

No sabia que aun se usase este motor, yo pensé que se quedo en algo a medias.

De hecho ha salido algún que otro juego para movíles (iPhone y android) que hacen uso de él. Aunque son pocos títulos, pero los hay. :+1:

[saboteur]

Es el mismo que salió para Wiz? O han metido actualizaciones a saco?

[jduranmaster]

Es el mismo que salió para Wiz? O han metido actualizaciones a saco?

En su día me bajé los fuentes del Yeti3D original e hice el port de uno de los "mini-juegos" (por así llamarlo) para Wiz y GBA. Se trataba del código fuente de la primera versión del motor que fué desarrollado para DreamCast y otras plataformas: Port para GBA de Yeti3D-Engine original (https://www.gp32spain.com/foros/showthread.php?74549-HILO-OFICIAL-GameBoy-Advance-amp-GameBoy-Development&p=1143665#post1143665).

Este Yeti3D-Pro es una versión del motor más trabajada con un editor de niveles que cómo digo es mucho más potente que el original ya que permite de forma más sencillo el modelado de mapas y la carga de texturas.

Yeti3d-Demo / GP2x-Wiz (http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,38,493)
Port para GP2X-Wiz de Yeti3D-Engine original (https://www.gp32spain.com/foros/showthread.php?77269-Motor-Gr%E1fico-Yeti3D-para-Wiz-Port)

[swapd0]

Entonces estas usando este, no?
https://sourceforge.net/projects/yeti3dpro/

[jduranmaster]

Entonces estas usando este, no?
https://sourceforge.net/projects/yeti3dpro/

Si. Ese es el que estoy usando. El Yeti3d-Pro.

[saucjedi]

El que cuesta encontrar, o al menos a mí, es el original que tuvo incluso ports a PSX.

Cayó la web y con ella todo, por lo que parece... el PRO tiene bastantes modificaciones con respecto al original.

[jduranmaster]

saucjedi Puede que lo que estés buscando sea esta versión (ver GIF). Esta fué la primera versión con la que estuve trabajando hace tiempo cuando hice el port de GBA. Esta bien porque es una versión muy mínima del motor para ver como se hacen las cosas desde cero pero luego me cambié a una versión más avanzada Port de Yeti3D-Engine para GBA (https://www.gp32spain.com/foros/showthread.php?74549-HILO-OFICIAL-GameBoy-Advance-amp-GameBoy-Development&p=1143665#post1143665) que es la que acabé haciendo para GBA. Digamos que la versión para GBA es intermedia entre la básica que se ve en el GIF y el Yeti3D-Pro que es la más trabajada actualmente.


50939



Engine Technical Notes
======================

These are design notes for the Yeti engine. Other engines use very different algorithms.
Im still refining the engine to improve quality while maintaining a acceptable rendering
speed.

- The current viewport is 120x80 pixels, 15bit.
- All textures are 64x64 8bit.
- Textures are converted to 15bit via a pre-calculated lighting LUT.
- Polygons can be any convex shape. Only squares are currently used.
- Each vertex is described as X, Y, Z, U, V and brightness.
- The renderer uses 24:8 fixed point maths.
- Polygons are clipped in 3D space using 45 degree planes. Distance to plane
calculations therefore use only additions and subtractions.
- Polygon edges are clipped using one divide and 6 multiplies.
- 4 clipping planes are used. No front plane is required. No back plane is used.
- No per-span clipping is used. Fixed point errors are hidden offscreen.
- Ray-casting is used to build a visablity list and valid polygon rendering order.
- Models are merged into the VIS without sorting.
- No Z-buffers are used. Rendering is back-to-front (painters algorithm).
- The is an acceptable level of overdraw. Complete polygons are culled. Polygon edges
are drawn faster than using a per span clipper.
- Lighting is pre-calculated on startup. Lighting can be moved at runtime.
- Lighting is expanded per vertex and interpolated along polygon edges.
- A reciprocal table is used to eliminate all divides from the DDA texture mapper.
- The affine texture loop is unrolled and renders blocks of 32 pixels.


main.cpp


/*
** Name: Yeti3D
** Desc: Portable GameBoy Advanced 3D Engine
** Auth: Derek J. Evans
**
** Copyright (C) 2003 Derek J. Evans. All Rights Reserved.
*/

#include "yeti.h"

void behaviour(entity_t* const e)
{
if (KEY_LEFT)
{
e->tt -= (12 << 16);
e->r -= 800000;
}
if (KEY_RIGHT)
{
e->tt += (12 << 16);
e->r += 800000;
}

if (KEY_UP)
{
e->xx += fixsin16(e->t >> 16) >> 5;
e->yy += fixcos16(e->t >> 16) >> 5;
}
if (KEY_DOWN)
{
e->xx -= fixsin16(e->t >> 16) >> 5;
e->yy -= fixcos16(e->t >> 16) >> 5;
}
e->xx -= ((e->xx + (e->xx < 0 ? -15 : 15)) >> 4);
e->yy -= ((e->yy + (e->yy < 0 ? -15 : 15)) >> 4);
e->tt -= ((e->tt + (e->tt < 0 ? - 3 : 3)) >> 2);

e->r -= ((e->r + (e->r < 0 ? -7 : 7)) >> 3);

e->x += e->xx; e->y += e->yy; e->z += e->zz;
e->r += e->rr; e->t += e->tt; e->p += e->pp;

entity_to_world_collision(e, 0x8000);
}

void world_create(world_t* world)
{
world->screen = (viewport_t*) 0x06000000;
world->buffer = (viewport_t*) 0x0600A000;

camera->x = MAP_SIZE << 15;
camera->y = MAP_SIZE << 15;
camera->z = 3 << 15;
camera->p = 100 << 16;
}

int main(void)
{
int x, y;

*(short*)0x4000000 = 0x405;
*(short*)0x4000020 = 0;
*(short*)0x4000022 = -128;
*(short*)0x4000024 = 128;
*(short*)0x4000026 = 0;
*(short*)0x4000028 = i2f(120);
*(short*)0x400002C = i2f(4);

world_create(&world);

entity_t* box = entity_create(33 << 16, 35 << 16, 1 << 16);
entity_create(33 << 16, 33 << 16, 1 << 16);

for (y = 0; y < MAP_SIZE; y++)
{
for (x = 0; x < MAP_SIZE; x++)
{
world.cells[y][x].l = 0;
world.cells[y][x].bot = 0;
world.cells[y][x].top = 4;
world.cells[y][x].wtx = 0;
world.cells[y][x].btx = 2;
world.cells[y][x].ttx = 1;

if (x == 0 || y == 0 || x == (MAP_SIZE - 1) || y == (MAP_SIZE - 1))
{
world.cells[y][x].top = 0;
world.cells[y][x].bot = 0;
}
}
}

for (x = 1; x < MAP_SIZE - 1; x++)
{
for (y = 1; y < MAP_SIZE - 1; y += 10)
{
if (rand() % 10)
{
world.cells[y][x].top = 0;
world.cells[y][x].bot = 0;
world.cells[x][y].top = 0;
world.cells[x][y].bot = 0;

world.cells[y][x].wtx = 0;
world.cells[x][y].wtx = 0;
}
else
{
world.cells[y][x].top--;
}
}
}
for (x = 0; x < 400; x++)
{
cell_t* cell = &world.cells[rand() % MAP_SIZE][rand() % MAP_SIZE];

cell->bot += 2;
cell->wtx = 3;
cell->btx = 3;
}

for (y = 0; y < MAP_SIZE; y += 1)
{
for (x = 0; x < MAP_SIZE; x += 1)
{
world.cells[y][x].l = 0;
}
}

for (y = 1; y < MAP_SIZE; y += 5)
{
for (x = 1; x < MAP_SIZE; x += 5)
{
draw_light((x << 16) + 0x8000, (y << 16) + 0x8000, 900);
world.cells[y][x].ttx = 5;
world.cells[y][x].btx = 6;
}
}

while (!KEY_SELECT)
{
behaviour(camera);
box->t += 50 << 16;
box->r += 40 << 16;
box->p += 30 << 16;

draw_world();
}

return 0;
}




yeti.cpp


/*
** Name: Yeti3D
** Desc: Portable GameBoy Advanced 3D Engine
** Auth: Derek J. Evans
**
** Copyright (C) 2003 Derek J. Evans. All Rights Reserved.
*/

#include "yeti.h"

/*
** Name: entity_create
** Desc: Creates a new entity and returns a entity pointer.
*/
entity_t* entity_create(int x, int y, int z)
{
entity_t* e = &entities[nentities++];
e->x = x;
e->y = y;
e->z = z;
return e;
}

/*
** Name: draw_light
** Desc: Renders a spot light at a given cell location.
*/
void draw_light(const int lightx, const int lighty, const int diffuse)
{
world.time++;

for (int i = 0; i < 2048; i += 8)
{
int x = lightx + 0x8000, xx = fixsin16(i) >> 1;
int y = lighty + 0x8000, yy = fixcos16(i) >> 1;
int l = i2f(63), d = 0;

for (; l >= 0; x += xx, y += yy)
{
cell_t* cell = &world.cells[y >> 16][x >> 16];

if (CELL_ISSOLID(cell)) break;

if (world.time != cell->time)
{
int nl = cell->l + f2i(l);
cell->l = min(nl, 63);
cell->time = world.time;
}
l -= d += diffuse;
}
}
}

/*
** Name: entity_to_world_collision
** Desc: Simple map to entity collision.
*/
void entity_to_world_collision(entity_t* const e, int const radius)
{
int x, y;
cell_t* c;

#define IS_COLLISION ((e->z > (c->top << 16)) || (e->z < (c->bot << 16)))

c = &world.cells[e->y >> 16][(x = e->x - radius) >> 16];

if (IS_COLLISION)
{
e->x += 0x10000 - (x & 0xFFFF);
e->xx = 0;
}

c = &world.cells[e->y >> 16][(x = e->x + radius) >> 16];

if (IS_COLLISION)
{
e->x -= (x & 0xFFFF);
e->xx = 0;
}

c = &world.cells[(y = e->y - radius) >> 16][e->x >> 16];

if (IS_COLLISION)
{
e->y += 0x10000 - (y & 0xFFFF);
e->yy = 0;
}

c = &world.cells[(y = e->y + radius) >> 16][e->x >> 16];

if (IS_COLLISION)
{
e->y -= (y & 0xFFFF);
e->yy = 0;
}
}



yeti.h


/*
** Name: Yeti3D
** Desc: Portable GameBoy Advanced 3D Engine
** Auth: Derek J. Evans
**
** Copyright (C) 2003 Derek J. Evans. All Rights Reserved.
*/

#ifndef __YETI3D_H__
#define __YETI3D_H__

#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <string.h>
#include <limits.h>

#define RGB_SET(r,g,b) (((b)<<10)+((g)<<5)+(r))

inline int abs(const int a)
{
return a < 0 ? -a : a;
}

inline int min(const int a, const int b)
{
return a < b ? a : b;
}

...
#endif



data.cpp


#include "data.h"
const texture_t textures[] = {
{
{1,3,3,3,3,5,6,5,5,2,3,3,3,2,2,4,3,3,3,2,2,2,3,4,4 ,5,3,4,4,4,3,2,1,6,7,8,7,7,9,8,9,10,11,10,9,8,7,7, 7,7,6,6,6,6,5,5,5,6,6,5,3,4,2,0},
{2,4,4,2,5,7,6,65,5,4,5,65,4,3,4,5,5,6,5,5,4,3,5,7 ,7,9,6,5,5,6,5,2,4,5,7,7,11,10,9,11,11,10,10,11,11 ,11,10,11,9,9,10,9,10,9,8,9,8,8,8,8,8,5,7,2},
{3,6,4,4,4,5,5,5,6,4,9,7,6,5,6,6,6,7,6,5,5,5,7,8,9 ,7,7,5,6,6,6,5,5,5,7,6,7,7,9,10,10,9,9,9,9,68,9,7, 7,7,7,7,7,7,9,7,6,6,8,8,7,6,7,4},
{3,7,5,4,5,6,7,5,6,5,6,9,67,7,6,6,7,8,8,67,5,5,7,9 ,10,9,6,6,7,7,6,5,5,7,7,7,7,9,8,8,9,7,7,7,8,9,9,9, 8,8,8,8,7,7,7,7,8,11,7,7,7,8,8,5},
{3,6,5,5,5,7,6,6,7,5,5,67,7,6,5,5,5,6,9,7,6,5,8,8, 9,9,7,6,6,7,7,4,5,6,7,8,7,8,7,8,8,9,8,9,7,9,9,8,8, 9,9,8,8,7,7,7,8,9,8,8,8,8,6,4},
{3,5,5,5,5,6,6,6,6,7,5,5,5,5,6,8,7,8,68,6,4,5,5,8, 68,9,6,5,7,8,7,5,7,8,7,8,9,8,7,7,7,7,9,7,8,10,9,8, 7,8,7,7,7,7,7,7,8,8,8,7,7,7,6,3},
{3,5,5,4,5,6,7,8,7,6,5,6,7,7,6,7,8,8,8,7,6,65,6,6, 6,7,6,5,7,7,7,4,6,7,8,9,9,8,8,7,6,7,8,8,8,9,9,9,7, 7,8,7,7,7,7,7,7,8,7,8,7,7,5,3},
...
-603,
-402,
-201
};



Script de compilación con devkitadv (se puede usar también devkitPro). Se puede obviar la línea donde se llama a gbafix sino se tiene la herramienta pero al no hacerlo la ROM generada no tirará en hardware real al no tener la cabecera el tamaño adecuado.


g++ -marm -mthumb-interwork -mlong-calls -O3 -o game.elf data.cpp yeti.cpp draw.cpp main.cpp

objcopy -O binary game.elf yeti3d-engine-gba-e1m0.gba

gbafix yeti3d-engine-gba-e1m0.gba -p -tYeti3De1m0 -c7790 -m86 -r1

del game.elf
del *.o

[saucjedi]

Gracias jduranmaster, tiene toda la pinta de ser esta, incluso la fecha de los comentarios en los fuentes cuadra

[jduranmaster]

Yo creo que esta versión es "portable" sin mucha dificultad prácticamente a cualquier sistema. La única pega la pone el entorno de desarrollo. Por ejemplo en el caso de PlayStation el devkit "Psy-Q" sólo funciona en Windows-XP (no sé si hay algún otro devkit) por lo que hay que virtualizar.

[swapd0]

Lo poco que he visto del código es mas pequeño de lo que pensaba y tiene ideas curiosas como lo de los planos de clip a 45 grados y que no tiene plano de clip near.

Lo malo es que el viewport es ridículamente pequeño y no se si al hacerlo mas grande se verán problemas de precisión con las texturas o aristas de los polígonos.

[jduranmaster]

Lo malo es que el viewport es ridículamente pequeño y no se si al hacerlo mas grande se verán problemas de precisión con las texturas o aristas de los polígonos.

Seguramente pero depende también de como lo vayas a usar. Yo ahora mismo me estoy dedicando a portar el Yeti3D-PRO a Android que es el último "target" que me falta por tener disponible. A partir de ahí quiero ver hasta donde puedo llegar porque a pesar de que Yeti3D-PRO es más avanzado que las dos versiones anteriores del yeti3D (incluida la primera "release" que he dejado antes) tiene algunas lagunas a la hora de construir "puertas" o "elevadores" con el editor de mapas.

[jduranmaster]

Nuevos avances. Ya tengo el proyecto integrado en los "target" que pretendía: GBA, NDS, 3DS, Android y PC (default). El editor de mapas de Yeti3D-Pro es muy bueno la verdad (hasta donde he investigado) pero por desgracia no tiene retro-compatibilidad con los mapas diseñados con el editor antiguo de Yeti3D y tampoco veo que haya una herramienta para convertir mapas de Yeti3D a Yeti3D-Pro. Sea como sea el editor de mapas de Yeti3D-Pro me parece muy bueno y se aún se puede mejorar.


50971

Ahora me estoy dedicando a investigar las herramientas de modelado de objetos. Pensaba que aquí iba a tener algún problema pero las herramientas son suficientes para convertir modelos ya existentes al formato de Yeti3D o bien modelar los objetos desde cero. En el fondo la mayoría de estas herramientas admiten modelos en definidos según el formato MD2 ("Quake 2") con lo que es bastante fácil de manejar.



50972

[saboteur]

Una pregunta...

Jamás he intentado hacer nada parecido a un port de este tipo, pero si intentara portarlo a Wiz, ¿qué se necesitaría? Algo de hardware (aceleración, etc...), software (opengl, etc...)??? o es todo una librería software que escribe en la pantalla?

[jduranmaster]

Una pregunta...

Jamás he intentado hacer nada parecido a un port de este tipo, pero si intentara portarlo a Wiz, ¿qué se necesitaría? Algo de hardware (aceleración, etc...), software (opengl, etc...)??? o es todo una librería software que escribe en la pantalla?

El motor Yeti3D (tanto el normal como la versión Pro) es aceleración por software y no depende de ninguna librería externa como OpenGL. Sólo tiene dependencias con las librerías que necesites para mostrar el resultado de la "renderización" en una ventana. Por ejemplo, el target para Windows depende de SDL. Es más en su día cuando hice el port del Yeti3D para Wiz usé SDL, pero ya te digo que el engine en lo que a 3D se refiere es totalmente independiente.

[tSuKiYoMi]

Vaya pasada. La herramienta de modelado me suena. ¿Era una compatible también con MD3?

[jduranmaster]

Ayer estuve trasteando bastante con el editor de niveles. Cómo ya había comentado es bastante intuitivo de manejar y tiene los comandos necesarios. Lo que me ha costado más fué como averiguar la forma de añadir nuevos modelos al editor y con modelos me refiero a cualquier objeto ya fuesen armas, cajas de munición, enemigos, etc. Aquí os dejo unas capturas del "modo navegación" del editor con uno de los niveles por defecto que vienen en el editor y que me dediqué a modificar (a nivel de estructura) y en el que posteriormente añadí algunos objetos. Todos los modelos ya estaban por defecto en la versión de Yeti3D-Pro que está disponible salvo el modelo del BFG-10k de Quake 2 que añadí ayer y el modelo de enemigo ALX_PL4.MD2 (el robot de unos post más arriba) que aparece al final de la lista. Ahora me toca descubrir como hacer que en los "targets" GBA, NDS y 3DS del proyecto haya soporte para música y efectos de sonido pues en los "targets" Android y PC esto ya está cubierto.











Captura-1
50976


Captura-2
50977


Captura-3
50978





Vaya pasada. La herramienta de modelado me suena. ¿Era una compatible también con MD3?

Si. Es compatible con varios tipos de formatos. Con MD3 también. La herramienta se llama "Misfit Model 3D". Luego para ver como quedaría (más o menos) el modelo integrado en el motor tienes la herramienta "MD2Viewer".

[SplinterGU]

excelente!

[jduranmaster]

Ya tengo una buena colección de modelos en formato MDL, MD2 y MD3 aunque la mayoría son para pruebas pues me interesan sólo unos pocos para continuar con el desarrollo del juego para las diferentes plataformas.

La idea sería poder sacar una DEMO para GBA del Yeti3D-Pro con uno o dos escenarios como mucho y en los cuales el jugador tenga que enfrentarse a algunos enemigos para pasar de nivel. Debido a las limitaciones en el tamaño de las roms de GBA no puede haber muchos enemigos diferentes así que al menos serviría como base para los ports de NDS y 3DS dado que esta limitación no existe en las versiones de PC y Android.

[Solo]

Cómo mola. Espero que siga adelante el proyecto. :brindis:

[tSuKiYoMi]

Una pregunta. He leído que el Yeti3D admite modelos MD2 que son el tipo de objetos admitidos en Quake 2. ¿sólo admite ese tipo de modelos? es decir, ¿no se podrían usar los MDL de Quake o los MD3 de Quake 3?

[jduranmaster]

Una pregunta. He leído que el Yeti3D admite modelos MD2 que son el tipo de objetos admitidos en Quake 2. ¿sólo admite ese tipo de modelos? es decir, ¿no se podrían usar los MDL de Quake o los MD3 de Quake 3?

Si, sólo admite modelos MD2 de Quake 2. De hecho en el código fuente del motor se puede ver lo siguiente:



void animation_mode(animation_t* a, int mode, int speed, int loops)
{
const u8 frames[][2] =
{
{ 0, 40}, //MD2_ANIM_STAND
{ 40, 6}, //MD2_ANIM_RUN
{ 46, 8}, //MD2_ANIM_ATTACK
{ 54, 4}, //MD2_ANIM_PAIN1
{ 58, 4}, //MD2_ANIM_PAIN2
{ 62, 4}, //MD2_ANIM_PAIN3
{ 66, 6}, //MD2_ANIM_JUMP
{ 72, 12}, //MD2_ANIM_FLIPOFF
{ 84, 11}, //MD2_ANIM_SALUTE
{ 95, 17}, //MD2_ANIM_TAUNT
{112, 11}, //MD2_ANIM_WAVE
{123, 12}, //MD2_ANIM_POINT
{135, 19}, //MD2_ANIM_CROUCH_STAND
{154, 6}, //MD2_ANIM_CROUCH_WALK
{160, 9}, //MD2_ANIM_CROUCH_ATTACK
{169, 4}, //MD2_ANIM_CROUCH_PAIN
{173, 5}, //MD2_ANIM_CROUCH_DEATH
{178, 6}, //MD2_ANIM_DEATH1
{184, 6}, //MD2_ANIM_DEATH2
{190, 8} //MD2_ANIM_DEATH3
};
animation_init(a, mode, frames[mode][0], frames[mode][1], speed, loops);
}


La definición de los modelos se hace asumiendo la estructura del MD2 por eso en el método anterior que se usa para animar los modelos 3D que suelen tiener 199 frames de animación distribuidos en 21 animaciones completas. Si se quisiera tener "soporte nativo" para modelos MDL de Quake o MD3 de Quake 3 se podría picar el código correspondiente para cargar y manejar dichos modelos sin tener que usar herramientas de conversión de modelos que permitan pasar de MDL a MD2, de MD3 a MD2 o de OBJ a MD2. Estás herramientas existen y funcionan. Sin embargo esas herramientas convierten tal cual el modelo original a MD2 manteniendo los frames de animación del modelo original.

En los modelos MD2 el límite máximo de frames está en 512 frames de animación y en MD3 está en 1024, mientras que en MDL este límite superior está en 256. Si todos los modelos MD3 y MDL que conviertas siguen en el esquema del segmento de código anterior y tienen definidos 199 frames no hay problema a la hora de realizar la conversión. Sin embargo hay varios problemas cuando el modelo tiene menos frames de los soportados por el límite máximo de MD2 (cuando se supera el límite también y supongo que la herramienta no dejará realizar la conversión aunque nunca me he topado con un modelo MD3 de más de 512 frames pero seguro que los hay) porque la estructura anterior te queda descabalada a la hora de leer los "frames" de animación y ya no se puede leer la animación según el esquema anterior.

Esto se puede ver en la siguiente imagen. He probado a convertir rápidamente el modelo MDL "KNIGHT" de Quake a MD2. La herramienta que he usado me saca por pantalla que el número de frames de animación de este modelo es de 160 por tanto hasta 199 tengo 39 frames que pierdo o no tengo en el nuevo modelo MD2. Así con el modelo del ejemplo al cargar al "KNIGHT" en el editor el modelo aparece siempre repitiendo en LOOP la mitad de su animación de ataque (es decir levantando la espada y bajándola a media altura). ¿Eso significa que no puedo usarlo? No, simplemente que tengo que usar otro tipo de distribución para por ejemplo meter dicho modelo con la animación "MD2_ANIM_RUN" en el editor (que es la animación por defecto que se usa al cargar un modelo en el editor, es decir, en modo edición todos los modelos salen corriendo en el sitio cuando se cargan).

51228

Esto último se puede hacer por código para cada modelo en concreto y sacando con una herramienta de visionado de modelos cuantos frames pertencen a cada animación una vez convertido a MD2 y picando un handler para cada modelo MDL covertido a MD2 que tenga menos de 199 frames. Esto se me ocurre así a vote pronto, pero no es lo más óptimo.

Lo mejor sería coger la siguiente web MDL Specification (http://tfc.duke.free.fr/coding/mdl-specs-en.html) y picar en el código del engine la definición nativa de los modelos MDL para que el engine sea capaz de tratarlos directamente al leer el fichero MDL con el objeto3D y tenga funciones propias para tratar dichos modelos y animarlos.

[masteries]

Tengo por ahí una versión del motor Yeti3D Pro para GP2X a la que le añadí soporte para reproducir música en .ogg en el segundo procesador.

El rendimiento aumentó bastante; la calida gráfica del engine siempre me pareció estupenda para hacerlo todo por software,


Pero nunca profundicé como está haciendo jduranmaster respecto a cómo usar el editor de niveles y hacer algo jugable.

[jduranmaster]

Bueno, dejo por aquí dos videos con las pruebas que estuve realizando no hace demasiado, aunque ambos no reflejan el estado actual que es bastante más avanzado ya que he conseguido bastantes progresos desde entonces. El primero no es más que un "paseo" por uno de los mapas que vienen incluidos en el engine después de hacer algunas pruebas para la carga de modelos básicos.


https://www.youtube.com/watch?v=TsoNvnBzipM

Uno de los aspectos que llevo investigando desde entonces como asociar a cada modelo MD2 de enemigo otro modelo MD2 de un arma ya que en el estado actual de desarrollo cuando los enemigos disparan se activa su animación correspondiente "MD2_ANIM_ATTACK" y se ponen en postura de ataque pero sólo se ve como "el rayo" del disparo sale objeto MD2 del personaje ya que este no tiene arma asociada, es un poco gracioso la verdad. Creo que esto no estaba contemplado el motor Yeti3D original y tampoco ha sido añadido al Yeti3D-Pro. En todo caso se me ocurren dos formas de solventarlo: la primera es por código y la segunda es hacer un "MERGE" entre el modelo MD2 del enemigo en cuestión y el modelo MD2 del arma. Esto último es posible ya que muchas de las herramientas de modelado ya contemplan este tipo de solución para fusionar modelos.

El segundo video es una prueba de carga de varios modelos MD2 externos en el engine.


https://www.youtube.com/watch?v=oE7ZQjffHzs

Espero ir pudiendo traer nuevas actualizaciones del proyecto cada mes más o menos.

[dj syto]

mola mucho!

[<aSaCo>]

coñe ¿uno de los modelos es de tekkaman blade?

PD: si hasta hay un modelo de kirby y otro de Mario. ¿se podría usar el engine para crear un juego tipo Mario64?

[jduranmaster]

coñe ¿uno de los modelos es de tekkaman blade?


Así es.



PD: si hasta hay un modelo de kirby y otro de Mario. ¿se podría usar el engine para crear un juego tipo Mario64?

Si, es totalmente posible desarrollar juegos 3D de varios géneros diferentes, no sólo un FPS.

[jduranmaster]

Dejo por aquí un nuevo video sobre el proyecto del FPS en el que llevo trabajando desde hace algunos meses. Como ya he comentado en algunas ocasiones el juego está basado en una modificación (profunda) y propia del Yeti3D Pro Engine desarrollado inicialmente por Derek J. Evans y posteriormente modificado por el usuario "NiXot". Actualmente la versión que he modificado permite añadir en el modo "editor" puertas y elevadores que no estaban soportados en las versiones previas así como la carga de modelos 3D en formato MDL y OBJ/MTL ya que hasta la fecha sólo soportaba modelos MD2 (es decir el formato usado en juegos como Quake 2). El video está dividido en dos partes: en la primera se puede apreciar un gameplay corto en el que controlamos al personaje usando diversas armas (modelos Md2 sacados de Quake 2) contra enemigos sacados de diversos repositorios de modelos 3d en Internet, se trata pues de una prueba de carga básica ya que el nivel donde se desarrolla todo es una modificación de un nivel antiguo que tenía pleneado para la realease de GBA. En la segunda parte del video se puede apreciar como es parte del proceso de testeo de modelos MD2 y como estos son cargados en el mapa usando el editor de niveles de Yeti3D Pro.


https://www.youtube.com/watch?v=xosu1rpN5EA

Las imágenes del video se corresponden con las versiones de PC/Android, cuando haya material de las versiones para GBA y 3DS lo iré subiendo al canal principal de YT así que si estáis interesados en seguir el proceso de creación del juego (con nuevos enemigos y niveles modelados desde cero) como se suele decir... STAY TUNNED.

[tSuKiYoMi]

Vaya pasote. Se ve muy fluido aunque claro es la versión para PC y Android. Me imagino que en una GBA no irá tan fluido ni de coña. ¿y en una 3DS?

[<aSaCo>]

Creo que de este proyecto puede salir algo chulo :brindis: ¿los enemigos no llevan arma? Cuando disparan parece que los modelos hacen una animación en la que se ponen en posición de disparo pero no llevan ninguna arma salvo en algunos casos como el Gunner de Q2 o en el cyber-demon que como tienen el arma integrada en el propio modelo lo no les hace falta.

[jduranmaster]

Creo que de este proyecto puede salir algo chulo :brindis: ¿los enemigos no llevan arma? Cuando disparan parece que los modelos hacen una animación en la que se ponen en posición de disparo pero no llevan ninguna arma salvo en algunos casos como el Gunner de Q2 o en el cyber-demon que como tienen el arma integrada en el propio modelo lo no les hace falta.

No, de momento sólo llevan arma aquellos enemigos que la llevan integrada en el modelo como es el caso del GUNNER de Quake 2 que comentabas y de algún otro. Uno de los aspectos que hay que pulir es precisamente el asociar un modelo de arma con otro objeto, en este caso el un enemigo. Existen varías formas de hacerlo, una sería programaticamente y la otra consistiría en hacer un "MERGE" entre ambos modelos 3D (arma+enemigo). Esto último es más sencillo de lo que parece usando para ello la herramienta "Quake Model Editor" (http://www.moddb.com/games/quake-2/downloads/quake-2-model-editor-v090).

Ahora mismo tengo terminados dos modelos 3D de enemigos para el juego y los dos, que en realidad es uno sólo que tiene una variación de colores tanto en tipo como en distribución en el SKIN, tienen el arma integrada en el propio modelo 3D no va a parte. (De hecho el este modelo esta cargado y se puede ver en el video en medio de todos los demás...XD)

[Solo]

Muy grande. Ahora que se está empezando a sacar homebrew para switch (empezando por emuladores) podrías desarrollar el juego también para esa consola. ;)

[jduranmaster]

Muy grande. Ahora que se está empezando a sacar homebrew para switch (empezando por emuladores) podrías desarrollar el juego también para esa consola. ;)

El objetivo último también sería ese. ;-)

[jduranmaster]

Llevaba un tiempo sin postear nada por aquí y a la vuelta de vacaciones me he puesto a trastear cosas que tenía pendientes. Mientras me meto de nuevo con el Yeti3D-Pro os dejo por aquí un hack del MegaMan de GB en el que estuve trabajando hace unos meses y que por fin he dejado más o menos finiquitado.

NEW Cut-Man Stage

https://www.youtube.com/watch?v=Y91mu8-96hs

NEW Fire-Man Stage

https://www.youtube.com/watch?v=dTRYHThRmKM

NEW Elec-Man Stage

https://www.youtube.com/watch?v=wxju0FzcREs

NEW Ice-Man Stage

https://www.youtube.com/watch?v=tPRwLTv1wIY

NEW Dr.Willy Stage-1

https://www.youtube.com/watch?v=HGDQxSL0ppg

NEW Dr.Willy Stage-2

https://www.youtube.com/watch?v=Mm47TKCduOU

El "hack" de momento no tiene nombre pero en cuanto tenga un momento generaré el fichero IPS para subirlo romhacking(dot)net.

[swapd0]

¿Existen herramientas para hacer estos hacks? Cambiar los gráficos lo veo mas o menos fácil, los niveles mas complicado y la lógica del juego si no lo desensamblas olvídate.

Es que me han aparecido muchos hacks del mega man para la NES en las recomendaciones del tubo y algunos son una pasada.

[jduranmaster]

Si, existen herramientas para lo que comentas. Principalmente se trata de editores de niveles que permiten modificar el mapeado de los niveles así como los enemigos que aparecen en cada nivel. En el caso de los juegos de la saga MegaMan para NES lo curioso es permiten también introducir enemigos de la saga en otros juegos de la misma saga, por ejemplo enemigos de MegaMan 4 en MegaMan 2 y cosas así. Luego hay algunos hacks que han sido modificados a nivel de código del juego para soportar mappers especiales y así tener efectos gráficos que de otra forma hubiesen sido imposibles. Un ejemplo de esto es el hack "MegaMan4 Minus Inifity" que es un hack de MegaMan4, pero hay otros muchos ejemplos.

[tSuKiYoMi]

En algunas de las fases parece que la dificultad se ha incrementado bastante.

[<aSaCo>]

Oye, como mola ese "hack" del MegaMan: Dr. Wily´s Revenge para Gameboy. ¿Está el parche IPS en algún lado para poder jugarlo?

[futu-block]

hablando de hacks, ¿hay algo para hackear placas de mame vertical? o lo he soñao yo...
o era un programa para hacer juegos de mame...

[jduranmaster]

hablando de hacks, ¿hay algo para hackear placas de mame vertical? o lo he soñao yo...
o era un programa para hacer juegos de mame...

No se nada acerca de eso. Hasta donde yo sé sobre "hacks" de juegos ARCADEs hay muy pocas herramientas específicas y siempre se tira de editores haxadecimales para modificar los juegos.

Pero vamos no se como decírtelo: "AQUÍ ARCADE LO QUÉ MÁS".

[davken]

Hablando de todo un poco, me ha parecido curioso este detalle sobre la resolución de los juegos de Capcom

https://twitter.com/Locomalito/status/1049762723679092736

​Some classic arcades used a 384 x 224 resolution. The curious thing is that they were made for 4:3 monitors, but cut 8 pixels on the vertical and you will have a perfect 16:9 proportion.

[jduranmaster]

Hablando de todo un poco, me ha parecido curioso este detalle sobre la resolución de los juegos de Capcom

https://twitter.com/Locomalito/status/1049762723679092736

​Some classic arcades used a 384 x 224 resolution. The curious thing is that they were made for 4:3 monitors, but cut 8 pixels on the vertical and you will have a perfect 16:9 proportion.

Es curioso si, pero no termino de ver lo de la conversión a 16:9

[tSuKiYoMi]

¿Son complicadas de usar esas herramientas de "hackeo" para GB? Estuve mirando las herramientas para hackear el MegaMan 2 y el MegaMan 3 de NES y parecen más editores de niveles que otra cosa con la facilidad de cambiar los enemigos de la fase en cuestión. Luego estuve mirando como hackear cualquier juego de NES para modificar gráficos en los juegos y se suele utilizar un editor Hexadeciamal así como otro utilidad de la que no recuerdo el nombre y que permite precisamente hacer el cambio de sprites.

[<aSaCo>]

Avisa cuando liberes el IPS del hack.

[swapd0]

Es curioso si, pero no termino de ver lo de la conversión a 16:9
16/9 = 1,77
4/3 = 1,33
384/(224 - 8) = 384/216 = 1,77

[jduranmaster]

16/9 = 1,77
4/3 = 1,33
384/(224 - 8) = 384/216 = 1,77

Cuiroso si. :+1:

[jduranmaster]

Dejo por aquí una pequeña muestra de unas pruebas que estuve haciendo hace poco para un engine-2D para la GBA. Se trata de una animación básica de sprites 2D en movimiento con backgrounds de MegaMan 2 (el de NES) y Gus Grover, el jefe final del juego ShatterHand (también de NES). Esto viene a cuento de nada pero como en mis ratos libres estoy con varios proyectos, estas pruebas están dentro de "un desarrollo más grande".


https://www.youtube.com/watch?v=lT4vsv_Xu6E

Saludos.

[josepzin]

Se mueve mucho para caminar muy despacio... :P

[jduranmaster]

Si, es que el sprite-sheet tenía sólo dos posiciones así que imagínate a que ritmo iba la animación

[futu-block]

por eso creo que debería moverse mas rápido, ¿no?

[jduranmaster]

por eso creo que debería moverse mas rápido, ¿no?

debería, si desplazas el cursor de reproducción un poco más adelante verás la velocidad real cuando el sprite del personaje es azul. Cuando se ve más lento es porque he metido unos delays para que no marease tanto. Haciendo pruebas con sprite-sheets de 6 y 8 elementos va de lujo y una velocidad decente.

[futu-block]

Voy a ver, que me pudo la fatiga y no lo vi entero

[jduranmaster]

Hace poco terminé mi primera ROM para GBC. Se trata de un clón del juego Tetris: The Soviet Mind Game que TENGEN sacó para NES hace ya unos años. Al principio iba a tener varios modos de juego y la inclusión de otros "tetraminos" como los que se pueden ver en algunas "maquinitas" de Tetris chinas pero al final como me metí en otros proyectos el juego se quedo descontinuado en esa parte, sin embargo si cuenta con las piezas básicas de toda la vida. También me hubiese gustado añadirle algunos efectos de sonido cuando se hace "línea" o los bloques quedan colocados pero igualmente esa parte se ha quedado en el tintero.


https://www.youtube.com/watch?v=fbx69ZqjExk

Por si alguien tiene interés las paletas que he utilizado para los sprites del juego tienen la siguiente pinta:



const UWORD sprite_palette[] = {
RGB_RED, RGB_DARKRED, RGB_GREEN, RGB_DARKGREEN,
RGB_BLUE, RGB_DARKBLUE, RGB_YELLOW, RGB_DARKYELLOW,
RGB_CYAN, RGB_AQUA, RGB_PINK, RGB_PURPLE,
RGB_LIGHTGRAY, RGB_DARKGRAY, RGB_WHITE, RGB_LIGHTFLESH,
RGB_BLACK, RGB_BROWN, RGB_ORANGE, RGB_TEAL
};


Siendo la definición de cada uno de los colores el siguiente:



#define RGB_RED RGB(31, 0, 0)
#define RGB_DARKRED RGB(15, 0, 0)
#define RGB_GREEN RGB( 0, 31, 0)
#define RGB_DARKGREEN RGB( 0, 15, 0)
#define RGB_BLUE RGB( 0, 0, 31)
#define RGB_DARKBLUE RGB( 0, 0, 15)
#define RGB_YELLOW RGB(31, 31, 0)
#define RGB_DARKYELLOW RGB(21, 21, 0)
#define RGB_CYAN RGB( 0, 31, 31)
#define RGB_AQUA RGB(28, 5, 22)
#define RGB_PINK RGB(11, 0, 31)
#define RGB_PURPLE RGB(21, 0, 21)
#define RGB_BLACK RGB( 0, 0, 0)
#define RGB_DARKGRAY RGB(10, 10, 10)
#define RGB_LIGHTGRAY RGB(21, 21, 21)
#define RGB_WHITE RGB(31, 31, 31)

#define RGB_LIGHTFLESH RGB(30, 20, 15)
#define RGB_BROWN RGB(10, 10, 0)
#define RGB_ORANGE RGB(30, 20, 0)
#define RGB_TEAL RGB(15, 15, 0)

[swapd0]

¿por que tiene esa indentation tan rara?

[jduranmaster]

¿por que tiene esa indentation tan rara?

Si lo dices por el código, es porque el video está grabado usando un "robot de teclado" al que le paso el código para que lo escriba sólo. Debí haberle pasado al fichero el corrector de indentación (por ejemplo con el notepad++) antes de ejecutar el robot, pero se me olvidó.

[tSuKiYoMi]

Mola. Una cosa que he notado es que las piezas se mueven sólo en el sentido de las agujas del reloj. ¿?es es porque el movimiento está implementado sólo en una dirección

[Solo]

¿y que otras piezas de Tetris se podrían incluir en el juego? Nunca he tenido una máquina china de Tetris.

[jduranmaster]

¿y que otras piezas de Tetris se podrían incluir en el juego? Nunca he tenido una máquina china de Tetris.

Pues digamos que hay varias opciones en cuanto a meter piezas nuevas en el juego. Por un lado tienes estas que son una modificación de las piezas originales a las cuales se les han quitado un "cuadrado" en alguna parte de su estructura.



_ _ _
_ _ _ |_|_ |_|_ _ _ _|_|
|_|_|_| |_|_| |_|_| |_|_|
_
_ _|_|
_|_|_ _|_|
|_| |_| |_|



Por otro lado existe una configuración de "pentominos" que también es bastante popular en algunos clones chinos de Tetris.




_ _ _
|_| |_|_|
_ _ _ _ _ _ ___ _ _
_ _ _ |_|_ |_|_ _ _|_|_ _ _|_| _|_|_| |_|_|_ |_|_|_|
|_|_|_| |_|_| |_|_|_| |_|_|_| |_|_|_| |_|_| |_|_| |_|_|_|
_ _ _ _ _ _
|_|_ _|_| |_|_| |_|_|
_|_|_| |_|_|_ _|_| |_|_
|_|_| |_|_| |_|_| |_|_|
_ _ _ _
|_| |_| |_|_ _|_|_
_|_|_ |_|_ _ |_|_|_ |_|_|_|
|_|_|_| |_|_|_| |_|_| |_|

[<aSaCo>]

No está nada mal. ¿Funciona en hardware real?

[jduranmaster]

No está nada mal. ¿Funciona en hardware real?

Si. Funciona perfectamente en hardware real. Pero como decía en el post inicial no creo que termine el desarrollo de este juego porque estoy trabajando en otras cosas que ahora mismo me interesan más.

[jduranmaster]

Mola. Una cosa que he notado es que las piezas se mueven sólo en el sentido de las agujas del reloj. ¿?es es porque el movimiento está implementado sólo en una dirección

Si, el movimiento de las piezas está codificado en una sola dirección. Hacer el cambio para soportar las dos direcciones no es nada del otro mundo, pero la ROM ya se ha quedado así y el desarrollo no va a avanzar más.

[jduranmaster]

Hace poco estuve probando a realizar un pequeño engine-2D en GBA para realizar animaciones sobre sprite-sheets. Ahora esto lo tengo un poco más dominado y he estado probando varios tipos de sprite-sheets con personajes de juegos de 8 y 16 bits a ver que tal quedaba el resultado.


https://www.youtube.com/watch?v=X2NVrveQBOI

Para la animación de los sprites me he creado una pequeña librería que tiene las funciones que permiten dado un sprite-sheet de entrada poder mover el "objeto" a la vez que se anima a lo largo de la dirección X o Y de la pantalla:

52236



void DrawBitmapWithTransparency( u16 x, u16 y, u16 height, u16 width, u16* data );


Como sprite-sheets he utilizado algunas procedentes de juegos bastante conocidos en general:
52237

A partir de aquí la idea sería intentar tener las animaciones completas de un personaje para a partir de la librería que he generado crear una máquina de estados controlada por las pulsaciones de los botones de la GBA para así mover al personaje por la pantalla con sus diferentes animaciones en función de si está caminando, saltando, disparando, caminando+disparando, etc.

PD: he seguido trabajando en el engine-3D para GBA / 3DS / Android basado en Yeti3D-Pro y tengo algunas cosas nuevas, así que espero poder enseñar nuevos avances pronto.

[futu-block]

¿entonces, lo que hace este script es pintar una sección del grafico cada frame o ciertos frames?
¿como afecta eso al rendimiento? digo por si es mas cómodo que cargar una imagen diferente cada vez

[jduranmaster]

¿entonces, lo que hace este script es pintar una sección del grafico cada frame o ciertos frames?
¿como afecta eso al rendimiento? digo por si es mas cómodo que cargar una imagen diferente cada vez

Así es, yo lo que hago es coger una imagen con el sprite-sheet completo, como los ejemplos que he enlazado, convierto dicha a imagen aun array hexadecimal que queda almacenado en un fichero de cabecera .h y luego lo cargo cuando voy a usarlo. Desde el punto de vista del rendimiento va bastante bien, siempre con los mismos fps estables sin alti-bajos.

[Solo]

Como sprite-sheets he utilizado algunas procedentes de juegos bastante conocidos en general:

https://www.youtube.com/watch?v=X2NVrveQBOI

A partir de aquí la idea sería intentar tener las animaciones completas de un personaje para a partir de la librería que he generado crear una máquina de estados controlada por las pulsaciones de los botones de la GBA para así mover al personaje por la pantalla con sus diferentes animaciones en función de si está caminando, saltando, disparando, caminando+disparando, etc.



Eso me gustaría verlo. A ver si puedes sacarlo y enseñarlo por aquí explicando como hacer el proceso. :+1:

[jduranmaster]

Eso me gustaría verlo. A ver si puedes sacarlo y enseñarlo por aquí explicando como hacer el proceso. :+1:

Eso llegará a no mucho tardar porque quiero ver si es posible hacer una especie de Run&Gun para GBA, de hecho ahora tengo más tiempo libre para dedicarle a los juegos que tengo en desarrollo para las diferentes plataformas. Así que he sacado el cuaderno y rebuscado todos los juegos de GBA que fuí dejando a medias en su momento. Uno que me apetece terminar es un clón del "Jewels" que empecé hace unos meses usando el devkitpro pero que no acabé.

Jewel-Clone-GBA
52295

De este juego me falta añadir efectos de sonido que es algo que hace poco conseguí dominar y a ver si soy capaz de meterle una música de fondo que es algo que todavía no controlo demasiado. Por otro lado, ya he conseguido adaptar el editor de niveles del Yeti3D-Pro que estoy usando para el juego en Android para que sea capaz de generar también "los datos" de los niveles para que estos sean procesados por el Yeti3D en GBA, parece una tontería pero "alguien" en algún momento al pasar de Yeti3D a Yeti3D-Pro modificó las herramientas que generaban los datos de los mapas a partir de la herramienta de modelado haciendo que ambas versiones fuesen incompatibles. Ahora sólo me queda empezar a trastear en la versión de GBA con la importación de modelos MD2, e intentar comprobar si es posible usar el mapper de modelos MDL (Quake) que hice para la versión de PC/Android también en la versión de GBA, aunque esto último va a requerrir algo más de trabajo.

3D-FPS-GBA
52296

[tSuKiYoMi]

La verdad es que ese "clón" del beJewel tiene buena pinta. ¿Al final para meter efectos de sonido en un juego de GBA se hace igual que programando para GB/GBC? quiero decir que hace falta inicializar unos registros y luego escribir el valor en otros para que se escuché un sonido por la salida de audio. ¿Y para la música se hace igual? ¿No se podría usar algún tracker para GBA y crear la música que quieras y luego incluirla en tú juego?

El rendimiento del Yeti3D en GBA ¿es bueno? quiero decir ¿a cuantos FPS puedes mover la rom en emulador y a cuantos baja cuando lo metes en un flashcart? :brindis:

[jduranmaster]

La verdad es que ese "clón" del beJewel tiene buena pinta. ¿Al final para meter efectos de sonido en un juego de GBA se hace igual que programando para GB/GBC? quiero decir que hace falta inicializar unos registros y luego escribir el valor en otros para que se escuché un sonido por la salida de audio. ¿Y para la música se hace igual? ¿No se podría usar algún tracker para GBA y crear la música que quieras y luego incluirla en tú juego?

Si, para meter efectos de sonido en un juego de GBA al final se debe hacer lo mismo que en uno de GB. Se inicializan una serie de registros hardqare y se cargan valores en otros registros para hacer sonar una determinada nota, incluso esta técnica se puede usar para componer músicas, no sólo para los SFX. Para GBA existe una librería llamada KRAWALL que permite incluir música externa en la rom de GBA de forma más simple, es sólo que aún tengo que darle una vuelta para saber como usarla bien.

Ya tengo un prototipo jugable del juego, así que dentro de poco haré una primera release para que la juegue la gente.





52307

52308






52309

52310





El rendimiento del Yeti3D en GBA ¿es bueno? quiero decir ¿a cuantos FPS puedes mover la rom en emulador y a cuantos baja cuando lo metes en un flashcart? :brindis:

La rom e emulador va más rápida que en el flashcart debido a que se ejecuta en PC pero te puedo asegurar que en el hardware de GBA es jugable. No he hecho una medición de FPS en condiciones pero puedo intentar hacerlo.

[<aSaCo>]

Ya tengo un prototipo jugable del juego, así que dentro de poco haré una primera release para que la juegue la gente.





52307

52308






52309

52310




Me mola un montón. A ver si lo puedes liberar pronto para probarlo en mi GBA-SP. :brindis:

[tSuKiYoMi]

La rom en emulador va más rápida que en el flashcart debido a que se ejecuta en PC pero te puedo asegurar que en el hardware de GBA es jugable. No he hecho una medición de FPS en condiciones pero puedo intentar hacerlo.

OK. Si sacas una demo rápida aunque no tenga todos los elementos para probar, mejor.

[jduranmaster]

OK. Si sacas una demo rápida aunque no tenga todos los elementos para probar, mejor.

Este es uno de los mapas nuevos para la versión de GBA. Está ejecutándose en el emulador VisualBoy Advance.


https://www.youtube.com/watch?v=cigUZtaJCL8

[tSuKiYoMi]

Se mueve bastante bien para ser una GBA.

[jduranmaster]

Video demostrativo de programación en GBA en el que intento mejorar un poco la tasa de FRAMES en este motor de raycasting para GBA usando DevKitAdv y lenguaje de programación C. Puede que de esto salga algo más potente en un futuro.


https://www.youtube.com/watch?v=FFHBnv0HD5M


Me mola un montón. A ver si lo puedes liberar pronto para probarlo en mi GBA-SP. :brindis:

Pues lo tengo ya avanzado. Así que espero no demorarme demasiado.

[jduranmaster]

Ya casi tengo acabado el port para 3DS y GBA del Yeti3D-pro-EnHanCeD.

52688

Ha costado pero ya no queda mucho.

[Solo]

¿De donde has sacado el modelo de Mario en 3D? ¿de algún juego oficial de NINTENDO? Buen trabajo. A ver cuando lo podemos ver en movimiento.

[jduranmaster]

En estos meses he seguido trabajando en mi versión "EnHanCeD" del Yeti3D-Pro-Engine a la que le he añadido nuevos elementos interesantes a nivel de mapeados y texturas de cara a la versión multi-plataforma para GBA/3DS/Switch/Android/PC. Ahora mismo estoy trabajando con algunos modelos de pruebas para testear en las plataformas menos potentes (especificamente GBA y NDS) como el rendimiento global cuando se cargan varios modelos MD2 en el entorno.




53198
53199


53200
53201


53202
53203


53204
53205



Alguna DEMO sacaré para que se pueda probar cuando acabe con las pruebas. Después de eso me gustaría realizar algunos juegos 3D usando mi versión mejorada del engine.

-----Actualizado-----


¿De donde has sacado el modelo de Mario en 3D? ¿de algún juego oficial de NINTENDO? Buen trabajo. A ver cuando lo podemos ver en movimiento.

No. De un repositorio de modelos MD2. Si te fijas bien ese modelo 3D de Mario en concreto no es de ningún juego oficial de Nintendo.

[Karkayu]

Avisa por aquí para probar DEMO :)

[jduranmaster]

Si, subiré la DEMO a este hilo. :brindis:

[<aSaCo>]

Que bueno. A ver si lo puedes compartir pronto. :awesome:

[tSuKiYoMi]

Tiene muy buena pinta. ¿El engine puede "leer" sólo modelos MD2 o has incluido algún mapper para otros tipos de modelos como MDL o MD3?

[jduranmaster]

Tiene muy buena pinta. ¿El engine puede "leer" sólo modelos MD2 o has incluido algún mapper para otros tipos de modelos como MDL o MD3?

Al final he incluido la posibilidad de que el ENGINE pueda leer modelos MDL, MD2 y MD3. De esta forma te ahorras tener que hacer conversiones de MDL a MD2 o de MD3 a MD2.

[jduranmaster]

Aprovechando que ahora tengo más tiempo libre después del trabajo he continuado el desarrollo de este emulador de Master System que dejé en el tintero hace unos años. No es nada pretencioso, simplemente una prueba de concepto, pero no va nada mal. El emulador en cuestión está desarrollado en lenguaje de programación JAVA(ahora que tengo tiempo libre, he actualizado el código fuente a la versión JAVA8) y permite emular los juegos de las siguientes plataformas:

Sega Master System / Game Gear
Sega SG-1000

Para hacer del emulador algo más completo le he incluido algunas herramientas que pueden ser de interés. La herramienta más interesante (desde mi punto de vista) es un debbuger (o depurador). El depurador proporciona muchas características que pueden ser útiles para descubrir trucos en ROMs de juegos licenciados y no licenciados así como en el desarrollo de juegos Homebrew. Proporciona resaltado de sintaxis personalizable, registro de seguimiento, puntos de interrupción y puntos de observación. Dejo a continuación un pequeño vídeo del emulador corriendo varios juegos de Master System. El trabajo está en su mayor parte completado pero aún quedan algunos pequeños flecos, así que espero poder actualizar mi repositorio local en breve con los últimos cambios para que el código fuente sea distribuido a un repositorio de GitHub público.


https://www.youtube.com/watch?v=9bpmlYgQ2As

[<aSaCo>]

Ostías! Como mola ese emu de Master Sytem. ¿Has probado a intentar jugar a alguno de los juegos no licenciados que hay para las master?

[jduranmaster]

En estos meses he seguido trabajando en mi versión "EnHanCeD" del Yeti3D-Pro-Engine. Ya tengo una versión estable para "Nintendo-Switch" y he estado probando a realizar varios tipos de pruebas para intentar desarrollar diferentes tipos de juegos pertenecientes a géneros que no sean First Person Shooter. En este caso he realizado una pequeña prueba de concepto para intentar desarrollar un pequeño juego de plataformas 3D estilo Mario64.


https://www.youtube.com/watch?v=k385oEHccFo

Sigo trabajando con algunos modelos de pruebas para testear en las plataformas menos potentes (especificamente GBA y NDS) como el rendimiento global cuando se cargan varios modelos MD2 en el entorno. En el caso de GBA el rendimiento es más bajo y se queda por debajo de los 25fps aunque creo que sería posible subir un poco más.

-----Actualizado-----


Ostías! Como mola ese emu de Master Sytem. ¿Has probado a intentar jugar a alguno de los juegos no licenciados que hay para las master?

Si, en su momento llegué a probar el Super Boy II.

[swapd0]

¿El yeti3d no iba con aritmética de punto fijo? ¿Sigue siendo así?

[jduranmaster]

¿El yeti3d no iba con aritmética de punto fijo? ¿Sigue siendo así?

La versión original creo que si, y el primer port que se hizo en su día para GBA también, de hecho la GBA sólo soporta aritmética de punto fijo y en la NDS todas las operaciones de punto flotante se emulaban por software, porque ninguno de los procesadores tenía una FPU.

A partir del Yeti3D-pro apareció un fork que usaba coma flotante, y esa es la versión en la que está basada el Yeti3d-pro-enhanced. El asunto es que para que seguir evolucionando el engine en GBA hay que seguir trabajando con artimética de punto fijo.

[^OMAP-Cranck^]

En estos meses he seguido trabajando en mi versión "EnHanCeD" del Yeti3D-Pro-Engine. Ya tengo una versión estable para "Nintendo-Switch" y he estado probando a realizar varios tipos de pruebas para intentar desarrollar diferentes tipos de juegos pertenecientes a géneros que no sean First Person Shooter. En este caso he realizado una pequeña prueba de concepto para intentar desarrollar un pequeño juego de plataformas 3D estilo Mario64.


https://www.youtube.com/watch?v=k385oEHccFo

Sigo trabajando con algunos modelos de pruebas para testear en las plataformas menos potentes (especificamente GBA y NDS) como el rendimiento global cuando se cargan varios modelos MD2 en el entorno. En el caso de GBA el rendimiento es más bajo y se queda por debajo de los 25fps aunque creo que sería posible subir un poco más.

-----Actualizado-----

Si, en su momento llegué a probar el Super Boy II.

¿Otro Mario más para Switch? JAJA. Es broma. Me parece un curro realmente excelente. Me interesa ver sobre todo hasta donde puede llegar la versión para Game Boy Advance.

[Solo]

Me gustaría probar a hacer un pequeño juego para GBA. ¿El kit de desarrollo más completo a día de hoy sigue siendo devkitPro?

[jduranmaster]

Me gustaría probar a hacer un pequeño juego para GBA. ¿El kit de desarrollo más completo a día de hoy sigue siendo devkitPro?

Así es. A día de hoy devkitpro es el más completo y yo empezaría por ahí. Últimamente están apareciendo además alguna que otra librería para programar en GBA por ejemplo en versiones más modernas de C++ por si le quieres echar un ojo a eso.

[jduranmaster]

En estos meses he seguido trabajando en mi versión "EnHanCeD" del Yeti3D-Pro-Engine. Con respecto a la versión anterior ya conseguí avanzar la compatibilidad del engine con modelos MDL (a parte de los MD2 para los que ya tenía soporte) y ahora estoy intentando hacer algo similar con los modelos MD3. He hecho un pequeño video haciendo una prueba para cargar varios modelos de forma simultánea y probar las colisiones.


https://www.youtube.com/watch?v=zMeLfUbznp4

[josepzin]

Parece que va corriendo sobre alguna especie de semisólidos de esos :P

[Solo]

Vaya chulada. ¿El modelo 3D del "Ranger" es MDL?

[jduranmaster]

Hace pocos días conseguí dar soporte a modelos 3D en formato MDL en el engine. Para probarlo decidí crear una pequeña demo a modo de juego de carreras para probar algunos modelos MDL.


https://www.youtube.com/watch?v=0kTL-CUWOfk

Se trata de una demo bastante sencilla en la aparecen dos modelos MDL. Un camión que está aparcado cerca de un muro, y un modelo 3D de Mario sacado de unos de los juegos 3D de la saga "Mario Kart" que se puede controlar por el jugador. Otro aspecto importante que llevaba tiempo queriendo incluir es el tema de pistas de música en formato OGG. Es algo a lo que le he estado dando vueltas últimamente para la versión de SWITCH porque en GBA creo que sería complicado meterlo.


Vaya chulada. ¿El modelo 3D del "Ranger" es MDL?

No. Ese en concreto es un modelo MD2 que fué desarrollado en su día para algún mod de Quake 2.

[SplinterGU]

Hace pocos días conseguí dar soporte a modelos 3D en formato MDL en el engine. Para probarlo decidí crear una pequeña demo a modo de juego de carreras para probar algunos modelos MDL.


https://www.youtube.com/watch?v=0kTL-CUWOfk

Se trata de una demo bastante sencilla en la aparecen dos modelos MDL. Un camión que está aparcado cerca de un muro, y un modelo 3D de Mario sacado de unos de los juegos 3D de la saga "Mario Kart" que se puede controlar por el jugador. Otro aspecto importante que llevaba tiempo queriendo incluir es el tema de pistas de música en formato OGG. Es algo a lo que le he estado dando vueltas últimamente para la versión de SWITCH porque en GBA creo que sería complicado meterlo.



No. Ese en concreto es un modelo MD2 que fué desarrollado en su día para algún mod de Quake 2.

muy bueno! felicitaciones!

[Solo]

Cada vez pinta mejor esta nueva versión del motor. Un juego de carreras tipo F-Zero sería un puntazo.

[tSuKiYoMi]

Hace pocos días conseguí dar soporte a modelos 3D en formato MDL en el engine. Para probarlo decidí crear una pequeña demo a modo de juego de carreras para probar algunos modelos MDL.


https://www.youtube.com/watch?v=0kTL-CUWOfk

Se trata de una demo bastante sencilla en la aparecen dos modelos MDL. Un camión que está aparcado cerca de un muro, y un modelo 3D de Mario sacado de unos de los juegos 3D de la saga "Mario Kart" que se puede controlar por el jugador. Otro aspecto importante que llevaba tiempo queriendo incluir es el tema de pistas de música en formato OGG. Es algo a lo que le he estado dando vueltas últimamente para la versión de SWITCH porque en GBA creo que sería complicado meterlo.


Muy chulo la verdad. El tema de meter OGG en GBA no se hasta que punto sería viable, de todas formas hace poco creo que salió una versión actualizada de la librería "APEX Sound Studio" que se usaba en su momento (2003 / 2004) para meter música en juegos de GBA y que ahora por lo visto se ha visto mejorada su integración con devkitPro.

[jduranmaster]

Hace poco me topé con la DEMO original de Yeti3D que salió allá por 2002 / 2003 para DreamCast y la he portado a GBA. Pero en lugar de usar devkitadv que es el sdk para el que estaba preparado en su día está versión lo he portado a la última versión del DEVKITPRO que es la versión con la que estoy trabajando actualmente en mis ports de las versión mejorada de este ENGINE para GBA / 3DS y Android.


https://www.youtube.com/watch?v=DUNougdSB04

No he tocado mucho más del código original para no modificar el trabajo original de "Derek J. Evans" ya que para eso tengo mi propio fork (Yeti3d-Pro eNHaNCeD (https://www.youtube.com/watch?v=zMeLfUbznp4)).


Muy chulo la verdad. El tema de meter OGG en GBA no se hasta que punto sería viable, de todas formas hace poco creo que salió una versión actualizada de la librería "APEX Sound Studio" que se usaba en su momento (2003 / 2004) para meter música en juegos de GBA y que ahora por lo visto se ha visto mejorada su integración con devkitPro.

Si, la última versión de Apex Sound Studio se puede usar de forma más sencilla ahora en devkitpro. Han habido varias actualizaciones al respecto.

[swapd0]

Molan los engines por software, una pregunta, ¿son lightmaps o son polígonos con gouraud?

[jduranmaster]

Traigo una pequeña actualización en el desarrollo de la versión enhanced de Yeti3D Pro. Se trata de un pequeño test cargando modelos MDL directamente del MOD Arcane Dimensions de Quake. La música del video es "in ROM" y está sacada directamente una pista de Quake 2 reproducida usando el APEX Sound Studio que comentábamos más arriba y que en las últimas actualizaciones de DEVKIT PRO había tenido una actualización para ser integrada de forma más sencilla.


https://www.youtube.com/watch?v=uupxlWDvsHE


Molan los engines por software, una pregunta, ¿son lightmaps o son polígonos con gouraud?

Lightmaps

[jduranmaster]

He creado una pequeña ROM para testear las funciones RGB de la GBA. No es un proyecto muy complejo pero ahí está.


https://www.youtube.com/watch?v=7RYwmK6CVow

El motivo es que últimamente he seguido investigando bastante acerca de las capacidades que puede tener la GBA para las llamadas "non-gaming applications" y he obtenido algunos resultados bastante chulos que compartiré por aquí cuando llegue el momento.

[swapd0]

¿Por qué escribes cada linea con un tab más que la linea anterior?

[josepzin]

Se llama Programación escalonada, un nuevo paradigma.

[swapd0]

Solo recomendada para usuarios con monitores ultra wide XDXDXD

[jduranmaster]

¿Por qué escribes cada linea con un tab más que la linea anterior?

Es que no lo escribo yo. El código lo paso por un BOT de teclado que lo escribe por mi y yo me voy a tomar un café. Como el código no debía estar formateado en el fichero original no pilla bien los tabs.

[swapd0]

Entonces es por los saltos de linea, en msdos y windows se pone LF (10 ) y CR (13), mientras que en unix y derivados solo LF.

[tSuKiYoMi]

He creado una pequeña ROM para testear las funciones RGB de la GBA. No es un proyecto muy complejo pero ahí está.


https://www.youtube.com/watch?v=7RYwmK6CVow

El motivo es que últimamente he seguido investigando bastante acerca de las capacidades que puede tener la GBA para las llamadas "non-gaming applications" y he obtenido algunos resultados bastante chulos que compartiré por aquí cuando llegue el momento.

¿Con "non-gaming applications" te refieres por ejemplo a sistemas de "CONTROL" o cosas del estilo?

[jduranmaster]

¿Con "non-gaming applications" te refieres por ejemplo a sistemas de "CONTROL" o cosas del estilo?

Así es. Básicamente software de control que se ejecuta desde una GBA. He estado haciendo "algunas cosillas" al respecto que ya iré enseñando por aquí.

[tSuKiYoMi]

Entiendo. Hace poco vi una aplicación similar a lo que comentar. Se trataba de un proyecto para hacer streaming de video y audio desde una Raspberry Pi hacia una GBA y de esta manera usar la pantalla de la GBA sus controles para jugar emuladores como el PSX.

[jduranmaster]

Hace tiempo que no actualizo el hilo, pero se vienen "cosas" (https://darkryoga.wordpress.com/2023/02/27/rom-hacking-personal-projects-parte-x-galaga-starwaga-edition-version-1-1/) en los próximos meses. De entrada os traigo por aquí un pequeño "hack" (https://darkryoga.wordpress.com/2023/02/27/rom-hacking-personal-projects-parte-x-galaga-starwaga-edition-version-1-1/) de Galaga (J) para Famicom (https://darkryoga.wordpress.com/2023/02/27/rom-hacking-personal-projects-parte-x-galaga-starwaga-edition-version-1-1/) que estuve haciendo con motivo del estreno de la tercera temporada de "The Mandalorian" (https://darkryoga.wordpress.com/2023/02/27/rom-hacking-personal-projects-parte-x-galaga-starwaga-edition-version-1-1/). Se trata de un "hack" (https://darkryoga.wordpress.com/2023/02/27/rom-hacking-personal-projects-parte-x-galaga-starwaga-edition-version-1-1/) al que he llamado GALAGA: STARWAGA Edition (https://darkryoga.wordpress.com/2023/02/27/rom-hacking-personal-projects-parte-x-galaga-starwaga-edition-version-1-1/) y si tenéis más interés al respecto (o en probarlo vosotros mismos) podéis encontrar información en la página del BLOG (https://darkryoga.wordpress.com/2023/02/27/rom-hacking-personal-projects-parte-x-galaga-starwaga-edition-version-1-1/).


https://www.youtube.com/watch?v=BW9zMoGoTfM

[Solo]

Ahora que han estrenado la tercera temporada del Mandaloriano esto me va como anillo al dedo.

[jduranmaster]

"GALAGA: MOGURIGA Edition" (https://darkryoga.wordpress.com/2023/03/20/rom-hacking-personal-projects-parte-xi-galaga-moguriga-edition-version-1-0/) es el segundo hack (https://www.youtube.com/watch?v=j2WWnuHTMco) de Galaga (https://www.youtube.com/watch?v=j2WWnuHTMco) que forma parte de mi "tetralogía" (https://www.youtube.com/watch?v=j2WWnuHTMco) particular de hacks relacionados con este juego. Si os apetece probarlo tenéis más información AQUÍ (https://darkryoga.wordpress.com/2023/03/20/rom-hacking-personal-projects-parte-xi-galaga-moguriga-edition-version-1-0/). En este caso se trata de un hack (https://www.youtube.com/watch?v=j2WWnuHTMco) de Galaga (https://www.youtube.com/watch?v=j2WWnuHTMco) con temática de "Final Fantasy" (https://www.youtube.com/watch?v=j2WWnuHTMco) en el que he incluido sprites de juegos como Final Fantasy I (NES) (https://www.youtube.com/watch?v=j2WWnuHTMco), Final Fantasy II (NES) (https://www.youtube.com/watch?v=j2WWnuHTMco), Final Fantasy III (Famicom) (https://www.youtube.com/watch?v=j2WWnuHTMco), Final Fantasy IV (SNES) (https://www.youtube.com/watch?v=j2WWnuHTMco) y Final Fantasy VII (Ch) (Famicom) (https://www.youtube.com/watch?v=j2WWnuHTMco).


https://www.youtube.com/watch?v=j2WWnuHTMco

[tSuKiYoMi]

Los sprites de Final Fantasy están chulos, aunque supongo que es más complicado adaptar las paletas de colores.

[jduranmaster]

"GALAGA: MARIOGA Edition" (https://www.youtube.com/watch?v=MJniFhndH4A) es el tercer hack (https://www.youtube.com/watch?v=MJniFhndH4A) de Galaga (https://www.youtube.com/watch?v=MJniFhndH4A) que forma parte de mi "tetralogía" (https://www.youtube.com/watch?v=MJniFhndH4A) particular de hacks relacionados con este juego. Si os apetece probarlo tenéis más información AQUÍ (https://darkryoga.wordpress.com/2023/04/17/rom-hacking-personal-projects-parte-xii-galaga-marioga-edition-version-1-2/). En este caso se trata de un hack (https://www.youtube.com/watch?v=MJniFhndH4A) de Galaga (https://www.youtube.com/watch?v=MJniFhndH4A) que incluye sprites sacados de juegos como SMB (https://www.youtube.com/watch?v=MJniFhndH4A) o SMB3 (https://www.youtube.com/watch?v=MJniFhndH4A) de NES (https://www.youtube.com/watch?v=MJniFhndH4A).


https://www.youtube.com/watch?v=MJniFhndH4A

-----Actualizado-----


Los sprites de Final Fantasy están chulos, aunque supongo que es más complicado adaptar las paletas de colores.

Ya tienes un hack nuevo. xD

[<aSaCo>]

Estos hacks de Galaga tienen su aquel. Los basados en Final Fantasy y Star Wars molan bastante. El basado en Mario Bros bueno, no está mal.

[jduranmaster]

Hace relativamente poco estuve probando algunos de los modelos 3d para SNES que se filtraron en el Nintendo GigaLeak (https://www.youtube.com/watch?v=KXLh5x2Q1_8) de 2020 (https://www.youtube.com/watch?v=KXLh5x2Q1_8). En primer lugar, me llamó la atención el efecto de estela en la espada de Link, que es similar a lo que se hizo más tarde para Ocarina of Time. Hay otros 10 archivos con modelos animados de Link pero sólo dos de ellos parecen presentar los colores, la espada y el escudo de Link. Los otros tienen colores genéricos y realizan una animación de baile genérica.


https://www.youtube.com/watch?v=KXLh5x2Q1_8

Me llamaron especialmente la atención este modelo 3d de Link (https://www.youtube.com/watch?v=KXLh5x2Q1_8) y el modelo 3d de Yoshi (https://www.youtube.com/watch?v=Waey9gfO9lM).

Algunos detalles interesantes que fueron obtenidos por la persona que se encargo de importar el modelo de Yoshi (https://www.youtube.com/watch?v=KXLh5x2Q1_8) dentro del motor de juego de StarFox (https://www.youtube.com/watch?v=KXLh5x2Q1_8):


When imported in StarFox, Yoshi's body color is a red/purple-ish color, the color were changed manually and changed it to green. The rest of the colors seemed to match the standard Star Fox palette. Maybe he was intended to be this color, or the palette they used was different. It has 105 vertices, which is more than what is allocated per object in the Super FX RAM for Star Fox (default max is 80). It had to increase the limit and reduce the RAM allocated for other stuff, which makes the game crashy. The model being very large, It had to delete a few other models from the ROM bank where it was inserted, as the ROM is nearly full. The vertices order for its body are flipped. Fixing that does allow the shaped.exe tool to generate z-sorting BSP tree data, but the in game result has even more z-sorting issues than left as is. Fixing z-sorting issues in a BSP-tree based renderer is not as easy as it sounds. It is possible to use an early Argonaut tool to generate the shape code and BSP data. Ultimately the Yoshi model might be a better match for Star Fox 2, since the game includes walking ships and levels/objects designed for it.

[swapd0]

¿Estas seguro de que es Link? No se parece mucho XD

[wolf_noir]

https://youtu.be/Waey9gfO9lM

-----Actualizado-----

Yo me quedado en plan y donde está Yoshi xD ... Para comparar jajajaja... Arreglado ya está el vídeo para comparar los dos modelos 3D :D

[Drumpi]

Entonces ¿las estelas de las espadas en los modelos 3D de SNES y N64 están en el modelo? Yo pensaba que se generaban de forma procedural :S

De todas formas, molan estas pruebas de concepto. Te hacen soñar con lo que podría haber llegado a salir, pero claro, las limitaciones de la SNES eran muy bestias para hacer algo parecido a un plataformas... o para tener un escenario. Esto es usando el SuperFX 1.0, quizás con el 2.0, usado en Yoshi's Island se podría haber hecho algo...
De hecho ¿nadie ha pensado en meter los juegos de Starfox y StuntRace FX en un cartucho con el chip SFX2, a ver si mejoraba el rendimiento? (aunque a lo mejor estoy diciendo una barbaridad :P )

[jduranmaster]

Aquí el último de los modelos 3D que se descubrieron en el Nintendo GigaLeak (https://www.youtube.com/watch?v=lq-yZZDPraY) de 2020 (https://www.youtube.com/watch?v=lq-yZZDPraY). Se trata de otro modelo nombrado como "LINK" (https://www.youtube.com/watch?v=lq-yZZDPraY) en la documentación pero que a diferencia del "LINK" (https://www.youtube.com/watch?v=lq-yZZDPraY) que porta escudo y tiene animación de ataque con la espada, este otro modelo sólo integra un único color (el morado) y realiza una animación de baile.


https://www.youtube.com/watch?v=lq-yZZDPraY



¿Estas seguro de que es Link? No se parece mucho XD

Si, es uno de los modelos de Link que se dieron a conocer en el Nintendo GigaLeak de 2020. Es cierto que mucho detalles por lo que creo que tanto este como los otros modelos en realidad son pruebas de concepto para el el Chip Super FX (que entiendo que por fechas se trata de las revisión GSU-1, aunque serían compatibles también para correr en GSU-2). No creo que hubiese un interés real en realizar juegos usando estos modelos como base.

-----Actualizado-----



De todas formas, molan estas pruebas de concepto. Te hacen soñar con lo que podría haber llegado a salir, pero claro, las limitaciones de la SNES eran muy bestias para hacer algo parecido a un plataformas... o para tener un escenario. Esto es usando el SuperFX 1.0, quizás con el 2.0, usado en Yoshi's Island se podría haber hecho algo...
De hecho ¿nadie ha pensado en meter los juegos de Starfox y StuntRace FX en un cartucho con el chip SFX2, a ver si mejoraba el rendimiento? (aunque a lo mejor estoy diciendo una barbaridad :P )

Nadie lo había pensado antes. (https://www.romhacking.net/hacks/6333/)

[wolf_noir]

¿Estas seguro de que es Link? No se parece mucho XD

:D Como osas dudar, si está hecho con triángulos de la trifuerza xD :lol:

[Drumpi]

Nadie lo había pensado antes. (https://www.romhacking.net/hacks/6333/)

¿Cómo oso dudar de la imaginación de la scene? :D
Sí que había visto vídeos de Starfox en un SuperFX overclockeado, pero no había visto ninguno funcionando en un Super FX 2. He visto algunos vídeos, y hay algunos que van al doble de su velocidad, y otros que van a su velocidad, mejorando los FPS. Lo que no tengo claro es cómo se hace cada cosa :P


¿Estas seguro de que es Link? No se parece mucho XD

A ver, son 4 polígonos con forma humanoide, con espada y escudo, hecho por un empleado que trabaja para Nintendo (no sé si de la propia Nintendo o de la Argonaut de entonces): ¡por supuesto que le va a llamar "Link"! No le va a llamar Squall... o Jim. Jim, the knight.

[Solo]

Molan mucho estos modelos 3D. Imagino que la salida de Nintendo 64 hizo que Nintendo se replantease mucho el sacar más juegos en 3D con ese hardware en SNES. A pesar de esto me hubiese gustado ver en movimiento el port de "FX FIGHTER" para SNES que fue cancelado.

[Drumpi]

Más bien, creo que el que Argonaut les diseñase el SuperFX fue lo que convenció a Nintendo para crear la N64. Seguro que sabéis de muchos proyectos cancelados en favor de N64, pero creo que fue una muy buena decisión: el precio de los cartuchos, las enormes limitaciones y el tiempo de vida que le quedaba a la SNES (sin contar retrasos de la Nintendo Ultra 64) no hubieran dado buenos productos, o al menos, no productos que compensasen el esfuerzo.
Pero oye, que salieron muy buenos juegos :D Yo ya tengo el Starwing y el Sunt Race FX, sólo me falta el Vortex para tener los juegos poligonales que me interesan :D Sí, tengo el Yoshi's Island también.

[jduranmaster]

¿Cómo oso dudar de la imaginación de la scene? :D
Sí que había visto vídeos de Starfox en un SuperFX overclockeado, pero no había visto ninguno funcionando en un Super FX 2. He visto algunos vídeos, y hay algunos que van al doble de su velocidad, y otros que van a su velocidad, mejorando los FPS. Lo que no tengo claro es cómo se hace cada cosa :P


Arquitectura y Características técnicas:



Architecture: RISC
Clock Speed: 10.74Mhz M.A.R.I/O chip & FX GSU-1 / 21MHz FX GSU-2
Peripheral ROM: 8Mbits M.A.R.I/O chip / 16Mbits FX GSU-1 & GSU-2
Peripheral RAM: 1Mbit max
Internal Data Bus: 16 bits
External Data Bus: 8 bits
Internal Registers: 16 bit x 16
Instruction Cache: 512 Bytes
Processing Advantages: Polygon Processing; Software Sprite Processing



El chip era un microprocesador RISC (Reduced Instruction Set Computer), con una frecuencia de 21MHz, y era capáz de renderizar algunos cientos de polígonos. La primera versión comercial fue la conocida como Chip M.A.R.I/O que llevaba el Star Fox. Este procesador actúa como un chip acelerador de gráficos que dibuja polígonos a un framebuffer en la memoria RAM, también situada en el cartucho. Para los juegos, los datos de este framebuffer se transfieren periódicamente a la memoria de vídeo principal dentro de la consola, usando DMA, y de ahí, directamente a la televisión. La primera versión del chip, comúnmente llamada el Super FX (sin número), es sincronizada con una señal de 21 MHz, pero un divisor de frecuencia interno lo dividía a la mitad (a 10,5 MHz). Más tarde, el diseño fue revisado para convertirse en el Super FX GSU-1 / GSU-2; esta, a diferencia de la primera revisión del chip Super FX si corría a 21Mhz. Todas las versiones del chip Super FX son funcionalmente compatibles en términos de su SET de instrucciones. Las diferencias surgen en la forma en que han sido encapsulados, sus pins de salida, y su velocidad de reloj interna. Como resultado de cambiar el encapsulado cuando se creó el GSU-2, más pins externos estaban disponibles y asignados para direccionamiento, con lo que una mayor cantidad de memoria ROM o RAM externa podía ser accedida.

En términos de "overclockeo" todos los cartuchos con las revisiones GSU-1 y GSU-2 se pueden modificar "físicamente" sustituyendo su oscilador de serie por otro de 24Mhz o de 26Mhz (junto con un par de condensadores) para mejorar el framerate de los juegos (se ve más suave) y se eliminan o reducen de forma total las ralentizaciones. Este procedimiento de cambiar el oscilador no se puede realizar en los cartuchos o juegos que lleven el chip M.A.R.I/O aunque lo que si se puede hacer es coger una ROM de Star Fox y hacer una "repro" que corra en GSU-1 o en GSU-2 con y sin overclock pero para hacer eso se necesita un cartucho donante de otro juego con GSU-1 o GSU-2.

[Drumpi]

Bueno, me refería a que no sabía cómo se metía la ROM de forma que en unos casos fuera al doble de velocidad, y en otros casos al doble de fotogramas por segundo ^^U
Pero me alegra leer el tocho este, ya me queda claro las diferencias y similitudes entre los diferentes chips, y la compatibilidad entre ellos.
Ahora, buscar un donante GSU-1 o GSU-2 sólo para cacharrear es, en la mayoría de los casos, un crimen, y merecedor de una paliza por parte del policía del retro... salvo que el cartucho sea del Dirty Trax o como se llamase aquel de motos que era regulero... y diría que Vortex, pero su BSO merece la pena escucharla (en concreto hay dos versiones de la BSO en yutúb, no sé si por culpa de diferentes emuladores, pero no suenan igual, y no sé cuál es la buena).

[jduranmaster]

Bueno, me refería a que no sabía cómo se metía la ROM de forma que en unos casos fuera al doble de velocidad, y en otros casos al doble de fotogramas por segundo ^^U


Necesitas un memoria EEPROM compatible o similar donde grabar la ROM del juego usando para ello un programador de EEPROM. Hay bastante info al respecto de que EEPROMs se pueden usar para grabar las ROMs. En el caso del Star Fox por ejemplo para poder jugarlo a 21Mhz además hay que aplicar sobre la rom este parche (https://www.romhacking.net/hacks/6333/) antes de grabarlo en la EEPROM. No hay que hacer mucho más a parte de luego soldar la EEPROM a la PCB del cartucho donante. Dado que todas las revisiones del chip Super FX son compatibles en términos de SET de instrucciones no hay que hacer mucho más. El tema del framerate sólo depende del oscilador que tenga el cartucho. Cuando le haces el cambio del oscilador original por el nuevo de 24Mhz o de 26Mhz el juego ya toma como base la frecuencia de reloj del oscilador nuevo sin tener que hacer nada más.

[Solo]

Pues a mi me hubiese gustado ver rulando el port de FX Fighter usando el Super FX y además overclockeado. Por pedir que no quede. :D ¡Que la scene se ponga con ello! JAJAJAJA

[swapd0]

Pues echale un vistazo al virtua fighter de 32x y te lo imaginas con menos poligonos :P

[Drumpi]

Necesitas un memoria EEPROM compatible o similar donde grabar la ROM del juego usando para ello un programador de EEPROM. Hay bastante info al respecto de que EEPROMs se pueden usar para grabar las ROMs. En el caso del Star Fox por ejemplo para poder jugarlo a 21Mhz además hay que aplicar sobre la rom este parche (https://www.romhacking.net/hacks/6333/) antes de grabarlo en la EEPROM. No hay que hacer mucho más a parte de luego soldar la EEPROM a la PCB del cartucho donante. Dado que todas las revisiones del chip Super FX son compatibles en términos de SET de instrucciones no hay que hacer mucho más. El tema del framerate sólo depende del oscilador que tenga el cartucho. Cuando le haces el cambio del oscilador original por el nuevo de 24Mhz o de 26Mhz el juego ya toma como base la frecuencia de reloj del oscilador nuevo sin tener que hacer nada más.

Tampoco me refiero a cómo hacer una repro (ya tengo alguna en casa, y si no costasen tanto los programadores, y tuviera sitio, me pasaría el día haciéndolos para la MD).
Me refiero a la parte subrayada. ¿Seguro que el juego sabe la frecuencia de reloj, y ajusta los tiempos a dicha frecuencia?
Lo digo porque hay casos como el Sonic original, que tiene velocidades diferentes según la región... como la mayoría de juegos de los primeros años de MD.
O casos como juegos de la era pre-Windows98 que funcionan mucho más rápido de lo que deben en ordenadores más modernos.
Yo he jugado con el "delta time" en Unity, pero no sé si eso lo han tenido en cuenta en el código del Starfox o en el hack, o si realmente sabe el juego cuánto tiempo es 1 "delta".

Porque hay una diferencia entre que pase de ir a 10FPS a 20FPS, y de 10Km/h a 20Km/h.

PD: al final fracasé con el transplante del chip del Sonic 3D Director's cut, y creo que me lo he cargado, voy a tener que conseguir otro ^^U O reprogramar el chip, que no sé si es que se ha desprogramado o qué.

[swapd0]

Creo que algunos juegos antiguos lo que hacian es calcular la nueva posicion en interrupcion del barrido de pantalla, y despues dibujaban lo que podia, en esos casos con un ordenador mas rapido el juego te va mas suave pero no se vuelve injugable.

[jduranmaster]

Tampoco me refiero a cómo hacer una repro (ya tengo alguna en casa, y si no costasen tanto los programadores, y tuviera sitio, me pasaría el día haciéndolos para la MD).
Me refiero a la parte subrayada. ¿Seguro que el juego sabe la frecuencia de reloj, y ajusta los tiempos a dicha frecuencia?.

El juego toma como referencia la señal que le llega del oscilador. Por eso se hicieron pruebas en su momento con varios cristales de 20 Mhz / 40 Mhz / 80 Mhz e incluso 100 Mhz (https://www.youtube.com/watch?v=3gVg8vDhfQk) y se llegó a la conclusión de que la mejor frecuencia de reloj que garantiza un game play más suave con un framerate superior al de salida cuando se publicaron estos juegos y que además se garantice que el juego sigue siendo jugable y no "ridículamente" rápido son las frecuencias de 24 Mhz / 26 Mhz para los osciladores. Existen algunos mods que permiten jugar a al DOOM a 40 Mhz pero se aplica a la ROM un parche para que la música y los efectos de sonido no vayan desacompasados con la velocidad de movimiento del juego.

[Solo]

Pues echale un vistazo al virtua fighter de 32x y te lo imaginas con menos poligonos :P

Poco consuelo. Creo que hay algún que otro video en UNSEEN64 donde se puede ver el prototipo del FX Fighter de SNES en movimiento, pero el juego no está terminado claro.

[Drumpi]

El juego toma como referencia la señal que le llega del oscilador. Por eso se hicieron pruebas en su momento con varios cristales de 20 Mhz / 40 Mhz / 80 Mhz e incluso 100 Mhz (https://www.youtube.com/watch?v=3gVg8vDhfQk) y se llegó a la conclusión de que la mejor frecuencia de reloj que garantiza un game play más suave con un framerate superior al de salida cuando se publicaron estos juegos y que además se garantice que el juego sigue siendo jugable y no "ridículamente" rápido son las frecuencias de 24 Mhz / 26 Mhz para los osciladores. Existen algunos mods que permiten jugar a al DOOM a 40 Mhz pero se aplica a la ROM un parche para que la música y los efectos de sonido no vayan desacompasados con la velocidad de movimiento del juego.

Pero claro, no hay forma de hacer que los objetos del juego se muevan a la misma velocidad, pero con más cuadros por segundo ¿no? Eso está ya grabado a fuego en el código.
Es como cuando en 360 portaron los juegos de Banjo-Kazooie, y no se dieron cuenta de que la música estaba sincronizada con las ralentizaciones de la N64, y al ir suave en la 360, el audio se quedaba atrás respecto a la acción :D

Hablando de lo cual, el sábado probé el FZero X en la CV de la Switch y... ¿cómo es posible que sufra de caídas de FPS? Y no sólo eso, es que me dieron una paliza en nivel normal, a pesar de usar un mando Afterglow USB. Sé que hace mucho que no juego, pero en la RetroChiclana me pasé las copas más difíciles en la misma dificultad o mayor en la consola japonesa, y con un mando que decían que era analógico, pero tenía una sensibilidad que, a la mínima, ya registraba el máximo en esa dirección.

[jduranmaster]

Para el que no lo sepa en el año 2002 (https://darkryoga.wordpress.com/2023/07/10/cancelled-games-parte-i-survival-horror-game-by-qbix-game-boy-advance/) se formó Qbix (https://darkryoga.wordpress.com/2023/07/10/cancelled-games-parte-i-survival-horror-game-by-qbix-game-boy-advance/), una pequeña empresa valenciana que quería demostrar lo que se podía hacer en una Gameboy Advance (https://www.youtube.com/watch?v=WQ0ekpL0fb8). Uno de los proyectos era esta demo de survival horror, que lamentablemente no llegó a buen puerto, a pesar de tener una muy buena calidad gráfica y jugable.


https://www.youtube.com/watch?v=WQ0ekpL0fb8

Tal y como comentó Luis Pons (https://www.youtube.com/watch?v=WQ0ekpL0fb8) en una entrevista para la web (https://www.youtube.com/watch?v=WQ0ekpL0fb8) RetroManiac (https://darkryoga.wordpress.com/2023/07/10/cancelled-games-parte-i-survival-horror-game-by-qbix-game-boy-advance/) su motor era muy parecido al motor Blueroses (https://www.youtube.com/watch?v=WQ0ekpL0fb8), ya que ambos motores usaban un enfoque similar al que se usaba en PS1, es decir, polígonos texturados sin perspectiva ni Z-buffer (https://www.youtube.com/watch?v=WQ0ekpL0fb8). Una técnica que bien utilizada puede llegar a dar muy buenos resultados y tiene bajo coste de proceso. Esta técnica (https://www.youtube.com/watch?v=WQ0ekpL0fb8) era la más adecuada para máquinas como Game Boy Advance así como para desarrollar juegos en 3D (https://darkryoga.wordpress.com/2023/07/10/cancelled-games-parte-i-survival-horror-game-by-qbix-game-boy-advance/) para los móviles de aquella época. Tal y como destaca Luis Pons (https://darkryoga.wordpress.com/2023/07/10/cancelled-games-parte-i-survival-horror-game-by-qbix-game-boy-advance/) en dicha entrevista su motor estaba desarrollado en el ensamblador del procesador ARM7TDMI de GBA y muy probablemente el motor Blueroses (https://darkryoga.wordpress.com/2023/07/10/cancelled-games-parte-i-survival-horror-game-by-qbix-game-boy-advance/) también estuviese implementado en este lenguaje de bajo nivel.

El video de esta DEMO es lo único que hay disponible en la red puesto que la ROM sigue siendo a día de hoy PRIVADA (https://www.youtube.com/watch?v=WQ0ekpL0fb8).

[Drumpi]

La cuestión era darle palos a Capcom por no atreverse a sacar RE en GBC, y sacar aquella... cosa del barco.
Entre Alone in the Dark, esto, y no sé qué otras demos y juegos que salieron para GBC y GBA, lo que dijo Capcom de que "no se puede conseguir que un juego de miedo en GBC" quedó más que refutado :D

[Solo]

Me gusta lo fluido que se ve para tratarse de GBA. Creo que en Qbix trataron de vender este motor no sólo para hacer juegos para Game Boy Advance sino también para teléfonos móviles con Symbian.

[swapd0]

Mola un huevo los motores estos por software.

[jduranmaster]

Otro de los estudios que en la época de GBA (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/) se dedicó a intentar explotar la consola en el ámbito del 3D (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/) fue "Raylight Studios" (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/), la cual por su parte se dedicó a sacar numerosas demos de juegos de actualidad en aquel momento (todo ello sin licencia) como eran Resident Evil (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/), Metal Gear (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/) o V-Rally (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/) (empleando otros nombres) y usando para ello famoso motor "Blue Roses". Este motor en términos técnicos era muy similar al motor de Qbix ya que se hacía uso también de polígonos texturados sin perspectiva ni Z-Buffer. Es decir replicaron igual que en el caso de Qbix (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/) la técnica que se usaba en PS1 (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/) pero adaptada a las limitaciones de GBA (https://darkryoga.wordpress.com/2023/08/07/cancelled-games-parte-iii-blue-roses-3d-engine-raylight-studios-game-boy-advance/).


https://www.youtube.com/watch?v=UxoOqybz6mk

[swapd0]

Como molan los motores 3D por software. Debieron sacarle mas partido al motor en vez de hacer tantas demos.

[tSuKiYoMi]

Este es el engine con el que hicieron la DEMO de Metal Gear aquella. Imagínate un port en 3d de Metal Gear Solid en GBA. Para volverse loco.

[jduranmaster]

He aquí la compilación de todas las DEMOS (https://darkryoga.wordpress.com/2023/08/14/cancelled-games-parte-v-all-demos-showcase-blue-roses-3d-engine-raylight-studios-game-boy-advance/) que RayLight Studios (https://darkryoga.wordpress.com/2023/08/14/cancelled-games-parte-v-all-demos-showcase-blue-roses-3d-engine-raylight-studios-game-boy-advance/) llegó a publicar usando su motor Blue Roses (https://darkryoga.wordpress.com/2023/08/14/cancelled-games-parte-v-all-demos-showcase-blue-roses-3d-engine-raylight-studios-game-boy-advance/).


https://www.youtube.com/watch?v=s0dS0pzKpyY

[<aSaCo>]

Sino recuerdo mal RayLight Studios si que llegó a sacar al menos un juego 3D para GBA pero no se si usaba este motor. El juego era el "Street Racing Sindycate" (malo como él sólo).

[jduranmaster]

Busqué el juego sólo por curiosidad y la verdad es que es bastante malo si. Muy lento en comparación con lo que se ve en las DEMOs.

[OscarBraindeaD]

Buenos días,
También hicieron o colaboraron en el wings para gba; las batallas aéreas son en 3d y, aunque el escenario está algo desangelado y vacío, son resultonas.
Saludos

[tSuKiYoMi]

Sino recuerdo mal RayLight Studios si que llegó a sacar al menos un juego 3D para GBA pero no se si usaba este motor. El juego era el "Street Racing Sindycate" (malo como él sólo).

Tengo ese juego comprado de segunda mano. Menos mal que costó poco.

[jduranmaster]

De hace un tiempo a esta parte no he podido actualizar mucho el hilo con lo último que he estado haciendo pero prometo hacerlo pronto. Mientras tanto dejo por aquí un nuevo SET de DEMOS (https://darkryoga.wordpress.com/2024/10/14/cancelled-games-parte-vi-rare-3d-demos-showcase-blue-roses-3d-engine-raylight-studios-game-boy-advance/) que RayLight Studios (https://darkryoga.wordpress.com/2024/10/14/cancelled-games-parte-vi-rare-3d-demos-showcase-blue-roses-3d-engine-raylight-studios-game-boy-advance/) llegó a publicar usando su motor Blue Roses (https://darkryoga.wordpress.com/2024/10/14/cancelled-games-parte-vi-rare-3d-demos-showcase-blue-roses-3d-engine-raylight-studios-game-boy-advance/). Algunas de ellas son únicas en el sentido de que no aguantaron mucho tiempo publicadas en su web


https://www.youtube.com/watch?v=Mqf5RBb-7lM

[swapd0]

Molan los motores 3d por software.

Hace eones programe un "motor 3D" en el Atari ST, llevo unos días dandole vueltas para retomarlo y optimizarlo, a ver si me animo.

[Drumpi]

Me fascina cómo se ven estos motores en máquinas tan modestas como la GBA. A mi me gustaría aprender a hacer este tipo de cosas, pero me parece que mis conocimientos matemáticos no están a la altura, no lo sé, nunca he encontrado un sitio que me enseñe las nociones básicas para ponerme a hacer esto... incluso una simple carretera tipo Out Run se me atasca (más que nada, la transición entre, por ejemplo, una recta y una curva, o entre un llano y una cuesta).

[swapd0]

Con las mates de instituto, vectores y matrices te montas un motor 3D, no es tan complicado.

Para las carreteras pseudo3D mira esto:

http://www.extentofthejam.com/pseudo/

[fbustamante]

Pedazo de artículo. Tengo que leerlo... :awesome:

[Drumpi]

Yo lo he estado intentando, y sin papel y lápiz me ha costado seguirlo... También puede ser porque estoy haciendo otra cosa al mismo tiempo :D

Ahora, eso de hacer un motor 3D "con las mates de instituto, vectores y matrices" no lo tengo yo tan claro, porque habría muchas optimizaciones que hacer al margen de la trigonometría... además, que yo soy de FP, y eso de las matrices no se veían; ya eran los vectores e íbamos a trancas y barrancas intentando que todos los alumnos lo pillaran :D :D :D
Y estoy seguro que luego me saltará alguien con transformar el espacio euclídeo a algún tipo de espacio pentadimensional mediante alguna fórmula que implique integrales dobles, que simplificará el cálculo de senos y cosenos a sumas y multiplicaciones, y me volveré a acordar de sus ancestros, como cuando nos enseñaron matrices para resolver circuitos de más de dos mallas, la transformada de L'aplace para el cálculo de los circuitos LCR, o la de Fourier para la descomposición y tratamiento de señales. Y cuanto menos hablemos de ángulos en Unity, mejor :D

[swapd0]

Las optimizaciones se hacían en los 8bits, por ejemplo en el elite aplicaban el logaritmo a las coordenadas porque el logaritmo de un producto equivale a la suma de logaritmos, con eso evitas hacer multiplicaciones y solo necesitas un par de tablas para hacer la conversión. En los 16bits como tienes instrucciones para multiplicar no hace falta calentarte la cabeza, y en un ordenador moderno ya lo hará la GPU a toda leche.

Y ya te digo que con multiplicar dos matrices, multiplicar una matriz y un vector, producto escalar y vectorial entre dos vectores hice todo, mucho mas tarde hice otro motor con aritmética de punto fijo para PC y solo usaba esas operaciones.

[Drumpi]

No, yo me refería a técnicas de tipo z-buffer, occlusion culling, normal mapping, o lo que se usaba hace años en lugar de raytracing para el cálculo de la iluminación y demás historias. No quería decir nombres porque me tachan de viejuno y de decir técnicas que han quedado en desuso.
El cálculo de vértices y demás es sólo la primera parte del motor, y las matemáticas pueden ser más o menos complejas, pero, según sé, es sólo la primera de las 4 fases que hay en un motor 3D.