Novedades scene retro

@Sexy MotherFucker correjio.

Como curiosidad con respecto al Addon del Sega Chanel es que se modificó para que aceptara Micro SD. Posiblemente sea el primer Flashcard para Megadrive. El menú de listas es el mismo que el original noventero pero con más secciones para ordenar el catálogo.

@Yoshin mod-micro SD / Sega Channel

Y después del sotn en megadrive ahora existe esto:

https://www.youtube.com/watch?v=Rif6F-wQN9U

@wah_wah_69 lo publique en el hilo de cajón desastre MD, a ver si se superan y van completando poco a poco algunas fases y de paso añadir las cinemáticas de anime


bonus = encontré esto de un proyecto SGDK

37 nuevos juegos para Amstrad CPC
https://itch.io/jam/cpcretrodev2021

F-Zero Climax (GBA) en inglés:







hilo_traduccion-f-zero-climax-en-ingles-completada_2438689
http://www.romhacking.net/translations/6339/

@Feroz El Mejor ¿Planes de traducirlo al castellano?

Ragnastrife escribió:F-Zero Climax (GBA) en inglés:

hilo_traduccion-f-zero-climax-en-ingles-completada_2438689
http://www.romhacking.net/translations/6339/

@Feroz El Mejor ¿Planes de traducirlo al castellano?

Si fuera facil editar los graficos no me importaria, pero es complicado.

Tengo que pedir que me ayuden a modificar unas cosas de las herramientas para poder añadirle los caracteres españoles y asi tener traducidos los menus, misiones zero y lo que son los perfiles y la historia. Los graficos los dejare en inglés, sera una traduccion como la de F-Zero GX, en lugar de una como la de GP Legend.

En el subforo de GameBoy teneis los textos traducidos al castellano:
hilo_finalizada-traduccion-en-textos-al-castellano-de-f-zero-climax-gba_2436908

Que si alguien que sepa de editar roms quiere usarlos o algo, por mi encantado, la idea es que todo el glosario es el oficial, y estan los nombres localizados como en GP Legend.

Espero que la traduccion inglesa haga el apaño para el resto de jugadores occidentales, que quitando las cosas que son texto, lo demas deberia de ser accesible con el parche inglés.

@Feroz El Mejor
Bueno, era por curiosidad al ver que estabas tú ahí involucrado en el proyecto.
Por otra parte me parecía raro que nadie se hubiese puesto con F-Zero Climax hasta ahora, aunque fuese en inglés.

jrll escribió:37 nuevos juegos para Amstrad CPC
https://itch.io/jam/cpcretrodev2021

Alguna forma de descargarlos en un solo click ?
Gracias!

Creation escribió:@wah_wah_69 lo publique en el hilo de cajón desastre MD, a ver si se superan y van completando poco a poco algunas fases y de paso añadir las cinemáticas de anime


bonus = encontré esto de un proyecto SGDK

Esa es la nave del... Darius?

@wah_wah_69 zip, una versión con el sprite más grande

kanyero escribió:

jrll escribió:37 nuevos juegos para Amstrad CPC
https://itch.io/jam/cpcretrodev2021

Alguna forma de descargarlos en un solo click ?
Gracias!

Por ahora parece que no.
Imagino que cuando entreguen los premios la semana que viene, lo colgarán todo el la web de la UA, como hacen todos los años.

Homebrew Panasonic 3DO - Tomb Raider [Alpha] (Disculpas si fué posteado)




Demo de Scud Race para Dreamcast

¿Me lo parece a mí, o esa versión del Tomb Raider para 3DO no tiene el fallo de corrección de perspectiva en las texturas de la versión de PSX?

gynion escribió:¿Me lo parece a mí, o esa versión del Tomb Raider para 3DO no tiene el fallo de corrección de perspectiva en las texturas de la versión de PSX?

3DO y Saturn generan los gráficos 3D mediante Sprites , de ahí que se note menos la falta de corrección de perspectiva que en PSX, que lo hace con triángulos.

