RGBuntu (EmulationStation + RetroArch)

dinamita4922 escribió:@theelf

Este esquema es correcto??

Si, es correcta. Las resistencias estan por el tema de voltaje, yo cuando armo cables para vender en alguna maquina, las pongo

Si es algun cable para mi de pruebas, paso de ellas

@dinamita4922

Es correcto el esquema, el cable rojo más la resistencia le proporciona 2v al pin16 para conmutar a rgb y el cable amarillo le mete 12v al pin8 para que la tv se cambie al canal av directamente sin el mando.

Yo el cable lo compré hecho en tienda, viene con un usb soldado al pin16, es obligatorio, luego yo opcionalmente le soldé un step up al pin8 para coger 5v del conector usb de la placa base y elevarlos hasta los 12v necesarios para que cambie al canal av y no tocar el mando.

Fotos en spoiler.

@theelf @extremorpg

Gracias a los dos. Me lio esta semana con ello

El tamaño de la iso (1.8 gb) es con roms ?¿ yo siempre he usado raspberry para emular uso retropie+attractmode. Aunque la emulacion de los pcs (amstrad,spectrum,msx...) me gusta mas en pc.

Ahora tengo ubuntu + scripts retropie que te lo instala todo. Ventajas ante esto ?¿ tiene buena si , todos estos proyectos y mas siendo de aqui me encantan

@snock

snock escribió:El tamaño de la iso (1.8 gb) es con roms ?

En la ISO, no se pueden incluir roms, ni bios. Y si merece la pena el cambio de una raspberry a un PC. En cuanto a potencia, y sistemas soportados, existe una gran diferencia.
Un saludo.

diavluci escribió:@snock

snock escribió:El tamaño de la iso (1.8 gb) es con roms ?

En la ISO, no se pueden incluir roms, ni bios. Y si merece la pena el cambio de una raspberry a un PC. En cuanto a potencia, y sistemas soportados, existe una gran diferencia.
Un saludo.

Como dice el compañero nosotros no podemos facilitar esos archivos dentro de la iso. Incumple las normas del foro y no es legal. El tema de la bios... de alguna manera os enterareis de donde conseguir las adecuadas con la estructura necesaria
Con roms, pues si alguien se anima puede hacer una versión con todos los romset metidos. Recordar que lo que estamos creando es software libre, por lo tanto abierto a todas las modificaciones que queráis hacerle.
El tamaño de la nueva versión es mucho menor, le hemos puesto a una dieta estricta. Y aún llevando muchas más cosas ha perdido mucho peso.

Un saludo.

Buenas,una pregunta que no viene al caso pero que necesitaria saber.

Segun veo,usais attract mode,me gustaria saber,a que resolucion lo poneis para que se vea en el crt

Estoy liado con un pc conectado a un televisor crt,use vuestra distro pero aun activando el script de los 15khz me salen rayas en la tv(la grafica que uso es una ATI RADEON HD 6870),asi que volvi a lo que tenia,windows,drivers de calamity a 15khz,pero cuando ejecuto attract mode,pierde la sincronia y nada mas se ven rayas.Como veo que lo utilizais,la resolucion de usais que salga en la tv crt es de 640x480?yo uso esa y se ve todo bien,hasta que ejecuto attract mode y no se ve nada y como en attract mode no veo ningun archivo que pueda configurar la resolucion o algo precido no se cual debe ser el problema

Gracias y perdon por desviarme del tema principal que nos ocupa

@treme, bueno, yo creo que si viene al caso del hilo. Para eso se ha creado: parado dudas, sugerencias, apoyos... a RGBuntu.

En las RC sí, estamos usando AM. En la final hemos empezado a usar Emulationstation. La resolución que usamos es 648x480. Al poner 640x480, en mi caso, tenía problemas que quedan pieles en negro.

Sobre las rayas, me interesaría saber porque te salen para intentar ayudarte y si podemos solucionarlo. Si puedes enviarme el fichero /etc/X11/Xorg.conf después de lanzar el script me ayudaría mucho. Supongo que pueden ser por algunos de los parámetros activados. En la final ya no estarán estos parámetros con el fin de intentar buscar compatibilidad con tarjetas de no ATI que soporten bajas resoluciones.
AM no se configura la resolución, es el theme el que se ajusta a la relación de aspecto de la pantalla. De hecho el theme que usábamos tuve que modificarlo para que aceptase 648x480, aunque sigue aceptando el resto de resoluciones estándar.
En nuestro caso no hacemos modificación en la bios de la tarjeta, por lo tanto los drivers de calamity a 15khz no se verán alterados en Windows.
Una parte que desconozco, pero creo, es que la tarjeta funcionará a 15khz tanto en Windows como en Linux. Quizás los problemas de las rayas vengan por esta parte, ya que RGBuntu espera encontrarse con una tarjeta que no emite en 15khz.

Un saludo.

@Vassag0

Prueba de usar 480x270 a 50hz para ES, es divisor de 1920x1080 y progresiva. Asi podras reutilizar muchos skins fullhd... no todos se veran bien, pero bastantes seguro q si

En caso de querer usar entrelazado, 640x540 seria mejor. Me parece todos los skins apuntan a 1080p ahora

Supongo podrias llegar hasta los 52hz en las dos resoluciones

