[Homebrew] Noah and the Poohludies WIP

Responder


También tendrá port a Saturn que por ahora está más verde: https://streamable.com/oq5fc3

Si no es vaporware es el desarrollo 3D para un sistema retro más currado que he visto al representar un mundo 3D abierto y con movimiento de cámara. La distancia de dibujado está muy alejada para un juego de PS1, si bien es cierto que es a costa de generarlo con una carga poligonal baja y sin texturas, pero comparado con la niebla a dos metros o la aparición repentina de una montaña de 2km de altura está muy bien. La técnica se parece a la usada por Spyro, supongo que será la misma ya que todavía se usa en el presente en juegos actuales, que es ir bajando/aumentado la carga poligonal y texturas del entorno según el jugador se acerque o aleje. En Spyro es mucho más sutil ya que los escenarios no son tan abiertos, al menos visualmente hablando.

No he encontrado ninguna web que seguir del proyecto, hoy me puse a buscar homebrew de PSX y apareció en vídeos de casualidad. Lo único que he encontrado fue en facebook una página dedicada a Saturn que dice esto:

So.., here's an intriguing twist... 😮🤯
Turns out the recently shared Saturn homebrew by misscelan, is actually a PORT of a PlayStation homebrew.., also by misscelan!!! This, of course, makes for a very interesting story, so here's a little more information on this fascinating new work in progress... 😉
Working Title: "Noah and the Poohloudies" by misscelan
Original PlayStation version:
https://www.youtube.com/channel/UCkh_i0 ... yjgYN_91cw
Sega Saturn Port:
https://streamable.com/oq5fc3
Brief Synopsis:
"You are a robot called Noah and you are tasked with a mission to save several other robots [Poohloudies] from a meteorite that is on a path to destroy their planet. When you encounter and jump on one of these robots [Poohloudies], they will merge with you, granting new abilities. So, it's kind of like a 3D Platformer with monster hunting..."
Development:
"I actually spent a great deal of time working on the PlayStation version [before deciding to port it to Saturn].
Saturn does have some benefits over PlayStation (and vice versa). The same goes for the assembly language they use.
If you want to squeeze them, each has its own cool features that the other doesn't...
That said, the PlayStation's GTE [Geometry Transfer Engine] makes it much easier to push a huge amount of polygons, but the Saturn's lighting fast [CPU] multiplication gets it pretty close. Each console is basically a completely different world.
The [Saturn's] architecture is a bit messy, but I like to make it a 'well-thought architecture' by simply ignoring some parts of the hardware, like the DSP or VDP2 (I don't use them at all, and if everything goes according to plan, I never will...)
Without them, it's fairly similar [to PSX development]. The use of quads and the lack of UVS is a annoyance, but it's just a bit more initial work for the exporters on the art side of things...
I'm basically using a custom renderer that doesn't bother waiting for VDP2 to sync... The benefit of this is not having to wait for VDP2 on every frame, however, the drawback is the inability to create some of the more advanced lighting and effects that XL2 does, for example, in HellSlave.
Without the use of VDP2, the background is just a skydome rendered in VDP1. There are probably ways to do it in VDP2.., but that would likely mess with the overall rendering and possiblity of doing other things while the plotter works... So, it's basically just a sphere with a gradient color inside, and other textures, like the clouds, are placed on an inner sphere.
As for the use of the DSP, it looks good when most of the polys are sequential and you're not culling much, like a racing game or a crash bandicoot type game.., because the MAC operation on the SH-2s does already 4 instructions at a time without halting much. [for a more open environment like this, it didn't seem appropriate]
[For the Saturn version] I still need to implement some missing features, and it's currently running on a single processor at about 17-18 FPS on real hardware, so it's not really playable yet... Using both CPUs, it ought to reach 30 FPS, and once I have everything implemented that is present in the PlayStation version and optimize it a bit more, I'll be sure to share a demo on SegaXtreme."


Se centra sobre todo en comentar la versión de Saturn como era de esperar. Pero bueno al menos parece que es cierto. El vídeo de PSX se publicó el 29 de Marzo así que April's Fools no debería ser.
Hola!

Soy el creador del juego :). Visito a menudo EOL aunque nunca escribo nada (de hecho he ido a contestar a este hilo pensando q ya tenía una cuenta desde hace tiempo, pero no).

Me ha hecho ilusión ver el post aquí la verdad. Es un juego en el q llevo trabajando unos años, pero lo hago en mi tiempo libre así q va mu despacio.

Empecé con el homebrew para la versión de ps1, y más tarde lo intenté portar a dreamcast pero antes de terminar me picó la curiosidad por la saturn y ahí es donde estoy ahora mismo. La idea es intentar q la versión de saturn corra a 30 fps y luego traer los avances de esta a las otras versiones, pero como digo esto va despacito.

No tengo de momento página web ni nada específico, solo el canal de Youtube con un video visible XD. Si en algún momento puedo trabajar más rápido y poner actualizaciones más a menudo ya crearé algo. De momento cuando trabajo en algo lo enseño en el discord de segaxtreme (ya q ahora estoy con la saturn) con el mismo nombre de usuario.

Este es el vídeo de la última actualización q hice:



Y hace poco me hicieron una entrevista para una pagina web q aunque está centrada en saturn, hablo un poco de todo y de q irá el proyecto en sí:

https://www.segasaturnshiro.com/2021/04 ... view-natp/

Un saludo!
@Misscelan buenas! No sabía que eras español [beer] Lo primero felicitarte, no abunda el homebrew en 3D y mucho menos en Saturn o PSX por eso me sorprendió mucho tu proyecto. Si en algún momento tienes algo jugable aquí somos varios que seguro estamos encantado de probarlo, en Saturn por mi parte también aunque todavía estoy esperando que me llegue mi cacharro para cargar juegos en ella porque lleva 20 días parado en Aduanas.

Cuando puedas revisa tu canal de youtube porque al investigar tu perfil para encontrar más vídeos sólo aparece el que enlacé aquí de hace 11 meses. Lo que has enlazado tú debe estar configurado de forma que sea privado excepto para quienes tengan el enlace. Por cierto vaya mejora en la versión de Saturn [tadoramo]