Salud.

En Saturn pasa lo mismo, busca los vídeos comparando ambas versiones del juego, la de PSX es claramente mejor en todo, excepto en que las texturas están más torcidas que en Saturn. Debe ser la única ventaja que tiene usar quads frente a triángulo sin corrección de perspectiva (con corrección evidentemente no).

@dirtymagic

Claro, pues será eso. El framerate es el que noto algo peor, y supongo que la consola ya va al limite, mientras que en el caso de PSX tan solo era uno de sus primeros juegos, aunque ese defecto la acompañó hasta el final, en mayor o menor grado.

dirtymagic escribió:

gynion escribió:¿Me lo parece a mí, o esa versión del Tomb Raider para 3DO no tiene el fallo de corrección de perspectiva en las texturas de la versión de PSX?

3DO y Saturn generan los gráficos 3D mediante Sprites , de ahí que se note menos la falta de corrección de perspectiva que en PSX, que lo hace con triángulos.

Salud.

Aquí te has columpiado bastante. Es Doom, el idtech el que usaba sprites para simular entornos 3d.

Lo que hace Saturn es generar polígonos con cuadrados en vez de hacerlo con triángulos. Esto, en algunos juegos hacía que sus entornos fuesen más robustos que en su par de psx.

Lo que sí utilizó Saturn en Virtua Fighter 2, es el ring a base de sprites con sincronía horizontal y estirado aplicando interpolación lo que le daba un aspecto soberbio y no perdía rendimiento.

Saludos.

gordon81 escribió:Lo que hace Saturn es generar polígonos con cuadrados en vez de hacerlo con triángulos. Esto, en algunos juegos hacía que sus entornos fuesen más robustos que en su par de psx.

Tiene razón dirtymagic con Saturn. La consola genera sprites y los deforma para crear modelos tridimensionales. No hace lo que Playstation, que genera triángulos y a esos triángulos aplica texturas.



No hay un ejemplo más claro que este vídeo de Tomb Raider en Saturn, donde emplea Cheat Engine para desactivar la transformación de sprites. Todos esos cuadrados que avanzan hacia la pantalla son los gráficos reales de Saturn, sin transformar.

Pero lo que hacen en el video es mostrar el uso de sprites para rellenar polígonos basados en quads, algo así como utilizar colores o dithering para simular textura en juegos como 4ds sport driving, o el primer virtua fighter.

Quiero decir, uso de un entorno 3d poligonal a base de quads pero las texturas son sprites que se unen a esos vértices.

Diría que en este caso ambos tenéis razón. Por un lado, entiendo que son sprites o tiles lo que maneja Saturn, y no polígonos con texturas; pero por otro tiene sentido que para deformarlos se utilice una malla 3D; aunque ésta sea basada en quads, creo que no dejan de ser mallas en 3D.

A ojo, por intuición y por lo que he ido leyendo, creo que la Saturn trabaja mucho más para hacer lo mismo. Aunque a la PSX le faltó un chip de apoyo para corregir las texturas en 3D; ya que sí, las pondrá en 3D con mayor facilidad y calidad, para también con mayor distorsión e inestabilidad.

¿Entonces la Saturn no texturiza? ¿Esto no debería ayudarle a poder poner más polígonos en pantalla a mejor rendimiento? Por ejemplo PSX creo que puede mover 500K poligonos por segundo sin texturizar, cosa que caía al activar sombreado y otros efectos y por supuesto texturizado a 80-120K

@gordon81 @gynion @SuperPadLand

Aunque ya hemos comentado alguna vez que lo de que es 3D o no es una discusión un poco sin sentido, la Saturn realmente lo unico que hace es usar sprites 2D, que "puede deformar" en una forma parecida al Modo 7 ( pero por srpite). Lo bueno es que eso permite transformar un sprite "cuadrado" en cualquier forma de Quad. Pero eso significa que no hay texturizado ni nada, solo esos sprites deformados.