Vassag0 escribió:Con roms, pues si alguien se anima puede hacer una versión con todos los romset metidos. Recordar que lo que estamos creando es software libre, por lo tanto abierto a todas las modificaciones que queráis hacerle.
El tamaño de la nueva versión es mucho menor, le hemos puesto a una dieta estricta. Y aún llevando muchas más cosas ha perdido mucho peso.
Un saludo.

Mas que romset, yo he aprendido que es mejor tener algo como lo de los 333 juegos de MAME o como el top de MEGA y SNES que me curré (el cual no acabé subiendo el pack, que era la ideam, por que había movimiento cero en el hilo que abrí)

hilo_top-clasicos-megadrive-snes-listas-inside_2303309

Si se se acaba quedando Attract Mode puedo montar una versión "no oficial" con esos dos sistemas que tengo montados (y si Mur3 da su permiso también meto lo de MAME que lo tengo montado en attract) y subirlo al espacio sideral...

Si se queda en emulestation, puedo montarlo pero sinceramente me volví loco intentando adaptar los temas que me gustaban para mostar vídeo y no pude, me desespera ese front-end (ojala launchbox funcionara en equipos livianos...)

Por lo demás, si tengo tiempo esta semana intento probar la distro RC en el futro por ver como va...

No os preocupeis que para hablar de packs y sistemas, tendremos tiempo. Hay otros medios, para hacerlo más directos, y con los que no incumpliremos ninguna norma del foro, (no estando en el). Todo llega, lo primero es poder terminar la versión final.,y a posteriori veremos todos estos temas, así como dudas , configuraciones y problemas.

Buenas, no se si es necesario presentarme en el foro , indicadme si es preciso.

Comentaros que esta rgbuntu tiene buena pinta , y tras las primeras pruebas en juegos horizonates, y consolas , que también son horizontales, va todo bastante bien. Se nota se han realizado mucho test en horizontal, peroooo en vertical para shoom em ups , somos unos cuantos los que nos gusta jugar en tate mode, rotando el monitor para tener el feeling autentico , es ahí donde donde veo que las cosas no están tan afinadas. En resoluciones de 256x256 y cosas por ese estilo también veo que sobran unos bordes negros a ambos lados de la pantalla que se supone no deberian estar, he ido trasteando con el aspect ratio, y demás. Seguiremos probando y a ver si podemos colaborar para mejorar esta pedazo de distribución de emulación.

jgalanco escribió:Buenas, no se si es necesario presentarme en el foro , indicadme si es preciso.

Comentaros que esta rgbuntu tiene buena pinta , y tras las primeras pruebas en juegos horizonates, y consolas , que también son horizontales, va todo bastante bien. Se nota se han realizado mucho test en horizontal, peroooo en vertical para shoom em ups , somos unos cuantos los que nos gusta jugar en tate mode, rotando el monitor para tener el feeling autentico , es ahí donde donde veo que las cosas no están tan afinadas. En resoluciones de 256x256 y cosas por ese estilo también veo que sobran unos bordes negros a ambos lados de la pantalla que se supone no deberian estar, he ido trasteando con el aspect ratio, y demás. Seguiremos probando y a ver si podemos colaborar para mejorar esta pedazo de distribución de emulación.

Muchas gracias por feedback @jgalanco, nos viene increible. Te voy comentando.

Efectivamente el trabajo sólo se ha realizado en juegos horizontales para la RC1. La versión final podrás escoger jugar tanto verticales en pantallas horizontales como en monitor rotado. En el caso del monitor rotado en pixel perfect.

En caso de los juegos a 256, nosotros apostamos por el pixel perfect. No por crear un aspect ratio "estirado". Revisa unos hilos más para atrás para ver las explicaciones. Pero, por el ejemplo, el bubble bobble tiene una resolución de 256x224, por lo tanto su aspect ratio correcto es de 1,14 y es el aspect ratio que mantenemos para evitar efectos indeseados. De hecho yo lo he jugado, en salones recreativos, con la relación de 1,14. Iba a contactar con el creador de este juego, que también hizo el Rainbow Islands (en este caso en 320x224). Si su intención era estirar los juegos o mantener la proporción de aspecto, debido al debate que se ha montado... pero desgraciadamente falleció en 2008. Por lo tanto, me he ceñido a la teoría que tenía cuando programaba en Amstrad CPC: los sprites tienen una relación de pixeles (en aquel momento matriz) para respetarse, no para estirarse.

Si alguien tiene documentación donde se indique que deben estirarse los juegos... es bienvenida.

Un saludo.

@Vassag0

el aspect ratio lo da el monitor... o sea 4:3 en arcades. No hay mas...

theelf escribió:@Vassag0

el aspect ratio lo da el monitor... o sea 4:3 en arcades. No hay mas...

Lo que me gusta flagelarme, pero vuelvo a intentarlo.

Por esa misma razón una película de 4:3, en un CRT de 16:9, ¿debemos estirarla horizontalmente? Y una película en formato 2,39:1 ¿debemos estirarla verticalmente? Creo que los directores de fotografía estarían encantados con esa idea, viendo como su trabajo no sirve de nada...
Te recomiendo la película Mommy, donde juegan con la relación de aspecto para ver que, dentro de un mismo monitor, se pueden usar distintas relaciones de aspecto (dejando bandas negras en función de la misma) con intencionalidad.

Por favor, necesito documentación al respecto... de otro modo, seguiré ciñéndome a la relación de aspecto del creador.

Un saludo.

