76

(16 replies, posted in Discussion)

That's interesting. Does it support unlimited favorites lists?

77

(10 replies, posted in Support)

Anchounio, don't duplicate threads, please, even with different languages. If you think you haven't been read, just post a new reminding message in the existing thread no matter how old it is, though that will rarely be the case.

Either, this thread or the other will be deleted in a few hours.

Yo creo que no es difícil notar los artefactos gráficos por una resolución súper ancha en determinadas situaciones, pero es cierto que, generalmente, son imperceptibles. Si los juegos con "auto-scroll" horizontal es donde vas a dedicar la mayor parte de tu tiempo, yo sí me molestaría en usar resoluciones nativas en estos casos. Suponiendo que la fidelidad visual absoluta sea tu prioridad, esto es. He publicado una nueva lista de modos para VMM que, además de considerar buena parte de los emuladores distintos de Groovy MAME, contemple también un uso de éste mixto "resoluciones nativas-super-resoluciones", para, con sólo un puñado (o dos) de modos, definir manualmente la resolución por juego sin recurrir a la extracción desde MAME con VMM.

Respecto a ASIO/ASIO-4-All, si el emulador los soporta, como es el caso de GM 0.170 "ASIO", yo sí creo que merece la pena ("la pena" no es la instalación en sí, sino la configuración que pueda requerir por juego para evitar sacudidas y demás), pero, de nuevo, depende de tu nivel de exigencia. Yo he llegado a notar la mejora (en el retardo del audio, digo, que de eso va) y no creo estar especialmente capacitado para estas cosas.

79

(1 replies, posted in Discussion)

Updated the list once more. Groovy MAME under native resolutions is better contemplated now with it, so that there'll be hopefully very few cases where you can't define the display resolution attending to the native horizontal resolution of the emulated machine, if you don't want to use "super resolutions" nor extracting the whole modes from MAME through VMM.

80

(2 replies, posted in Support)

For XP, you have "magic resolutions" instead, with similar results. The thing is, why XP in 2016?

Thanks, Grendelrt. An RGB interface is indeed a device I also recommend for anybody using a CRT for gaming these days. They have many uses. They were much less common in Europe than in the US, I'm afraid.

W7 y CRT de 15 kHz hacen buena combinación para la emulación de forma general, y te has de servir de un monitor de ordenador para la instalación inicial. Y no "vamos" hacia W7 sino hacia W8/W10, mucho me temo.

¿?

Dated, but it's something:

https://web.archive.org/web/20141017161 … c=116023.0

That's an aspect Calamity is working on currently, I believe. The guide is for GM 0.170. Many changes are expected to come, little by little.

As for the rest, those are mostly "correct" depending on what you want to emulate and how. For games using vertically-mounted monitors you'll need to change the -orientation as explained if you're indeed using a vertically-mounted monitor. The hi-score patch, I believe, was removed from 0.171 onwards.


Edited a bit the F.2 chapter, by the way. You must not unlock V-freq in A-OSD when just making porch changes.

85

(3 replies, posted in En español)

No sé si me estoy perdiendo algo, pero, como aproximación genérica, Groovy MAME no necesita importar "modelines", sino las especificaciones del monitor para generar los "modelines" al vuelo, que es lo que consigues con el botón de Exportar a GM de VMM. Debes asegurarte de que el "preset" del monitor aparece en "mame.ini".

Si los modos están ya recogidos con los valores deseados en A-OSD, GM los usará atendiendo a tu configuración del emulador -- si se los quieres forzar a determinados juegos/máquinas, deberás introducir la "etiqueta" correspondiente al modo en el INI de ese juego/máquina. Pero también puedes definir ahí el "modeline" directamente para que GM lo genere al vuelo. Se emplea el archivo "user_modes.ini" para generar modos en el sistema, que GM, como digo, adoptará si así se le requiere por juego/maquina, pero la gracia de GM (una de ellas), es que no necesitas cada modo predefinido. Otra cosa es el resto de emuladores.