@kusfo79 claro, pero supongo que la "máquina definitiva 2D" soportará el uso de todos esos sprites por hardware sin demasiada penalización, o al menos sin una penalización directa en la capacidad poligonal ¿no? Por tanto al no texturizar no debería verse beneficiada de un incremento de calidad poligonal? O quizás es que la capacidad de manejo de sprites deformada alcanzaba el límite a partir de cierta calidad poligonal y aunque podías subir esta, no llegaban ya los sprites que maneja el sistema para pseudo-texturizarlos?

@kusfo79

Sí, en el video que han puesto antes he visto los tiles cuadrados perfectamente, y es verdad que te haces una idea de que realmente esas texturas son tiles; pero para deformarlas con tanta precisión y tan sincronizadas se supone que se tienen que adaptar a una malla 3D que haga de guía, aunque esta malla sea solo de lineas sin pintar.

La Megadrive por ejemplo, ¿que hace con la demo de Starfox de Gasega? supongo que eso es 3D, por lo que si supuestamente Megadrive puede, ¿cómo no va a poder Saturn?

@SuperPadLand
En Saturn hay dos límites, el número de sprites (226 por línea), y los cálculos de donde han de estar los 4 vértices del sprite, ahí hay matemática de la buena, pero una vez hecho eso, todo va por hardware en el VDP1.

@gynion
A ver, lo que han de hacer es calcular donde van los 4 puntos, y eso, hasta donde yo sé, no lo hace el hardware, así que es donde se consume capacidad de cálculo de la buena.
Sobre el StarFox de Gasega, lo que hace es usar uno de los fondos y sus tiles como framebuffer (o lienzo) e ir pintando ahí. Esto consume mucho, ya que tienes que realizar cálculos por cada pixel de la imagen (aunque gasega lo ha optimizado locamente en su código).

En Saturn podrías hacer lo mismo usando el VDP2, que hace fondos 2d, y pintando el juego en el fondo, calculándolo todo a mano, pero en lugar de calcular 4 vertices por quad, calcularias todos los píxeles de cada triángulo.

Tanto la Saturn como en la Psx el programador genera una listas de commandos/paquetes donde se definen el tipo sprite/polígono, sus coordenadas, si es texturizado o no, si usa gouraud o no etc... Estos comandos se pasan a la gpu y esta se encarga de procesarlos. El limite viene dado por el fillrate de la consola (o en casos mu raros por la memoria para albergar estos comandos).

Si lo que Saturn llama "distorted sprite" es un polígono o no lo dejo para los filósofos. Para el usuario final no creo que importe.

El problema de texturizado incorrecto de psx no depende de si son triangulos o no (aunque luce peor en triangulos), depende del tipo de mapping utilizado "affine texture mapping", este tipo de texturizado no utiliza la distancia de la cámara para generar texturas correctamente, simplemente interpola la textura sin tener en cuenta la profundidad. Cuanta más diferencia en profundidad peores resultados, por eso si la textura es paralela a la camara es casi inapreciable y por eso si se subdivide el polígono el resultado mejora.

Saturn y 3DO usan "forward mapping" que también es incorrecto (interpola de textura a pantalla (al revés de affine)) aunque luce mejor que affine. Las texturas en estas consolas se deforman principalmente porque no tienen UVs así que cuando un polígono se extiende hacia la pantalla y la división entre Z de las componentes X e Y, si Z se aproxima a 0 o se vuelve negativa puede producir resultados impredecibles así que lo que se hace es que esos vertices se mueven hacia adelante y como no hay UVs toda la textura se comprime. Como en psx la solución es subdividir el polígono solo que con la diferencia de que en estas consolas también tienes que tener una versión subdividida de la textura en consola.
Una diferencia entre saturn y 3do es que el algoritmo de rasterizado de la primera no sabe si ya ha pintado un pixel o no, y si la textura está muy inclinada se puede producir bastante "overdraw" esto además de consumir recursos es la razón por la que la transparencia con "distorted sprites" en saturn produce errores ya que algunos pixels se escriben más de una vez.