@Vassag0
Eso q dices no tiene sentido alguno, los arcades clasicos son 4:3, porque los monitores son 4:3. El bubble bobble es 4:3 porque es el montior q traia de serie la maquina

Me parece solo hay algunos casos de monitores q no son 4:3 de arcades vectoriales, q no vienen al caso

Lo que ocurre es que el monitor del Arcade es 4:3, si cogemos cualquier resolución 4:3 y dividimos la horizontal con la vertical nos da un Aspect Ratio de 1,333333333 pero si el juego usa una resolución cuya división no da la cifra anterior tal vez no es 4:3 por lo que a su alrededor se vería un fondo negro o de cualquier otro color que después se cubriría con un bezel.

En el caso del juego que comentáis el resultado de dividir la resolución del juego horizontal y vertical (256/224) da un Aspect Ratio de 1,14285714............ no llega a 4:3, pero se juega en monitores 4:3, al igual que vemos peliculas con relaciones de aspecto raras y franjas arriba y abajo en monitores 16:9

Que hacemos hoy en dia para poder ver una pelicula clasica?. De esas en blanco y negro, con una tele moderna en formato panoramico 16:9.
Pues si quieres verla respetando como se rodó , te tienes que tragar dos bandas negras en los laterales. Si quieres llenar la pantalla, aplicas el reescalado en tu mando a distancia, y tendrás a los protagonistas de la pelicula a sus anchas.
Hay que separar la relación de aspecto de un monitor, del contenido que se reproduce en ella.
Un saludo.

Los famosos formatos letter box y pilar box, pero no recuerdo haber visto que se usaran en ninguna recreativa en su época. Y todos llenaban la pantalla al completo

Lo mismo seria interesante confirmar estos datos con alguien que tuviera placas originales. Así saldríamos de dudas

El problema, de quien tenga la placa original, es que puede usar los controles del monitor arcade para poner la relación que quiera. Sería alguien que tuviese el cabinet original, para ver si el bezel cambia la resolución de aspecto.
O lo mejor el manual técnico de instalación. Digo que ahí darían instrucciones de cómo debía configurarse.
En mi pueblo cada máquina tenía su resolución de aspecto. No digo que dueño fuese un purista, que lo dudo mucho, quizás el técnico era vaguete y pasaba de estirar la imagen. No podría asegurar al 100% dónde está la verdad. Encima el dueño de los recreativos también está muerto.

Para esta versión no me dará tiempo. Pero supongo que para la versión 2 espero meter los cambios de Alphanau (por cierto habéis visto que ha sacado ya una distro Alpha), y creo que voy a dar al usuario la posibilidad de elegir entre relación de aspecto original o forzar 4:3. Y así que cada cual elija lo que le gusta. No quiero hacer una guerra con este tema, más sin tener más datos que los basados en recuerdos, experiencias en otros sistemas, o suposiciones.

Un saludo

No entiendo lo de las peliculas, no tienen nada q ver con juegos

Los juegos son 4:3 porque son los monitores los q definen el aspect ratio, y en la epoca son los q se usaban

Igual que un juego de DOS VGA es 4:3 porque los monitores eran 4:3, no 16:9 ni 5:4 en la epoca.

theelf escribió:No entiendo lo de las peliculas, no tienen nada q ver con juegos

Los juegos son 4:3 porque son los monitores los q definen el aspect ratio, y en la epoca son los q se usaban

Igual que un juego de DOS VGA es 4:3 porque los monitores eran 4:3, no 16:9 ni 5:4 en la epoca.

No hay más ciego que quien no quiere ver...

Dile a los creadores de vídeojuegos que no tiene nada que ver lo suyo con las películas: ambos son un arte.

¿Que pasaba en la época de las teles 4:3 cuando se creaban películas en 16:9 o cinemascope?
https://es.m.wikipedia.org/wiki/Ben-Hur ... la_de_1959)
Dile al director de fotografía de Ben-hur que se debe estirar en 4:3 porque todas las teles de su época eran así.

La relación de aspecto no la define el dispositivo de visionado, ni la época.

Un saludo.

Dejo por aquí esta lista por si queréis echar un vistazo.

https://en.wikipedia.org/wiki/List_of_common_resolutions

extremorpg escribió:Dejo por aquí esta lista por si queréis echar un vistazo.

https://en.wikipedia.org/wiki/List_of_common_resolutions

Muchas gracias.

No la conocía y me parece de una gran utilidad.

Un saludo.

@Vassag0
Entre esto y el pixel perfect, es para sacar palomitas. No, no tienen nada q ver las pelis con los juegos, nada

Ni tampoco tiene nada q ver resolucion con aspect ratio

Se puede intentar contactar con Arcade planet o similar que tienen tropecientas maquinas originales para preguntarles a ellos. Aquí en el mismo foro habrá mucha gente con maquinas originales

Bajo mi punto de vista esa resolución pertenece a una imagen anamorfica, pensada para que el crt la estirara y la representara a pantalla completa. Y si en alguna maquina la representaba 1:1 era por mala configuracion del tecnico. Pero claro que es solo mi opinión y no la puedo argumentar ni contrastar

@dinamita4922

Los arcades ya se vendian con su monitor, y venian con unas instrucciones para el operador. Tambien por ejemplo, venian con utilidades como el dot cross hatch, para poder ademas de ajustar la linearidad, poder dejar la imagen corerctamente centrada