Lecturas recomendadas:

http://geedorah.com/eiusdemmodi/forum/v … php?id=290

http://geedorah.com/eiusdemmodi/forum/v … d=327#p327

Updated again to add Intealls' Groovy MAME build with ASIO/ASIO-4-All compatibility and a mention of the drawback of using super resolutions against the native mode (check E. Per-game configuration, 1. Resolution).

87

(1 replies, posted in Discussion)

This would make for a more complete/updated user_modes.ini for usage with emulators other than Groovy MAME:

## Desktop ##

 640 x 480 @ 60.000000 desktop
 640 x 480 @ 30.000000 desktop

## Super resolutions ##

2560 x 240 @ 60.000000 super
2560 x 248 @ 60.000000 super
2560 x 256 @ 60.000000 super
2560 x 264 @ 60.000000 super
2560 x 272 @ 60.000000 super
2560 x 280 @ 60.000000 super
2560 x 288 @ 60.000000 super
2560 x 296 @ 60.000000 super
2560 x 304 @ 60.000000 super
2560 x 320 @ 60.000000 super
2560 x 336 @ 60.000000 super
2560 x 344 @ 60.000000 super
2560 x 352 @ 60.000000 super
2560 x 360 @ 60.000000 super
2560 x 368 @ 60.000000 super
2560 x 376 @ 60.000000 super
2560 x 384 @ 60.000000 super
2560 x 392 @ 60.000000 super
2560 x 400 @ 60.000000 super
2560 x 416 @ 60.000000 super
2560 x 432 @ 60.000000 super
2560 x 448 @ 60.000000 super
2560 x 464 @ 60.000000 super
2560 x 480 @ 60.000000 super
2560 x 496 @ 60.000000 super
2560 x 512 @ 59.000000 super
2560 x 544 @ 55.000000 super
2560 x 560 @ 54.000000 super
2560 x 768 @ 60.000000 super
2560 x 800 @ 60.000000 super

## Specified ##

 240 x 180 @ 59.727501 gba
 256 x 224 @ 60.098475 sfc
 256 x 225 @ 60.098475 sfc
 256 x 239 @ 60.098475 sfc_fc
 256 x 240 @ 55.450000 x68
 256 x 240 @ 60.098475 sfc_fc
 256 x 240 @ 61.460000 x68
 256 x 242 @ 59.826098 pce_pcfx
 256 x 256 @ 55.450000 x68
 256 x 256 @ 61.460000 x68
 268 x 224 @ 59.922743 mk3
 272 x 240 @ 60.000000 msx2
 288 x 224 @ 55.450000 x68
 304 x 224 @ 59.185606 ng
 320 x 200 @ 59.940052 a500
 320 x 224 @ 55.450000 x68
 320 x 224 @ 59.185606 ng
 320 x 224 @ 59.922738 md
 320 x 224 @ 61.460000 x68
 320 x 240 @ 59.764793 ss
 320 x 256 @ 49.890391 a500
 336 x 224 @ 59.826098 pce
 336 x 225 @ 59.826098 pce
 336 x 240 @ 59.826098 pce
 336 x 242 @ 59.826098 pce
 352 x 224 @ 59.764793 ss
 352 x 240 @ 59.764793 ss
 360 x 288 @ 49.890391 a500
 384 x 256 @ 55.450000 x68
 384 x 256 @ 61.460000 x68
 448 x 240 @ 55.450000 x68
 448 x 240 @ 61.460000 x68
 512 x 212 @ 60.000000 msx2
 512 x 224 @ 60.098476 sfc
 512 x 240 @ 55.450000 x68
 512 x 240 @ 60.098476 sfc
 512 x 256 @ 61.460000 x68
 512 x 312 @ 49.664704 st
 544 x 240 @ 60.000000 msx2
 640 x 200 @ 56.533419 88sr
 640 x 200 @ 60.000000 88va_77av
 640 x 400 @ 56.533419 88sr
 1088 x 225 @ 59.826098 pce
 1088 x 242 @ 59.826098 pce
 1280 x 224 @ 59.922738 md
 1280 x 240 @ 59.922738 md
 3520 x 224 @ 59.764793 ss
 3520 x 240 @ 59.764793 ss
 5376 x 224 @ 59.826098 pce
 5376 x 240 @ 59.826098 pce