¿Por cierto que SDK usas? Encontré tu vídeo buscando si alguien había empezado a usar el PSnoobSDK ( http://lameguy64.net/?page=psn00bsdk ) que apareció hace un par de años, pero no parece que nadie lo esté usando realmente o la scene de PSX está muy escondida, esta consola está muy abandonada en este aspecto lamentablemente.

Y sobre la entrevista, el mundo es pañuelo, pero Vaccine lo conocía me lo pasó un amigo que sabe que juego los RE clásicos de cuando en cuando y me dijo que podría gustarme. FreezeMe en cambio acabo de descubrirlo y me sorprende porque en el 2016 exploré bastante a fondo lo poco que salía de WiiU. [tomaaa]

Un saludo y gracias por dar señales de vida!
@Misscelan enhorabuena por el homebrew, yo estoy intentando ponerme con la PSX ¿que SDK me recomiendas?

Gracias por el currazo que te pegas!

Saludos
Gray Fox 69 escribió:@Misscelan enhorabuena por el homebrew, yo estoy intentando ponerme con la PSX ¿que SDK me recomiendas?

Gracias por el currazo que te pegas!

Saludos


Buscando homebrew también encontré esto que creo que aclara un poco tu pregunta: http://www.psxdev.net/forum/viewtopic.php?f=24&t=3702
SuperPadLand escribió:
Gray Fox 69 escribió:@Misscelan enhorabuena por el homebrew, yo estoy intentando ponerme con la PSX ¿que SDK me recomiendas?

Gracias por el currazo que te pegas!

Saludos


Buscando homebrew también encontré esto que creo que aclara un poco tu pregunta: http://www.psxdev.net/forum/viewtopic.php?f=24&t=3702


@SuperPadLand gracias por el enlace, me pondré con ello.
@Gray Fox 69 cualquier proyecto o avance comunícalo [angelito]
Gracias por los comentarios!


SuperPadLand escribió:@Misscelan buenas! No sabía que eras español [beer] Lo primero felicitarte, no abunda el homebrew en 3D y mucho menos en Saturn o PSX por eso me sorprendió mucho tu proyecto...


La demo es algo q tengo previsto para verano cuando haya podido meterme con el segundo procesador de saturn, pero bueno siempre voy con retraso así q a ver si lo consigo.

Desgraciadamente no hay muchos juegos homebrew para psx, la comunidad está más centrada en decompilación de proyectos, emuladores y software. Aunque está el minecraft desarollado con candyk q tiene muy buena pinta.
Para saturn si que hay más cositas, todos los años se celebra una competición de juegos y salen cosas chulas, aquí puedes ver las entradas del año anterior:

https://segaxtreme.net/threads/sega-sat ... ion.24626/

Lo del canal de Youtube tengo más videos de desarrollo que están ocultos igual, los q haga públicos quieron q sean más completos, tengo la impresión de q si pongo los de saturn públicos q funcionan con un procesador solo o le faltan texturas la gente se lo va a tomar como q es como va a funcionar al final (aunque explique la situación en la descripción).

Y sí, uso el psnoobsdk :)


Gray Fox 69 escribió:@Misscelan enhorabuena por el homebrew, yo estoy intentando ponerme con la PSX ¿que SDK me recomiendas?

Gracias por el currazo que te pegas!

Saludos


El link q te ha puesto @superpadland te explica bastante bien todas las opciones. Yo te recomendaría cualquiera opensource para no usar de manera ilegal librerias, aunque seguramente a sony le da igual mejor no jugártela y además cuando le cojas el tranquillo puedes hacerle cambios para ajustar el sdk al proyecto. Psnoobsdk me parece el más completo y los nombres de la api son iguales a la oficial así q te valen la mayor parte de los ejemplos y la documentación de esta, la única pega es q está escrita en ensamblador mips y es un poco tedioso si quieres tú modificar o añadir algo.

Un saludo!
Gracias a los 2 @SuperPadLand y @Misscelan, ya tengo el entorno preparado y compilé los ejemplos, para muestra un imagen:

Imagen

Y ya no ensucio más el hilo de este magnífico homebrew.

Saludos
Pinta bien, el titulo me recuerda al crash bandicoot con las letras rotadas.

Quizá si corre algo más rápido luce más (más ágil todo) , no me he fijado si hay sombra bajo el personaje, era la solución para calcular los saltos en 3D.
@gadesx hay sombra sí. De hecho hasta las montañas tienen sombra en función de donde les da el sol.
@Misscelan ¿Cómo lo llevas? ¿Algún vídeo nuevo que mostrar?
hey @SuperPadLand :)

Pues mi intención era terminar la implementación de Saturn antes de volver a las plataformas anteriores (PSX y PC), pero tengo que hacer un montón de mini-tests para ver como mejoro la cache de instrucciones antes de saltar al segundo procesador, el problema que los emuladores no emulan la cache correctamente y para hacer esos mini-tests en hardware básicamente tengo que cambiar un par de líneas de código, recompilar el proyecto, pasarlo a una tarjeta SD, meterlo en el Fenrir, esperar a que se cargue, ver los resultados y decidir cuál va a ser el siguiente test y empezar otra vez desde 0.

Tengo poco tiempo para trabajar en esto y con ese método se me va una brutalidad de tiempo en pocos tests, así que la versión de Saturn lleva aparcada ya unos meses hasta que Fenrir implemente la opción de transferir juegos por wifi, cuando compré el Fenrir a principios de año parecía que se iba a implementar inminentemente, pero está tardando un poquillo en ver la luz.

Así que mientras espero a eso, volví a la versión de Dreamcast (que había dejado de lado para trabajar en la de Saturn).
La de Dreamcast está así ahora mismo. Esto es de un emulador, en hardware se me queda atascado en el menú principal (problemas de alineamiento en memoria de algunas variables).



Este es la primera vez que enseño la versión de Dreamcast :) Está todavía en un estado algo primitivo pero bueno se puede ver un poco como va.

Como ves todo el desarrollo va mu despacito, mi idea es implementar lo que tengo en dos o tres plataformas más y abir un patreon (no sería antes de mediados del 2022) y si despierta algo de interés pues podré dedicar más tiempo y trabajar más rápido, sino pues seguiré trabajando a este mismo ritmo, pero terminar salvo que me pase algo se terminará.
Misscelan escribió:hey @SuperPadLand :)

Pues mi intención era terminar la implementación de Saturn antes de volver a las plataformas anteriores (PSX y PC), pero tengo que hacer un montón de mini-tests para ver como mejoro la cache de instrucciones antes de saltar al segundo procesador, el problema que los emuladores no emulan la cache correctamente y para hacer esos mini-tests en hardware básicamente tengo que cambiar un par de líneas de código, recompilar el proyecto, pasarlo a una tarjeta SD, meterlo en el Fenrir, esperar a que se cargue, ver los resultados y decidir cuál va a ser el siguiente test y empezar otra vez desde 0.