Las consolas es diferente, por eso por ejemplo, 320 pixeles de una megadrive, no son iguales a los 320 pixeles de una neogeo, porque el pixel clock no es el mismo

@theelf

Gracias por la aclaración.
Entonces entiendo que si alguna maquina no llenara por completo la pantalla seria por una configuración errónea del operador??

Hay dos conceptos que estáis confundiendo: la relación de aspecto del monitor (4:3) y la relación de aspecto de los píxeles individuales ("pixel aspect"). Según la documentación de MAME (render.h):

Regarding pixel_aspect, this is the aspect ratio of the individual
pixels, not the aspect ratio of the screen. You can determine this by
dividing the aspect ratio of the screen by the aspect ratio of the
resolution. For example, a 4:3 screen displaying 640x480 gives a
pixel aspect ratio of (4/3)/(640/480) = 1.0, meaning the pixels are
square. That same screen displaying 1280x1024 would have a pixel
aspect ratio of (4/3)/(1280/1024) = 1.06666, meaning the pixels are
slightly wider than they are tall.

Dividir resolución horizontal partido de vertical para calcular la relación de aspecto es incorrecto. Sólo es correcto en el caso particular en que los píxeles son cuadrados (pixel aspect = 1:1), que es lo habitual en las pantallas actuales, y de ahí viene la confusión.

Aplicar el concepto de píxel cuadrado retrospectivamente a los CRTs es un anacronismo.

---

En realidad es sencillo. Lo único que debe hacerse es tomar la resolución nativa del juego y crear un modo de vídeo con idéntica resolución. Que es lo que entiendo que estáis haciendo (según el ejemplo de Bubble Bobble que comentamos más arriba). Las consideraciones sobre la relación de aspecto, por tanto, son innecesarias.

---

Caso distinto es, en eso estoy de acuerdo, el asunto de los juegos de Megadrive en formato PAL. Ahí evidentemente los gráficos se diseñaron para televisores NTSC, que vienen ajustados de fábrica para que muestren 240 líneas (incluso menos, normalmente quedan 16 líneas en el overscan). Cuando estos juegos se pasan a PAL, aparecen los infames bordes negros, dado que los televisores PAL vienen ajustados para 288 líneas. Por lo que, en efecto, la relación de aspecto sería incorrecta en este caso. Hoy el problema lo solucionaríamos ajustando el televisor mediante el menú de servicio o el control de amplitud vertical en el propio chasis. Entonces, no sabiamos tanto.

@Calamity15kHz

Perfecta explicación. Te comento un poco más a fondo, más a la luz de la tabla que ha facilitado @extremorpg, donde viene definido para cada resolución su PAR y su DAR (utilizaré estos términos por no acércanos a equívocos).

En nuestra distro partimos de ofrecer el PAR para un juego desde RetroArch, ya que de otro modo encuentras efectos indeseados como el efecto agua. De todos modos hablar de PAR no lo veo tan anacrónico en CRT, pero eso lo hablamos delante de un café. Evidentemente no existe una relación exacta 1:1, es innegable.

Una vez tenemos el PAR de un juego, ajustamos a un modeline, lo que te daría un DAR. No en todos los casos tenemos un modeline exacto. Hay juegos que ajustan a un modeline que no es su PAR, pero mantiene su DAR.

Cuando hacemos esto, en pantalla se muestra el videojuego con un DAR, proveniente de su creación. Existen juegos que tienen ligeras bandas negras arriba y abajo, otros más amplias, otros en los laterales... depende de su DAR. Pero gracias a que mantenemos su PAR no tenemos problemas como el efecto agua.

Lo que no compartimos, yo al menos, es como trabaja CRTswitch en árcade (en consolas el trabajo es para quitarse el sombrero). Ya que ajusta cualquier juego, incluso verticales, a una resolución de 320x240 con un DAR de 4:3. Lo cual me parece alejado de la realidad.

Gracias a la tabla de @extremorpg (por desgracia no está la resolución del manido bubble bobble), podemos ajustar mejor el DAR en algunos juego, cambiando el modeline, que quizás no hayamos tomado correctamente. Eso tendremos que verlo más despacio.

En el caso de la conversión NTSC a PAL en consolas, no puedo estar más que de acuerdo... todos sufrimos aquellas infames conversiones. Hoy en día, gracias a la emulación, existen multiples maneras de evitarlo. No obstante, lo hemos dejado tal cual, efecto nostalgia, y sencillez. Ya que usamos CRTSwitch que hace un gran trabajo.

Espero que haya quedado más claro, como funciona la distro. En nuestro caso trabajamos el frame desde el pixel perfect, directamente mantenemos en RetroArch el PAR. Y el DAR viene establecido por el modeline, que intenta acercarse lo máximo posible al PAR.

Un saludo.

Vassag0,

Quiero aclarar que yo no tengo nada que ver con el CRT Switchres de Retroarch. El autor le ha puesto el mismo nombre que el de "nuestro" Switchres, lo que crea confusión. Pero no son el mismo proyecto. El Switchres que lleva GroovyMAME trabaja de otra manera. Os recomiendo encarecidamente que le echéis un vistazo al original.

No es mi intención en absoluto polemizar aquí. Al contrario, lo que pretendo es ayudar. Insisto en el asunto porque veo que os vais a complicar la vida de mala manera. Por descontado, hacedlo como os dé la gana, que para eso es vuestro proyecto.