## Aux. ##

 240 x 224 @ 59.727501 aux
 240 x 240 @ 59.727501 aux
 240 x 256 @ 60.000000 aux
 248 x 240 @ 60.000000 aux
 256 x 223 @ 60.000000 aux
 256 x 224 @ 58.000000 aux
 256 x 224 @ 59.400000 aux
 256 x 224 @ 60.600000 aux
 256 x 240 @ 59.400000 aux
 264 x 240 @ 60.000000 aux
 280 x 240 @ 60.000000 aux
 288 x 240 @ 60.000000 aux
 304 x 240 @ 60.000000 aux
 320 x 224 @ 58.400000 aux
 320 x 256 @ 55.400000 aux
 320 x 256 @ 61.000000 aux
 338 x 240 @ 60.000000 aux
 360 x 240 @ 60.000000 aux
 368 x 240 @ 60.000000 aux
 376 x 240 @ 60.000000 aux
 380 x 240 @ 60.000000 aux
 384 x 240 @ 60.000000 aux
 400 x 240 @ 60.000000 aux
 410 x 256 @ 60.000000 aux
 416 x 240 @ 60.000000 aux
 448 x 240 @ 60.000000 aux
 512 x 224 @ 59.400000 aux
 512 x 225 @ 60.000000 aux
 544 x 242 @ 60.000000 aux

## Interlaced ##

 320 x 512 @ 49.890391 a500
 512 x 448 @ 60.098476 sfc
 512 x 512 @ 55.450000 x68
 544 x 480 @ 30.000000 msx2
 640 x 400 @ 60.000000 pc98
 640 x 448 @ 30.000000 ss
 640 x 480 @ 55.450000 x68
 640 x 480 @ 53.178707 dos_vga
 640 x 480 @ 59.400000 aux
 640 x 480 @ 61.460000 x68
 768 x 512 @ 55.450000 x68

## Total -- 105 modes (18 redundant) ##

Guide updated with the recent changes in both, Groovy MAME and VMM. I've also added a section for geometry tweaking.

Cópianos aquí tu vmmaker.ini.

90

(27 replies, posted in En español)

Beaches, para evitar estos mensajes kilométricos y preservar nuestra salud mental, por favor, embebe cada "log" que has copiado con la orden "code", correspondiente al último botón del panel. (Si tienes dudas, dale a editar en tu mensaje del otro día.)

91

(27 replies, posted in En español)

Si te refieres a los "drivers" basados en Catalyst 6.5 y en 9.3, la hay. Para empezar, el nº de modos que son capaces de generar simultáneamente. Ten en cuenta que tu tarjeta está entre los modelos poco recomendables por limitaciones con el "dot clock"; ¿has visto en el hilo de descarga las indicaciones al respecto?

Y en cualquier caso, crea un "log" con GM y ese juego desde la consola de comandos del SO y cópialo aquí como te ha dicho Calamity (e incluso copia aquí también tu vmmaker.ini entero). Ayuda a que te ayuden...

92

(27 replies, posted in En español)

Pero no lo tienes dentro de una cabina, ¿verdá? Yo soy muy defensor de los TV --al menos de los Trinitron negros con altavoces traseros de gama media-alta, ya lo sabes-- pero principalmente por la posibilidad de voltearlos(*). Si lo metes en una cabina, te despides de la principal ventaja de aquéllos y de una de las pocas ventajas de las cabinas -- ser el soporte de un monitor de calidad (cuya imagen uno podría preferir a la de la rejilla de apertura de Sony con bastantes argumentos). Ésa era mi extrañeza.