Misscelan escribió:Tanto la Saturn como en la Psx el programador genera una listas de commandos/paquetes donde se definen el tipo sprite/polígono, sus coordenadas, si es texturizado o no, si usa gouraud o no etc... Estos comandos se pasan a la gpu y esta se encarga de procesarlos. El limite viene dado por el fillrate de la consola (o en casos mu raros por la memoria para albergar estos comandos).

Si lo que Saturn llama "distorted sprite" es un polígono o no lo dejo para los filósofos. Para el usuario final no creo que importe.

El problema de texturizado incorrecto de psx no depende de si son triangulos o no (aunque luce peor en triangulos), depende del tipo de mapping utilizado "affine texture mapping", este tipo de texturizado no utiliza la distancia de la cámara para generar texturas correctamente, simplemente interpola la textura sin tener en cuenta la profundidad. Cuanta más diferencia en profundidad peores resultados, por eso si la textura es paralela a la camara es casi inapreciable y por eso si se subdivide el polígono el resultado mejora.

Saturn y 3DO usan "forward mapping" que también es incorrecto (interpola de textura a pantalla (al revés de affine)) aunque luce mejor que affine. Las texturas en estas consolas se deforman principalmente porque no tienen UVs así que cuando un polígono se extiende hacia la pantalla y la división entre Z de las componentes X e Y, si Z se aproxima a 0 o se vuelve negativa puede producir resultados impredecibles así que lo que se hace es que esos vertices se mueven hacia adelante y como no hay UVs toda la textura se comprime. Como en psx la solución es subdividir el polígono solo que con la diferencia de que en estas consolas también tienes que tener una versión subdividida de la textura en consola.
Una diferencia entre saturn y 3do es que el algoritmo de rasterizado de la primera no sabe si ya ha pintado un pixel o no, y si la textura está muy inclinada se puede producir bastante "overdraw" esto además de consumir recursos es la razón por la que la transparencia con "distorted sprites" en saturn produce errores ya que algunos pixels se escriben más de una vez.

La Sega Saturn puede deformar los sprites dandole las coordenadas en pantalla de cada vertice. Eso significa que se puede calcular la proyección 2D de la malla 3D por CPU, es decir, en la malla que vemos en el vídeo subido anteriormente, cada intersección de las líneas es donde se coloca el vertice del sprite correspondiente:


También la Saturn puede generar gráficos vectoriales. Es decir, una línea de un punto a otro, o un cuadrángulo vacío o rellenado de un color. Es como se dibuja la malla en el vídeo, los 4 vertices del sprite se transforman en 4 pares de puntos de 4 líneas o un cuadrángulo vacío.


Y lo que se hace en el vídeo es cambiar la propiedad del sprite de distorsionado por los 4 vertices a normal, eliminando toda distorsión por vertices.

Novedades retro

Nuevos juegos para Amiga.


''Devil's Temple : Son of the Kung-Fu Master'' para Amiga 100/200/500. Es una fusión entre Kung-Fu Master y Vigilante

https://mcgeezer.itch.io/kung-fu-remaster





'Jackal' para Amiga 500. (W.I.P)



''Lost Asylum - A Ruff N Tumble'', (Alpha) ,nuevo juego de plataformas para Amiga 500 inspirado en el clásico Ruff 'n' Tumble.

Soul Eater (Wii) traducido al inglés: https://www.romhacking.net/translations/6340/

Parche 60hz para Super Bust A Move (GC): https://www.romhacking.net/hacks/6312/

Wonder Boy hack de color para parecerse al arcade (MS): https://www.romhacking.net/hacks/6299/

Parche para cambiar la fuente de los textos de Forbidden Siren 2 y además corrige errores de la traducción española (PS2): https://www.romhacking.net/hacks/6264/