Lo que comentas del efecto "agua", tiene necesariamente que ser un problema de escalado de Retroarch. Si un emulador utiliza escalado entero, eso no puede pasar. La relación de aspecto es tan irrelevante en esto como la temperatura de la habitación. Si tenéis que andar falseando la resolución para que no se fastidie el escalado es porque Retroarch os está haciendo escalado fraccionario.

----

Respecto de PAR, DAR, etc., la cosa según mi leal saber y entender es así:

DAR = 4:3 (fijo, es un dato de partida, nos lo da el tubo, no es el resultado de ninguna operación)
PAR = (4/3) / (ancho / alto)

(el enlace de wikipedia lo hace más complicado de lo que realmente es)

Ejemplo:

Bubble Bobble: 256x224, PAR = (4/3) / (256/224) = 1,1667

Me sale un PAR de 1,1667. Pues bien, este valor nos da igual. Como si fuera 3,1416. Nosotros generamos un modeline de 256x224, escalamos ancho y alto por 1 (entero), y asunto resuelto. Esto es todo lo "perfect" que puede llegar a ser, no hay más (bueno, sí lo hay, además tenemos que clavar el refresco, ahí empieza lo divertido).

@Calamity15kHz.

Efectivamente el problema del efecto agua viene cuando intentamos forzar el escalado de RetroArch fuera de enteros. Mientras nos movamos en enteros no hay problema. Eso ya fue motivo de otra discursion, había quien decía que no pasaba nada por escalar en fraccionados...
Pero, como veo que bien sabes, si salimos de los enteros en el escalado, la interpolación de píxeles da como resultado artefactos indeseados. Por ello en RetroArch nos movemos en enteros, de ahí la denominación "Pixel perfect".

Ahora la siguiente discursion es si nos debemos mover en una relación de aspecto de 4:3. Por la sencilla razón que los CRT son 4:3... Cosa que no tiene nada que ver, como llevamos rato diciendo algunos y acabas de explicar.
Justo el ejemplo que has puesto es el modeline que usamos, pero hay usuarios que al ver bandas negras en los laterales... No lo entienden. Buscan que vayamos a un PAR 320x240 y un DAR 1,333. Cosa que, al menos yo, me niego.
Repitiendo la que acabas de decir, en este caso vamos a entero 1x: 256x224 y modeline 256x224. Hay casos como ciertos juegos de SNK donde tenemos un PAR de 304x224, donde aprovechamos el modeline de 320x224. Como apuntas, obtener los modelines con el refresco correcto es un gran trabajo. Por lo que aunque hemos creado sobre unos 40, no tenemos un modeline exacto para todas las resoluciones. Y aún nos quedan crear los modeline para monitores verticales.

Realmente en el equipo vamos avanzando por donde creemos que es el rumbo correcto. Pero como sabes siempre se genera debate de "distorsión". Que siempre es provechoso, porque se puede encontrar gente, dentro de la distorsión, que aporta cosas interesantes.

Un saludo y gracias por los consejos.

Vassag0 escribió:@Calamity15kHz.
Justo el ejemplo que has puesto es el modeline que usamos, pero hay usuarios que al ver bandas negras en los laterales... No lo entienden. Buscan que vayamos a un PAR 320x240 y un DAR 1,333. Cosa que, al menos yo, me niego.

Esto de las bandas negras en los laterales es la parte que no entiendo. Si mantienes la correspondencia exacta entre resolución del juego y resolución de pantalla, no puede haber bandas negras en los laterales. Si las hay, son debidas a la propia geometría del modo de vídeo, que tiene márgenes excesivos, y se pueden eliminar ajustando el modeline para reducir esos márgenes, sin afectar a la resolución.

Sólo en casos contadísimos, como el de Neo-Geo que mencionas, ocurre que aparecen esas bandas negras o de gráficos "basura", formando parte del propio cuadro del juego, que en el sistema original debían quedar ocultas en la zona de overscan.

En fin, me da la impresión de que estamos hablando de lo mismo, pero cuando recurres a la relación de aspecto como base de tu explicación me resulta todo muy confuso.

Saludos.

Calamity15kHz escribió:

Vassag0 escribió:@Calamity15kHz.
Justo el ejemplo que has puesto es el modeline que usamos, pero hay usuarios que al ver bandas negras en los laterales... No lo entienden. Buscan que vayamos a un PAR 320x240 y un DAR 1,333. Cosa que, al menos yo, me niego.

Esto de las bandas negras en los laterales es la parte que no entiendo. Si mantienes la correspondencia exacta entre resolución del juego y resolución de pantalla, no puede haber bandas negras en los laterales. Si las hay, son debidas a la propia geometría del modo de vídeo, que tiene márgenes excesivos, y se pueden eliminar ajustando el modeline para reducir esos márgenes, sin afectar a la resolución.

Sólo en casos contadísimos, como el de Neo-Geo que mencionas, ocurre que aparecen esas bandas negras o de gráficos "basura", formando parte del propio cuadro del juego, que en el sistema original debían quedar ocultas en la zona de overscan.

En fin, me da la impresión de que estamos hablando de lo mismo, pero cuando recurres a la relación de aspecto como base de tu explicación me resulta todo muy confuso.

Saludos.