(*)Aunque con criterio, que el paso constante de una posición a otra acaba por desenfocar poco a poco el tubo y es un dolor restaurarlo.


Los Hantarex multi de aquella tanda no salieron muy buenos, se ve, no... A Diego el suyo le ha venido quitando el sueño hasta hace muy poco al menos. Lo de entrar en los servicios (...), de todos modos, puede ser desde infumable si necesitas quitar la carcasa para activarlo hasta razonablemente cómodo si es una mera combinación de botones desde el remoto y éste está en buen estado. Yo, con el de la foto, lo hacía continuamente. Y, si has escogido bien, te da la ventaja sobre los monitores de poder forzar el desentrelazado, que puede ser más que útil incluso más allá de la propia emulación (aunque siempre te puedes hacer con un interfaz RGB para esto, como solución universal).

(Diatriba que me recuerda, por cierto, que estaría bien abordar de una vez el capítulo sobre CRT para aclarar cuestiones que inevitablemente a la gente se le presentan a posteriori... Pena que el día sólo tenga 24 h, eh...)

93

(27 replies, posted in En español)

¿Tienes un televisor en una cabina? ¡! ¿No es como un poco lo peor de los dos mundos?

94

(27 replies, posted in En español)

Marchando una de yes-we-can para Beaches.

http://s17.postimg.org/ovvmpf4f3/yeswecan.jpg

95

(27 replies, posted in En español)

beaches wrote:

He jugado al donkey Kong y por abajo se pierde unos 4 cms, vamos que al empezar a jugar no se ve ni a Mario.

En información se ve esta resolución
Switchres 768 x 512i 58.484 Hz 16.229 Khz.

He probado otros juegos verticales, 1942,comecocos, y no me come la pantalla, a lo sumo por arriba te corta un poco la puntuación.

A qué es debido este corte y que no se vea la pantalla completa?
Que resolución sería la idónea para que se viese la pantalla sin cortes?
Gracias.

Si crees que un mensaje no se ha leído o quieres repreguntar, mejor sube el mismo hilo.

Si ambos juegos te usan el mismo modo en Switchres, dado que ambos comparten resolución nativa, ambos deben tener el mismo grado de "overscan", aunque el posicionamiento vertical varíe o te resulte menos idóneo para un juego que para otro. Lo más positivo es que recurras al servicio de tu televisor para variar la geometría [ > ] -- ten en cuenta que estás en el extremo del rango y 512 líneas a esa frecuencia están muy por encima de lo que los TV convencionales consideran "área visible". Aunque lo suyo, desde luego, es que emules el juego en un monitor dispuesto verticalmente, que es como se concibió.

96

(7 replies, posted in Support)

Hey, thanks for the mention, but really, that's not deserved at all. Calamity's too modest to admit that this is mostly his own work so just saluting him would be enough and more fair.

We're not exactly fluent in Italian, but good luck with it. Also, please, use proper capitalization here.

97

(7 replies, posted in Support)

Unless Calamity says otherwise, we have nothing against advertising external homepages or boards here, so serve yourself in this thread.

Changed the title, by the way, for a more general purpose.

Nice. Thanks to everyone involved. I'll wait a couple of versions before properly updating the guide just in case, but does this still apply?

Groovy MAME will choose Direct 3-D when leaving this option in auto except for the case of the games using interlaced modes, where Groovy MAME will automatically pick Direct Draw.

Forgot to thank Cools for his own guide at http://forum.arcadeotaku.com

It was used as the base for this due to its popularity.

F )   S o l v i n g   o v e r s c a n   a n d   g e o m e t r y   i s s u e s