Tengo poco tiempo para trabajar en esto y con ese método se me va una brutalidad de tiempo en pocos tests, así que la versión de Saturn lleva aparcada ya unos meses hasta que Fenrir implemente la opción de transferir juegos por wifi, cuando compré el Fenrir a principios de año parecía que se iba a implementar inminentemente, pero está tardando un poquillo en ver la luz.

Así que mientras espero a eso, volví a la versión de Dreamcast (que había dejado de lado para trabajar en la de Saturn).
La de Dreamcast está así ahora mismo. Esto es de un emulador, en hardware se me queda atascado en el menú principal (problemas de alineamiento en memoria de algunas variables).



Este es la primera vez que enseño la versión de Dreamcast :) Está todavía en un estado algo primitivo pero bueno se puede ver un poco como va.

Como ves todo el desarrollo va mu despacito, mi idea es implementar lo que tengo en dos o tres plataformas más y abir un patreon (no sería antes de mediados del 2022) y si despierta algo de interés pues podré dedicar más tiempo y trabajar más rápido, sino pues seguiré trabajando a este mismo ritmo, pero terminar salvo que me pase algo se terminará.

joer, pues yo le tengo ganas, kickstarter y versión fisica de PS1 [+risas]
@misterjano lamentablemente eso no es posible porque la PS1 requiere tener la consola lista para leer copias, imagina el jaleo si alguien financia esto sin leer la letra pequeña y le llega un juego para PS1 que detecta como copia pirata. [carcajad]

Ese es uno de los motivos por los que hay tantos homebrew en físico para Dreamcast, tu puedes hacer un programa para ella, quemarlo en un CD cutre y la consola lo traga como un original.

Por alguna razón no se sabe o no debe ser barato hacer repros en CD con la información de disco al arrancar necesaria para que la máquina lo lea directamente. Es una pena porque yo pillaría repros de este tipo de los juegos más caros del sistema (SotN, Suikoden 2, etc)
SuperPadLand escribió:@misterjano lamentablemente eso no es posible porque la PS1 requiere tener la consola lista para leer copias, imagina el jaleo si alguien financia esto sin leer la letra pequeña y le llega un juego para PS1 que detecta como copia pirata. [carcajad]

Ese es uno de los motivos por los que hay tantos homebrew en físico para Dreamcast, tu puedes hacer un programa para ella, quemarlo en un CD cutre y la consola lo traga como un original.

Por alguna razón no se sabe o no debe ser barato hacer repros en CD con la información de disco al arrancar necesaria para que la máquina lo lea directamente. Es una pena porque yo pillaría repros de este tipo de los juegos más caros del sistema (SotN, Suikoden 2, etc)

Pack con la memory lista? [+risas] [+risas] [+risas]

Será por alternativas.
He pensado lo del kickstarter y también lo de la distribución física.
Pero no me va mucho el kickstarter porque me va a crear un montón de estrés con gente demandando el producto final y estás cosas siempre tienen retrasos.

Me gusta más la idea de patreon durante el desarrollo porque alguien da un poco y obtiene algo en ese mismo momento y si no le gusta pues adiós y si le medio interesa siempre puede volver más tarde cuando esté más avanzado (o si le mola mucho sigue subscrito).

Pero bueno tampoco tengo lo del patreon muy claro, es algo que me plantearé cuando el juego tenga algo de jugo y no solo sea una demo técnica.

El cuanto a la distribución física, es otro berenjenal que no me gustaría meterme, pero si el juego saliese medio decente (que ya es mucho decir) siempre saldría algún interesado en hacer la distribución y llevarse una parte, lo cual no me importaría.
Misscelan escribió:He pensado lo del kickstarter y también lo de la distribución física.
Pero no me va mucho el kickstarter porque me va a crear un montón de estrés con gente demandando el producto final y estás cosas siempre tienen retrasos.

Me gusta más la idea de patreon durante el desarrollo porque alguien da un poco y obtiene algo en ese mismo momento y si no le gusta pues adiós y si le medio interesa siempre puede volver más tarde cuando esté más avanzado (o si le mola mucho sigue subscrito).

Pero bueno tampoco tengo lo del patreon muy claro, es algo que me plantearé cuando el juego tenga algo de jugo y no solo sea una demo técnica.

El cuanto a la distribución física, es otro berenjenal que no me gustaría meterme, pero si el juego saliese medio decente (que ya es mucho decir) siempre saldría algún interesado en hacer la distribución y llevarse una parte, lo cual no me importaría.

¿Te importaría compartir información técnica del cómo estás llevando a cabo el juego? SDK, manuales, algunas directrices básicas para alguien a quien le interese mojar los dedos. El know-how de cómo tirar para adelante vaya.
Tengo 6 años de experiencia como programador (y aparte la carrera y patatín patatán), pero tengo el ensamblador oxidado no, lo siguiente. De ver los vídeos estos me han dado ganas de bichear pero nunca sabe uno por dónde empezar en estos temas, es algo bastante poco recurrido. A mí no me importa aprender literalmente lo que sea, me encanta de hecho.
La información siempre está muy dispersa y los recursos instructivos son bastante pobres (siempre se enseña cómo utilizar las cosas en términos muy abstractos, y con pocos o ningunos ejemplos prácticos). A mí me basta con bastante poco para aprender porque tengo facilidades para tirar hacia adelante con poco material, pero generalmente cuando busco sobre estas cosas me siento en la selva porque el conocimiento está siempre muy escondido.

En fin, que gracias por tu tiempo hombre.
Enhorabuena por los resultados actuales por cierto, para ser tan solo una demo técnica se ve bastante legítimo. Se lanzaron al mercado juegos mucho, pero que mucho peores que lo que ya llevas entre manos [carcajad]

(PD: Los privados los tengo bien abiertos [ayay] )

EDIT: Estoy en la parra y he visto que utilizaste el psnoobsdk.
Pues una pregunta: ¿Cómo empezaste con él? ¿Lectura de documentación y probar cosas a saco? Generalmente estoy más acostumbrado a una metodología de aprendizaje mucho más visual que lo que se suele tener en este tipo de herramientas que como mucho están documentadas por funcionalidad y "buena suerte", sin un guión estructurado que muestre las cosas punto por punto.
hey @BSTCloud

El mejor sitio para aprender como programar para PSX en mi opinion es psxdev.net, ahí tienes SDKs, herramientas, tutoriales e incluso el código de algún juego completo. También tiene discord, pero en el discord la gente está más centrada en emuladores y exploits de la consola.

Pasa PSX puedes programar en C, incluso con los SDKs más nuevos tienes alguna función de C++ mu básica.
Para empezar, creo que intenté mostrar un sprite en pantalla y luego moverlo con el mando.
Aquí tienes 3 tutoriales de iniciación diferentes:

Cuando programas las principales a tener en cuenta es la multiplicación es lenta y la división aún más.
PSX tiene 4k de cache de instrucciones pero no tiene cache de datos. Te conviene que el código sea lo más compacto posible y por supuesto acceder a la memoria RAM lo menos posible (pierdes 5 ciclos por cada acceso a RAM). Tiene 1k de scratchpad (es como una memoria cache pero que solo la controla el usuario) en secciones críticas de código se suele reemplazar la dirección de memoria del stack por la dirección donde empieza esta memoria.

Tienes 2mb de memoria RAM y una parte de ella se te va en albergar el ejecutable.

El aspecto diferenciador de PSX respecto a la competencia era el GTE, un coprocesador que era capaz de realizar algunas operaciones matemáticas muy rápido para su tiempo. Por ejemplo puede transformar y proyectar 3 vértices en menos de 30 ciclos con el GTE y además hacerlo en paralelo (por referencia la Saturn tarda más que eso para proyectar un vértices solo, aunque la Saturn tiene otras virtudes). Para exprimir la consola al máximo te interesa echarle un ojo a que funciones puedes delegar para que haga el GTE en vez del procesador normal, e intentar correr otras funciones en paralelo en el procesador principal mientras el GTE te devuelve los resultados.

También si quieres sacarle todo el juego, necesitaras un poco de ensamblador MIPS, pero son pocas instrucciones y se aprende rápido. En cualquier caso MIPS es solo para sacar hasta la última gota, puedes hacer juegos perfectamente sin aprenderlo.

En cuando a recursos gráficos, PSX usa para imágenes su propio formato (TIM). Tienes herramientas para convertir imagenes en formato TIM. Hay que tener en cuenta que solo tienes 1mb de memoria de video y esta compartida con los buffers de imagen, osea a más resolución menos espacio para las texturas.

En cuanto a formato 3d, solo el SDK oficial tiene funciones para importar un formato 3d creado por ellos, que es horrible y ya no soporta ninguna herramienta de edición 3d actual. Lo mejor es que te crees tu formato desde 0.
También si te metes en el mundo de las 3d, tienes que tener en cuenta uno de los principales talones de aquiles de la PSX: Affine texture mapping, esto es que las texturas no tienen corrección de perspectiva, por lo general no importa mucho pero cuando vienen muy tumbadas y cerca de la cámara puede generar bastante confusión al jugador. La única manera de reducirlo es dividiendo los polígonos que estén cerca de la cámara en partes más pequeñas, esto te va a quitar bastantes ciclos de procesador y también añadir trabajo extra a la GPU.

Y así en resumen puede parecer un poco abrumador, pero si lo vas haciendo paso a paso las cosas van saliendo y es muy gratificante. Eso sí, si te metes en homebrew tienes que saber que el desarrollo siempre va muy despacio y hay que tomárselo con filosofía.
Llevo una semana siguiendo un curso de youtube para programar en ensamblador cuyo primer objetivo es crear un sprite (creo que inanimado) en Amstrad CPC y me veía muy feliz por haber comprendido más o menos lo de las instrucciones, como meterlas, ver que hacen, etc. Acabo de leeros y bueno, fingiré que no existís y seguiré siendo feliz poniendo pixeles de colores aleatoriamente en ensamblador y sentirme Dios. [sonrisa]
@Misscelan
No te había contestado pero vamos, de Dios todopoderoso el post que has escrito.
Lo recurriré en unos meses, ya que ahora mismo me ando (descansando en el último tercio de) un proyecto no-homebrewtástico pero sí de programación a modo de demo técnica/ejercicio de aprendizaje (unity) en el que llevo más de un año metido, y lo quiero acabar ya por cabezonería, así que hasta 2022 al menos no creo que me vea tomándome en serio la programación de PSX.

Pero me encantaría, es mi consola favorita.

(EDIT: Aquí había puesto unas preguntas sobre ejecutar el código en la consola, pero en realidad me debería de callar y buscar en los enlaces que has recomendado y ya está)
Desarchivado
@Misscelan buenas Missce, cuando tengas un rato haznos un update del estado del proyecto, ya te leí que lo habías parado, pero algo habrás avanzado desde este hilo hasta esa parada. [beer]
Hey @SuperPadLand,

Perdón por tardar en responder, no suelo hacer login y no me había dado cuenta de que había resucitao esto.

Pues la verdad es que avances hay pocos y que pueda enseñar ninguno. Del 2019 al 2021 coincidió que estaba bastante relajado en el curro, con la pandemia y muchos findes podía dedicarle tiempo. Ahora, estoy bastante más liado en el curro y a los findes llego muerto mentalmente o directamente ni estoy por casa.
Además, se junta que el siguiente paso que quiero dar, me obliga a reescribir buena parte del código. Estuve haciendo pruebas con una estructura de datos, que me permitiría colapsar mallas de cuadriláteros (como un Nanite de aliexpress) con muy poco coste para la CPU.

De cerca a LOD2

Esta estructura, me ayudaría a muchas cosas, como tener solo un nivel en memoria(en vez de tener uno para cerca y otro para lejos/colisiones) y haría las transiciones de LOD más suaves. También en vez de almacenarse con valores absolutos, almacenaría deltas con lo que haría las subdivisiones más rápido.

Eso lo juntaría con una manera nueva que he encontrado para hacer las trasformaciones un 50% más rápido y que también me permitiría tener escenarios 64 veces más grandes (evidentemente ni la PSX, ni la Saturn podrían con eso), pero sí que entraría dentro de lo posible doblar el tamaño haciendo uso de la estructura que antes he mencionado. O tener niveles más grandes en memoria sin la necesidad de que esté todo a la vista.
Pero a parte de reescribir buena parte del código, también tendría que rehacer modelos para que sacasen partido de esto.

Y ahora que he releído esto, parezco el Peter Molyneux vendiendo humo XD.