Shinobi X PAL a 60hz (SS): https://www.romhacking.net/hacks/6046/ (desconozco si era necesario este parche por no ser compatible con forzarlo a 60hz directamente desde la consola con el mod de 50/60hz)

Los parches de Bust A Move y Shinobi X son porque las versiones europeas eran "mejores".

En el caso de Shinobi X, la música japonesa y americana era tan malísima, una especie de midi ratonero, que el productor del juego en Europa encargó a un nuevo artista rehacerla del todo. La música europea es muy buena, unas composiciones inspiradas en la obra de Yuzo Koshiro. Lo malo es que el parche se carga la intro, aunque no el resto de vídeos.

En el caso de Bust A Move es porque las versiones europea, japonesa y coreana tienen dos modos extra respecto a la americana. Por un lado multijugador a pantalla partida para cuatro jugadores (dos en el americano) y luego una especie de minijuego a lo Space Invaders. La versión coreana tiene todo esto y va a 60 hz, con lo que también puedes usar esa. La única diferencia es que la europea tiene 4 idiomas más.

@SuperPadLand Gracias por poner la noticia del hack de Wonder Boy para Master System. No lo sabía.

Y se nota la mejora??

Diría que emulado siempre lo he jugado sin esas ralentizaciones tan notables. Hay que ver lo que aguantábamos de peques por jugar.

Magical Quest 3 Fastrom: https://twitter.com/MaxwelOlinda1/statu ... 2416360453





@Karaculo a la hora de criticar las ralentizaciones de SNES se notan siempre, por minúsculas que sean.

Pues se ve la diferencia, una pena que esto tenga que llegar en forma de hack y los cartuchos no fueran así en su época

Yo creo que en algunos casos (como el del Magical Quest 3) no es problema del tipo de rom del cartucho, si no de simple mala programación: No había gran cosa en pantalla y ya tenía algunos tirones, mientras que juegos como smash tv mueven un montón de objetos sin demasiados problemas, y hay juegos de NES que mueven más sin tampoco ralentizaciones.

Juer escribió:Pues se ve la diferencia, una pena que esto tenga que llegar en forma de hack y los cartuchos no fueran así en su época

pues si, pero casi todo lo relativo a la scene es fuera de su época .
arreglos de ralentizaciones, redibujado de sprites ,mejor sonido ect
al final lo bueno es que se puede disfrutar ahora y el objetivo es para personas que siguen utilizando sus sistemas retro.

En Aladdin y Magical Quest 3, al poner el juego en fastrom, acaba con las ralentizaciones o solo va más rápido en general?. Es que el que vaya más rápido yo no lo veo una ventaja.

Si fuera más rápido en general seguirían habiendo ralentizaciones, solo que más rápidas.

8bit Guy esta porteando su juego Petscii Robots a varios ordenadores y consolas de 8 y 16 bits, incluyendo NES, SNES y MegaDrive.

Pero lo de fastrom básicamente es activar un bit, no han mejorado el codigo, con lo cual ¿Por qué no lo activaron los programadores en su día?

En proceso nueva versión de Double Dragon para Amiga, (port directo del arcade),

http://www.indieretronews.com/2021/11/d ... sumed.html

Página oficial




Boulder Dash Junior para Commodore 64, nueva entrega Homebrew de Boulder Dash

http://www.indieretronews.com/2021/11/b ... r-c64.html

Descarga

Karaculo escribió:Pero lo de fastrom básicamente es activar un bit, no han mejorado el codigo, con lo cual ¿Por qué no lo activaron los programadores en su día?

Porque los cartuchos fastrom eran más caros.

GValiente escribió:

Karaculo escribió:Pero lo de fastrom básicamente es activar un bit, no han mejorado el codigo, con lo cual ¿Por qué no lo activaron los programadores en su día?

Porque los cartuchos fastrom eran más caros.

No creo que mas caros que los de megadrive. Esa es la cuestión.


P.D: Las ralentizaciones se quitan, o no se quitan, no hay forma de que no dejen de existir si las eliminas.