As a previous note, be aware that we always recommend the usage of monitors with adjustable geometry settings. Most will have them, but for many TV sets it'll not be easy to get access to the service menu or the devices which control them. Arcade games (and many old PC games) were conceived for monitors with easy-to-control screen geometry, so it wasn't really important which model or video mode they used and the consequent variations in screen geometry parameters against other samples (position, borders, etc.). Therefore, you can't expect a universal solution by software which sets a perfectly adjusted visible area on screen for every game in MAME so that you won't ever need to make monitor tweaks. Super resolutions (and only super resolutions) will essentially get the same horizontal amplitude for all the games, but you'll need to manually adjust the vertical size if you want to properly display games with different-enough video modes, though we'll show a way here (two ways, actually) to control the vertical position by software in case you want to leave at least that monitor setting intact.


F.1) Setting the best monitor specs

Different monitors require different definitions for the monitor's specifications in our system, and it's the monitor specs what determines overall screen geometry. Through Video Mode Maker, a definition of monitor specs was set in the process of installation; it's located in the Monitor settings tab, and it can be changed by another preset and even edited at will. It's likely that with the default preset you don't get a perfectly centered area under your current/default monitor parameters, so you may start by editing the monitor specs.

If you'll be using the monitor also with devices other than the PC for emulation (say, a game console), a smart approach may be firstly adjusting the monitor parameters to get the best geometry for these devices, given that they'll normally won't give you the option to do it internally.

In order to edit a preset (the one named Arcade 15.7 kHz - standard resolution is generally a good one to use as the basis for 15-kHz monitors, including TV sets), you need to know well what a monitor specs line consists of, which is widely explained here. Usually, you'll just need to correct the horizontal position, so take a look at this example:

15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576 (original Arcade 15.7 kHz preset)

15625-16200, 49.50-65.00, 2.000, 4.700, 6.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576 (edited Arcade 15.7 kHz preset)

By picking the aforementioned preset in the corresponding field and changing this value with Notepad when clicking the edit button in VMM, you'll center the picture horizontally according to the demands of most NTSC consoles on many Trinitron TV sets, so you won't need to enter the TV's service menu and adjust this setting every time you change from your PC to your consoles and viceversa.

If, for instance, you also get the image positioned too low, you'll need to reduce the vertical back porch value:

15625-16200, 49.50-65.00, 2.000, 4.700, 6.000, 0.064, 0.192, 1.020, 0, 0, 192, 288, 448, 576

And so on.

Given that you can export the defined monitor specs directly to Groovy MAME as explained before, you don't need to also define this in Groovy MAME's INI file, though you can do it if you want to for some reason by finding and editing this line:

monitor                   generic_15

Yet more presets here.

Much like with VMM, it's possible to set custom values by the monitor's particular specs. To do that, type custom in place of generic_15 and add the values in the crt_range lines accordingly, taking always as a reference one of the given samples and their effect. Check VMM's tutorial for further elaboration.


F.2) Tuning up the screen geometry in a per-game basis

Groovy MAME lets us define the modeline(s) in the machinename.ini files, overriding the definitions in MAME's INI file. This is extremely useful to solve particularly geometry problems, such as the vertical centering derived from the disparity of the vertical scan rates or the overscan-into-underscan issues in quite a few arcade games.

The easiest way to tweak modelines per-game is:

1. Run the game with verbose enabled: Start menu, Run, C:\GROOVYMAME\mame64.exe machinename -v

2. Exit Groovy MAME and launch Arcade OSD. You'll notice the Get mode from clipboard option is enabled, go there. It will launch the last mode used by Groovy MAME, including custom timings.

3. Make the geometry changes as desired. Remember that you can't modify the vertical amplitude by software. 

4. When done, select Back and Copy modeline to clipboard. Exit the program.

5. Open Notepad, press CTRL + V. Now copy to the clipboard the modeline line, not the CRT range line, and paste it in your machinename.ini:

modeline "2560x240_60 kHz Hz" PixelClock, HRes, HSyncStart, HSyncEnd, HTotal, VRes, VSyncStart, VSyncEnd, VTotal, hsync, vsync