Al fin y al caso eso es todo, teoría, y mucha falta de tiempo. De ahí a lo que llegue a hacerse realidad pues ni idea.
Ójala, se me despeje el panorama en un futuro cercano y pueda dedicarse más tiempo a esto, ganas no me faltan :(
@Misscelan gracias, tú ve con calma a tu ritmo aunque lo que cuentas suena muy prometedor 👏👏👏
Desarchivando
Este fin de semana he tenido tiempo para avanzar bastante con el nuevo motor, voy a poner algo de lo que he hecho por aquí por si a alguien le interesa el desarrollo en estos sistemas.

El motor anterior se construyó para PSX, en algún momento hice una implementación rápida N64 y luego otra más seria para Saturn, y finalmente otra rápida para Dreamcast.

Las implementaciones de otras plataformas, un poco a la fuerza, acabaron complicando el motor, su mantenimiento y también el desempeño.

Desde hace ya un tiempo tenía una idea para implementar un sistema de colapso de mallas para poder tener más independencia a la hora de crear modelos y que ellos se ajusten solos a las cualidades de cada sistema. También porque quedan visualmente más atractivas que varios modelos de LOD y consumen menos memoria.

También quería aprovechar para que el motor usara como base el mínimo común denominador de las consolas de la quinta generación:
    -Usar un máximo de 1mb de memoria RAM para uso rápido (según que sistema puedo usar otro mega extra para tener una zona de intercambio de datos): La Saturn tiene 1mb de memoria rápida y otro de lenta y bueno en general muchos sistemas de esa generación tienen diferentes problemas y cuellos de botella con acceso a memoria, así que poniendo el límite en 1mb lo encuentro como un buen compromiso entre espacio y desempeño.

    -Un máximo de 350kb para texturas de un nivel. La PSX tiene 1mb de memoria RAM a compartir con el buffer, la Saturn tiene 500kb en el VDP1 donde también entran los comandos, las paletas y las tablas de Gouraud y la N64 no tiene memoria de video dedicada y si desempeño mejora notablemente cuantas más texturas y menos cambios se produzcan en su 4k cache dedicado.

    -El motor sub-divisiona los polígonos cercanos a la pantalla. Esto es un requerimiento para deducir el bailoteo en PSX, para reducir el “warping“ en Saturn y evitar el bloqueo del VDP1 y en N64 para poder tener texturas de más resolución cercanas a la pantalla.

    -No se pueden usar divisiones y el uso de multiplicaciones está muy reducido. Hacer divisiones en estos sistemas es algo casi prohibitivo, así que o se usan LUTs, divisiones con bitshifts o aproximaciones (lo de las divisiones ya estaba implementado en el motor anterior). Y respecto a las multiplicaciones, ahora también he implementado un sistema que reduce las multiplicaciones al transformar un punto 3d, esto sería principalmente para acelerar las trasformaciones de 3d para sistemas sin hardware dedicado o donde las multiplicaciones se tomen demasiados ciclos.

    -No se puede usar UVs: Ni Saturn, ni 3DO tienen

    -No hay uso de decimales, ya que solo n64 tiene soporte nativo. El problema de los “vértices bailongos” en ciertas consolas se debe sobre todo a la falta precisión sub-pixel de la GPU pero la N64 tiene.
Hay una excepción a todo esto, que son los “vertex colors”, 3DO no tiene esto, pero quitárselo a todas las demás limita mucho el aspecto visual. Y bueno, aunque deje la puerta abierta tampoco sé si quiero intentar meter este proyecto en 3DO, Jaguar o la 32x. Otras consolas no específicas de esta generación como la NDS o la GBA también entrarían dentro de estas limitaciones, y por supuesto esto no sería ningún problema para cualquiera de sobremesa de generaciones posteriores.

Y con todo esto me puse con el nuevo motor, la idea es hacerlo para PC primero, porque es mucho más fácil debugear y desarrollar, pero antes tuve que implementar un raster que funcionase con números enteros y que no tuviese ni UV mapping, ni corrección de perspectiva. Así puedo ver también en PC cuando un polígono es muy grande y genera mucha distorsión o cuando un polígono está renderizando mucha parte fuera de pantalla, y así controlar mejor el grado de subdivisión.
Y ahora mismo es donde estoy. Esto es como se ve el motor en PC con todo eso implementado:


La idea es que las mallas y el color se vayan mezclando. La zona donde cambia cada malla se puede ajustar dependiendo de la plataforma, incluso podría ajustarse en tiempo real si hubiese caídas de rendimiento.

El exportador en Blender, crea nuevas texturas agrupando varías para cuando las mallas colapsan en la lejanía o crea subdivisiones de texturas para cuando está más cerca.
También gracias a Blender puedo hacer un “bake” de luz de bastante calidad a los “vertex colors”, en vez de “lightmaps” que dan bastante el pego.
Esto es el mismo nivel con wireframe y algunos coloritos para ver mejor como los vértices se van moviendo para el colapso y la subdivisión, y como se crean y destruyen caras:


Ahora mismo este nivel usa 78kb de memoria para la geometría y 88kb para las texturas y paletas.

Y bueno eso es todo por ahora. Nunca sé cuando tendré tiempo para darle el siguiente apretón. Ahora mismo tengo pendiente el “back face culling”, que quiero hacer algo que trabaje mejor con las mallas, hacer alguna optimización y ya ver el desempeño en consolas, pero eso seguramente ya sea para el año que viene 😊
@Misscelan buenas missce, siempre es una alegría verte activo. Lo que no sabía era que también andabas con N64 y DC. [tadoramo]

Creo que cualquier cosa 3D que se haga para esta gen es bienvenida siempre y cuando tengas una demo estable te ánimo a presentarla al concurso de homebrew de Saturn que hacen todos los años en segaxtreme. Me suena que hay también algo de N64, de PS1 creo que nada:(
hehe gracias @SuperPadLand :)

Empecé con N64 antes de Saturn y lo abandoné porque no quería usar el SDK Oficial pero ahora Libdragon (el SDK opensource) ha hecho bastantes progresos en 3d y creo que ya está listo para pueda hacer experimentos. En Dreamcast tuve una build funcionando a finales de 2021 (es 1 de los 2 vídeos que están como públicos en el canal).

Lo del concurso de Segaxtreme me lo planteé en 2020/21 cuando tenía tiempo en pandemia y podía progresar más rápido, pero al final nunca conseguí llevar la versión al punto que quería. Supongo que si en algún momento tengo una versión con la que esté a gusto para soltarla al aire libre, entonces también será el momento en el que me proponga hacer el juego entero buscando financiación exterior (publisher, patreon, etc...) y entonces presentarlo a esos concursos no tendría mucho sentido.

Pero viendo que empecé con esto en 2017 y siempre acabo rehaciendo el motor y añadiendo más plataformas, es muy probable que esto no pase nunca y se quede en un buen señor vaporware de manual [360º] . Me encantaría poder ponerme en serio, dedicándole tiempo y terminarlo, pero bueno, como no tengo ningún compromiso con nadie para sacarlo y al final me lo paso bien también solo cacharreando pues tampoco me como mucho la cabeza con eso. [fies]
Desarchivando para actualizar.
Venía desde hace tiempo con ganas de hincarle el diente a la rama preview de Libdragon (https://github.com/DragonMinded/libdragon/tree/preview) , llevaba tiempo viendo los progresos y hace un par de findes me animé a portar lo que tengo.



Esta escena renderiza approx 1200 triángulos con colisiones y animación del personaje principal a 20 fps @ 320x240, la captura es de Ares, pero en hardware los números son bastantes parecidos. Los cracs entre los polígonos es un bug del motor y no de N64, lo mismo con el tembleque de los vértices.

Activar o desactivar el antialiasing y el dithering no parece tener un impacto significante, quizás por la resolución del juego.

Por el momento no uso el Z-Buffer, tengo una lista ordenada de los polígonos de atrás para adelante, aunque tengo planeado usarlo. Creo que desactivar el Z-buffer tiene sentido en juegos donde el overdraw sea muy bajo (por ejemplo en juegos de carreras), si el juego tiene bastante overdraw es probable que si activas el Z-Buffer y le pasas los polígonos de adelante a atrás provoques menos accesos de memoria (esto es lo que me gustaría acabar implementando).
No tengo activada la corrección de perspectiva en las texturas, esto no cambia mucho la carga de trabajo del RDP, aunque si te obliga a tener en memoria la 1/W del resultado de la multiplicación del vértice contra la inversa de la matriz de la cámara, y por ende otro acceso a memoria más tarde. Haré pruebas a ver que implicaciones tiene, aunque no creo que tenga muchas.

Para texturas uso 4 bpp y paleta de 16 colores, así que tampoco le estoy dando mucho uso a la cache de texturas. Por el momento no estoy agrupando los polígonos por materiales para así ahorrar accesos de memoria para llenar la cache, aunque no creo que tenga mucho efecto al final si quiero tener cierta variedad de texturas.

Para la animación uso la que tenía ya en el motor “animación por vertex”. En principio esta no es la solución más óptima para N64 ya que, aunque la animación por huesos puede ser computacionalmente más intensa (más cuanto más huesos y más incidencia de vértices por hueso) requiere de accesos de memoria extra para cada vértice. Pero creo que se puede optimizar bastante si pones las animaciones descomprimidas en ROM y las pasas todos los vértices de golpe a la RAM.

Hago todo el cálculo matricial en la CPU y además de una manera que no le viene muy bien a N64, solo uso el RSP para cargar el overlay de Libdragon que prepara los coeficientes de los triángulos que demanda el RDP.

Así en general, hay mucho de donde se podría rascar todavía y mejorar. Comparando con otras consolas, el problema no parece ser de la potencia sino del sospechoso habitual de n64 “la memoria”, y casi todas las mejoras vendrían de apartar del acceso a ella en lo máximo posible a todos los componentes.
Si por ejemplo desactivo la parte donde el RSP calcula los coeficientes y los manda al RDP, todo los demás (incluidos los cálculos matriciales en la CPU) consumen un total de 20ms, 4ms menos y entraría en la franja del requerimiento de la CPU para los 60 fps (relativamente fácil de alcanzar con solo pasar los cálculos matriciales al RSP).

Como anécdota, una vez tenía una variable global declarada fuera de un procedimiento, la cambié a dentro de la función y gané 2 FPS XD. No es únicamente por tener que acceder a la memoria para leer la variable cada vez que entraba en la función, es que reorganizar el código cambia el alineamiento de memoria de funciones y variables y todo eso tiene implicaciones. En otros sistemas no he tenido estos cambios tan bruscos por cosas tan “nimias”. Esto es solo un ejemplo de lo tensionada que está la memoria unificada y como pequeños cambios tienen efectos en cascada.

El motor ya llevo bastante tiempo desarrollándolo, pero el “porting” a N64 lo he hecho en un par de fines de semana. No lo digo por fardar, lo digo porque sido posible gracias al trabajazo enorme que se ha hecho con Libdragon, es super fácil de usar, esta todo super bien documentado, no he tenido que preguntar nada porque se encontraba todo fácil, ¡y además es gratuito y legal! Así que bueno, si sabéis un poco de programación y os gusta cacharrear es de los SDKs retro más asequibles para nuevos.
Misscelan escribió:Venía desde hace tiempo con ganas de hincarle el diente a la rama preview de Libdragon (https://github.com/DragonMinded/libdragon/tree/preview) , llevaba tiempo viendo los progresos y hace un par de findes me animé a portar lo que tengo.



Esta escena renderiza approx 1200 triángulos con colisiones y animación del personaje principal a 20 fps @ 320x240, la captura es de Ares, pero en hardware los números son bastantes parecidos. Los cracs entre los polígonos es un bug del motor y no de N64, lo mismo con el tembleque de los vértices.

Activar o desactivar el antialiasing y el dithering no parece tener un impacto significante, quizás por la resolución del juego.

Por el momento no uso el Z-Buffer, tengo una lista ordenada de los polígonos de atrás para adelante, aunque tengo planeado usarlo. Creo que desactivar el Z-buffer tiene sentido en juegos donde el overdraw sea muy bajo (por ejemplo en juegos de carreras), si el juego tiene bastante overdraw es probable que si activas el Z-Buffer y le pasas los polígonos de adelante a atrás provoques menos accesos de memoria (esto es lo que me gustaría acabar implementando).
No tengo activada la corrección de perspectiva en las texturas, esto no cambia mucho la carga de trabajo del RDP, aunque si te obliga a tener en memoria la 1/W del resultado de la multiplicación del vértice contra la inversa de la matriz de la cámara, y por ende otro acceso a memoria más tarde. Haré pruebas a ver que implicaciones tiene, aunque no creo que tenga muchas.

Para texturas uso 4 bpp y paleta de 16 colores, así que tampoco le estoy dando mucho uso a la cache de texturas. Por el momento no estoy agrupando los polígonos por materiales para así ahorrar accesos de memoria para llenar la cache, aunque no creo que tenga mucho efecto al final si quiero tener cierta variedad de texturas.

Para la animación uso la que tenía ya en el motor “animación por vertex”. En principio esta no es la solución más óptima para N64 ya que, aunque la animación por huesos puede ser computacionalmente más intensa (más cuanto más huesos y más incidencia de vértices por hueso) requiere de accesos de memoria extra para cada vértice. Pero creo que se puede optimizar bastante si pones las animaciones descomprimidas en ROM y las pasas todos los vértices de golpe a la RAM.

Hago todo el cálculo matricial en la CPU y además de una manera que no le viene muy bien a N64, solo uso el RSP para cargar el overlay de Libdragon que prepara los coeficientes de los triángulos que demanda el RDP.

Así en general, hay mucho de donde se podría rascar todavía y mejorar. Comparando con otras consolas, el problema no parece ser de la potencia sino del sospechoso habitual de n64 “la memoria”, y casi todas las mejoras vendrían de apartar del acceso a ella en lo máximo posible a todos los componentes.
Si por ejemplo desactivo la parte donde el RSP calcula los coeficientes y los manda al RDP, todo los demás (incluidos los cálculos matriciales en la CPU) consumen un total de 20ms, 4ms menos y entraría en la franja del requerimiento de la CPU para los 60 fps (relativamente fácil de alcanzar con solo pasar los cálculos matriciales al RSP).

Como anécdota, una vez tenía una variable global declarada fuera de un procedimiento, la cambié a dentro de la función y gané 2 FPS XD. No es únicamente por tener que acceder a la memoria para leer la variable cada vez que entraba en la función, es que reorganizar el código cambia el alineamiento de memoria de funciones y variables y todo eso tiene implicaciones. En otros sistemas no he tenido estos cambios tan bruscos por cosas tan “nimias”. Esto es solo un ejemplo de lo tensionada que está la memoria unificada y como pequeños cambios tienen efectos en cascada.

El motor ya llevo bastante tiempo desarrollándolo, pero el “porting” a N64 lo he hecho en un par de fines de semana. No lo digo por fardar, lo digo porque sido posible gracias al trabajazo enorme que se ha hecho con Libdragon, es super fácil de usar, esta todo super bien documentado, no he tenido que preguntar nada porque se encontraba todo fácil, ¡y además es gratuito y legal! Así que bueno, si sabéis un poco de programación y os gusta cacharrear es de los SDKs retro más asequibles para nuevos.


Te lo voy a pegar también en el hilo de N64 [beer]
@Misscelan
Puede que te interese esto:

https://github.com/HailToDodongo/tiny3d

Salud.
Gracias @dirtymagic

Le tenía un ojo echado a esa librería, la verdad es que tiene una pintaza tremenda. El otro día pusieron un post en el Discord de N64Brew sobre una especie de Monkeyball techdemo que iba bastante bien.

Pero creo que me tengo que mover en la dirección opuesta. Ahora mismo uso rdpq_tri a pelo (https://github.com/DragonMinded/libdrag ... rdpq_tri.h) y por lo que entiendo Tiny3d usa un wrapper sobre un nuevo overlay (RDPQ_Triangle_Send_Async- que debería ser también incluido en Libdragon). Estos overlays están muy bien si quieres usar toda la pipeline de la manera que ellos la han envisionado, pero no son ideales para mi proyecto :S. Hacen cosas como back-face-culling dentro, y yo lo hago en otro momento, hacen casting de variables que no necesito o trabajan sobre todo con triangulos y yo tengo muchos quads. Osea, lo que tocará si quiero optimizar esta parte será crear mi propio overlay específico para mi proyecto, lo cual es mucho más fácil ahora gracias a RSPL(https://gitlab.com/mbeboek/rspl)

Aunque creo que la mayoría del cuello de botella en mi proyecto viene de como trato las texturas, el Zbuffer y la disposición de varios elementos en la RAM.
Pero bueno le daré a todo esto una vuelta y ya reportare de vuelta en unos meses a ver como va la cosa :).
Muy interesante, quedaré pendiente de novedades.
Otra pequeña actualización, sigo trayendo cosas del anterior motor al nuevo.

He traído partículas, los cálculos del plano de la sombra del personaje principal, carga de ítems y personajes secundarios y alguna otra cosilla.

En general estoy contento con el desempeño de la nueva versión del motor, con la anterior versión había tenido que meterme con ensamblador porque no tenía muchas opciones más de donde sacar, con este todavía sigo con todo en C con un desempeño parecido al anterior con ensamblador.

Esta es la versión de Saturn ahora mismo:


En escenario, es solo para tests :P, para tener una comparación un poco más fidedigna con otros escenarios que se usaban en esa generación.

Los FPS no tienen mucha importancia por varias razones: por un lado esta captura es de mednafen que casi siempre da más FPS que en hardware, pero por otro lado solo uso el VDP1, un procesador y como comento más arriba todavía todo se hace en C y nada funciona en ensamblador.

Como se ve en el vídeo, también añadí una especie de reflejos especulares a los ítems. Digo “especie” porque no hago los cálculos reales, si no sería insostenible para estos sistemas.

Solo se muestran unos pocos ítems porque tantos los ítems como los NPC/enemigos no están actualmente incluidos dentro del octree, así que si pongo muchos el motor ahora mismo no tendría manera de filtrarlos y se resentiría mucho.

También he añadido la posibilidad de añadir TAGS al texto, para poder cambiar de color u otros efectos.

Los agujeros pequeñitos que se muestran en las texturas, es porque está activado el descarte del primer pixel de cada textura en la paleta, eso sería para poner el primer pixel negro y poder usar cosas como verjas transparentes, etc…

Con la la versión de N64 probé a activar el z-buffer después de ordenar los polígonos de atrás para adelante y gané un par de frames VS sin z-buffer y los polígonos de adelante para atrás.
Pensaba que iba a ganar un poco más con esto, al parecer tiene más peso todo el cálculo de los vértices en la CPU y los deltas de las aristas (esto se hace en el RSP pero el microcódigo actual bloquea el hilo principal), para solucionar eso tengo trabajar en un microcódigo customizado pero no trabajaré en eso hasta que vea que no puedo ganar más desempeño en el motor usando C a secas.

La versión de PSX y Dreamcast las tengo un poco abandonadas. La de PSX porque no me quiero meter a llamadas del GTE por las mismas razones que no hago el microcódigo para N64, con la diferencia de que en PSX si no usas el GTE para los vértices la CPU se te muere con 4 polígonos. Y la Dreamcast por temas de potencia, es la menos desafiante y la que menos me motiva por el momento, pero cuando tenga listo los demás, será el port más rápido.

Dentro de unos cuantos meses si tengo otro hueco y he conseguido avanzar algo ya lo pondré por aquí 😊
Ánimo y a seguir así.
Últimamente he podido introducir diezma de modelos automática.

Normalmente, se tienen varios modelos que se intercambian a medida que te alejas o te acercas. Pero con esto me da más libertad al diseñar, pierdo menos tiempo creando más modelos y también libero espacio de memoria.
Los niveles 3 y 4 son terroríficos pero como se activan bastante lejos en el video de n64 se puede ver como no canta tanto.

Imagen

También terminé de meter todos los modelos extras dentro del octree, así que ahora puedo ponerlos donde quiera y ya se encarga el octree de mostrar los que estén cerca y en pantalla.

3do
Empecé También a portarlo a 3do, aquí un video funcionando a la escalofriante cifra de 5 fps.


De momento, tampoco me he metido con ensamblador en este port, y le vendría bastante bien porque el único compilador disponible es antediluviano y seguro que se le puede sacar bastante jugo.

Tampoco uso el coprocesador matemático todavía. Lo único útil que hace este coprocesador es la multiplicación de matrices, no es un GTE o un RSP pero algo ayuda.

Si pudiese llevar, el port a velocidades de Shadowman para PSX (10-15) XD ya me daría por satisfecho.

La 3do no tiene coloreado de vértice (no se puede hacer gouraud), por lo que el juego queda bastante más plano sin ese sombreado, por verle algo positivo gracias a eso te ahorras algunos cálculos.

3do tiene un procesador bastante flojeras, es un ARM a 12.5mhz. La versión de ARM que tiene le permite algunas instrucciones chulas como por ejemplo el “bit-shifting” sale gratis, o puedes cargar varios registros en una instrucción, pero entre la velocidad y que no tiene ningún tipo de cache se le atraganta el 3d un poco.

Además, la 3do junto con la n64 son las únicas consolas con raster completo a las que pasarle los vértices, coordenadas de las texturas o los colores de los polígonos no se hacen en formato “estándar”, tienen una GPU un poco vaga y quiero que la cpu haga parte del trabajo.

Esto es por por ejemplo lo que tienes que hacer para convertir los datos después de haber proyecto los vértices en 3do (la función MapCel):
    https://github.com/trapexit/portfolio_os/blob/bee7b0c8e4287083c73cb5497b658880c9e7af8e/src/graphics/intgraf.c#L903

Y esto en n64 (las funciones __rdpq_write_zbuf_coeffs, __rdpq_write_tex_coeffs, __rdpq_write_shade_coeffs y __rdpq_write_edge_coeffs)
    https://github.com/DragonMinded/libdragon/blob/trunk/src/rdpq/rdpq_tri.c

Como veis es bastante tarea, ni la Saturn ni la PSX tienen que hacer nada después de las proyecciones. El RSP puede despachar esto con bastante más facilidad que la 3do, pero bueno la 3do es un sistema del 93 y para su tiempo no estaba mal.

Y hablando de la n64…
N64
Todavía no he tenido tiempo de pasar las proyecciones a microcódigo, y también estoy usando el microcódigo de Libdragon para hacer esos cálculos que puse en el link arriba, pero resulta que antes de llamar a ese microcódigo Libdragon tiene un wrapper para salir del paso y darle la opción a la gente de renderizar triángulos de forma rápida, pero recibe “floats” que luego se convierten a enteros (como necesita el RSP y el RDP). Pero los resultados que yo obtenía de las proyecciones estaban en enteros, así que lo pasaba a floats, para que luego el wrapper los pasase devuelta a enteros otra vez :S. Pues solo con saltarse el wrapper ya me ahorro unos 15ms en esta escena.

Con eso y gracias a las modificaciones que tuve que hacer para introducir para la 3do se puede ver va bastante más suelta ahora esta versión:


SATURN
Y los cambios para la 3do también han mejorado la versión de Saturn que ahora, con algo más de elementos en pantalla, funciona a un par de FPS más (la animación parece más lenta que el anterior video porque se han doblado los frames):



En unos meses si he vuelto a avanzar en algo lo postearé por aquí 😊
@Misscelan menuda capacidad debes tener para ser capaz de programar en cuatro sistemas simulatneamente. Felicidades!
Talento desaprovechado [buuuaaaa]
@SuperPadLand Gracias por los comentarios :) Pero bueno al final todos nosotros con el tiempo adquirimos más conocimientos de lo que nos interesa, tú por ejemplo eres una enciclopedia de la historia de los videojuegos y conoces juegos o anecdotas de las que yo no había oído hablar en mi vida
Guala que profesional te esta quedando.
Me encanta el resultado que veo y gracias por pasar la novedad por aqui. ¿Te ha sido muy dificil hacerlo o es tema mas de tiempo y conocimiento de maquina?
Yo me suscribo en youtube para que me peqgue cualquier aviso
Flash-Original escribió:Guala que profesional te esta quedando.
Me encanta el resultado que veo y gracias por pasar la novedad por aqui. ¿Te ha sido muy dificil hacerlo o es tema mas de tiempo y conocimiento de maquina?
Yo me suscribo en youtube para que me peqgue cualquier aviso


Gracias también por los comentarios!

Pues al final es un poco de todo, creo que empecé como en el 2017 con PSX pero solo puedo trabajar en el proyecto uno o dos días al mes (si hay suerte).

El principio es lo más difícil porque estas consolas no trabajan con formatos estándar de hoy en día, no leen JPGs, ni BMPs, ni lo mismo para los formatos 3d, así que si quieres algo medio decente tienes que empezar a crear herramientas que conviertan esos formatos a formatos que puedan leer esas consolas.
Al principio no había ni SDKs que funcionases en sistemas operativos actuales, así que tenía que trabajar en un entorno virtual con Windows XP.

En pandemia tuvo algo más de tiempo libre y le pude dar un apretón al proyecto (que son los únicos dos vídeos que son públicos del canal), pero ese motor estaba pensado principalmente para PSX y cuando empecé a añadir nuevas plataformas se volvió un caos y se le veían las costuras por todos los lados. Así que después de un parón de un año por el curro, empecé a desarrollar el motor otra vez desde 0 pero esta vez teniendo en mente el mínimo común denominador de todas las plataformas que quería implementar.

Y en eso estoy más o menos ahora, todavía no he terminado de portar todas las cosas del motor antiguo, pero también he implementado cosas nuevas, y en general el motor es más sólido y versátil que el anterior.

Desarrollar para estas plataformas es como hacer un poco de arqueología, aunque en su tiempo había bastantes desarrolladores para ellas, por aquel tiempo no tenían redes sociales ni se compartía el conocimiento de la misma manera, así que si tienes un problema específico para tu proyecto sueles estar solo y te toca empezar a buscar en la documentación de la consola que a veces no está escrita de la forma más clara o simplemente está mal traducida de algún otro idioma.
Pero bueno, cuando consigues sacar algo es muy reconfortante.

Gracias también por suscribirte al canal, aunque desafortunadamente no te valdrá de mucho :P. Como comenté arriba solo un par de videos del 2021/2022 son públicos, el resto los publico ocultos. Me encantaría poder trabajar para esto de forma oficial, pero por el momento es solo un proyecto hobby y no le quiero dar mucho bombo, con enseñar algo por aquí ya me motiva 😊.
42 respuestas
Responder
Volver a PlayStation