En uno de esos juegos de 256x256 , se ve una luna, y sale distorsonada, casí diria "apepinada", y recuerdo perfectamente como veian juegos como el ghost'n'goblins en los recreativos, y no tenian bandas negras, la imagen sale encogida. La única solución que he encontrado es habilitar el switchres a 15 hkz, y ajustar el eje x a un valor cercano a 0, y se aunque salen un poquito por los lados , entro en el menú de servicio y ajusto la pantalla.

@Calamity15kHz aprobechando que estás en el hilo quiero hacerte una pregunta, aunque es un poco off topic. Hace algún tiempo (3 años según github) teníamos la opción de usar vuestro switchres como programa independiente, el código se puede descargar y compilar de aquí
https://github.com/Ansa89/switchres

Ahora las nuevas versiones están integradas en el propio groovymame. Sería muy complicado volver a sacar una versión independiente? Personalmente me gusta mucho más la forma de trabajar que tiene groovy a la que tiene retroarch, lo uso en un crt de pc (con el perfil vesa_1024) y es una maravilla.

Ronbin escribió:@Calamity15kHz aprobechando que estás en el hilo quiero hacerte una pregunta, aunque es un poco off topic. Hace algún tiempo (3 años según github) teníamos la opción de usar vuestro switchres como programa independiente, el código se puede descargar y compilar de aquí
https://github.com/Ansa89/switchres

Ahora las nuevas versiones están integradas en el propio groovymame. Sería muy complicado volver a sacar una versión independiente? Personalmente me gusta mucho más la forma de trabajar que tiene groovy a la que tiene retroarch, lo uso en un crt de pc (con el perfil vesa_1024) y es una maravilla.

La idea es convertir Switchres en una biblioteca que se pueda compilar con cualquier emulador, no solo con MAME. Lo haremos tan pronto como sea posible, aunque probablemente ya sea tarde porque están saliendo alternativas, que están teniendo mucho éxito por razones de sencillez, aunque sean inferiores en todo (me refiero a los desarrollos para Pi, principalmente). La verdad es que nosotros apostamos por MAME por la superioridad absoluta de su arquitectura frente a Retroarch, pero la emulación de consolas en MAME no ha avanzado a la velocidad que esperábamos.

Mi televisor crt ha petado, tiene ya varias reparaciones a sus espaldas, así que esta vez ya lo doy por muerto. Es una pena pero no voy a poder probar ni esta distro ni la de alphanu, con la buena pinta que tenían ambas. Creo que voy a centrar mis ganas de cacharrear en el monitor de ordenador crt que conservo y en resoluciones personalizadas bajo windows con la intel integrada, o bien probar batocera, yo que sé. Voy a guardar mi hd 5450 y el cable vga/scart en un cajón, porque si la pongo a la venta de donde soy la gente o no valora o no conoce las capacidades de estos cacharros; asi que ahí morirán hasta que pille otro televisor, cosa que dudo porque en canarias este mercado es jodido.


En fin, mucho ánimo con vuestro proyecto, estas cosas hacen feliz a mucha gente.

Cataplasta escribió:Mi televisor crt ha petado, tiene ya varias reparaciones a sus espaldas, así que esta vez ya lo doy por muerto. Es una pena pero no voy a poder probar ni esta distro ni la de alphanu, con la buena pinta que tenían ambas. Creo que voy a centrar mis ganas de cacharrear en el monitor de ordenador crt que conservo

En la distro de Alphanu puedes elegir entre 15kHz y 31kHz, creo que sirve tanto para televisores como para monitores CRT

https://youtu.be/kAi8qq4KySg?t=142

jgalanco escribió:En uno de esos juegos de 256x256 , se ve una luna, y sale distorsonada, casí diria "apepinada".

Si a 4:3 un juego te muestra un redondel como un ovalo, pues asi es, no hay mas. Es lo correcto

Buenos días. Voy por partes.

@Calamity15kHz, perdona, hay partes que las doy por supuestas porque están en mensajes más atrás, Intento hacer una recopilación.

Vamos a definir ciertos conceptos desde los cuales partimos:
Contamos con una resolución del frame, el PAR, la cual sólo podemos alterar en enteros si no queremos efectos indeseados. En su momento estoy fue cuestionado, ya que había personas que decían que podíamos movernos en fraccionados. Por nuestra parte, no creemos en ello, el PAR debe ser por entero.
Contamos con una pantalla CRT, la cual, si trasladamos a pixel tenemos una resolución entrelazada de 640x480 4:3 (1,333) donde deben mostrarse los juegos.
Por otra parte contamos con un modeline, es el factor que le dice a las X como deben pintarse en pantalla. Lo tomaremos como resolución.

El problema llega, por ejemplo, con un juego que tiene una resolución de creación de 256x224. Nosotros generamos un PAR, para este caso de 256x224, de otro modo obtenemos efectos indeseados. En este caso generamos un modeline progresivo de 256x224, ya que partimos de la base mantener un DAR de 1:1. Al mostrarse en pantalla 4:3, quedan bandas negras en los laterales. Ya que la resolución progresiva que corresponde con un DAR de 4:3 es 320x240. Hay usuarios que indican que deberíamos eliminar esas bandas negras ajustando a 320x240. De entrada esto no podemos encajarlo desde RetroArch, ya que sería usar resoluciones fraccionadas. Podríamos usar un modeline de 320x240 y rellenar pantalla. Pero, tenemos el problema de que, por ejemplo, en bubble bobble, las burbujas parecen "melones", pues el juego se ve estirado horizontalmente.
Y en ese debate nos encontramos... estiramos o no estiramos. La lista que ha facilitado @extremorpg nos da una idea de que no todos los juegos en CGA tienen DAR 4:3. El problema es que no aparecen todas las resoluciones existentes para ajustar su DAR. De hecho el dichoso bubble bobble no aparece.