6. Save changes and test the game/machine.

Notes:

- Regarding the modeline option, the only requirement to use it is to have a modeline already available in the system with the same active width and height.

- Groovy MAME keeps the video mode specifications if modeline is used, but if the mode is defined with resolution instead, Groovy MAME will not use the vertical refresh attending Arcade OSD, but attending the emulator's request for that game, if v-sync is not disabled. The picture won't be scaled if it doesn't match the defined resolution (black borders and some shift will appear).

- If resolution is used, the video mode displayed in-game through MAME's menu and splash screen shows the vertical refresh from A-OSD according to that label, which usually won't be the one in actual use for the reason above.

- For minor tweaks, MAME's Slider Controls (reach them also through the TAB menu when running a machine), allows to modify the screen's horizontal and vertical position.



G )   E x t r a   t i p s

Calamity also provides us with the following advices for some particular situations:


G.1) Improving performance on games with switching resolutions

Windows 7's video stack adds an absurd overhead to video mode switching -- it's something you're not supposed to do so often in normal applications. With regards to games that dynamically witch resolutions, there are some things that can be done to avoid issues:

- Disable the changeres option in mame.ini. This will leave the game all the time at its default resolution, the one that's reported by MAME's XML. There'll be a single mode change on load, then no in-game mode switching. The problem with this is yhat, very often, the resolution reported is the first one assigned by the hardware initialization, which doesn't match the main video mode used by the game.

- Force a given resolution by means of the resolution option. This by itself will disable mode switching (same as nochangeres) but you can specify the main video mode that's actually used during the game.

- Use super resolutions. By using super resolutions, most mode changes will be unneeded. Only vertical resolution changes will trigger an actual video mode change. This is ideal for some systems (such as Sega Mega Drive) which change horizontal frequency quite often while leaving vertical unchanged. For systems that also change vertical resolution, the previous method is preferred.

Besides this, follow these recommendations when possible:

- Try to keep the mode list as short as possible; this will make mode changes work faster. Super resolutions will be of help here.

- Only enable the outputs you actually use. Each extra output that's enabled exponentially increases the time required by certain graphic API calls (e. g. EnumDisplaySettings).

- Use your frontend as your system shell (instead of explorer.exe). Having the default shell at the background means that upon a mode change, Windows will send messages to all the little things that live on your desktop, asking them to redraw themselves etc., which takes a lot of time.


G.2) Forcing single scan on games with double-scanned graphics

This comes in handy, for instance, with the systems where MAME mistakenly reports a vertical resolution which doubles the native one. Let's illustrate this with MSX 2 computer series emulation -- MAME always reports a vertical display resolution of 466 pixels for most MSX2/MSXP games, but, in actuality, MSX 2's Screen 5~7 modes displayed either, single-scan (233 lines) or interlaced (466 lines), and very few games used the interlaced modality (and those which did, only used it at some very particular moments). So, when emulating these games on a 15-kHz monitor, the correct approach consists in getting progressive modes of 233 lines instead of the interlaced mode at 466 lines, which, if anything, should only be called at those moments to make the change dynamically.

Until MAME fixes it in the driver's code, other than hardware de-interlacing, this can only be achieved by installing a super wide resolution of 233 lines in this case, setting it through machinename.ini and the resolution command, and also setting cleanstretch 2.

(Note: From Groovy MAME 0.177 onwards, cleanstretch options are no longer used, so set -ues (unevenstretch 1) in machinename.ini. This is required so fractional stretching is forced. We need to apply a fractional scale factor of 0.5 to the vertical axis. Integer subscaling is not possible since the minimum possible integer factor is 1. The trick to avoid scaling artifacts is to choose a resolution whose height is the exact half of MAME's reported resolution (466). The width is not a problem because we have a super wide resolution.)

Using nochangeres 1 is recommended too if the emulated system makes constant resolution changes, as these make the emulation too slow.



End of the guide