@jgalanco
Entiendo que dices que el ghost'n'goblins te muestra la luna "apepinada", según nosotros lo mostramos en pantalla, ya que lo hacemos en 256x256 y cuando la estiras horizontalmente te sale de forma correcta. Debes tener en cuenta que cuando usas crtswitch en RetroArch la imagen la encoge verticalmente: te muestra una imagen 320x240. En principio, según la lista de DAR la resolución 256x256, tienen un DAR de 1:1. Pero con suerte quizás has encontrado un juego que demuestra que las resoluciones deben ser estiradas. Le hecho un ojo y te comento. Muchas gracias por ir informándonos de los resultados que encuentras.

@Cataplasta
Pues lo siento, la verdad que en las islas tiene que ser difícil recurrir a la segunda mano y un porte desde la península debe ser prohibitivo. Ojala encuentres algo en segunda mano. No desesperes.

Un saludo.

Vassag0,

Te agradezco mucho la educación y la paciencia que te tomas para contestarme. Por desgracia, yo cuanto más leo tus respuestas menos entiendo, por más vueltas que le doy sigo viendo que estáis introduciendo en la ecuación una variable innecesaria y que complica las cosas. Luego cuando tenga un rato me releeré el hilo, a ver si logro entender el problema. Por ello, y porque no quiero enguarrar el hilo, lo dejo aquí. Cuando tengáis la distro lista la probaremos.

Saludos.

Calamity15kHz escribió:La idea es convertir Switchres en una biblioteca que se pueda compilar con cualquier emulador, no solo con MAME. Lo haremos tan pronto como sea posible, aunque probablemente ya sea tarde porque están saliendo alternativas, que están teniendo mucho éxito por razones de sencillez, aunque sean inferiores en todo (me refiero a los desarrollos para Pi, principalmente). La verdad es que nosotros apostamos por MAME por la superioridad absoluta de su arquitectura frente a Retroarch, pero la emulación de consolas en MAME no ha avanzado a la velocidad que esperábamos.

Entendido, ojalá sea más pronto que tarde. Aún así yo creo que la mejor opción sería un ejecutable propio, que se utilice para calcular la resolución y lance el emulador con la configuración adecuada, así podríamos usar cualquier emulador y no sólo los que decidan usar vuestra biblioteca. Ánimo, hacéis un gran trabajo.

@Calamity15kHz

En primer lugar gracias por todo.

En segundo lugar, a poco que enredes con retroarch, te encuentras con el problema que presenta @Vassag0

En mis tiempos de trasteo con una rpi, ponias una res total (ejemplo 320*240), y es lo que se "pintaba" en pantalla.
Si queria poner menos imagen, o escalabas en enteros (recuadro negro) o estirabas, con efecto agüilla.

Si querias mas res, subias a un X2 y ajustabas dentro de la parte "pintable" de la imagen.
No se como se dira en argot del que usais, pero yo lo defino tratamiento digital de la imagen.

En un pc a 15khz con crt emudriver o winmodelines NADA DE ESO OCURRE.

No he podido instalar la distro, porque no me llega el cable al monitor del pc y tengo que inventar algo, pero espero que se haya esclarecido un poco el asunto.

Calamity15kHz escribió:Vassag0,

Te agradezco mucho la educación y la paciencia que te tomas para contestarme. Por desgracia, yo cuanto más leo tus respuestas menos entiendo, por más vueltas que le doy sigo viendo que estáis introduciendo en la ecuación una variable innecesaria y que complica las cosas. Luego cuando tenga un rato me releeré el hilo, a ver si logro entender el problema. Por ello, y porque no quiero enguarrar el hilo, lo dejo aquí. Cuando tengáis la distro lista la probaremos.

Saludos.

Muchas gracias a ti por tu ayuda. Actualmente estamos "perdidos" en muchas cosas. Tenemos buena voluntad y vamos avanzando gracias a ella. Aprendiendo mientras trabajamos. Por eso nos es tan importante la información que nos da gente como tu, que ya lleva tiempo en esto.
A la vez, piensa que quizás partimos de alguna premisa equivocada y por eso en la explicación hay "ruido" por mi parte, y es lo que hace que te despistes.
El problema es sencillo:
¿debemos mostrar los juegos en su resolución nativa o estirarlos a 320x240?
- En el caso de RetroArch sabemos que no, no debemos maltratar el frame original fraccionando el escalado.
- En el caso del monitor hay quien dice que debe mostrarse con una proporción 4:3 a "full frame" (llenar la pantalla). Y los que decimos (me incluyo en este grupo), que debe mantenerse la proporción de imagen que da el frame original. Aunque produzca bandas negras.

Por ejemplo, el Ghosts 'n Goblins que se ha nombrado, he encontrado una foto de (encima una video sonic que eran casi todas las que había en pueblo) de este juego. Si veis la foto, podéis apreciar que, en la máquina árcade, existen bandas negras laterales. El juego no ocupa el 100% de la pantalla, se ve claramente. Y esa máquina y esas relaciones de aspecto son las que perduran en mi memoria.



Un saludo

@Vassag0 , si cierto que en esa foto el juego tiene un poco de borde, pero no tiene nada que ver con el borde que se está viendo que es considerablemente más grande. ya que era el operador el que podía estirar la imagen a su antojo , es posible que en otras máquinas estuviese estirada, pero en eso mejor no pararse.
Lo que más nos choca a la gente que venimos de groovymame es que ese tipo de juegos de baja resolución de menos de 320x240 que encajan perfectamente en la pantalla. Otra cosa que tengo que probar es este ghost'n'goblins en la rgbpi , a ver como se muestra ya que usa también retroarch en una distro recalbox, y si eso te puede aportar alguna idea.

@jgalanco
Esa es la cuestión, que el operador puede darle el DAR que le de la gana. Salvo que exista documentación técnica. Por lo tanto no tenemos como guiarnos más allá de recuerdos o "creo que".

En rgbpi te saldrá a 320x240 ya que todos los juegos, incluso los verticales, pasan por CRTswitch y este convierte todo a 320x240.

Un saludo.

jgalanco escribió:Otra cosa que tengo que probar es este ghost'n'goblins en la rgbpi , a ver como se muestra ya que usa también retroarch en una distro recalbox, y si eso te puede aportar alguna idea.

Yo diría que si lo vas a probar con el cable rgbpi mejor usa la imagen de RetroPie ya que está construido sobre una distro Debian (Raspbian), al igual que RGBuntu se construye sobre otra Debian (Xubuntu)

Vassag0 escribió:El problema es sencillo:
¿debemos mostrar los juegos en su resolución nativa o estirarlos a 320x240?
- En el caso de RetroArch sabemos que no, no debemos maltratar el frame original fraccionando el escalado.

La resolución nativa, siempre (o un múltiplo entero de la resolución horizontal, o una super-resolución). Esto lo tenemos claro.

Por lo que estoy entendiendo hay dos temas diferentes que estáis tratando. Por una parte está el problema de la RGB-Pi que parece que saca todo a 320x240. Esto, si es cierto, es una chapuza, y yo no perdería mucho tiempo con un sistema así. Supongo que la limitación vendrá por el pixel clock de la Raspberry.

Vassag0 escribió:- En el caso del monitor hay quien dice que debe mostrarse con una proporción 4:3 a "full frame" (llenar la pantalla). Y los que decimos (me incluyo en este grupo), que debe mantenerse la proporción de imagen que da el frame original. Aunque produzca bandas negras.

Éste sería el segundo tema, que no tiene que ver con el primero (porque entiendo que vuestra distro es para pc, no para la Pi). Tú en pc no estás limitado a 320x240, puedes poner la resolución que quieras.

Aquí a mi juicio la razón la tienen los que dicen "full frame" a 4:3, pero OJO: sin escalado por software, sino ajustando físicamente el monitor.

En la postura que tú defiendes, si aceptamos que los juegos debían tener bordes, nos encontramos con el problema de cuantificar cómo de grandes debían ser esos bordes. Tú para ello te basas en unas relaciones de aspecto que calculas: esto es lo nuevo para mí.

Vassag0 escribió:@jgalanco
Esa es la cuestión, que el operador puede darle el DAR que le de la gana. Salvo que exista documentación técnica. Por lo tanto no tenemos como guiarnos más allá de recuerdos o "creo que".

En rgbpi te saldrá a 320x240 ya que todos los juegos, incluso los verticales, pasan por CRTswitch y este convierte todo a 320x240.

Un saludo.

Sabiendo esto, dejo lo de la raspberry pi, tampoco es cuestión de andar dandole vueltas a un sistema diferente que tiene un montón de limitaciones. Sabía que un ati tiene muchas posibilidades en cuanto a resoluciones y modos gráficos que un Rgbpi, ahora ya queda totalmente confirmado.

@Calamity15kHz

De verdad no sabes cuanto lo agradezco. Tu resumen... simplemente perfecto.

El problema, donde algunos se hayan encallados, es en la siguiente parte:

Calamity15kHz escribió:Aquí a mi juicio la razón la tienen los que dicen "full frame" a 4:3, pero OJO: sin escalado por software, sino ajustando físicamente el monitor.

En la postura que tú defiendes, si aceptamos que los juegos debían tener bordes, nos encontramos con el problema de cuantificar cómo de grandes debían ser esos bordes. Tú para ello te basas en unas relaciones de aspecto que calculas: esto es lo nuevo para mí.

A nivel personal ha llegado un momento que pagaría por saber cual es la solución perfecta. Como tu indicas, yo pongo el modeline, y el que quiera que ajuste por hardware a la relación de aspecto que más le guste. Por software puedo ajustar a 320x240, pero no me parece una solución adecuada.
Lo ideal sería saber el DAR de cada resolución, que pienso que debe existir, y ajustar cada resolución. Las resoluciones de aspecto que calculo es sencillo: ahora mismo es 1:1, no tengo manera de saber el DAR que tendrían en árcade. No digo que 1:1 sea lo más acertado, pero a mi ojo me parece lo más adecuado.

Me niego a pensar que alguien vea el bubble bobble mejor a 320:


Que a su resolución de 256:


Los dragones están cebados y todo pierde la proporción. Se ve claramente.

Por mi parte vamos a seguir con la proporción 1:1. Y no sé si en esta versión, o en la próxima, meteré una opción para el que quiera tener una imagen a 320x240, por software claro... más no puedo hacer.

Un saludo.