Post by: Calamity on January 30, 2021, 01:52:56 pm
GroovyMAME is a M.A.M.E. fork aimed at CRT monitors, with a strong focus on CRT preservation, since this is the only display technology that accurately replicates the genuine video game experience. However you can use GroovyMAME to alleviate some of the annoyances associated to emulation on LCD displays, specially for those models which are capable of refreshing at custom rates.
GroovyMAME's main features as compared to official MAME:
- Improved video and audio synchronization that achieves truly smooth scrolling, tearing-free video and hiccup-free audio.
- Automatic generation of custom video timings for CRT monitors.
- Reduced input latency
Download:
Always get the most recent GroovyMAME's package from our github's site. (https://github.com/antonioginer/GroovyMAME/releases)
Important: in Windows, just unzip and run! Ignore instructions about downloading official MAME and replacing the binary.
What is Switchres 2.0?
Switchres 2.0 is a modeline generation engine for emulation. The Switchres project has become an independent library (https://github.com/antonioginer/switchres), and with it, GroovyMAME has been reworked, to hopefully achieve a cleaner and more robust integration.
New features:
- Multi-monitor support: Switchres 2.0 can handle up to 4 displays simultaneously, each with its own separate configuration. Default Switchres settings for all displays are read from MAME's usual .ini system, but now you can create specific per-display .ini files, named display0.ini, display1.ini, etc., that allow independent configuration for each display. Vertical synchronization (-syncrefresh) is always done to display #0.
Most importantly, the user can decide which exact monitor the output will go to in a multi-monitor setup. While this is not a new feature, it now works reliably on both Windows and Linux. As usual, set the option -screen <screen> for that. Remind that in Windows <screen> is typically \\.\DISPLAY1, \\.\DISPLAY2, etc., while in Linux (SDL2) you have screen0, screen1, etc. - Automatic LCD monitor preset: now -monitor lcd dynamically creates a fixed resolution preset based on your reported monitor timings, so GM can adjust output refresh rate to match game's refresh on supported graphic cards (Windows: AMD; Linux: AMD, Nvidia, Intel), within the Hz range defined by -lcd_range <min_refresh-max_refresh>. In Windows, it requires -allow_hw_refresh.
New options:
All platforms
- -switchres_backend <option>: Choose between different supported backends: ati, adl, powerstrip, xrandr, drmkms. Default (recommended) setting is auto. Notice that drmkms doesn't work yet but is expected to be a real alternative as SDL2 support gets better.
- -[no]modesetting: sets video modes directly bypassing the renderer backend. This is useful when the backend doesn't handle mode switching natively (BGFX) or uses a cached mode list so it doesn't see the modes we create at runtime (SDL2). Note that while mode switching on BGFX is now possible, synchronization with -frame_delay is still only supported on the following backends: d3d (Windows) and opengl (Linux).
- -[no]pixel_precision: greatly improves horizontal centering of video modes, by calculating horizontal borders with 1-pixel precision, instead of the default 8-pixels blocks that were required in the past.
Windows
- -[no]allow_hw_refresh: dynamically adds new modes or updates existing ones just like VMMaker does, even on stock AMD drivers. This feature is experimental and is disabled by default. It has the following limitations and problems:
- Synchronization is not perfect yet and the new modes may not always be ready on time for mode switching, causing a wrong display output.
- A plug-n-play audio notification will be present on startup and exit, if the explorer shell is used.
- Refreshing the hardware is an expensive task that takes time, specially if the app has already entered fullscreen mode. This makes it unpractical for games that switch video modes more than once, unless -nochangeres is used, or alternatively super resolutions are forced (-resolution 2560x0) so that effective mode changes are neutralized (the later trick won't help for games that switch between interlaced and progressive).
- When used on stock AMD drivers instead of CRT Emudriver, usual limitations apply: no support for low resolutions (below 640x480) nor low dotclocks. Not a problem however if you're using a 31 kHz monitor.
- Synchronization is not perfect yet and the new modes may not always be ready on time for mode switching, causing a wrong display output.
Linux/X11
- -[no]screen_compositing: adjusts the crtc position each time a new video mode is set, maintaining the relative position of screens in a multi-monitor setup.
- -[no]screen_reordering: stacks the screens vertically on startup to allow each screen to freely resize up to the maximum width. Useful to avoid video glitches when using super-resolutions. -screen_reordering overrides -screen_compositing.
Dropped features:
- Magic resolutions (Windows XP). This old technique relied on a Windows XP's feature that was abolished on newer Windows versions and is no longer possible. It has been replaced in practice by super resolutions.
Dropped options:
- -orientation <option>: This option has been removed since experience has proved it caused confusion to new users because it collided with MAME's native rotation options. So now, all orientation settings are handled through MAME's options. Leave the default settings for an horizontally mounted monitor, and use either -autoror or -autorol for a vertical one.
- -connector <option> This option was meant to achieve multi-monitor support on Linux but was never properly wired and now has been superseded by the more correct integration with MAME's -screen option.
Post by: Calamity on January 30, 2021, 01:53:21 pm
- [nogpu] New option -[no]mister_interlaced_fb: if enabled, odd and even fields of interlaced modes are sent separately (as in previous releases). If disabled, both fields are sent together and the fpga will pick the correct one based on its current raster status (this avoids field synchronization issues, but requires higher bandwidth).
- [nogpu] New input backend -joystickprovider mister: allows using gamepads connected to the MiSTer (2 players).
Both features require up-to-date groovymister core.
What's new in Switchres 2.220a (February 2024)
- Version synchronized with first Switchres full release.
What's new in Switchres 2.002zz (January 2024)
- [nogpu]
- Add audio support.
- Various fixes to allow building on Mac [djfumberger]
- Fix blinking on internal FE with lz4
- Avoid modes bigger than RGB buffer (force 640x480)
- Add bilinear filterning, linked to -autofilterAdd audio support.
What's new in Switchres 2.002z (January 2024)
- [nogpu] Properly compute pixel aspect ratio of nogpu(MiSTer) screen.
What's new in Switchres 2.002y (December 2023)
- [nogpu] First release with GroovyMiSTer support. New video backend -video mister for RGB video through network.
What's new in Switchres 2.002x (December 2023)
- [Linux] Add new option -dri_device. Use to force vsync on a specific gpu, e.g. "card0", "card1", etc., or "auto" for automatic selection (currently it will pick the first device with a valid connector.
- [Windows] Raw input improvements. Workaround for devices with buggy drivers. PlayStation triggers hack removed. Should now be compatible with most existing gamepads. [star69rem]
What's new in Switchres 2.002w (October 2023)
- [Linux] Added Switchres fixes to drmkms backend to properly poll dri devices.
What's new in Switchres 2.002v (July 2023)
- Also save Screen Refresh Rate slider.
What's new in Switchres 2.002u (May 2023)
- Only save certain sliders: frame delay, vsync-offset, overclock and CRT geometry sliders. This avoids the problem with vector games not responding to ini settings.
What's new in Switchres 2.002t (May 2023)
- [Windows] Fix rawinput for joysticks for certain devices [star69rem].
- Fix lcd_range operation.
What's new in Switchres 2.002s (April 2023)
- Fix popup error with custom preset (switchres: error trying to fill monitor range with).
What's new in Switchres 2.002r (March 2023)
- Improve rendering of UI frames and lines in low resolutions. [Oomek]
- Correctly apply rotation after modeline adjustment (using the geometry sliders with rotated games now works).
- Correctly apply syncrefresh (it wasn't applied automatically since v_scale was changed from int to float).
What's new in Switchres 2.002q (February 2023)
- Implement integer scaled fonts. Finally clear fonts for CRTs at low resolutions. Set uifont uismall.bdf in mame.ini to enable it. [Oomek & Calamity]
- Force 2-line step for -v_shift (option & slider) on interlaced modes. This way it preserves vertical field parity which is required for correct timings and some hardware. Maybe you need to readjust your previous -v_shift settings.
- [Windows] Make rawinput for joysticks not the default option. Set joystickprovider rawinput manually in mame.ini if you want to use it. It doesn't work for UltraStick and probably other controllers yet.
What's new in Switchres 2.002m (September 2022)
- [Windows] Add rawinput support for joysticks. Split global inputs settings for keyboards, mice and joysticks. [Chester C. Rumpled]
- Extend h-size slider to 2.00 maximum.
What's new in Switchres 2.002l (August 2022)
- Added controls for geometry adjustment. These are available both as command-line/.ini options and in-game sliders for interactive adjustment:
* H-size [0.5 - 1.5]: option -h_size
* H-shift [positive or negative, in pixels]: option -h_shift
* V-shift [positive or negative, in lines]: option -v_shift
As a reminder: V-size is not possible from software.
What's new in Switchres 2.002k (July 2022)
- [Linux] Add low latency (drm) vsync to sdl2 video backend (-video accel).
- Properly apply -keepaspect on rotated targets with -autostretch.
What's new in Switchres 2.002j (June 2022)
- Improve UI text drawing performance. [Oomek]
- Another fix to the scaling algorithm (hopefully the last needed).
What's new in Switchres 2.002i (April 2022)
- Fixed wrong scaling of vertical games in certain cases.
- [Linux] Internal changes to support libdrm hook (experimental feature).
What's new in Switchres 2.002g (January 2022)
- New option -switchres_ini. If enabled, GroovyMAME will try to parse switchres.ini and use it for its configuration. Options priorities, in increasing order: mame.ini < switchres.ini < display#.ini < orientation.ini < ..... < command line.
- [Linux] Improved support for mode switching on KMS.
- [Linux] Fixes toggling fullscreen on/off (still imperfect but functional).
What's new in Switchres 2.002f (December 2021)
- [Linux] First release ever to support mode switching on KMS. It needs Substring's patched kernel and SDL2 (>=2.0.16) available on GroovyArcade's repository.
What's new in Switchres 2.002e (October 2021)
- Properly fix configuration saving from the ui.
What's new in Switchres 2.002d (October 2021)
- [Windows] Fix bug that caused interlaced modes to lock screen updates.
- Fix bug that caused an exception when saving configuration after doing changes from the ui.
- Make -vsync_offset slider setting not propagate between different games when launched from the ui.
What's new in Switchres 2.002c (September 2021)
- [Windows] Fixed bug that caused games using interlaced modes run at double speed.
What's new in Switchres 2.002b (June 2021)
- New option -[no]syncaudio: Make audio synchronization (resampling) optional. Default is enabled. Disable to avoid sound wobble with erratic emulation speeds (like that caused by frame delay on some systems).
- New option -[no]autostretch: Make auto stretching feature optional. Default is enabled, so GM will apply the scaling mode (fractional or integer) that best fits the situation.
- New option -[no]autofilter: Make auto filter optional. Default is enabled, so GM will apply bilinear filtering when fractional scaling or an interlaced mode are used.
- New option -[no]interlace_force_even: Calculate all vertical values of interlaced modes as even numbers. Required by AMD APU hardware on Linux
- [Windows] Implement asynchronous rendering through native D3D9ex api (replace for old multithreaded -triplebuffer). This mode is selected automatically by -autosync. You can force it manually with -waitvsync -nosyncrefresh.
- [Linux] New option -sync_mode <0-4>: In combination with -syncrefresh, select the synchronization mode that offers the lowest latency based for the specific video driver. The default value is 2, which gives good results for both amdgpu and radeon on X11 and kms mode. Other modes are provided that could be useful with other hardware/driver combination.
Code: [Select]
sync algorithm amdgpu radeon radeon/kms amdgpu/kms
mode
0 -Swap(1) perfect(1) perfect smooth smooth
-glFinish lag 1 frame lag 1 frame
1 -Swap(0) tearing tearing perfect tearing/
-drmWaitVBlank perfect w/fd stuttering
-glFinish
2 -Swap(1) perfect(1) perfect perfect perfect(1)
-drmWaitVBlank
-glFinish
3 -drmWaitVBlank tearing perfect(2) tearing tearing
-Swap(0)
-glFinish
4 -drmWaitVBlank half speed half speed smooth smooth
-Swap(1) lag 1 frame lag 1 frame
-glFinish
- Swap(x), x = Opegl swap interval (0 = immediate, 1 = v-sync)
(1) Low frame delay performance
(2) GM's pre-0.232 implementation
perfect = smooth + subframe latency
Note: amdgpu on X11 has tearing with mode 1, however tearing can be removed with frame delay, and when done, it offers better performance than mode 2.
What's new in Switchres 2.002a (March 2021)
- Fixed crash on emulated systems with 2 or more screens.
- Correctly update game video information after machine initialization.
- Properly account for refresh scaling & black frame insertion with frame delay.
Post by: Calamity on January 30, 2021, 01:53:35 pm
Post by: Calamity on January 30, 2021, 01:54:17 pm
Post by: donluca on January 30, 2021, 03:04:03 pm
Good stuff, I'm really interested in what other emulator developers will be able to do with the new standalone switchres... I might ping the blast'em developer about this... :angel:
Post by: dmckean on January 30, 2021, 07:11:26 pm
-[no]pixel_precision: greatly improves horizontal centering of video modes, by calculating horizontal borders with 1-pixel precision, instead of the default 8-pixels blocks that were required in the past.
Nice!
Post by: haynor666 on January 31, 2021, 07:13:31 am
Post by: pmc3 on January 31, 2021, 07:20:36 am
Post by: Calamity on January 31, 2021, 07:36:56 am
Thanks, changelog for 2.001b ?
The code for versions is 2.001 (SR) + b (GM integration)
So SR's is still 2.001 (no changes upstream), and "b" is the second release. We'll see how well or bad this works.
The commit history can be checked here (https://github.com/antonioginer/GroovyMAME/commits/newswitchres). The relevant change of "b" from the user's point of view is "Add 1 decimal precision to CPU overclock slider". This feature was already in 0.017t but was missing in 2.001a. I'll post a changelog anyway since the commit history is not meant to be used for that.
Once we update SR, the new version will be 2.002a, etc.
Post by: Paradroid on January 31, 2021, 07:53:42 pm
Post by: Arroyo on January 31, 2021, 09:36:16 pm
Post by: dth930 on February 01, 2021, 03:05:58 am
With all of these changes, is the update procedure still to overwrite all the files from the prior version besides the .ini's in the root directory? Or are there other files we need to retain or regenerate?
Post by: pixel69 on February 01, 2021, 07:20:44 am
great great job :notworthy:
Post by: m.andrade1 on February 02, 2021, 02:25:34 pm
Thanks a lot for your wonderfull effort to make our hobby great!
I´m trying to run 0228b but some strange reason it doesnt want to run, cannot even create a log file, so i will attach a photo so maybe anyone can figure out what is going on.
Strange thing that 0227b runs perfectly fine, on same config.
Using win7 , crt_emudriver 2.0 15, with an ati 6450, display 15khz on \\.\DISPLAY2, and regular dvi with a lcd on \\.\DISPLAY1
https://photos.app.goo.gl/Tqo1hjBRPqsUVoDk6
Thanks for help
Marcos
Post by: Calamity on February 02, 2021, 02:37:51 pm
Post by: reeone on February 03, 2021, 02:35:05 am
my another pc,amd a6 with r4 gpu,crt_emudriver_&_tools_2.0_beta_15_16.2.1_W.7.8.10-64,it run groovymame64_0228.001b_win-7-8-10 very good
Post by: Max_FS on February 03, 2021, 05:45:28 am
ASUS Z87-A Mainboard
Intel Pentium G3258 CPU
Sapphire Radeon HD 6450 GPU with CRT EMU-Driver, flashed with Atom-15
Windows 7
Sony Trinitron CRT as first screen
Stretched LCD as second screen
Post by: Calamity on February 03, 2021, 06:01:46 am
Are you using Emudriver based on 12.6? If so, please try with version 16.2.1.
Post by: m.andrade1 on February 03, 2021, 07:43:30 am
Thanks again for your fast reply, i used to mix mame´s dev version and them with yours.
But now as you suggest i unpacked your´s Github only, but unfortunelly same issue.
I saw your help for another user i have instaled 12.6 with ATi 6450, do you think i can install 16.2.1 with that card ?
Thanks
Marcos
Post by: Calamity on February 03, 2021, 09:24:05 am
I saw your help for another user i have instaled 12.6 with ATi 6450, do you think i can install 16.2.1 with that card ?
Yes, 16.2.1 is the recommended version for your card. 12.6 is just provided for backwards compatibility with pre-HD 5000 cards.
Post by: fred92 on February 03, 2021, 11:38:56 am
i post here too my request because for the first time, groovymame doesn't work with games.
with all latest releases there were no issues at all.
I'm working windows 7 64bits,groovymame 0.228 downloaded on github.
my videocard is ATI Radeon HD 5450 with Calamity drivers CRT emudrivers WDDM 1.20) for few years without issues.
VMMaker says CRT Emudriver 2.0 12.6 found.
i don't remember if it's beta 14 or 15 (how to check it ?) but i think it's the beta 15.
Any help welcome.
i saw you speak about 16.2.1.
where can this driver can be found, and, should i re install all modelines etc. ?
And i want to thank Calamity for this great job, i use my old arcadecabinets for years in pixel perfect !!
Fred, From France.
Post by: m.andrade1 on February 03, 2021, 12:05:11 pm
Thank you so much for your feedback again!
Will definely try 16.2.1 with my Ati 6450 !
Tried to download drivers but seems site is down : http://geedorah.com/eiusdemmodi/forum/index.php
Thanks
Marcos
Post by: Calamity on February 03, 2021, 12:41:44 pm
You'll need to reinstall your modelines. If you prefer you can "export" your modelines first. In VMMaker->Video card tab:
- Import modes from driver -> OK
- Export modes to file
Then once in 16.2.1:
- Import modes from file
- Install modes
Post by: m.andrade1 on February 03, 2021, 02:19:48 pm
Drivers 16.2.1 on my Ati 6450, fix the crash issue on 0228b.
Only thing i noticed on 0228b have a bigger horiontal widht screen, and on 0227b had a short Width.
Thank you so much for your time and help!
Marcos
Post by: fred92 on February 03, 2021, 04:14:31 pm
Use this link (https://drive.google.com/file/d/1dwjXRFdySz4moxGTGcVWLdQDG-zw5-cJ/view?usp=sharing) for 16.2.1 for non-GCN cards.
You'll need to reinstall your modelines. If you prefer you can "export" your modelines first. In VMMaker->Video card tab:
- Import modes from driver -> OK
- Export modes to file
Then once in 16.2.1:
- Import modes from file
- Install modes
hello Calamity, thanks you so much for your advice.
it now works.
Just a word, when a game is launched, the info screen is not very readable... but all works, that's enough.
Thank you for your quick answer and all the job you've done for us and our common passion: arcade games and pixel perfet.
Fred.
Post by: Max_FS on February 03, 2021, 06:33:00 pm
basically it also worked for me (many thanks for that), but unfortunately, I still have some trouble.
First of all, installing 16.2.1 made it a lot better and now GM runs with switchres activated.
However, it only works, when GM is being started from a frontend. When I try starting it directly, it produces error messages ("Switchres: Could not find a video mode that meets your specs"). Maybe that's not a problem at all but still leaves me confused.
Next thing is, that directly after installing CRTEmuDriver, it assigns my CRT to DISPLAY5 and my LCD (used as a second screen for marquee artwork) to DISPLAY4. After a restart of Windows, it is suddenly DISPLAY2 and DISPLAY1. This also may not be a problem but maybe is worth telling.
Now it comes to a bigger problem which is with regard to my second screen (the LCD besides the CRT to display marquee artwork). After changing to CRT EmuDriver 16.2.1 and GM0.228 nothing is displayed on the second screen, while GM is running. However, other artwork, like bezels, work correctly.
While the frontend is runnig, there is artwork displayed on the second screen. First it was in a wrong position but I was able fix that.
If anyone could help me with the last problem, I would be really grateful.
Best regards
Max
Post by: reeone on February 04, 2021, 12:12:28 am
Post by: Calamity on February 04, 2021, 02:54:41 am
oh，my gpu is too old to install CRT EmuDriver 16.2.1 :(
Have you tried?
Post by: reeone on February 04, 2021, 03:02:02 am
CRT EmuDriver 16.2.1 or nieg find no compatible devices with hd6310oh，my gpu is too old to install CRT EmuDriver 16.2.1 :(
Have you tried?
Post by: Max_FS on February 04, 2021, 04:46:36 am
Hi Calamity,
basically it also worked for me (many thanks for that), but unfortunately, I still have some trouble.
First of all, installing 16.2.1 made it a lot better and now GM runs with switchres activated.
However, it only works, when GM is being started from a frontend. When I try starting it directly, it produces error messages ("Switchres: Could not find a video mode that meets your specs"). Maybe that's not a problem at all but still leaves me confused.
Next thing is, that directly after installing CRTEmuDriver, it assigns my CRT to DISPLAY5 and my LCD (used as a second screen for marquee artwork) to DISPLAY4. After a restart of Windows, it is suddenly DISPLAY2 and DISPLAY1. This also may not be a problem but maybe is worth telling.
Now it comes to a bigger problem which is with regard to my second screen (the LCD besides the CRT to display marquee artwork). After changing to CRT EmuDriver 16.2.1 and GM0.228 nothing is displayed on the second screen, while GM is running. However, other artwork, like bezels, work correctly.
While the frontend is runnig, there is artwork displayed on the second screen. First it was in a wrong position but I was able fix that.
If anyone could help me with the last problem, I would be really grateful.
Best regards
Max
When I start GM via FrontEnd and then press TAB (to enter the menu) and then ESC I get back to the frontend without GM being closed (To leave GM and to get back to the frontend I normally use another key). However, when doing so and then closing the frontend and getting back to windows, GM is still running and when I maximise it, GM displays the artwork on the second just fine.
I really do not understand what's happening there.
Post by: Calamity on February 04, 2021, 06:10:05 am
Since SR is now fully multi-monitor, you need to configure it properly. You say your secondary screen (marquee) is an LCD. So you need to configure it like "monitor lcd" in a separate .ini file, named display1.ini where you should just put "monitor lcd". That should fix the error you're seeing on command line. If it doesn't, please post a log here. I need your results from command line, not from the frontend.
Post by: Calamity on February 04, 2021, 06:15:53 am
CRT EmuDriver 16.2.1 or nieg find no compatible devices with hd6310
Yeah it looks like the HD 6310 is actually an HD 4330, so 12.6 should be fine because it would use the legacy ati interface instead of adl. But for some reason it's trying to initialize adl. This leaves this card somehow in a dead zone. Could you post a log of legacy GM with your card on 12.6?
Post by: Max_FS on February 04, 2021, 08:32:11 am
Max_FS,
Since SR is now fully multi-monitor, you need to configure it properly. You say your secondary screen (marquee) is an LCD. So you need to configure it like "monitor lcd" in a separate .ini file, named display1.ini where you should just put "monitor lcd". That should fix the error you're seeing on command line. If it doesn't, please post a log here. I need your results from command line, not from the frontend.
Many thanks for that hint. I did so (creating display1.ini only containing monitor lcd) and suddenly it is possible to start mame directly by double clicking on it or via command line.
However, it still won't display any artwork on the second screen. Therefore I attached a log file. Additonally, there was a message saying "Warning: layout view 'Marquee_Only' contains deprecated marquee element". It appears three times, whenever I start the game...
OK, just found out that my .lay-files are a little bit outdated so I got the warning. However, that did not cause the problem. I build a new lay-file for one game but there is still no artwork displayed.
But when I start the game, press TAB, choose "video options" and then change display1 (my second screen) to "standard" and then back to "Marquee_only" the artwork suddenly appears. When exiting the game and starting it again, the artwork is gone.
Post by: pakoman on February 04, 2021, 08:56:17 am
What is GroovyMAME?
-[no]pixel_precision: greatly improves horizontal centering of video modes, by calculating horizontal borders with 1-pixel precision, instead of the default 8-pixels blocks that were required in the past.
This is a good one, how comes 8-pixels blocks are not required anymore? (if it is long to explain, just don't bother, I don't want to waste your time here)
What is GroovyMAME?
When used on stock AMD drivers instead of CRT Emudriver, usual limitations apply: no support for low resolutions (below 640x480) nor low dotclocks. Not a problem however if you're using a 31 kHz monitor.
Still, this feature is interesting enough to be provided as an option, and is a requirement for the new automatic lcd preset (as it's what makes it possible to refresh the current desktop mode).
I'm a bit (very) disconnected but Toasty's patcher (cru and so) easily removes those limitations on stock drivers (or at least it did a couple of years ago!). It doesn't add the ability to accept custom resolutions on the fly, though.
Post by: Calamity on February 04, 2021, 10:06:46 am
I think you also need to set "modeline_generation 0" in display1.ini. When doing so, please post your log again so I can compare.
Post by: Max_FS on February 04, 2021, 10:29:33 am
@Max_FS
I think you also need to set "modeline_generation 0" in display1.ini. When doing so, please post your log again so I can compare.
Ok, here we go. I set modeline to 0 and created two log files:
asterix2.txt: Just started the game and quit
asterix3.txt: Started the game, changed Display1 to "standard" and then back to "marquee_only" and then quit.
Post by: Calamity on February 04, 2021, 10:51:51 am
Ok, here we go. I set modeline to 0 and created two log files:
asterix2.txt: Just started the game and quit
asterix3.txt: Started the game, changed Display1 to "standard" and then back to "marquee_only" and then quit.
Can you see anything on the lcd?
Post by: Max_FS on February 04, 2021, 11:08:50 am
Ok, here we go. I set modeline to 0 and created two log files:
asterix2.txt: Just started the game and quit
asterix3.txt: Started the game, changed Display1 to "standard" and then back to "marquee_only" and then quit.
Can you see anything on the lcd?
Yes, I can see the extended desktop under windows and i see correctly positoned artwork while the frontend is running.
Only when starting GM (via frontend, directly from desktop or via command line) nothing appears on the lcd. There is no reaction.
Once GM is running, there are two ways to have something displayed on the lcd:
1. After GM was launched via frontend, I would press TAB to enter the menu and then press ESC to go back to the frontend which happens without GM being closed. Then I would close the frontend and maximise GM and suddenly both screens are working correctly.
2. Pressing TAB to enter the "video menu", then changing Display1 (which is the lcd) to standard view and then back to marquee view. Suddenly both screens are working correctly.
However, when exiting GM, the effect is gone and I would have to repeat the described way.
As a conclusion we know that the lcd is working properly and GM can basically display marquees on the lcd but it doesn't happen as expected.
Post by: Calamity on February 04, 2021, 11:33:52 am
Please ignore the frontend situation since that's beyond my control. I'm trying to simulate your case here but it's working fine, I'm just trying orunners with -numscreens 2, crt + lcd. Would you mind sending one of your marquee layouts so I can try? (calamity15khz@gmail.com)
Post by: reeone on February 05, 2021, 01:58:18 am
ERROR: ADL Initialization error!
Post by: xbrunox on February 05, 2021, 04:25:29 am
pls can u explain which options we can use in display1.ini or in display0.ini and don't be better remove that options from mame.ini
Post by: Calamity on February 05, 2021, 08:11:05 am
This is a good one, how comes 8-pixels blocks are not required anymore? (if it is long to explain, just don't bother, I don't want to waste your time here)
My tests back in 2007 with the old radeons showed that 8-pixel blocks were needed. This was probably a legacy feature from old VGA registers. Then some time ago, the user MrMikeZH pointed that pixel granularity worked for him (http://forum.arcadecontrols.com/index.php?topic=161457.0), so I tried here and it seems to work on my current cards too both in Windows and Linux. Probably older cards don't support this feature, that's why -pixel_precision is optional. Setting it to 0 brings old 8-pixel granularity back.
So after all we might have used this much before, I just assumed it wasn't possible.
Quote
I'm a bit (very) disconnected but Toasty's patcher (cru and so) easily removes those limitations on stock drivers (or at least it did a couple of years ago!). It doesn't add the ability to accept custom resolutions on the fly, though.
I tried a few months ago, and the patches we're concerned with weren't found unfortunately. Now that CRU's source code is available, it'd be possible to adapt it to our needs, with Toasty's permission. This is something I'm planning to do at some point but I have too many fronts open.
Post by: Calamity on February 05, 2021, 12:38:27 pm
ATI/AMD ADL init
ERROR: ADL Initialization error!
Hi reeone,
Yes, in fact your card is using ADL. But now GM uses ADL2, and 12.6 is only compatible with ADL(1). This means 12.6 will now just work for legacy (pre-HD5000) cards (non-ADL). HD 5000+ cards will be forced to use 16.2.1. So we'll need to modify 16.2.1 files so it recognizes your card. It should support it already, but for some stupid reason Mobility models have usually been removed from the generic driver package. I only realise when someone with a Mobility card complains.
Well, to be honest I didn't anticipate this incompatibility with 12.6, but at least now people will move forward to 16.2.1 which works definitely better in general.
Post by: Calamity on February 05, 2021, 12:44:43 pm
Hi Calamity
pls can u explain which options we can use in display1.ini or in display0.ini and don't be better remove that options from mame.ini
You can use all the options from switchres.ini, here: https://github.com/antonioginer/switchres/blob/master/switchres.ini
The options in mame.ini are the default ones that'll apply to all displays that don't have overrides for them in specific display#.ini files.
The reason we're still keeping some of them in mame.ini, that might seem a bit messy, I admit, is because otherwise we would not be able to apply command line options and switches for these very needed features.
Post by: R-Typer on February 05, 2021, 04:43:24 pm
BTW, I use Sony Trinitron CRT that has a mind of his own and is so unpredictable when screen centering is in question.
Post by: schmerzkaufen on February 06, 2021, 11:44:58 am
Post by: Trnzaddict on February 07, 2021, 08:18:54 am
So I have another arcade machine running a vertically oriented non VRR LCD monitor. It is 1920x1200, but I have created custom Nvidia resolutions @1920x1200 54hz-61hz.
So with the new SR engine, from what I understand with the LCD preset, defining the range and allowing HW refresh, will Groovymame still need to see those custom resolutions or can I delete them? From what I understood from the original post was the new engine will automatically adjust timings based on what your monitor is capable of refreshing at and do a much better job at getting a closer timing rather than old Groovymame?
Post by: Calamity on February 08, 2021, 09:41:09 am
Well, not really, for the lcd preset to work as described in the changelog, GM needs to be able to read and write the actual timings from and to your gpu, and this on Windows is currently possible with AMD cards only. On Linux it applies to Nvidia and Intel too, but these have other issues.
Post by: italospain on February 09, 2021, 05:40:33 am
after updating from 227 to 228 with the new switchres version i am not able to use the frame delay option.
i use the LCD auto Preset for my plasma-tv with an NVIDIA card
thanks for groovymame btw
greetings
Post by: Calamity on February 09, 2021, 06:37:11 am
Post by: italospain on February 09, 2021, 12:36:57 pm
now it works like before.
can you give me a hint howto configure groovymame the right way for a plasma tv (1080p) that only supports 50 and 60 hz with nvidia ?
Post by: xbrunox on February 09, 2021, 01:28:58 pm
Calamity for use FFB plugin I must set output=windows
Is something change in new switches?
Post by: Calamity on February 09, 2021, 04:25:35 pm
Whatever change affecting input in 0.228 must have happened upstream, not in Switchres.
I don't know how the FFB plug works, the code in github looks like a dll wrapper. If it was a lua plugin, I would have thought the problem was caused by recent lua interface overhaul, but it's not likely the case.
Post by: SuperMagoAlex on February 10, 2021, 04:27:41 am
I've a problem with my 2 monitors setup.
This is my config:
- Intel i3 9100
- 8Gb ram
- Radeon R7 240 2Gb (3 output: VGA, DVI-D, hdmi)
- Win10 Pro 64 bit
- CRT Emudrivers 18.5.1
- Groovymame 0.228, Switchres 2.001b
- 1 TV Sony 15" connected to GPU's DVI-D via Scart-VGA cable + VGA/DVI-D adaptor
- 1 monitor Commodore 1084S (vertically rotated for vertical games) connected to GPU's VGA
If I connect one monitor at a time everything works perfectly, horizontal games on TV and vertical games on monitor.
If I connect the two monitors simultaneously and start a vertical game, on the vertical monitor the game goes at an accelerated speed, while if I start an horizontal game, I see the game with waves in the background on the horizontal TV.
What could be the problem?
Post by: Calamity on February 10, 2021, 04:39:20 am
You need specific configuration in mame.ini to correctly map each display, please share your mame.ini and a log and I'll be able to help.
Post by: SuperMagoAlex on February 10, 2021, 06:40:35 am
@SuperMagoAlex,
You need specific configuration in mame.ini to correctly map each display, please share your mame.ini and a log and I'll be able to help.
Hi, here you are log and ini files.
Thanks for you help :)
Post by: Calamity on February 13, 2021, 05:23:07 am
Your problem with vertical games at accelerated speed is clearly caused by the waitvsync 0 line in your vertical.ini file. This prevents autosync from working, because vertical.ini has higher priority than mame.ini. So I'd just remove the whole "# OSD VIDEO OPTIONS" block. Besides, I'd say you need to add either autoror 1 or autorol 1 to vertical.ini for correct orientation.
With regards to the waves in the background with horizontal games, I can't see anything wrong in your configuration or logs.
Post by: SuperMagoAlex on February 13, 2021, 11:50:56 am
Thanks for the info, vertical games runs fine now.
I noticed that turning off one of the two monitors, the wave interference disappears, so when I play vertical games I have to turn off the horizontal monitor and vice versa.
Post by: Robbbert on February 13, 2021, 07:18:25 pm
Post by: Torkyo on February 16, 2021, 07:17:55 pm
thanks for this huge update.
I've got a question: I got an Hantarex polo star 28", I'm used to play vertical games rotated. Often such games go 25 or 31KHz with perfect timing and resolution thanks to its three frequencies feature.
I realised that after the switcher update (GM 0.228), vertical games, seems less defined. it is like a sort vague "super scale".
I compared the GM old and new for a specific game and I realised that the super resolution used are precisely the same. resolution and timing are the same. so apparently I think I should have the same visual outcome.
If it can help I can provide my GM ini for 0.225 and the last 0.228. as soon as I can.
BtW i tried to switch off the new feature "granularity" as it seemed pertinent to the problem so I did a try but it didn't help.
Have you got any idea about this issue?
thanks
Post by: Torkyo on February 17, 2021, 06:07:16 am
thanks again
Post by: tonyt76 on February 22, 2021, 08:57:43 pm
Post by: Zebidee on February 22, 2021, 09:07:25 pm
I cant find the triplebuffer option in the groovymame 0.228 mame.ini file?
Would think you don't need it
Post by: Torkyo on February 23, 2021, 08:54:05 am
I tried to change some other options of the 228 like "intoverscan" "intscalex" "intscaley". also the new "pixel_precision". Sadly no success.
I also gave a try to the standard resolution to see if that could help but noway.
IMHO it seems that the new switcher have a different behaviour to stretch vertical games.
I tried to read any difference 225 and 228 logs I posted above but I don't have the knowledge to spot something helpful.
Hope this may help a bit.
thanks
Post by: Calamity on February 23, 2021, 04:09:05 pm
The missing "feature" in SR 2 is to force "-filter" when unevenstretch is enabled. I removed this temporarily since it's d3d specific, until I decide what's the correct way to re-add it. If it's you really miss it I may re-add it.
Post by: Calamity on February 23, 2021, 04:15:09 pm
I cant find the triplebuffer option in the groovymame 0.228 mame.ini file?
I also removed the multithreaded triplebuffer implementation of old GM, because it's d3d/Windows specific, and the new bgfx backend already implements multithreaded rendering, so the idea was to move to that api eventually.
Besides, the new automatic lcd preset (AMD) makes triplebuffer less necessary on LCDs because in theory you can use syncrefresh in most situations as now the correct refresh will be used. This allows using frame delay too in situations where before wasn't possible due to the use triplebuffer.
Anyway, again, if it's a much needed feature, I may re-add it.
Post by: Torkyo on February 23, 2021, 07:19:25 pm
@Torkyo,
The missing "feature" in SR 2 is to force "-filter" when unevenstretch is enabled. I removed this temporarily since it's d3d specific, until I decide what's the correct way to re-add it. If it's you really miss it I may re-add it.
thank you very much, Calamity!
Well, I really miss it. If you could re-add it, that would be really appreciated.
For vertical games using CRT 31Khz capable to draw many lines without interlace, I do think that the filter is a very good compromise
Post by: RobeeJ on February 25, 2021, 04:47:42 am
Thank you!
Post by: saint on February 25, 2021, 10:12:39 am
Pretty please?
Just, no. Take it somewhere else.
Thank you.
Post by: tonyt76 on February 25, 2021, 03:26:01 pm
I cant find the triplebuffer option in the groovymame 0.228 mame.ini file?
I also removed the multithreaded triplebuffer implementation of old GM, because it's d3d/Windows specific, and the new bgfx backend already implements multithreaded rendering, so the idea was to move to that api eventually.
Besides, the new automatic lcd preset (AMD) makes triplebuffer less necessary on LCDs because in theory you can use syncrefresh in most situations as now the correct refresh will be used. This allows using frame delay too in situations where before wasn't possible due to the use triplebuffer.
Anyway, again, if it's a much needed feature, I may re-add it.
I don't use this option, I was just following recap's guide and couldn't find it.
Post by: mode11 on March 01, 2021, 05:46:37 pm
Post by: Sledge on March 05, 2021, 03:07:22 am
I'm still somewhere back on win 7 with GM .207 maybe?
Wondering if i should update to Win 10 with new GM as well?
Worth it?
Looks like i'll have to learn it all over again haha
Post by: beernut on March 10, 2021, 11:08:22 am
Here is the log from sinistar for example:
Working switchres v0.017s from GM 0.226
Code: [Select]
SwitchRes: v0.017s, Monitor: custom, Orientation: horizontal, Modeline generation: enabled SwitchRes: Monitor range 15250.00-18000.00,49.00-61.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,224,288,448,576 SwitchRes: Monitor range 20000.00-21500.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,320,360,0,0 SwitchRes: Monitor range 23900.00-29000.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,384,400,0,0 SwitchRes: Monitor range 29001.00-32000.00,49.00-61.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,400,512,0,0 SwitchRes: Monitor range 32000.00-35000.00,49.00-61.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,512,600,0,0 SwitchRes: xrandr version 1.6 SwitchRes: Found output connector 'VGA-0'
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.017s:[sinistar] Calculating best video mode for 240x292@60.096153 orientation: rotated
SwitchRes: ( 1)x( 1)_(60=60.000000Hz)
rng(0): 728 x 544_60.096153i 17.878606 [fract] scale(2, 1, 1) diff(17.22, 0.00, 0.0000) ratio(3.033, 1.863)
rng(1): 432 x 320_60.096153p 21.394231 [fract] scale(1, 1, 1) diff(1.23, 0.00, 0.0000) ratio(1.800, 1.096)
rng(2): 536 x 400_60.096153p 26.682692 [fract] scale(1, 1, 1) diff(20.40, 0.00, 0.0000) ratio(2.233, 1.370)
rng(3): 640 x 480_60.096153p 31.550480 [fract] scale(1, 1, 1) diff(33.33, 0.00, 0.0000) ratio(2.667, 1.644)
rng(4): 736 x 552_60.096153p 34.675480 [fract] scale(2, 1, 1) diff(15.94, 36.07, 0.0000) ratio(3.067, 1.890)
SwitchRes: [sinistar] (1) vertical (240x292@60.096153)->(736x552@60.096153)
rng(4): 736 x 552_60.096153p 34.675480 [fract] scale(2, 1, 1) diff(15.94, 36.07, 0.0000) ratio(3.067, 1.890)
SwitchRes: Modeline "736x552_60 34.675480KHz 60.096153Hz" 32.733652 736 768 872 944 552 553 557 577 -hsync -vsync
Switchres: CRTC 0: mode 0x57, 648x480+0+0.
Switchres: xrandr change screen size.
Switchres: xrandr mode (GM-736x552_60.096153) (0x6fe) 32.733652MHz
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -noautoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -unevenstretch
SwitchRes: Setting option -nounevenstretchx
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -syncrefresh
SwitchRes: Setting option -waitvsync
SwitchRes: Setting option -filter
Available videodrivers: x11 wayland KMSDRM dummy
Current Videodriver: x11
Display #0
Renderdrivers:
opengl (0x0)
opengles2 (0x0)
software (0x0)
....
Adding monitor screen0 (736 x 552)
....
And the broken for me SR2.0 from GM 0.227 (same results on 0.228)
the screen locks up mostly black with a few lines of graphics on the top and requires switching consoles to reset monitor.
Code: [Select]
Available videodrivers: x11 wayland KMSDRM dummy
Current Videodriver: x11
Display #0
Renderdrivers:
opengl (0x0)
opengles2 (0x0)
software (0x0)
...
Enter init_monitors
Adding monitor screen0 (648 x 480)
Leave init_monitors
...
Switchres(v2.00) display[0]: monitor[custom] generation[on]
Switchres: Monitor range 15250.00-18000.00,49.00-61.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,224,288,448,576
Switchres: Monitor range 20000.00-21500.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,320,360,0,0
Switchres: Monitor range 23900.00-29000.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,384,400,0,0
Switchres: Monitor range 29001.00-32000.00,49.00-61.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,400,512,0,0
Switchres: Monitor range 32000.00-35000.00,49.00-61.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,512,600,0,0
XRANDR: <1> (xrandr_timing) creation (screen0)
XRANDR: <1> (xrandr_timing) checking X availability (early stub)
XRANDR: <1> (init) loading Xrandr library
XRANDR: <1> (init) loading X11 library
XRANDR: <1> (init) version 1.6
XRANDR: <1> (init) check screen number 0
XRANDR: <1> (init) check output connector 'HDMI-0' active 0 crtc 0
XRANDR: <1> (init) check output connector 'DVI-0' active 0 crtc 0
XRANDR: <1> (init) check output connector 'VGA-0' active 1 crtc 1 [SELECTED]
XRANDR: <1> (get_timing) mode 0057 648x480 refresh 60.000000 added
Switchres: [ 1] 648x 480 @ 60p* : XRANDR timing "648x480_60 31.500000KHz 60.000000Hz" 25.452000 648 664 760 808 480 490 492 525 -hsync -vsync
XRANDR: <1> (get_timing) mode 0058 640x480 refresh 60.000000 added
Switchres: [ 2] 640x 480 @ 60i : XRANDR timing "640x480_60i 15.750000KHz 60.000000Hz" 13.104000 640 664 728 832 480 484 490 525 interlace -hsync -vsync
Switchres: get_mode(0) 292 240 60.096154 1.333333
Switchres: Calculating best video mode for 292x240@60.096153 orientation: rotated
Switchres: [ 648]x[ 480]_[60=60.000000Hz]
rng(0): out of range
rng(1): out of range
rng(2): out of range
rng(3): 648 x 480_60.000000p 31.500000 [fract] scale(2, 1, 1) diff(31.69, 38.33, -0.0962) ratio(2.700, 1.622)
rng(4): out of range
Switchres: [ 640]x[ 480]_[60=60.000000Hz]
rng(0): 640 x 480_60.000000i 15.750000 [fract] scale(1, 1, 1) diff(33.33, 38.33, -0.0962) ratio(2.667, 1.622)
rng(1): out of range
rng(2): out of range
rng(3): out of range
rng(4): out of range
Switchres: ( 0)x( 0)_(0=0.000000Hz)
rng(0): 728 x 544_60.096153i 17.878606 [fract] scale(2, 1, 1) diff(17.22, 0.00, 0.0000) ratio(3.033, 1.838)
rng(1): 432 x 320_60.096153p 21.394231 [fract] scale(1, 1, 1) diff(1.23, 0.00, 0.0000) ratio(1.800, 1.081)
rng(2): 536 x 400_60.096153p 26.682692 [fract] scale(1, 1, 1) diff(20.40, 0.00, 0.0000) ratio(2.233, 1.351)
rng(3): 640 x 480_60.096153p 31.550480 [fract] scale(1, 1, 1) diff(33.33, 0.00, 0.0000) ratio(2.667, 1.622)
rng(4): 432 x 296_56.634304pd 35.000000 [integ] scale(1, 1, 1) diff(0.00, 0.00, -3.4618) ratio(1.800, 1.000)
Switchres: rotated (292x240@60.096153)->(432x296@56.634304)
rng(4): 432 x 296_56.634304pd 35.000000 [integ] scale(1, 1, 1) diff(0.00, 0.00, -3.4618) ratio(1.800, 1.000)
Switchres: Modeline "432x296_56 35.000000KHz 56.634304Hz" 19.460000 432 451 513 556 296 297 299 309 doublescan -hsync -vsync
XRANDR: <1> (add_mode) create mode SR-1_432x296@56.63
XRANDR: <1> (add_mode) mode 0707 432x296 refresh 56.634304 added
Switchres: added XRANDR timing "432x296_56 35.000000KHz 56.634304Hz" 19.460000 432 451 513 556 296 297 299 309 doublescan -hsync -vsync
XRANDR: <1> (set_timing) DISABLE crtc relocation
XRANDR: <1> (set_timing) crtc 0* [0057] 648x480+0+0 --> [0707] 432x296+0+0 flags [11]
XRANDR: <1> (set_timing) setting screen size to 432 x 296
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -nounevenstretch
SwitchRes: Setting option -nounevenstretchx
SwitchRes: Setting option -nowaitvsync
SwitchRes: Setting option -nosyncrefresh
Enter sdl_info::create
/dev/dri/card0 successfully opened
OpenGL: X.Org
OpenGL: AMD CEDAR (DRM 2.50.0 / 5.9.2-arch1-1-15khz, LLVM 10.0.1)
OpenGL: 3.1 Mesa 20.2.1
OpenGL: texture rectangle supported
OpenGL: non-power-of-2 textures supported (new method)
OpenGL: vertex buffer supported
OpenGL: pixel buffers supported
OpenGL: framebuffer object supported
OpenGL: GLSL supported, but disabled
OpenGL: max texture size 16384 x 16384
Leave renderer_ogl::create
...
Starting Sinistar (revision 3)
GL texture: copy 0, shader 0, dynamic 0, 292x240 292x240 [RGB32, Equal: 1, Palette: 0,
scale 1x1, border 0, pitch 512,292/16384], bytes/pix 4
GL texture: copy 0, shader 0, dynamic 0, 292x240 292x240 [RGB32, Equal: 1, Palette: 0,
scale 1x1, border 0, pitch 512,292/16384], bytes/pix 4
Average speed: 100.00% (2 seconds)
sdl_kill: closing audio
Enter sdlwindow_exit
Leave sdlwindow_exit
Switchres: exit
XRANDR: <1> (set_timing) DISABLE crtc relocation
XRANDR: <1> (set_timing) [WARNING] unexpected active modeline detected (last:[0707] now:[0057] 648x480+0+0 want:[0057])
XRANDR: <1> (set_timing) crtc 0* [0057] 648x480+0+0 flags [01]
XRANDR: <1> (set_timing) setting screen size to 648 x 480
XRANDR: <1> (delete_mode) remove mode SR-1_432x296@56.63
Switchres: success deleting mode XRANDR timing "432x296_56 35.000000KHz 56.634304Hz" 19.460000 432 451 513 556 296 297 299 309 doublescan -hsync -vsync
I'm sure it's some wrong or new setting I am missing or perhaps my modelines need fixing for 2.0
Code: [Select]
#
# OSD FULL SCREEN OPTIONS
#
switchres 1
switchres_backend auto
modesetting 1
modeline_generation 1
monitor custom
interlace 1
doublescan 1
super_width 2560
changeres 1
lock_system_modes 1 lock_unsupported_modes 1
refresh_dont_care 0
dotclock_min 0
v_shift_correct 0
pixel_precision 1
sync_refresh_tolerance 2.0
autosync 1
screen_compositing 0
screen_reordering 0
allow_hw_refresh 0
modeline auto
ps_timing auto
lcd_range auto
crt_range0 "15250-18000, 49-61, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 224, 288, 448, 576"
crt_range1 "20000-21500, 49-61, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 320, 360, 0, 0"
crt_range2 "23900-29000, 49-61, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 384, 400, 0, 0"
crt_range3 "29001-32000, 49-61, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 400, 512, 0, 0"
crt_range4 "32000-35000, 49-61, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 512, 600, 0, 0"
crt_range5 auto
crt_range6 auto
crt_range7 auto
crt_range8 auto
crt_range9 auto
If I add the following to sinistar.ini then it works again like it did in sr 0.017s
Code: [Select]
resolution 736x552
So clearly something is off on my rotation settings. But almost every other vertical game works fine. I'm ok just making the manual change above but am curious if there is something causing this that I can fix to avoid that issue on any other games matching sinistar's resolution.
Thanks in advance for any help sorting this.
Post by: Calamity on March 10, 2021, 03:39:28 pm
Post by: Calamity on March 11, 2021, 04:42:55 pm
What's new in Switchres 2.002a (March 2021)
- Fixed crash on emulated systems with 2 or more screens.
- Correctly update game video information after machine initialization.
- Properly account for refresh scaling & black frame insertion with frame delay.
Post by: R-Typer on March 11, 2021, 04:44:12 pm
Post by: pakoman on March 11, 2021, 05:21:29 pm
You got me hitting F5 for this one :D
Post by: beernut on March 11, 2021, 09:03:00 pm
Thanks. That fixed Sinistar. Any reason to keep doublescan in my ini for other games or with my D9200 is it not necessary. So many video options.
Appreciate the help and GM in general.
Post by: schmerzkaufen on March 12, 2021, 03:16:05 am
For now SR2 Groovy is pretty much a no-go for playing the way-off 60Hz games on a non-VRR/non-Emudriver compatible flat panel,
unless it's for ppl who don't mind either tearing or much accelerated gameplay for games like Raiden II or the MK series.
At present on anything but a dedicated compatible setup for playing that kind of games decently, one's stuck with Legacy (SR1) 0.227 which is the last to feature the Groovy-only faster triplebuffer.
Also on that topic I was wondering; if it's not coming back, what use is there for the sync_refresh_tolerance setting now ?
Post by: Calamity on March 12, 2021, 05:42:29 am
As I explained, as long as you have an AMD card, not necessarily with CRT Emudriver, just stock drivers and a normal LCD, you can benefit from the automatic lcd preset, which is waaaay better than triplebuffer since it allows the use of frame delay.
The purpose of sync_refresh_tolerance still holds, just changes -triplebuffer by -nosyncrefresh. Besides, this option also has a purpose in modeline scoring.
Post by: schmerzkaufen on March 12, 2021, 02:04:48 pm
Guess ppl who are on intel/nvidia gpus with fixed sync & modes better stick to Legacy 0.227 until you take a decision on the matter then.
automatic lcd preset > haven't had time to experience that yet, because both my old desktop pc, and the new (WIP), are still not ready.
But I'll let you know what I think about it later, if that works fine or if I meet issues, whatever.
PS: when will you talk about that mysterious 'emusync' thing you guys seem to be working on for the future ?
EDIT: damn, really it's too bad that the branded Groovy triplebuffer's missing now, I felt it today as I'm still without a full/flexible/AMD setup for a while. So I had no choice but to go back to Legacy 0.227
As an nVidia & Intel user w/ a normal flat panel you're really left behind the moment you play these way off-60Hz games, Groovy feels incomplete without it.
I really hope you'll think it over or have an alternative to it some day, and not leave it at that which would be a shame. Im being redundant but heh, it's important.
Post by: tom5151 on March 20, 2021, 03:16:35 pm
@b4nd1t0 Do you plan to build a nonag version as usual ?
Post by: MrMikeZH on March 21, 2021, 04:15:09 pm
The 1pix granularity was possible back to the radeon 7000 for sure. Before groovy there was cabmame, that was around 2008 or even earlier. Sailorsat is the woman who made cabmame and she did also a modeline editig tool which i can distribute for nostalgia reason, had used it back then in 2008.
Now there is only the info missing on how to set the refresh rate to 30 or 60hz aka 1 or 2 fields per frame.
Hi Pakoman,This is a good one, how comes 8-pixels blocks are not required anymore? (if it is long to explain, just don't bother, I don't want to waste your time here)
My tests back in 2007 with the old radeons showed that 8-pixel blocks were needed. This was probably a legacy feature from old VGA registers. Then some time ago, the user MrMikeZH pointed that pixel granularity worked for him (http://forum.arcadecontrols.com/index.php?topic=161457.0), so I tried here and it seems to work on my current cards too both in Windows and Linux. Probably older cards don't support this feature, that's why -pixel_precision is optional. Setting it to 0 brings old 8-pixel granularity back.
So after all we might have used this much before, I just assumed it wasn't possible.
Post by: b4nd1t0 on March 21, 2021, 05:00:20 pm
Thanks @Calamity :applaud:arcade only is available
@b4nd1t0 Do you plan to build a nonag version as usual ?
Post by: tom5151 on March 22, 2021, 02:38:23 am
Thanks @b4nd1t0 :cheers:Thanks @Calamity :applaud:arcade only is available
@b4nd1t0 Do you plan to build a nonag version as usual ?
But in your 229 folder there is an archive with in its name "228" and which contains a linux binary.
Post by: b4nd1t0 on March 22, 2021, 04:29:21 am
Sent from the sixth floor
Post by: tom5151 on March 22, 2021, 01:47:19 pm
Ops! Only a name error when zippingThanks.
Sent from the sixth floor
Post by: fred92 on March 22, 2021, 05:14:42 pm
in order to compile my own groovymame,
i wonder why we can't find the groovymame.diff on the new https://github.com/antonioginer/GroovyMAME/releases
previously on https://drive.google.com/drive/folders/0B5iMjDor3P__aEFpcVNkVW5jbEE we could find on each release the .diff files.
thank you very much.
Fred, From France.
Post by: b4nd1t0 on March 23, 2021, 05:19:23 am
Post by: RobeeJ on March 23, 2021, 05:20:09 am
https://github.com/antonioginer/GroovyMAME/releases
And then I apply the supression patch from here:
http://mamestuff.lowtrucks.net/MKChamp/
Post by: digitalwacker on March 25, 2021, 04:11:58 pm
ATI/AMD ADL init
ERROR: ADL Initialization error!
Hi reeone,
Yes, in fact your card is using ADL. But now GM uses ADL2, and 12.6 is only compatible with ADL(1). This means 12.6 will now just work for legacy (pre-HD5000) cards (non-ADL). HD 5000+ cards will be forced to use 16.2.1. So we'll need to modify 16.2.1 files so it recognizes your card. It should support it already, but for some stupid reason Mobility models have usually been removed from the generic driver package. I only realise when someone with a Mobility card complains.
Well, to be honest I didn't anticipate this incompatibility with 12.6, but at least now people will move forward to 16.2.1 which works definitely better in general.
Post by: beernut on March 31, 2021, 09:58:32 am
i wonder why we can't find the groovymame.diff on the new https://github.com/antonioginer/GroovyMAME/releases
Fred,
If you want diffs from github you just need to add .diff to the end of the compare url. Here are the diffs for GM 0.229 as compared to baseline 0.229
Here is the compare page on github:
https://github.com/mamedev/mame/compare/mame0229...antonioginer:groovymame0229
And here it is as a diff:
https://github.com/mamedev/mame/compare/mame0229...antonioginer:groovymame0229.diff
Post by: fred92 on March 31, 2021, 04:53:39 pm
Post by: Calamity on April 01, 2021, 04:13:51 am
Post by: schmerzkaufen on April 01, 2021, 04:53:26 am
But in the meantime it's still very useful.
Just yesterday I was fine-adjusting sync_refresh_tolerance to see how fast an acceleration is acceptable in general, and found that over 105% starts being too much, so I set 2.771 so syncrefresh at least covers Sega's classic system18 games @57.23
Beyond that limit which is close to halfway the 6Hz spanning from 60 to 54, there's really a lot of games for which Groovy's 9ex triplebuffer is the preferable solution, better than speed up or tearing.
NMK & UPL games, Raiden II & DX, most of the IREM catalog, Mortal Kombat series and many Williams & Midway games, Xexex, Raiden Fighters series a the bottom, and many more.
It's choppy and gives about 2 frames of delay (still unconfirmed yet this is what it feels like), but that's still better than dealing with 110% speed, or tearing, or the 3 frames of the 'normal' triplebuffer in other MAMEs.
Anyway great news.
Post by: Torkyo on April 01, 2021, 09:00:30 am
I was wondering if there are any chance to see reintroduced in v0.230 the “feature” “- filter” you were talking about past month.
if that wouldn’t be possible, do you know is there is any work around I could adopt to fix the issue, apart To stay stick to the old SR?
Thanks again
Post by: beernut on April 01, 2021, 10:15:37 am
If you do patch manually most certainly do not bug Calamity for any bug fixes or tech support until he releases his official 0.230.
Post by: Sledge on April 04, 2021, 05:02:42 am
Or is it still best to stick with Windows 7?
Edit: to answer my own question.. yes the guide is still correct to use with Win 10 :)
Post by: Sledge on April 18, 2021, 04:38:11 am
On a fresh install, for a plain old single arcade screen cabinet with Win 10 etc, what are the recommended settings to change in mame.ini these days, or do we just leave everything as it is?
ie: do we need to set video to d3dex or anything like that currently?
Post by: Calamity on April 18, 2021, 06:15:13 am
@CalamityOnly the rompath actually. And maybe the monitor preset to something not so conservative as generic_15 (e.g. arcade_15). Everything else is fine with the defaults, and frame delay is now set from the ui.
On a fresh install, for a plain old single arcade screen cabinet with Win 10 etc, what are the recommended settings to change in mame.ini these days, or do we just leave everything as it is?
ie: do we need to set video to d3dex or anything like that currently?
I'd configure the sound to use portaudio though for the lowest audio latency.
Post by: Sledge on April 18, 2021, 08:42:54 pm
Only the rompath actually. And maybe the monitor preset to something not so conservative as generic_15 (e.g. arcade_15). Everything else is fine with the defaults, and frame delay is now set from the ui.Cool, just how i had it :) (except for the portaudio)
I'd configure the sound to use portaudio though for the lowest audio latency.
Thanks!
Post by: schmerzkaufen on April 21, 2021, 06:27:33 am
(I think I'm gonna grab a fresh full set with the next Groovy since mine's really too old now, might as well match versions)
Post by: Calamity on April 23, 2021, 01:09:27 pm
Yo I bet this stuff's tough so I guess you're schedule skipping 0.230 since 0.131 iis only like a week away?
(I think I'm gonna grab a fresh full set with the next Groovy since mine's really too old now, might as well match versions)
Yes, I'm probably skipping 230, I still need to settle things down. But things are going fine.
Post by: schmerzkaufen on April 23, 2021, 03:16:49 pm
Post by: eewoke on April 28, 2021, 01:41:10 pm
Thanks for this new version. I did a fresh install on my arcade cabinet with Polostar 28” and ati 5450 Arcadevga 5000 version. Mame.ini is adapted to other paths, usage of portaudio (delay 2.00 😀) and switchres_backend ati and monitor pstar. The vertical games on the horizontal monitor are running great (although not always aligned in the middle of the screen), but on some resolutions (horizontal and vertical games) I experience tearing. I tried some other settings, but I did not succeed getting rid of the tearing. Maybe you have a suggestion or I just have to be patient and wait for the next optimized version.
Thanks again for Groovymame....using it for many years!
Nevermind Calamity..... sync_refresh_tolerance 3.0 did the trick. How can I determine the right number? 2.0 has tearing, but anything above not. Take for instance R-Type.....with 3.0 no tearing anymore. Thanks!
Post by: lolomre on May 16, 2021, 01:06:37 pm
Post by: sean_skroht on May 17, 2021, 01:51:02 am
Upload The new groovymame 0.231 calamity, PLEASE. Thanks you
I think it would be best being patient, and giving Calamity an opportunity to take his time to get things done properly.
Post by: Calamity on May 17, 2021, 04:07:41 am
Post by: psakhis on May 17, 2021, 01:09:35 pm
Upload The new groovymame 0.231 calamity, PLEASE. Thanks youIt's preferible wait for version 0.232, this version remains some sound problems.
Post by: hhtien1408 on May 26, 2021, 10:31:06 pm
Hope to hear from you asap. Thanks a lot!
Post by: PL1 on May 27, 2021, 12:28:21 am
Could you compile for Ubuntu Debian your version of Groovymame 0.229 - Switchres 2.002a "without nag screen" (suppression diff patch)?I think b4nd1t0 (http://forum.arcadecontrols.com/index.php?action=profile;u=87736) might have what you're looking for here:
https://b4nd1t0.blogspot.com/2021/03/mame-0229.html (https://b4nd1t0.blogspot.com/2021/03/mame-0229.html)
Quote
Mame64 arcadeonly + groovy switchres 2.002a + nonag - linux
Scott
Post by: hhtien1408 on May 27, 2021, 01:30:28 am
https://drive.google.com/drive/folders/0B_hdh1Ds66TvflV4alVlSzNIbDh3a0R6aFczYlJBc2t2STJ4U0tJS2FOTEZPdTdOWVIwYk0 (https://drive.google.com/drive/folders/0B_hdh1Ds66TvflV4alVlSzNIbDh3a0R6aFczYlJBc2t2STJ4U0tJS2FOTEZPdTdOWVIwYk0)
Post by: Calamity on June 20, 2021, 07:07:48 am
What's new in Switchres 2.002b (June 2021)
- New option -[no]syncaudio: Make audio synchronization (resampling) optional. Default is enabled. Disable to avoid sound wobble with erratic emulation speeds (like that caused by frame delay on some systems).
- New option -[no]autostretch: Make auto stretching feature optional. Default is enabled, so GM will apply the scaling mode (fractional or integer) that best fits the situation.
- New option -[no]autofilter: Make auto filter optional. Default is enabled, so GM will apply bilinear filtering when fractional scaling or an interlaced mode are used.
- New option -[no]interlace_force_even: Calculate all vertical values of interlaced modes as even numbers. Required by AMD APU hardware on Linux
- [Windows] Implement asynchronous rendering through native D3D9ex api (replace for old multithreaded -triplebuffer). This mode is selected automatically by -autosync. You can force it manually with -waitvsync -nosyncrefresh.
- [Linux] New option -sync_mode <0-4>: In combination with -syncrefresh, select the synchronization mode that offers the lowest latency based for the specific video driver. The default value is 2, which gives good results for both amdgpu and radeon on X11 and kms mode. Other modes are provided that could be useful with other hardware/driver combination.
Code: [Select]
sync algorithm amdgpu radeon radeon/kms amdgpu/kms
mode
0 -Swap(1) perfect(1) perfect smooth smooth
-glFinish lag 1 frame lag 1 frame
1 -Swap(0) tearing tearing perfect tearing/
-drmWaitVBlank perfect w/fd stuttering
-glFinish
2 -Swap(1) perfect(1) perfect perfect perfect(1)
-drmWaitVBlank
-glFinish
3 -drmWaitVBlank tearing perfect(2) tearing tearing
-Swap(0)
-glFinish
4 -drmWaitVBlank half speed half speed smooth smooth
-Swap(1) lag 1 frame lag 1 frame
-glFinish
- Swap(x), x = Opegl swap interval (0 = immediate, 1 = v-sync)
(1) Low frame delay performance
(2) GM's pre-0.232 implementation
perfect = smooth + subframe latency
Note: amdgpu on X11 has tearing with mode 1, however tearing can be removed with frame delay, and when done, it offers better performance than mode 2.
Post by: R-Typer on June 20, 2021, 08:26:59 am
Post by: donluca on June 20, 2021, 09:54:31 am
This could finally be the year of Linux™, if I may say so myself.
About that table: what about Intel and nVidia GPUs?
Post by: Calamity on June 20, 2021, 10:16:38 am
Amazing development, thanks.
This could finally be the year of Linux™, if I may say so myself.
About that table: what about Intel and nVidia GPUs?
Good question. I haven't tested nVidia nor Intel, but I have some hopes that any of the sync modes may work with them. So I'd appreciate some Linux testing on different hardware. Always keep in mind that many GPUs won't do low pixelclocks so setting -dotclock_min 25.0 is the most universal recommendation.
Post by: schmerzkaufen on June 21, 2021, 01:57:22 am
- New option -[no]syncaudio: Make audio synchronization (resampling) optional. Default is enabled. Disable to avoid sound wobble with erratic emulation speeds (like that caused by frame delay on some systems).This is really useful.
I wasn't under the impression that I was experiencing that specific problem too often before, but I actually do now, and that option works well.
Are there any drawbacks to having it ON all the time? (combined with w/ Portaudio also)
- New option -[no]autostretch: Make auto stretching feature optional. Default is enabled, so GM will apply the scaling mode (fractional or integer) that best fits the situation.Convenient! but are you sure you want this ON by default? I can already picture the long line of users complaining their output has strange borders or portions cut.
Integer is great and has its diehards, but I think it's a minority, most users have no idea what it is and wouldn't want it on anyway.
- New option -[no]autofilter: Make auto filter optional. Default is enabled, so GM will apply bilinear filtering when fractional scaling or an interlaced mode are used.Not sure how this works but is it bypassing 'filter' and 'prescale' when it's on ? (@ OSD ACCELERATED VIDEO OPTIONS)
I always use prescale for a sharper smoothing, but for some reason that didn't seem to work together.
However, turning 'autofilter' OFF fixed it and allowed me for the first time to control 'filter' and 'prescale' for all games directly from the mame.ini without needing specifics like vertical.ini and horizont.ini.
So maybe that wasn't the intent of this new setting, but it fixes an ages-old MAME annoyance! :applaud:
Note: dunno if it's a good idea to leave it ON by default, although yeah filtered is the MAME's default so that would be understandable.
- [Windows] Implement asynchronous rendering through native D3D9ex api (replace for old multithreaded -triplebuffer). This mode is selected automatically by -autosync. You can force it manually with -waitvsync -nosyncrefresh.Congratulation for finding a working replacement! it is however visibly less smooth than the old triplebuffer, trading what was tolerable micro-stutter for brutal hiccups.
I don't know if there's a way to make that smoother but as it is for actually playing games like Raiden DX of Xexex at normal speeds on a non-flexible Hz setup I'd still recommend 0.227, sorry I can't sugar-coat it.
PS: Just another recommendation to add, on that topic if you don't want users to see asynchronous too much you should really begin to consider pushing the default sync_refresh_tolerance to 3, so that games get syncrefreshed to 105% max. iirc that covers down to 57Hz games like the Midway seattle.
IF however someone has his desktop set to '59Hz' mode (lots of ppl don't suspect they do) then that'd bring the limit too far down, in which case to avoid 'accidents' a default value like 2.771 is safer, still covering down to Sega system18 even when desktop is really @60.
(I think it's precisely 2.770001 but heh)
Yeah it's mostly useless but for those who like to see that 1% difference, it at the very least cuts the tedium of having to switch manually from graphics control panel or windows. If it's the only other mode they can switch to, they can at least make it auto.
WARNING: you may not want to try that if you are using the current AMD Software, as this will set your default desktop mode to 59.94Hz, and today AMD don't provide direct desktop resolution controls, instead delegating to Windows, which - as you can guess - is actually too dumb to do the job properly...and so your desktop will be stuck @59.94Hz. So far I haven't found a way to bring back 60Hz.
EDIT: fixed! you can use VMMaker to wipe out that mode, read next page where Calamity explains.
Last-but-not-least: 'allow_hw_refresh' with a lcd_range set to 50-75 (tho 53-62 would do just fine) works well with my ViewSonic VX3211-mh and Belinea 2080 S2, using the latest AMD drivers on Vega 56.
Had a bizarre behaviour or two, like Xexex runnning 200% until I activated frame_delay, and apparently it's not able to force 60+ or so modes on the Belinea, but I don't remember if that one actually does support over-60 modes with Emudrivers or not, I'd have to check again with a different setup later. Or maybe it's because modern drivers don't come with native 1600x1200 modes but instead timings adapted from 1920x1200.
Post by: Calamity on June 21, 2021, 02:18:22 pm
I can confirm that this implementation DOES show worse stutter on cases where the refresh is too close (e.g. 59.63 vs 60.00), but it's not the case with higher refresh differences (e.g. 55 vs 60). So I thought it wouldn't matter because in those cases -syncrefresh would be preferable anyway.
So maybe it depends on the hardware/driver version, I don't know.
Post by: schmerzkaufen on June 21, 2021, 03:49:50 pm
Double-checked both 227sr1 and 232 settings too of course.
Well I don't understand what's happening since now the roles have been reversed; 232's asynchronous is much smoother now, and 227sr1 triplebuffer has caught the hiccups.
:dunno
I will have to look further into this later, and test on different rigs, to see if I can reproduce and find what's disrupting.
EDIT: so something that actually happened and the only hint I have for now, is that since I've tried allow_hw_refresh on the default lcd range then turned it off for testing async, my Radeon default display desktop mode had auto-set itself to 59.94Hz, and been stuck with it since, like hot glue, the desktop couldn't go back to 60 no matter what I've tried, in radeon soft, windows or intel setting.
Somehow I think this is when the 'shift' happened, and the behaviour of asynchronous and triplebuffer were affected.
(Yeah, no direct way to remove that in the current Radeon software version, unlike some time ago when we could select a custom mode as the desktop's default. AMD just like nVidia, or Intel or even Microsoft for what I know, keep doing that same stupid 'magnet 59Hz' mode mistake, like, the same over an over again since as far as I can remember, 20 years ago it was the same crap, only randomly working fine again for short periods in random revisions, then messed up again, and over again, and their bosses should be spanked till their skins peel off for that sin * sigh *)
EDIT: so it is apparently impossible these days to set the Radeon desktop default mode by oneself, back in the good old days there was ATI Tray Tools, which was the most handy little app to tell who's boss.
Is there any equivalent these days? ArcadeOSD won't even see the custom modes I've set in the Radeon software, the commercial SwitchRes is shareware...
Guess i'll have to erase 59Hz with CRU if there's nothing else.
EDIT: not even CRU lets me change it, it's clearly a bug, and a word of warning then, as though it's not Groovy that created it, it definitely triggered when I used allow_hw_refresh.
The official AMD drivers with that control panel software, aren't as convenient and controllable as some older versions, or Emudrivers.
Post by: Torkyo on June 21, 2021, 05:59:46 pm
thanks!
Post by: totozero on June 22, 2021, 04:46:38 am
I'm a bit confused with these 2 options :
Quote
- New option -[no]syncaudio: Make audio synchronization (resampling) optional. Default is enabled. Disable to avoid sound wobble with erratic emulation speeds (like that caused by frame delay on some systems).
Is the resampling needed in case you output a game to its native frequency ? Should I leave it off or on with an arcade monitor ?
Quote
- New option -[no]autofilter: Make auto filter optional. Default is enabled, so GM will apply bilinear filtering when fractional scaling or an interlaced mode are used.
I almost dropped my coffee cup when I saw bilinear filering. Wait, what ? Has it been always applied on horizontal fractional scaling and you added the choice to disable it, or is it a new feature !?
Interlaced I get it but with progressive what's the purpose besides adding some butter on the screen ?
Again thanks for the hard work
Post by: Calamity on June 22, 2021, 04:56:00 am
The idea is that now you can control all the stuff that GM sets automatically, instead of having to do ini overrides, with these options:
-autosync
-autostretch
-autofilter
And optionally, use -syncaudio to control audio synchronization associated to -syncrefresh, that previously was always on. This has been a long time request, now it's here. If the target refresh is matched, audio synchronization is probably not required in most cases, since the tiny mismatch (there will always be one) won't probably be audible.
With regards to -autofilter, this filtering was forced on GM 227 (pre SR2), then it was dropped completely, then I've recovered it but made it optional. Super resolutions won't be filtered because they're treated as integer scaling.
Post by: schmerzkaufen on June 22, 2021, 05:28:36 am
GroovyMAME's SR and my monitor's built-in software, as well as most games I have, aren't mistaken as they really see 59.94
I'm still looking for a way to fix that but it seems I will have to uninstall the AMD drivers, and either re-install and then don't try allow_hw_refresh again until I find a way to bring back true 60Hz, or install an older version of Catalyst which features the old-fashioned resolution controls.
EDIT: wrote a warning in my previous post.
EDIT: note that full use (allow_hw_refresh + lcd_range) is not affected of course, this way all required modes are picked and effectivly matching the games as they should.
The issue really happened when using allow_hw_refresh alone without setting LCD range, making it seek modes within the narrow 59.94~60Hz available, and for unknown absurd reasons Radeon decided that 59.94 should be the default desktop refresh now, and if I had complaints I needed to talk to Windows...but the latter of course denied the issue like "what are you talking about? me, Im seeing 60Hz period")
Post by: Calamity on June 22, 2021, 06:30:56 am
If this mode override was created by the -allow_hw_refresh option, then it should be simple to remove it. Launch vmmaker (it doesn't matter if you're using official drivers), settings->video card->delete all modes from driver.
You may need to restart Windows.
Post by: schmerzkaufen on June 22, 2021, 06:39:52 am
Didn't have to restart Windows btw.
PS: gonna keep an eye on it, see if it ever happens again I'll notify about it.
Post by: Calamity on June 22, 2021, 06:44:34 am
Post by: schmerzkaufen on June 22, 2021, 07:04:23 am
But seriously, AMD handing such elmementaery controls to Windows, what sort of messed up age do we live in? tsk tsk...
(I've missed which version of Catalist the switch from the previous software-UI was changed to the current terrible 'radeon software', but this is silly. Until recently even Intel somehow abandoned their own iGPUs simplistic control panel, handing all controls to Windows. but that didn't last too long and they've brought back their new in-house control panel - which is honestly better than the old and even features custom resolutions - So yeah even Intel for the sake of their puny iGPUs, were smarter than AMD here. Welp.)
Post by: Calamity on June 22, 2021, 07:13:29 am
Post by: schmerzkaufen on June 22, 2021, 07:23:01 am
Which is exactly what I did until about last year with both the Vega 56 and RX 570.
But with today's UI nope. They'll tell you to 'go to windows display settings and make sure its set to the resolution and refresh you want'.
And you can bet that doesn't work right, it never really did even long ago. On my W8 laptop it's the same story, 59Hz or 59p mode is like a magnet, all software and OS these days are permanently waiting for an opportunity to set the desktop to that mode, as long as it's a 'HDTV' resolution they're detecting.
Except on W8 I still somehow have the power to force back 60.
In any case, handing elementary, essential controls to Windows, was never a good idea, never will be...
Post by: schmerzkaufen on June 22, 2021, 07:41:55 am
I dunno if it's related to my previous issue and action, but after that I went back to full allow_hw_refresh + lcd_range 50-75, and tested the same games I usually do, then I've noticed Xexex (JAA) was now running @ 59.25Hz or something. ???
I mean from MAME's POV, which for some reason wasn't reading the correct original refresh for that game anymore.
Had a hunch, went and erased xexexj.cfg
-> that fixed it.
EDIT: so, going back to testing the asynchronous mode, I am again getting variable results.
Note that in any case SR(0) picks 59.939 instead of 60, even after I've cleaned up and have the desktop back to proper 60.
I still don't know the reason for this, but in short I have experienced the asynchronous mode in two flavours;
1. super choppy
2. super smooth (possibly smoother than even what the old triplebuffer was able to produce)
¯\(°_o)/¯
EDIT: and in fact async mode's inconsistent results, may or may not, be related to that strange 59Hz obsession SR seems to have, I dunno.
If I ever find what affects async's smoothness I'll let this thread know, of course, but for now I have no clue.
EDIT: going back to 227sr1, its triplebuffer mode suffers the same 59.939 obsession.
Checking Radeon after rebooting Windows: it's indeed back to 59.9394, which wasn't appearing a minute ago.
EDIT: last update for now because it's a bit draining, but yeah no matter what since the first occurence, the 59.939 mode is the only one Groovy 227sr1 and 232 want to see as being the desktop's, even after wiping out modes with VMmaker, it comes back.
Even, in 'normal' mode with default settings, syncrefreshed games like async/triplebuffered, are hooked to SR(0) 59.939 like a 60 desktop mode never existed.
And restarting Windows after playing either Groovy, shows that the desktop is actually back to 59.939.
:dizzy:
EDIT: Fresh AMD install after proper cleanup with their utility. Fresh GM232 install. Fresh log. At that instant the desktop mode is @60, no attempt to use allow_hw_refresh has been made since the cleanup and resintall of everything.
Looks like there is no 'pure' 60 mode available. Yet the first time I've used 232 I could swear it was seeing the desktop at 60, and it's after trying things with allow_hw_refresh that 60 was gone...
Post by: Calamity on June 22, 2021, 10:06:35 am
AMD ADL timing "1920x1080_60 67.431000KHz 59.938667Hz" 148.350000 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
That's the mode the driver is reporting. Maybe it's grabbed directly from your monitor's EDID, can't say.
The integer refresh that Windows reports is misleading. The exact timing is very unlikely going to be exact 60 Hz regardless of what Windows says.
Post by: schmerzkaufen on June 22, 2021, 10:10:32 am
The integer 60 is indeed false, and reported by both AMD software and Windows.
I don't understand either, I have reset my monitor as well. Maybe I'll try that again. (EDIT: nope that did nothing)
PS: also tested 232 on my laptop (W8.1, nvidia 880m + iGPU 'optimus' -> no issues)
Maybe the current AMD driver is garbage. I'm going to try an older one, same as yours maybe.
Post by: Calamity on June 22, 2021, 10:22:31 am
Post by: schmerzkaufen on June 22, 2021, 10:24:38 am
But I have to fix that lack of actual 60Hz before looking into that again. I'm downloading Adrenalin 18.5.1, we'll see.
EDIT: welp, same story with 18.5.1 :-\
Could allow_hw_refresh have edited my monitor's EDID somehow ? I'll see if I can manually re-install its drivers.
EDIT: nope that did nothing.
HOWEVER, since I have now the old Adrenalin UI, I am getting back direct control of desktop resolution via the custom ones, which unlike the in newer AMD software's, can apply directly to the desktop.
And the result is as seen in the new attached log.
We have a partial answer, the AMD software likely cannot find an integer 60Hz on my setup by itself, not until I actually force one using a custom desktop mode, which is impossible in the newer/current AMD software.
Post by: Calamity on June 22, 2021, 10:56:29 am
Could allow_hw_refresh have edited my monitor's EDID somehow ?
No, that's absolutely impossible. Frankly, I think you never had an exact 60 Hz mode. And it doesn't matter at all.
Post by: Calamity on June 22, 2021, 11:07:08 am
We have a partial answer, the AMD software likely cannot find an integer 60Hz on my setup by itself, not until I actually force one using a custom desktop mode, which is impossible in the newer/current AMD software.
Well that makes sense, when you've seen 60 Hz it's probably because you were using an override. If you check the new log, it shows a pixelclock of 148.50, vs your previous 148.35 that likely comes from your monitor, in an attempt to match NTSC refresh rather than 60 Hz.
Post by: schmerzkaufen on June 22, 2021, 11:10:42 am
Frankly, I think you never had an exact 60 Hz mode. And it doesn't matter at all.No I definitely did and have experienced enough applications where a difference between 59.94 and 60.00 was crucial, as the former would introduce stuttering.
Really until maybe a day or two at the furthest I can swear sevral games and emus were reporting proper 60, but today I've seen that change, so something definitely happened.
AMD, Crosoft and whomever always attempted to introduce the argument that it doesn't matter, but oh boy how wrong they are.
Also I see plenty of reasons why this is a problem with MAME games assuming we really want them to match to an actual clean 60Hz mode for those that are concerned.
Until I find a method to force a real integer 60 using the current Adrenalin, I'm staying away from it (which is kind of a bummer since I don't know if that affects the actual PC games performance)
Well that makes sense, when you've seen 60 Hz it's probably because you were using an override. If you check the new log, it shows a pixelclock of 148.50, vs your previous 148.35 that likely comes from your monitor, in an attempt to match NTSC refresh rather than 60 Hz.I wasn't using an override since I couldn't do that with the current AMD soft anyway, again until recently all was fine and actual 60.
Maybe a sneaky update introduced something disruptive, I dunno.
PS: an that's another argument in favor of fixed, dedicated setups for emulation.
PPS: I like that nothing can fool SR though, while everything else made by the big names fails to see reality.
Post by: schmerzkaufen on June 22, 2021, 02:14:06 pm
I can hardly see any difference at all in motion quality, between the old triplebuffer and the new asynchronous mode.
(can't say if they're identical lag-wise though, d3d9ex's triplebuffer 'cost' was supposedly 2 frames but that was never confirmed with hard testing figures, so anyway if asynchronous is the same then all that remains is to play enough to compare and confirm they're at least as responsive)
Any difference in 'smoothness' I've experienced before, the brutal hiccups while comparing triplebuffer and asynchronous, though I can't explain why those happened, must have been because of what I went through with the drivers issue, or mis-configuration.
Note I've crashed 227sr1 a couple of times. Dunno why.
Conclusion for now it's the Most Perfect GroovyMAME and MAME ever been period...MK.II :applaud:
(of course saying that within context I'm focused on flat panels use and Windows now, but I guess most CRT users must think something equivalent for what concerns the primary dimension of Groovy, and the progress of its Linux alter-ego)
Post by: b4nd1t0 on June 23, 2021, 06:13:48 am
Post by: schmerzkaufen on June 23, 2021, 03:35:50 pm
I have a 1920 wide panel, wouldn't I save a bit of GPU time for frame_delay if I was using that instead ? or even less ? or no super width at all ?
Or nope it's not directly related to the video output and I too, need it to be 2560 period ?
Post by: wolfsoft on June 25, 2021, 03:28:12 pm
and got a Exception access_violation when running it.
I tried gmame 0.227 and it works.
Any hint for me?
See attached error message.
Many thanks and GO ON! groovymame rules!
Post by: fred92 on June 26, 2021, 01:11:47 pm
i have compiled my own no nag version here (http://forum.arcadecontrols.com/index.php/topic,165277.0.html) if interrested.
Post by: wolfsoft on June 27, 2021, 05:36:19 pm
thanks for your effords but got the same error with your version.
I tried a fresh new install of windows 10 and used the "newer" Emudriver based on Adrenalin 18.5.1
(CRT Emudriver & CRT Tools 2.0 beta 15 (Adrenalin 18.5.1 for GCN cards) for Windows 10 64-bits)
instead of
CRT Emudriver & CRT Tools 2.0 beta 15 (Catalyst 12.6) for Windows 7810 64-bits
And with the emudriver for Adrenaline 18.5.1 groovymame 0.223b is working :-)
Post by: Calamity on July 04, 2021, 05:56:29 am
Post by: Calamity on July 04, 2021, 06:08:27 am
Probably stupid question but: was there ever a need for keeping super_width at 2560 even if you're a fixed matrix / flat panel user like me ?
I have a 1920 wide panel, wouldn't I save a bit of GPU time for frame_delay if I was using that instead ? or even less ? or no super width at all ?
Or nope it's not directly related to the video output and I too, need it to be 2560 period ?
Setting super_width at 1920 on your setup would force horizontal scaling as fractional for all games. You might see a small picture degradation in cases where integer scaling would be picked otherwise, just maybe not noticeable. I don't know whether this would have an impact on GPU load, I'd say it won't.
Post by: benimaru7 on July 04, 2021, 06:22:39 am
I’m not sure if you could check on your setup, but running a Neo Geo game in AES console mode such as Fatal Fury 2 results in broken audio, well it plays but like it’s been very downsampled! Running the same game in MVS results in crystal clear audio. I’ll pull a log for you, but just wanted to check if you had the same issue?
Post by: schmerzkaufen on July 04, 2021, 06:51:39 am
Post by: Calamity on July 04, 2021, 07:26:16 am
So after finally making sure I could compare in ideal and identical conditions, I can now state the following;
I can hardly see any difference at all in motion quality, between the old triplebuffer and the new asynchronous mode.
(can't say if they're identical lag-wise though, d3d9ex's triplebuffer 'cost' was supposedly 2 frames but that was never confirmed with hard testing figures, so anyway if asynchronous is the same then all that remains is to play enough to compare and confirm they're at least as responsive)
I can say I did saw differences when the refresh gap is small enough but since this is the situation where you'd force syncrefresh anyway I don't think it's a concern. The new implementation is definitely more robust and less hacky if that matters.
With regards to the latency, we have the same problem as with triplebuffer where GILT will fail the test after a second or two due to uneven framerate. But I can see that the latency is definitely 0.5-1.5 frames (7-25 ms) by the readings I get before it stops, so the value fluctuates within that range fast as the 2 independent frame rates interact. Which makes sense when compared to the figures we get with syncrefresh/frame delay.
Post by: schmerzkaufen on July 04, 2021, 10:45:28 am
You have really saved that feature which - if minor and not related to Groovy's primary purpose - is a convenient and unique lifesaver for a number of users who will be glad it's still there when they need it. :notworthy:
* Personal choice already redundantly stated but; on a system where I cannot benefit from dynamic resolutions, I usually set sync_refresh_tolerance to 3.0 so it limits sync'd acceleraction to 105%.
(or 2.771 if desktop is in "59Hz" a.k.a "59p" mode. Man if only we had a 1-click button for like "force true 60.00Hz desktop showing both your stupid gfx card drivers and Windows who's boss", i have really experienced many times that it's not a given. btw I think the last Adrenalin version to let the user set a custom mode as desktop was 19.10.1)
Post by: psakhis on July 08, 2021, 03:34:45 pm
These changes i have noticed with new switchres version:
- "noues" (abbreviation for unevenstretch 0) not working anymore BUT isn't necessary with new switchres version, now all neogeo games (304x224, 288x224, etc.) are centered perfectly!!
- "ror" argument isn't necessary now for non-rotate vertical games on horizontal monitor, but "rol" argument is needed for rotate vertical games on horizontal monitor
Very happy with switchres 2.0
:notworthy:
Post by: Calamity on July 31, 2021, 04:10:50 am
Note: Due to this modification (https://github.com/mamedev/mame/pull/8209) to baseline MAME, now -keepaspect works slightly different with super resolutions (-unevenstretchx). This change should be transparent to GM users as long as -autostretch is on.
If you notice any regression (0.233 vs 0.234) regarding aspect ratio handling please report.
Post by: RobeeJ on August 01, 2021, 10:45:58 am
Post by: R-Typer on August 01, 2021, 10:51:57 am
Post by: Endprodukt on August 07, 2021, 04:04:48 am
It will hang itself on the bootscreen (initialization), then switching the DIP for video to low and back to medium and resetting will make the games boot. Kinda weird.
Post by: Sociopathos on August 15, 2021, 06:13:10 pm
Post by: feltz on September 10, 2021, 04:44:36 pm
Running GM 0.235 on Windows 10 x64
Caught unhandled 25options_warning_exception exception: Illegal boolean value for keepaspect: "48"; reverting to 1
Post by: DaddyLongLegs on September 22, 2021, 11:48:05 am
I also noticed CORE SWITCHRES OPTIONS was removed from the mame.ini. I still have it in my old ini. Should I keep it there or remove it? Was this feature removed from groovymame or something?
Post by: Calamity on September 22, 2021, 01:40:36 pm
Post by: DaddyLongLegs on September 22, 2021, 08:09:31 pm
It's the 32-bit build the one that's gone, that's why now the exe is no longer named mame64.exe but just mame.exe, it's still 64 bits. The correct .ini is the one provided with my package, take that one and just modify the options that you need.
Thank you as always.
I am using a Wells Gardner standard res monitor, k7x series with Atom-15 and crtemudriver.
In the groovymame's mame.ini, what is the difference between monitor generic_15 and monitor k7000?
Which one am I better off using? Does groovymame actually do something different between the two options?
Post by: Calamity on September 30, 2021, 04:17:07 am
What's new in Switchres 2.002c (September 2021):
- [Windows] Fixed bug that caused games using interlaced modes run at dobble speed.
Post by: B2K24 on September 30, 2021, 12:22:09 pm
Post by: R-Typer on September 30, 2021, 12:28:13 pm
Post by: tronads on October 01, 2021, 10:34:45 am
Is the by any chance an Arcade only build, or will anyone be creating one ?
Post by: DaddyLongLegs on October 06, 2021, 09:57:47 am
Should I remove that line? Is it depreciated or something?
edit: never mind. it looks like it was moved from "CORE PERFORMANCE OPTION" to "OSD FULL SCREEN OPTIONS" for whatever reason.
Post by: DaddyLongLegs on October 06, 2021, 12:39:37 pm
So I went to play some Carnevil, and it didn't load (it worked just fine in 0.235 a week earlier). All I am getting is a black screen and the computer locks up; I can't get out of anything.
I noticed other games were not giving me issues, and the only thing I could think of was that Carnevil is a higher-resolution game than most. So I tried a few other high res games like Golden Tee Fore 2003, and those made GroovyMAME lock up, too!
I don't know what made me do it, but I put ini files in MAME/ini/presets; one for carnevil.ini and one for gtfore03.ini. For both of them, I have this inside:
Code: [Select]
syncrefresh 0
waitvsync 1And that completely fixes the issue! Also, it ONLY works if that code is in the individual INI files for each hi res game. If I put that code in mame.ini, it still crashes on hi-res ROMs.
Do you have any clue as to what's going on? Why is it only happening with groovymame 0.236? I am pretty sure I did the upgrade process correctly...I updated my ROMs from 0.235 to 0.236, and compared the values in the 0.235 mame.ini with the 0.236 mame.ini.
What is going on and why is that odd solution working?
If it helps solve the mystery, I have attached my mame.ini that I am currently using for 0.236. (it's named .txt because that's all I am allowed to upload)
Post by: DaddyLongLegs on October 07, 2021, 09:30:39 am
Here is my updated MAME.INI which did not make any difference.
Post by: Calamity on October 07, 2021, 11:43:28 am
I am also now getting very worbly/warped audio from games as basic as VS Super Mario Bros when I never had that issue before with 0.235. I have no clue what could be causing it.
Here is my updated MAME.INI which did not make any difference.
Disable syncaudio in mame.ini.
Post by: Calamity on October 07, 2021, 11:45:13 am
So I went to play some Carnevil, and it didn't load (it worked just fine in 0.235 a week earlier). All I am getting is a black screen and the computer locks up; I can't get out of anything.
Thanks for reporting. This seems to have been introduced by the most recent "fix" for interlaced modes odd speed. I'll look into it. It happens when a game switches from interlace to progressive mode. To workaround it you may disable changeres in mame.ini.
Post by: DaddyLongLegs on October 07, 2021, 02:09:13 pm
So I went to play some Carnevil, and it didn't load (it worked just fine in 0.235 a week earlier). All I am getting is a black screen and the computer locks up; I can't get out of anything.
Thanks for reporting. This seems to have been introduced by the most recent "fix" for interlaced modes odd speed. I'll look into it. It happens when a game switches from interlace to progressive mode. To workaround it you may disable changeres in mame.ini.
Wow, I am just happy to hear I contributed for once! And also that it wasn't something I did :)
Thank you as always for everything!
edit: Should I just leave changeres to 0 permanently? Are there really any MAME games that change resolution during the game?
Post by: DaddyLongLegs on October 07, 2021, 02:14:56 pm
I am also now getting very worbly/warped audio from games as basic as VS Super Mario Bros when I never had that issue before with 0.235. I have no clue what could be causing it.
Here is my updated MAME.INI which did not make any difference.
Disable syncaudio in mame.ini.
Thanks! I'll give that a shot.
Any reason I didn't have to change that in the previous version?
Edit: Unfortunately I tried it and now instead of "worbly" warped audio, the music literally skips entire notes. Again this is with a very basic game like VS Super Mario Bros and I did not experience this with 0.234. Any ideas?
Post by: RobeeJ on October 08, 2021, 04:23:34 am
Post by: schmerzkaufen on October 08, 2021, 06:56:24 am
Using a Ryzen 5600X now I can push frame_delay even further than with the 9700K, I can set 8~9 stable even on relatively heavy games like the Cave cv1k, when before I was limited to ~7 with the Intel.
Even if the GPU performance matters quite a lot for flat panel users who don't own VRR hardware, the CPU's raw thread performance definitely plays a major role too.
Note as I've already mentioned before: the little 'bug' that makes a vsync_offset value set in the UI for game 'X', carry over to a different selected 'Y' game for which you had not set anything yet, is still there.
Also, a previously set vsync_offset value might be erased if you do a change in intermediary bios or device pre-game setting menus (for instance if you select a different bios for a neo-geo game you had played previously)
But those are very minor annoyances, probably specific to UI, users just need to remind.
Oh and still about saving sliders and cv1k : tweakers need to know that 'blitter delay' must be turned on in 'machine configuration' then reset the game, before even starting to adjust blitter and CPU from the 'sliders' menu.
And yes all the settings do save in the cfg files, I've just checked with 0.236
Anyway, thanks as always nice to see Groovy still kicking. :cheers:
Post by: DaddyLongLegs on October 09, 2021, 02:07:00 pm
Have you checked your CPU usage? Maybe that's actually your root cause of audio problems. I've had this in the past when I've been using a less-than-optimal graphics library (one that isn't using hardware acceleration).
So the CPU is a Core i7 930 running at 4ghz (it's overclocked). When I look in task manager and I have GroovyMAME running, it only shows about 12% of the CPU is being utilized, even when running a crazy intensive game like Marvel Vs Capcom 2 that runs at like 8 fps.
I am taking it my CPU should be showing something more like 100% utilization when GroovyMAME is running?
Also what's the graphics library and how do I change it?
Post by: RobeeJ on October 10, 2021, 04:38:23 am
So the CPU is a Core i7 930 running at 4ghz (it's overclocked). When I look in task manager and I have GroovyMAME running, it only shows about 12% of the CPU is being utilized, even when running a crazy intensive game like Marvel Vs Capcom 2 that runs at like 8 fps.
I am taking it my CPU should be showing something more like 100% utilization when GroovyMAME is running?
Also what's the graphics library and how do I change it?
I think if your CPU is 12% then everything is fine and it's not that. If it was closer to 50% or more than that could be an issue as I've found these issues happen for me (on Arch Linux at least) around there. But it's also odd that you have a game struggling at 8fps and you aren't CPU limited. 🤔
Post by: donluca on October 10, 2021, 07:02:57 am
So the CPU is a Core i7 930 running at 4ghz (it's overclocked). When I look in task manager and I have GroovyMAME running, it only shows about 12% of the CPU is being utilized, even when running a crazy intensive game like Marvel Vs Capcom 2 that runs at like 8 fps.
This is the consequence of the incredibly irritating parroting that has been happening in the last 2 years: your CPU has 8 threads and MAME IS STILL A SINGLE THREADED PROCESS.
100% / 8 threads = 12.5% which is what you're seeing, a single thread capped at 100%.
Sure, there might be some minor stuff which is offloaded to other cores, but the bulk of MAME IS SINGLE THREADED.
Hopefully people will stop this idiocy of telling people that you get benefit from multicore processors in MAME.
/vent
EDIT: to add something more constructive, the new Ryzen Zen 3 processors have amazing single threaded performance, if you're looking for an upgrade to your current setup look at the passmark result on its website: they have multi core and singlethreaded performance benchmark results which will help you choosing the best CPU.
Post by: makya on October 11, 2021, 11:26:39 am
EDIT: nevermind, I found it here -> https://gitlab.com/groovyarcade/support/-/wikis/3-Post-Installation-and-Maintenance/3.9-Configure-System-Wide-Switchres
Post by: DaddyLongLegs on October 11, 2021, 02:16:05 pm
So the CPU is a Core i7 930 running at 4ghz (it's overclocked). When I look in task manager and I have GroovyMAME running, it only shows about 12% of the CPU is being utilized, even when running a crazy intensive game like Marvel Vs Capcom 2 that runs at like 8 fps.
This is the consequence of the incredibly irritating parroting that has been happening in the last 2 years: your CPU has 8 threads and MAME IS STILL A SINGLE THREADED PROCESS.
100% / 8 threads = 12.5% which is what you're seeing, a single thread capped at 100%.
Sure, there might be some minor stuff which is offloaded to other cores, but the bulk of MAME IS SINGLE THREADED.
Hopefully people will stop this idiocy of telling people that you get benefit from multicore processors in MAME.
/vent
EDIT: to add something more constructive, the new Ryzen Zen 3 processors have amazing single threaded performance, if you're looking for an upgrade to your current setup look at the passmark result on its website: they have multi core and singlethreaded performance benchmark results which will help you choosing the best CPU.
Thank you so much.
It would cost me a pretty penny to upgrade. Would I see a game like Marvel vs Capcom 2 run at full speed in MAME if I went to a Ryzen Zen 3?
I would also prefer to run games like House of the Dead 2 in MAME because DEMul is really old and I have all sorts of weird issues with it. Like for one, after about 20 minutes of playing House of the Dead 2, the game exists full screen mode and becomes a Window. So weird.
Post by: Substring on October 12, 2021, 03:38:11 am
Post by: RobeeJ on October 12, 2021, 04:44:19 am
Would I see a game like Marvel vs Capcom 2 run at full speed in MAME if I went to a Ryzen Zen 3?
Before you think about updating your CPU, try running MAME with the verbose logging option and see what video/audio driver options you have and which ones it is autoselecting. You may find that switching them in the mame.ini will give you a huge reduction in CPU.
Post by: faxesystem on October 17, 2021, 12:34:54 pm
Post by: Calamity on October 23, 2021, 07:17:07 am
When trying to change options and saving them, I get the following error. "Caught unhandled 25options warning exception exception: illegal boolean value for keepaspect "48";reverting to 1" Also found other threads that mentioned this problem but no solution so far. What can be done so that I can save the config without Groovymame crashing and showing the error message? Thank you.
Does this only happen with GM?
Post by: italospain on October 26, 2021, 12:16:43 pm
When trying to change options and saving them, I get the following error. "Caught unhandled 25options warning exception exception: illegal boolean value for keepaspect "48";reverting to 1" Also found other threads that mentioned this problem but no solution so far. What can be done so that I can save the config without Groovymame crashing and showing the error message? Thank you.
same here
yes only GM (MAME Vanilla works)
Post by: peterson65 on October 27, 2021, 08:42:58 am
Post by: Calamity on October 27, 2021, 10:13:38 am
so what are the best ini settings to stop screen tearing on new switchres 2? tripplebuffer used to work great for me but not sure how to get it good now, didn't notice it until I ran rampage word tour and its looks bad? thanks
I get no tearing here.
Option -triplebuffer is gone. Instead, use -waitvsync -nosyncrefresh.
Post by: peterson65 on October 27, 2021, 10:40:07 am
so what are the best ini settings to stop screen tearing on new switchres 2? tripplebuffer used to work great for me but not sure how to get it good now, didn't notice it until I ran rampage word tour and its looks bad? thanks
I get no tearing here.
Option -triplebuffer is gone. Instead, use -waitvsync -nosyncrefresh.
thanks I will try that tonight after work. I recently redid my hard drive and started from scratch . ;) I have a copy of my mame.ini on a flash drive with me, I see the waitvsync but don't see nosyncrefresh? do I need to add it somewhere. thansk
Post by: Calamity on October 29, 2021, 03:46:41 am
What's new in Switchres 2.002d (October 2021)
- [Windows] Fix bug that caused interlaced modes to lock screen updates.
- Fix bug that caused an exception when saving configuration after doing changes from the ui.
- Make -vsync_offset slider setting not propagate between different games when launched from the ui.
Post by: Calamity on October 29, 2021, 03:49:18 am
Note as I've already mentioned before: the little 'bug' that makes a vsync_offset value set in the UI for game 'X', carry over to a different selected 'Y' game for which you had not set anything yet, is still there.
Also, a previously set vsync_offset value might be erased if you do a change in intermediary bios or device pre-game setting menus (for instance if you select a different bios for a neo-geo game you had played previously)
The first problem (vsync_offset carrying over to a different game) should be fixed now. The second (when selecting a different bios) I couldn't check it, so it might still exist.
Post by: Calamity on October 29, 2021, 03:51:18 am
thanks I will try that tonight after work. I recently redid my hard drive and started from scratch . ;) I have a copy of my mame.ini on a flash drive with me, I see the waitvsync but don't see nosyncrefresh? do I need to add it somewhere. thansk
command-line -nosyncrefresh equals syncrefresh 0 in mame.ini. Anyway you don't edit that in mame.ini but in an ini for the particular game you need.
Post by: italospain on October 29, 2021, 05:20:04 am
but the error saving the Configuration still pops up
greetings
Post by: Calamity on October 29, 2021, 05:55:03 am
thanks for the new version
but the error saving the Configuration still pops up
greetings
I swear it was working yesterday :dizzy:
By the way, this is a bug in baseline as far as I understand. GM just exposes it as it does automatic option setting.
Post by: R-Typer on October 29, 2021, 08:17:54 am
Post by: Calamity on October 29, 2021, 10:52:03 am
thanks for the new version
but the error saving the Configuration still pops up
greetings
Are you using Windows or Linux?
Post by: italospain on October 29, 2021, 02:53:20 pm
thanks for the new version
but the error saving the Configuration still pops up
greetings
Are you using Windows or Linux?
Windows 10
Post by: Calamity on October 29, 2021, 03:42:28 pm
thanks for the new version
but the error saving the Configuration still pops up
greetings
Are you using Windows or Linux?
Windows 10
There's a new release on github's site that should fix the problem, please check it.
Post by: italospain on October 30, 2021, 04:27:56 am
now it works :applaud:
thanks
Post by: schmerzkaufen on October 30, 2021, 11:18:32 am
Note as I've already mentioned before: the little 'bug' that makes a vsync_offset value set in the UI for game 'X', carry over to a different selected 'Y' game for which you had not set anything yet, is still there.
Also, a previously set vsync_offset value might be erased if you do a change in intermediary bios or device pre-game setting menus (for instance if you select a different bios for a neo-geo game you had played previously)
The first problem (vsync_offset carrying over to a different game) should be fixed now. The second (when selecting a different bios) I couldn't check it, so it might still exist.
To me both look fixed, congrats ! :cheers:
(EDIT: I've only tried the latest 2.002e)
Post by: opossumita on November 04, 2021, 07:08:24 am
Post by: PL1 on November 04, 2021, 12:39:00 pm
which romset do I have to use for GroovyMAME 0.237?You should use a 0.237 ROMset.
- The further apart the ROMset and MAME versions are, the more things have changed.
If you have trouble finding the latest version, some people start by finding a recent ROMset then download the corresponding version of MAME, MAMEUI, or GroovyMAME. :cheers:
Scott
Post by: opossumita on November 10, 2021, 10:17:13 am
Post by: schmerzkaufen on November 11, 2021, 02:51:09 am
Only the non-merged romset doesn't require additional roms (but is noticeably larger).
Then in regards to warnings, yes many games show those anyway even if they work.
There is a 'skip_warnings' option in the ui.ini, tho I have never used it personally so I don't know if it's enough to hide all warnings.
Post by: schmerzkaufen on November 14, 2021, 06:17:57 am
intoverscan
intscalex
intscaley
If so that kinda sucks because, well, integer scale settings can no longer apply for good by chosen settings anymore, nor be saved from the UI.
Post by: Calamity on November 14, 2021, 02:54:10 pm
Just to confirm if it's global or just me; the ini integer scaling options stopped working since they've added the feature to the UI, didn't they ?
intoverscan
intscalex
intscaley
They are working here, both from ini and command line. You may need to disable unevenstretch first since these options only work with integer scaling.
Post by: makya on November 15, 2021, 11:14:21 am
I believe there is a small issue with switchres not updating the modeline when its *almost* the same. I remember reading that you blocked updating when the modeline does not actually change, however when refresh does change it should update right?
The trick is the UI mentions the new refresh rate but when you hit F11 it shows something else than 100%, for example a stable 94% (~56Hz to 60 Hz with kram rom). It's confirmed for me in that I can see that my (Euro) TV has not updated (vertical amplitude remains the same when it should have changed).
Thanks
Post by: Calamity on November 15, 2021, 12:10:58 pm
Hi Calamity,
I believe there is a small issue with switchres not updating the modeline when its *almost* the same. I remember reading that you blocked updating when the modeline does not actually change, however when refresh does change it should update right?
The trick is the UI mentions the new refresh rate but when you hit F11 it shows something else than 100%, for example a stable 94% (~56Hz to 60 Hz with kram rom). It's confirmed for me in that I can see that my (Euro) TV has not updated (vertical amplitude remains the same when it should have changed).
Thanks
This shouldn't be the case, in fact I would have noticed it here. There must be something else going on.
Post by: schmerzkaufen on November 15, 2021, 01:18:15 pm
They are working here, both from ini and command line. You may need to disable unevenstretch first since these options only work with integer scaling.
How could I forget about that ? must be age already...ugh. :embarassed:
Anyway thanks! ^^
Post by: makya on November 15, 2021, 05:50:22 pm
This shouldn't be the case, in fact I would have noticed it here. There must be something else going on.
Well, you could probably not notice as long as your range allows for enough different resolutions. Otherwise it may be an issue with my HD4870?
Anyway I made new tests on a freshly installed GM (0.237). So as long as the resolution changes (tested vertical res. only though) everything works ok, otherwise I get stuck with the initial refresh rate.
For 0x244 I forced 58Hz as initial refresh rate, so we get 58/60.021 = 96.63% vs GM average speed 96.66%
The other ones have initial refresh at 55.838 Hz, then 55.838/60.021 = 93.03% vs GM av. speed 93.01%
Post by: Calamity on November 22, 2021, 03:11:18 am
Post by: makya on November 23, 2021, 04:02:29 pm
Thanks for looking into this. To me it looks like the switch in the middle (let's say modeline #2) never really happens.
In the working case this has no influence because the last switch is required (modeline #3 != modeline #2), and we end up with the correct res./refresh.
In the not working cases, the last switch does not happen either (because modeline #3 = modeline #2).
Well those are my assumptions, I may be wrong... :dunno
Post by: peterson65 on December 15, 2021, 03:39:20 pm
Post by: Calamity on December 28, 2021, 02:21:57 pm
What's new in Switchres 2.002f (December 2021)
- [Linux] First release ever to support mode switching on KMS. It needs Substring's patched kernel and SDL2 (>=2.0.16) available on GroovyArcade's repository.
This release means a major breakthrough, allowing for the first time dynamic mode switching on KMS (i.e. without Xorg). This has been the result of a long continued work that started with Switchres 2.0 and its integration in GroovyMAME. Credits to Doozer for his work on the drmkms backend, and specially to Substring who developed to method to add modes dynamically so the magic can actually happen.
Note: due to real life commitments we're currently one release behind MAMEdev, hopefully we'll catch up in the following weeks.
Post by: donluca on December 28, 2021, 03:42:57 pm
GroovyMAME 0.238 is out!
What's new in Switchres 2.002f (December 2021)
- [Linux] First release ever to support mode switching on KMS. It needs Substring's patched kernel and SDL2 (>=2.0.16) available on GroovyArcade's repository.
Holy ---steaming pile of meadow muffin--- this is actually huge. Well done to all the people involved.
I wonder if in the future we could have GroovyMAME running on ARM platforms as well. There are some pretty capable CPUs out there.
EDIT: giving out a bit of prospective: I've been working on running a full blown Linux distro on the PSClassic, with hardware acceleration and all the bells and whistles, and I was surprised at the power of its quad-core ARM CPU, especially since it is the lowest version of that ARM family. And the GPU is a bomb, but that wouldn't help much in MAME.
Post by: Substring on December 29, 2021, 11:55:41 am
Post by: donluca on December 30, 2021, 08:37:16 am
Post by: Substring on December 30, 2021, 08:47:33 am
Post by: donluca on December 30, 2021, 06:10:28 pm
I don't know about the PSClassic hacks, but remember you need a patched kernel + patched SDL2 ...
I won't go too deep into this, but it's a complete mess.
I still somehow managed to get any Linux distro working on it, I have the kernel's source and had to recompile it with different options.
It works, but it is hindered by the binary blobs, mainly the PowerVR GPU driver which is stuck with a certain version of MESA and a bunch of other libraries since it has static links to them and won't work with any other library.
Weston is the only compositor who can properly load the driver and activate the HDMI output.
That is, if you want GPU hardware acceleration.
Otherwise you can use X.org with the Gallium drivers which are software based.
Which means you're stuck with Wayland, there are no X drivers, which in theory is not a bad thing, but the actual state of Wayland is... well, not that good, even on Debian which has fully embraced it.
Post by: eewoke on December 31, 2021, 06:18:50 am
Post by: schmerzkaufen on January 08, 2022, 05:22:35 am
Note: due to real life commitments we're currently one release behind MAMEdev, hopefully we'll catch up in the following weeks.Thank for the new build. Will we see a 0.239 though ? for the MAME side of things that would be absolutely excellent. :notworthy:
Post by: Substring on January 08, 2022, 02:11:03 pm
Post by: schmerzkaufen on January 08, 2022, 03:18:39 pm
If several MAME updates get skipped by Groovy after that I don't mind personally, but it'd be a shame to miss 0.239 yeah. :(
Post by: Substring on January 09, 2022, 10:31:46 am
Post by: schmerzkaufen on January 10, 2022, 09:54:01 am
Post by: Recapnation on January 11, 2022, 06:59:29 pm
also last build and romset to feature some games before their planned removal in 0.240 for probably what'll be a long, long time.
Which games aside of Akai Katana?
Post by: totozero on January 12, 2022, 03:25:13 am
DoDonPachi SaiDaiOuJou ?
exA "politely" asked the mame team to remove support, sending them a formal letter AFAIK.
https://www.reddit.com/r/shmupchumps/comments/rt3klb/akai_katana_and_ddp_saidaioujou_removed_from_mame/ (https://www.reddit.com/r/shmupchumps/comments/rt3klb/akai_katana_and_ddp_saidaioujou_removed_from_mame/)
Post by: Calamity on January 12, 2022, 04:32:20 am
What's new in Switchres 2.002g (January 2022)
- New option -switchres_ini. If enabled, GroovyMAME will try to parse switchres.ini and use it for its configuration. Options priorities, in increasing order: mame.ini < switchres.ini < display#.ini < orientation.ini < ..... < command line.
- [Linux] Improved support for mode switching on KMS.
- [Linux] Fixes toggling fullscreen on/off (still imperfect but functional).
NOTE: Windows users will probably want to keep new option -switchres_ini disabled (default), and just use mame.ini for configuration, as usual. Linux users, on the other hand, may now decide if GroovyMAME should use system-wide switchres.ini, so they can centralize all their SR's compatible emulators configuration in a single ini. Overrides are allowed, as usual, by following ini priority order.
Post by: RobeeJ on January 12, 2022, 04:35:37 am
Post by: pakoman on January 12, 2022, 07:21:37 am
Hmmm...
DoDonPachi SaiDaiOuJou ?
exA "politely" asked the mame team to remove support, sending them a formal letter AFAIK.
https://www.reddit.com/r/shmupchumps/comments/rt3klb/akai_katana_and_ddp_saidaioujou_removed_from_mame/ (https://www.reddit.com/r/shmupchumps/comments/rt3klb/akai_katana_and_ddp_saidaioujou_removed_from_mame/)
Wow, has this happened before with Mame, a developer asking to remove an arcade game?
Usually the issue is the rom and not the emulator. Funny how emulation in Mame is catching new releases.
Post by: Recapnation on January 12, 2022, 08:21:20 am
Though I didn't know that Saidaoioujou was already emulated by MAME officially; is that really the case?
Post by: totozero on January 12, 2022, 08:31:29 am
Technically mame doesn't provide any copyrighted rom but gives a way to emulate games through a framework and drivers (though you could always argue that any reverse engineering which made it possible and was published is actually a violation of an intellectual property).
They self apply the so called rule of ten years i.e they don't include public support to games that aren't at least 10 years old, even if they've been dumped for some time.
Now back to saidaioujou and akaikatana, exA-arcadia bought both IP titles for arcade exploitation and new releases of the games on their platform.
Since Shou, exA-arcadia owner (a well known arcade collector who funnliy enough turns out to be one the top pcb dumpers for mame in his time) threatened mame devs with a legal action, they'd back down and removed support from both games counting from mame 0.240.
Meanwhile Mame 0.239 still has the drivers built-in and the roms keep floatin around on the interweb...
Post by: totozero on January 12, 2022, 08:33:50 am
Though I didn't know that Saidaoioujou was already emulated by MAME officially; is that really the case?
Yup, pretty much.
They've planned for an official release on April 22 but it was leaked on 0.239.
Long story short, Cuavas explained the matter in details here :
https://www.reddit.com/r/emulation/comments/rtlceo/mame_is_officially_dropping_support_for_akai/ (https://www.reddit.com/r/emulation/comments/rtlceo/mame_is_officially_dropping_support_for_akai/)
Post by: Recapnation on January 12, 2022, 08:37:23 am
Post by: totozero on January 12, 2022, 09:00:49 am
(https://i.ibb.co/Yyz7dgm/Image-1.png)
Post by: schmerzkaufen on January 12, 2022, 11:51:53 am
Anyway thanks a lot for the update ! :cheers:
Post by: totozero on January 12, 2022, 04:55:41 pm
At some point, they removed saidaioujou support but the driver commits are still available from github, all you have to do is copy them into cv1k.cpp, compile and you're done.
Barely a hack...
Post by: Recapnation on January 12, 2022, 05:19:19 pm
Post by: totozero on January 12, 2022, 06:15:05 pm
Post by: schmerzkaufen on January 13, 2022, 06:22:01 am
EDIT: big thanks Man ! :cheers:
Post by: reeone on January 31, 2022, 09:42:14 pm
switchres_ini 1
and edit switchres.ini
api powerstrip
thats run perfect 240p & perfect refresh
If
switchres_ini 0
switchres_backend powerstrip
thats only 480i,but perfect refresh
Post by: Calamity on February 01, 2022, 07:13:13 am
Groovymame 0.239 - Switchres 2.002g can run with a crt_emudriver 12.6!
switchres_ini 1
and edit switchres.ini
api powerstrip
thats run perfect 240p & perfect refresh
If
switchres_ini 0
switchres_backend powerstrip
thats only 480i,but perfect refresh
It's basically not working, unless you have Powerstrip installed, which is a nonsense. Please don't use 12.6. It's only there to support pre-HD 5000 cards.
Post by: b4nd1t0 on February 01, 2022, 08:04:04 am
Thanks
Post by: Calamity on February 01, 2022, 09:57:31 am
Starting with this release, a source patch for GroovyMAME will be available along with the binaries on Github's releases. Thanks to Substring for implementing this. It will hopefully make life easier for those who keep alternative builds.
Post by: b4nd1t0 on February 01, 2022, 10:02:33 am
Post by: reeone on February 01, 2022, 09:59:29 pm
unfortunately this card only 12.6 can installedGroovymame 0.239 - Switchres 2.002g can run with a crt_emudriver 12.6!
switchres_ini 1
and edit switchres.ini
api powerstrip
thats run perfect 240p & perfect refresh
If
switchres_ini 0
switchres_backend powerstrip
thats only 480i,but perfect refresh
It's basically not working, unless you have Powerstrip installed, which is a nonsense. Please don't use 12.6. It's only there to support pre-HD 5000 cards.
Post by: reeone on February 13, 2022, 10:58:44 pm
unfortunately this card only 12.6 can installedGroovymame 0.239 - Switchres 2.002g can run with a crt_emudriver 12.6!
switchres_ini 1
and edit switchres.ini
api powerstrip
thats run perfect 240p & perfect refresh
If
switchres_ini 0
switchres_backend powerstrip
thats only 480i,but perfect refresh
It's basically not working, unless you have Powerstrip installed, which is a nonsense. Please don't use 12.6. It's only there to support pre-HD 5000 cards.
above is no needed,only edit C7299900.inf,add AMD9802.1 = AMD Radeon HD 6310 (CRT Emudriver)" in ;;; KFD
all is ok,also can use Csync
Post by: Calamity on February 24, 2022, 05:14:22 pm
Post by: NIGEL71 on March 02, 2022, 07:58:19 pm
Post by: Calamity on March 07, 2022, 10:11:13 am
Post by: R-Typer on March 07, 2022, 02:07:28 pm
Post by: RobeeJ on March 08, 2022, 04:36:50 am
NOTE: those who downloaded 0.241, please re-download it. Some features were lost from 240 to 241. They're back in. Sorry for the trouble.
Hi! Does this include from source, or just the binaries?
(We are grateful!)
Post by: Calamity on March 08, 2022, 07:47:35 am
Hi! Does this include from source, or just the binaries?
Of course, the source is updated too on github, also in patch format if you prefer.
Post by: Calamity on May 01, 2022, 03:03:01 pm
What's new in Switchres 2.002i (April 2022):
- Fixed wrong scaling of vertical games in certain cases.
- [Linux] Internal changes to support libdrm hook (experimental feature).
Post by: eewoke on May 01, 2022, 03:59:55 pm
Groovymame 0.243 is out!
What's new in Switchres 2.002i (April 2022):
- Fixed wrong scaling of vertical games in certain cases.
- [Linux] Internal changes to support libdrm hook (experimental feature).
I can confirm that scaling of vertical games works in this version. Thanks!
Post by: Recapnation on May 01, 2022, 04:17:35 pm
Post by: Calamity on May 01, 2022, 04:24:12 pm
What was wrong, in particular?
This. (http://forum.arcadecontrols.com/index.php/topic,166418.0.html)
Embarrasing...
Post by: Recapnation on May 02, 2022, 09:42:16 am
Post by: donluca on May 03, 2022, 08:18:01 am
I can't rotate my 29" monitor in my Astro City Cab everytime I want to play a vertical shmup. ;D
Post by: Recapnation on May 03, 2022, 10:08:52 am
(By the way, just learnt that Haze finally fixed R-Type Leo in time for 0.243.)
Post by: donluca on May 03, 2022, 03:04:51 pm
And I only have like 2 vertical shmups vs 50 horizontal games, so I've never found it worth the hassle unless I'm having something like a score contest with friends over at my place.
Post by: Recapnation on May 03, 2022, 06:11:43 pm
only have like 2 vertical shmups
I've spent one and a half minutes trying to picture that. I had to give up.
Post by: psakhis on May 04, 2022, 01:14:30 pm
Seems the ones in need of some mercy are the games -- please, do not scale my graphics; please, save me from an interlaced display; please, respect my native refresh rates. We've gone this freaking far in order to play the old games as they're intended but ---fudgesicle--- them if they don't accommodate to my current monitor? Play Giga Wing and ASO II until you rotate it for a season or something, man; they're quite good as well and you know it.I have an horizontal monitor and i enjoy with some vertical games with pixel perfect, a lot of them with 240 o 256 vertical lines...no complaints. For example Gunsmoke or Commando
Post by: Recapnation on May 04, 2022, 04:19:09 pm
Post by: psakhis on May 04, 2022, 05:28:27 pm
You can't run 1 : 1 Gun Smoke, Commando, or any game with a vertical resolution of 256 px or above and a refresh over ~56 Hz (that is, 99,8 % of the games displayed vertically) on a 15-kHz monitor mounted horizontally without dramatically changing the refresh, and therefore, the game's speed. It's the games the ones complaning there; listen to them.You are wrong. I can show 240p (unevenstretch 0) at 60hz with pixel perfect. Centering image, i loose 16 lines (8 on top, 8 on bottom depending on my taste)
Post by: Recapnation on May 04, 2022, 06:30:00 pm
(https://i.imgur.com/eWjrAtv.png) (https://i.imgur.com/qMuEPdF.png) (https://i.imgur.com/B8vFAqe.png)
It's obviously up to every one to destroy the games as they will and post it in all the internets, but please, do it with some consciousness. This subforum gets many new visitors every week silently looking for guidance, and this horizontally-mounted monitors for vertically-displayed games thing is utter ---steaming pile of meadow muffin--- which should not become popular.
Post by: psakhis on May 05, 2022, 04:21:24 pm
If your message is that's better vertically, there is nothing to say, I am talking about enjoyable.
example 1https://drive.google.com/file/d/17p0_0DM3qu-R0ElaDissWNc0v0KKweQ9/view?usp=sharing (https://drive.google.com/file/d/17p0_0DM3qu-R0ElaDissWNc0v0KKweQ9/view?usp=sharing)
example 2https://drive.google.com/file/d/17eTWyaFccJb30yVtM_3fA36YhnsepHZx/view?usp=sharing (https://drive.google.com/file/d/17eTWyaFccJb30yVtM_3fA36YhnsepHZx/view?usp=sharing)
Post by: schmerzkaufen on May 21, 2022, 11:01:20 am
EDIT; or is it that I should
2NDEDIT: BTW it's alright now, autosync off works fine, it's just that I got confused by G-Sync's behaviour that might be a bit quirkier than FreeSync (recently got a monitor that does both, that's a thing these days). The former - of which my personal experience dates from a long time ago - sort of changed over time and requires the use of v-sync simultaneously in PC games :o which might interfere with your emu settings depending on how you set that up (by app or global).
Post by: haynor666 on June 03, 2022, 04:42:40 am
Cropping the picture to get rid of an ~8 % of it is not what any sane person would call "pixel perfect", much less, run the game 1 : 1, man. Which one does taste better in this case of yours?
(https://i.imgur.com/eWjrAtv.png) (https://i.imgur.com/qMuEPdF.png) (https://i.imgur.com/B8vFAqe.png)
It's obviously up to every one to destroy the games as they will and post it in all the internets, but please, do it with some consciousness. This subforum gets many new visitors every week silently looking for guidance, and this horizontally-mounted monitors for vertically-displayed games thing is utter ---steaming pile of meadow muffin--- which should not become popular.
Actually many games back the arcade places was in my town worked this way, operators didn't bother carefully align picture :D
Post by: Recapnation on June 04, 2022, 06:54:21 am
Post by: haynor666 on June 04, 2022, 09:42:33 am
Post by: Recapnation on June 05, 2022, 07:29:20 pm
Post by: pakoman on June 06, 2022, 09:12:33 am
It's strongly believed that in my country there're were more Street Fighter IIs in cabinets with 2- or 3-buttons panels than 6-. Beat that.
And what about Cabal without the roll button connected? I think I've found more without than with... and never the trackball version.
Post by: Recapnation on June 06, 2022, 06:25:46 pm
Post by: Calamity on June 12, 2022, 04:42:06 am
What's new in Switchres 2.002j (June 2022)
- Improve UI text drawing performance. [Oomek]
- Another fix to the scaling algorithm (hopefully the last needed).
Post by: haynor666 on June 17, 2022, 04:01:31 pm
On my two TVs setup games on display1 has video options/screen #0/maintain aspect ratio OFF
but on second display (for vertical games has always options/screen #0/maintain aspect ratio ON
I have defined vertical.ini with just one line
Code: [Select]
screen0 \\.\DISPLAY2
Post by: Calamity on June 20, 2022, 10:40:45 am
Calamity, what exactly was changed for scalling algoritm?
It failed to scale properly on certain situations, e.g. mame galaga -autoror -r 576x224. Now it does it fine.
Quote
On my two TVs setup games on display1 has video options/screen #0/maintain aspect ratio OFF
but on second display (for vertical games has always options/screen #0/maintain aspect ratio ON
I have defined vertical.ini with just one lineCode: [Select]screen0 \\.\DISPLAY2
On a correct setup, -autostretch option takes care of keepaspect, so probably that's what you're seeing on the UI.
Post by: haynor666 on June 21, 2022, 02:43:29 am
Post by: Calamity on June 21, 2022, 05:43:39 am
I have autostretch enabled by default in mame.ini yet for every game running on second display I have maintain aspect ratio ON. For most games that's not a problem but running for example Omega Fighter (256x192) using 2560x240 producing black frames on only on left and right side but also from upper and bottom part of screen. It seems that mame does not save state of this option either.
Is your second display vertical? What resolution is the desktop set at? You may need to force the -aspect option in vertical.ini in case it's not a 4:3 mode.
I don't understand your issue. I don't know if you mean that you have -keepaspect enabled in vertical.ini or that keep aspect ratio ON is shown on the UI. I don't understand if you want to have black borders on right or left or you don't want to have them.
Post by: haynor666 on June 21, 2022, 06:43:37 am
DISPLAY 1 is for horizontal games, DISPLAY 2 for vertical games.
Both desktops have 640x480i
keep aspect ratio ON is shown in internal MAME UI on second DISPLAY/TV (vertical).
Black bars on left and right sides (vertical mode) is expected for when games with resolution 256x192 is displayed using 2560x240.
I'm at work right now so I cannot post pictures straight from my TVs.
EDIT. It appears that second display does nothing to do with this problem - running vertical game on first display and the same situation.
Post by: Calamity on June 22, 2022, 11:36:37 am
Post by: haynor666 on June 23, 2022, 06:20:35 am
I tested also Nikja Kun II (from the same driver, game is using 256x192 but it's horizontal) and it's ok.
Post by: Calamity on July 01, 2022, 08:20:08 am
What's new in Switchres 2.002k (July 2022)
- [Linux] Add low latency (drm) vsync to sdl2 video backend (-video accel).
- Properly apply -keepaspect on rotated targets with -autostretch.
Post by: Calamity on July 01, 2022, 08:20:33 am
Thanks Calamity, I really appreciate it :)
I tested also Nikja Kun II (from the same driver, game is using 256x192 but it's horizontal) and it's ok.
This issue should be fixed now.
Post by: haynor666 on July 01, 2022, 01:16:50 pm
Post by: Calamity on August 08, 2022, 02:37:42 pm
What's new in Switchres 2.002l (August 2022)
- Added controls for geometry adjustment. These are available both as command-line/.ini options and in-game sliders for interactive adjustment:
* H-size [0.5 - 1.5]: option -h_size
* H-shift [positive or negative, in pixels]: option -h_shift
* V-shift [positive or negative, in lines]: option -v_shift
As a reminder: V-size is not possible from software.
Post by: Zebidee on August 08, 2022, 05:47:01 pm
- Added controls for geometry adjustment. These are available both as command-line/.ini options and in-game sliders for interactive adjustment:
Wooot \o/ :woot
Post by: jimj on August 08, 2022, 09:24:33 pm
- Added controls for geometry adjustment. These are available both as command-line/.ini options and in-game sliders for interactive adjustment:
Wooot \o/ :woot
Double :woot I assume the geometry controls are unique to GroovyMAME? I.e. not found in stock MAME?
Post by: Calamity on August 09, 2022, 03:59:00 am
Double :woot I assume the geometry controls are unique to GroovyMAME? I.e. not found in stock MAME?
Yes, sure.
Post by: Recapnation on August 09, 2022, 06:37:20 am
Post by: haynor666 on August 09, 2022, 01:36:27 pm
Post by: m.andrade1 on August 10, 2022, 08:21:36 am
This update has one of the coolest feartures of all, because regular tv sets when you mod it, the majory has no H size, only H shift, so on some of my mods had to change the width cap to adjust the overall picture.
Thanks a lot for your work !
Marcos
Post by: makya on August 12, 2022, 10:32:52 am
Post by: Calamity on September 01, 2022, 03:24:04 pm
Post by: pakoman on September 09, 2022, 01:52:44 am
Post by: Endprodukt on September 24, 2022, 07:45:05 am
Post by: trev1976 on September 27, 2022, 02:18:31 pm
Im looking to build a new groovymame machine and was just wondering what the 0.247 patch did ? and how do you run it ?
Thanks
Post by: b4nd1t0 on September 28, 2022, 03:53:55 am
Post by: Calamity on September 30, 2022, 11:53:03 am
What's new in Switchres 2.002m (September 2022)
- [Windows] Add rawinput support for joysticks. Split global inputs settings for keyboards, mice and joysticks. [Chester C. Rumpled]
- Extend h-size slider to 2.00 maximum.
Post by: B2K24 on December 03, 2022, 11:01:38 am
Post by: haynor666 on December 03, 2022, 11:25:27 am
Post by: b4nd1t0 on December 03, 2022, 01:40:35 pm
Post by: RobeeJ on December 04, 2022, 03:45:34 am
Post by: B2K24 on January 08, 2023, 01:58:53 pm
Post by: BUTerrier2007 on February 07, 2023, 12:32:24 pm
'88 Games
1988 Konami
Driver: konami/88games.cpp
....
Video:
320 x 224 (H) 60 Hz
SR(0): 640 x 480p 60.000 Hz 31.500 kHz
Thanks.
Post by: flybynight on February 23, 2023, 01:06:08 pm
https://www.mamedev.org/releases/whatsnew_0252.txt
Do all these changes cause problem with integrating with GroovyMAME?
Post by: Calamity on February 25, 2023, 04:42:14 pm
What's new in Switchres 2.002q (February 2023)
- Implement integer scaled fonts. Finally clear fonts for CRTs at low resolutions. Set uifont uismall.bdf in mame.ini to enable it. [Oomek & Calamity]
- Force 2-line step for -v_shift (option & slider) on interlaced modes. This way it preserves vertical field parity which is required for correct timings and some hardware. Maybe you need to readjust your previous -v_shift settings.
- [Windows] Make rawinput for joysticks not the default option. Set joystickprovider rawinput manually in mame.ini if you want to use it. It doesn't work for UltraStick and probably other controllers yet.
Post by: Paradroid on February 27, 2023, 02:20:49 am
GroovyMAME 0.252 is out!
Very cool. I'm planning to put together another cabinet restoration this coming weekend and thought I'd check in to see whether GM 0.252 was out or not. Excited to take a look at these new scaled fonts.
As always, thanks for everything you guys do! :)
Post by: RobeeJ on February 27, 2023, 03:26:57 am
Post by: b4nd1t0 on February 27, 2023, 11:23:27 am
Post by: MK3FANATIC on February 27, 2023, 12:08:11 pm
Post by: Calamity on February 27, 2023, 12:41:17 pm
My PC is an i3 2120, AMD HD4550, 4GB RAM, Windows 10 with CRT EMUDRIVER, even on Groovymame 0.251 works perfectly. But now I tried to move to GM 0.252 and had some problems and did not work correctly. When trying to start a game with Mame.ini standard, gave me a black screen and closed the GM. I tried to change the video to D3D, BGFX, and also gave black screen. I changed to Opengl and started the game, only that it worked at a very fast speed, and also did not change for correct resolution. I saw that in the official mame there were several changes, video, controls etc. Anyone else with this problem? Is HD4550 not more compatible?
Well, if 0.251 worked, 0.252 should work too, unless something else changed upstream that I'm not aware of. Please create a log so I can see what's going on.
I'm surprised that pre-HD 5000 cards still work on Windows 10, to be honest.
Post by: MK3FANATIC on February 28, 2023, 06:53:44 pm
Quote
ell, if 0.251 worked, 0.252 should work too, unless something else changed upstream that I'm not aware of. Please create a log so I can see what's going on.
Testing here and strange things happen, for unknown reason to me when I try to make a log file using CMD, mame.exe -v romname >romname.txt, if mame is to open as administrator I am provided with a log.txt file in white. If I run it without being an administrator it gives me a log.txt normally, but as expected switchres doesn't work changing resolutions.
Another strange thing is that through CMD, or even using the FE attract mode, the GM 0.252 works normally. But if I try to run it by opening it normally and going to the list of roms it gives me a black screen and closes. Unless I change the video to opengl, but then it works accelerated and does not change to the correct resolution.
I'll leave the log.txt that I managed to generate, maybe you can find something.
Post by: psakhis on March 01, 2023, 03:48:35 am
It seems switchres don't have permission to read system modes.
Post by: Calamity on March 01, 2023, 05:37:12 am
Post by: MK3FANATIC on March 01, 2023, 05:40:18 am
Quote
@MK3FANATIC, can you attach .251 working version log?
It seems switchres don't have permission to read system modes.
I just discovered that I have this blank log.txt error in 0.251 and earlier versions as well. Maybe it could be some config I do in the OS. But even in version 0.251 the executable opens and everything works normally.
Post by: Calamity on March 01, 2023, 06:25:16 am
Another strange thing is that through CMD, or even using the FE attract mode, the GM 0.252 works normally. But if I try to run it by opening it normally and going to the list of roms it gives me a black screen and closes.
GM is preferably run either for command line or through a frontend. Using the internal ui to launch games isn't the typical procedure, although it should work in normal conditions. There have been changes upstream that may have broken that, some fixes have been pushed after 0.252 release already. So hopefully things will be back to normal on 0.253.
Post by: MK3FANATIC on March 01, 2023, 07:07:57 pm
Post by: psakhis on March 02, 2023, 02:25:53 pm
I found out the reason for the blank log.txt, I was forgetting to open the CMD with admin rights. I generated 2 files if you want to take a look, the hsf2.txt using opengl, which I can open the game through the GM252 user interface but it works at accelerated speed and in interlaced resolution. And kinst.txt using video "auto" in which d3d was selected, I opened it through CMD and it works normally.With OpenGL seems auto frame skip is disabled or something..can you test F9 key to set skip 0 frames?
Post by: MK3FANATIC on March 04, 2023, 10:42:45 am
Quote
With OpenGL seems auto frame skip is disabled or something..can you test F9 key to set skip 0 frames?
I checked this and frame skip is not enabled, something else causes this problem. As Calamity said, wait for the 0.253 to see if the problem will remain.
Post by: fsmith2003 on March 04, 2023, 12:26:48 pm
Switchres: error trying to fill monitor range with
Is there any way to stop this error from occurring?
Post by: psakhis on March 05, 2023, 04:03:03 am
Post by: MK3FANATIC on March 05, 2023, 06:47:48 am
Quote
Anyway..on Windows @Calamity d3d9ex implementation it's the way to go. Why are you using openGL?
yes with d3d9ex it works better, but as i said before in this version 0.252 i can't open the games through the user interface using d3d, just setting the video to opengl. If I use the command line it works fine.
Post by: haynor666 on March 10, 2023, 07:18:44 am
- Implement integer scaled fonts. Finally clear fonts for CRTs at low resolutions. Set uifont uismall.bdf in mame.ini to enable it. [Oomek & Calamity]
Yessss, finalllly. Thanks guys ;D
Post by: rogerxyz on March 20, 2023, 09:52:49 pm
Hi Calamity et al,
Great work on GM 0.252 and Switchres! Unfortunately I have to report an issue I'm having. I upgraded my windows 10, ATI R9 200, 15khz cabinet from GM 0.248 which was having no issues to 0.252, and I am experiencing an unhandled exception 100% of the time:
Exception at EIP=00007fff3023a060 (not found): ACCESS VIOLATION
While attempting to write memory at 00007fff3023a060
Full logs and ini attached. I reverted to 99% stock mame.ini including my custom modelines (though these did not work either). I tried the auto and ati backends.
When I launch a rom directly, interestingly enough, GM will switch to a proper modeline, run the game, and I only receive the exception when exiting gm. However, when launching into the gui via mame.exe, I get the exception and crash before GM switches modes. I believe I can rule out the romset (merged 0.252) as running the same rom on my main PC with switchres set to 0 is fine.
I am using crt_emudriver 2.0 beta 15, I haven't updated the driver since setting up the cab 1-2 years ago as I'm trying not to break anything that's already working, but I understand if this might be related.
If I can be of assistance collecting any additional information let me know. Thank you for your endless work on this project, I truly appreciate it!
Roger
Post by: Robbbert on March 21, 2023, 11:48:39 pm
Post by: MK3FANATIC on March 30, 2023, 08:10:14 am
Quote
There have been changes upstream that may have broken that, some fixes have been pushed after 0.252 release already. So hopefully things will be back to normal on 0.253.
MAME 0.253 released and the issues were fixed, working normally. Waiting for GM 0.253
Post by: Calamity on March 31, 2023, 07:13:17 am
What's new in Switchres 2.002r (March 2023)
- Improve rendering of UI frames and lines in low resolutions. [Oomek]
- Correctly apply rotation after modeline adjustment (using the geometry sliders with rotated games now works).
- Correctly apply syncrefresh (it wasn't applied automatically since v_scale was changed from int to float).
Post by: pakoman on March 31, 2023, 07:20:30 am
Post by: b4nd1t0 on March 31, 2023, 07:21:22 am
Inviato dal mio EML-L09 utilizzando Tapatalk
Post by: RobeeJ on April 01, 2023, 02:49:34 am
Post by: rogerxyz on April 01, 2023, 08:57:52 pm
I can confirm with GM 0.253 the issue I posted earlier with GM 0.252 is resolved. Success!!!
Post by: Jonny G on April 02, 2023, 09:48:36 am
I seem to remember this happening for a while many, many, releases ago, but I cannot remember the fix. Perhaps it involved removing entries for the mechanical cabs, etc from the source files. Does anyone know a temp. workaround to sort this for now in the hope this change isn't permanent?
Thanks
Jon
Post by: makya on April 02, 2023, 04:27:59 pm
So as I understand things from my own experience with attempting to compile 0.253 and a few posts on the MAME support forums, It is no longer possible to build an arcade only .exe using the subtarget option. I've also seen that B4nd1to who usually posts his custom builds here has stopped offering that particular option.
I seem to remember this happening for a while many, many, releases ago, but I cannot remember the fix. Perhaps it involved removing entries for the mechanical cabs, etc from the source files. Does anyone know a temp. workaround to sort this for now in the hope this change isn't permanent?
Thanks
Jon
I believe you can make mame.lst to include only games you want. Then it will compile what's required to run those games only.
Post by: Robbbert on April 02, 2023, 07:30:14 pm
Post by: Jonny G on April 03, 2023, 01:29:10 pm
Thanks!
Post by: Calamity on April 04, 2023, 07:42:01 am
OK, well that's a positive. I used to use MAMECompiler64 and obviously that has a GUI so it's just been as easy as ticking a box for me to build an arcade only .exe. Any tips on what to do with arcade.flt please?
Thanks!
Grab the arcade.flt file from a previous version, put it in src/mame, then:
Code: [Select]
make SOURCEFILTER=src/mame/arcade.fltIt will fail since a couple of files have been removed or renamed between 252 & 253. So edit arcade.flt and remove those lines and try again.
Post by: Jonny G on April 06, 2023, 04:42:02 am
Grab the arcade.flt file from a previous version, put it in src/mame, then:Code: [Select]make SOURCEFILTER=src/mame/arcade.flt
It will fail since a couple of files have been removed or renamed between 252 & 253. So edit arcade.flt and remove those lines and try again.
Thank you so much Calamity, seems to have worked!
Post by: crispux3 on April 21, 2023, 04:10:12 pm
unfortunately this card only 12.6 can installedGroovymame 0.239 - Switchres 2.002g can run with a crt_emudriver 12.6!
switchres_ini 1
and edit switchres.ini
api powerstrip
thats run perfect 240p & perfect refresh
If
switchres_ini 0
switchres_backend powerstrip
thats only 480i,but perfect refresh
It's basically not working, unless you have Powerstrip installed, which is a nonsense. Please don't use 12.6. It's only there to support pre-HD 5000 cards.Oh,I edit C7299900.inf,change the card from "%AMD9802.1%" = ati2mtag_Wrestler, PCI\VEN_1002&DEV_9802 to "%AMD9802.1%" = ati2mtag_Legacy, PCI\VEN_1002&DEV_9802.and crt_emudriver_&_tools_2.0_beta_15_16.2.1_W.7.8.10-64_nieg installed successfully!
above is no needed,only edit C7299900.inf,add AMD9802.1 = AMD Radeon HD 6310 (CRT Emudriver)" in ;;; KFD
all is ok,also can use Csync
I just received HP laptop with HD 6310 in it. I know how to edit file C7299900.inf, but where do you put the above line: AMD9802.1 = AMD Radeon HD 6310 (CRT Emudriver)" in ;;; KFD in the file itself?
What is the exact line that I need to put in the file and where do I actually put it (as it's a long file of information)? Thank you.
Post by: schmerzkaufen on April 26, 2023, 04:22:13 pm
I believe games will still require some adjustments contrary to Vas's statement, and therefore still have an use for the saving sliders, but with this it'll be the best way to do it and play those games so far.
Can't wait for this Groovy (and b4nd1to's) :droid
Post by: b4nd1t0 on April 27, 2023, 03:16:34 am
MAME 0.254 brings that new improvement to the Cave CV1000 blitter delay code, this will be a great time !if the groovy patch remain to "r" i can try to compile it today
I believe games will still require some adjustments contrary to Vas's statement, and therefore still have an use for the saving sliders, but with this it'll be the best way to do it and play those games so far.
Can't wait for this Groovy (and b4nd1to's) :droid
Post by: schmerzkaufen on April 27, 2023, 06:25:32 am
EDIT: it looks like they have removed the both switch and slider for Blitter Delay, if so that's quite the confidence they have in the recent improvement I must say.
IIRC the author was not as radical in his statement regarding how much his new code improved on the matter.
Welp, time will tell.
In Groovy we should at least still have control over the CPU%, which from what I could gather around is still necessary for CV1000 anyway.
ED2: it's fine the author himself is behind it, found on shmups;
Quote
Tuning the CPU underclock can work as somewhat of an approximation of the actual pcb behavior, but theres not going to be an exact value thats best. With the Blitter slider (that this code removes) it was way worse though. The Blitter delay code prior to this had pretty much nothing to do with how things work on pcbs, so tuning it to specific values made no sense really.
That said, until proper wait state support is implemented for the cpu, picking some cpu value that feels mostly right is probably close-ish at least.
Post by: Calamity on April 27, 2023, 11:27:33 am
EDIT: it looks like they have removed the both switch and slider for Blitter Delay, if so that's quite the confidence they have in the recent improvement I must say.
From what I could read, the blitter delay behaviour is now correctly understood and implemented, so the slider is worthless at this point. There's another source of delay in the SH-3 cpu wait states. This can't be emulated easily since MAME uses its dynamic recompiler for this cpu, otherwise it wouldn't be possible to emulate these games at full speed, as it was the case before Haze implemented it a few years ago.
Post by: schmerzkaufen on April 27, 2023, 01:03:46 pm
The build is in the oven, should be ready in a few hours if github is happy.8)
From what I could read, the blitter delay behaviour is now correctly understood and implemented, so the slider is worthless at this point. There's another source of delay in the SH-3 cpu wait states. This can't be emulated easily since MAME uses its dynamic recompiler for this cpu, otherwise it wouldn't be possible to emulate these games at full speed, as it was the case before Haze implemented it a few years ago.
Ah yes we've seen the topic mentioned here and there over the years, IIRC correct wait states for a lot of emulated hardwares would require a complete change of a massive part of MAME so it's a pipe dream, or something for the far future.
So games like those are getting close to the best they'll ever be emulated in the existing MAME at the very least, which is already damn awesome.
If we get gameplay results that don't pale - or even best - console ports, then there's only reasons to celebrate. :cheers:
I gave this new code a try and indeed we can see some of the expected slowdown behaviour pop up during gaming without us having to randomly seek hypotetical 'working' blitter delay values anymore.
CPU underclock is still needed though, but that's only one slider left to deal with. Good ! 8)
PS: even that will eventually become obsolete, not yet but little by little. Like, some time ago Dark Seal's sound was fixed, and recently Garou's messed up background animation since the CPU is more accurately emulated now.
Post by: Calamity on April 27, 2023, 01:26:43 pm
PS: even that will eventually become obsolete, not yet but little by little. Like, some time ago Dark Seal's sound was fixed, and recently Garou's messed up background animation since the CPU is more accurately emulated now.
The long-awaited M68K wait states emulation was added by OG in previous release, this is what fixed Garou (and probably many other timing derived bugs). Since M68K is used almost everywhere in arcades, this is a truly major leap in emulation accuracy.
Post by: schmerzkaufen on April 27, 2023, 01:34:43 pm
I guess it's something that can be done for at least a part of MAME's already established hardwares without a major rewrite of like a third of MAME's code globally lol.
EDIT: take that MiSTer ! hmph. you're nothing special. :P
Post by: Calamity on April 27, 2023, 02:58:40 pm
What's new in Switchres 2.002s (April 2023)
- Fix popup error with custom preset (switchres: error trying to fill monitor range with).
Post by: Robbbert on April 27, 2023, 06:47:22 pm
GroovyMAME 0.245 is out!
Er, don't you mean 0.254 ?
Post by: Sociopathos on April 27, 2023, 08:26:49 pm
PS: even that will eventually become obsolete, not yet but little by little. Like, some time ago Dark Seal's sound was fixed, and recently Garou's messed up background animation since the CPU is more accurately emulated now.
The long-awaited M68K wait states emulation was added by OG in previous release, this is what fixed Garou (and probably many other timing derived bugs). Since M68K is used almost everywhere in arcades, this is a truly major leap in emulation accuracy.
Yeah, too bad its not applied on the Cps1/2 drivers, so Sf2 Hyper Fighting is still too fast. :(
Post by: Calamity on April 28, 2023, 04:04:44 am
GroovyMAME 0.245 is out!
Er, don't you mean 0.254 ?
Corrected, thanks.
Post by: makya on April 28, 2023, 05:44:24 am
GroovyMAME 0.254 is out!
What's new in Switchres 2.002s (April 2023)
- Fix popup error with custom preset (switchres: error trying to fill monitor range with).
Many thanks Calamity!
Post by: donluca on April 28, 2023, 06:38:16 am
GroovyMAME 0.245 is out!
Er, don't you mean 0.254 ?
We're going back, Marty!
Post by: schmerzkaufen on April 29, 2023, 07:55:04 am
PS: I went back to my old LCD monitor (non-VRR) and tried to use allow_hw_refresh again, set lcd_range 50-75, and for a while it seemed to work well as it did before.
Today I'm using W10 and a 6650 XT.
But then I must have touched something I shouldn't have, dunno how as I wasn't meddling with anything related to sync, and now it refuses to work anymore, no more correct refreshes. :dunno
Please Calamity remind me of the required settings for that particular feature ? I can never remember every time I go back to using it and there's nothing written about it (well, somewhere deep down the forums I cannot find anymore). Here's how I'm set for now;
Code: [Select]
# OSD FULL SCREEN OPTIONS
#
switchres 1
switchres_ini 0
switchres_backend auto
modesetting 0
modeline_generation 1
monitor lcd
interlace 1
doublescan 0
super_width 2560
changeres 1
lock_system_modes 0
lock_unsupported_modes 0
refresh_dont_care 0
dotclock_min 0
h_size 1
h_shift 0
v_shift 0
v_shift_correct 0
pixel_precision 1
sync_refresh_tolerance 2.0
interlace_force_even 0
autosync 1
autofilter 1
autostretch 1
screen_compositing 0
screen_reordering 0
allow_hw_refresh 1
modeline auto
ps_timing auto
lcd_range 50-75
crt_range0 auto
Post by: Calamity on April 29, 2023, 11:24:04 am
But then I must have touched something I shouldn't have, dunno how as I wasn't meddling with anything related to sync, and now it refuses to work anymore, no more correct refreshes. :dunno
No, it's a bug. It must have been introduced with latest Switchres api internal update. I'll fix it when I have some time.
Post by: schmerzkaufen on April 29, 2023, 12:44:00 pm
Me for these past 20 years, every time I believe I finally have my hands on the ultimate MAME build of my dreams :
(https://i.postimg.cc/jSbnP8qV/cat-kitten.gif)
Post by: RobeeJ on April 30, 2023, 03:42:28 am
But then I must have touched something I shouldn't have, dunno how as I wasn't meddling with anything related to sync, and now it refuses to work anymore, no more correct refreshes. :dunno
Does it run way too fast? Mine has been doing this since 253, I wasn't sure if it was GM or an Arch Linux update so I was just turning off switchres. Didn't want to bug Calamity about it until I was sure it was GM, and also because I use an LCD which isn't quite the target audience I felt a little guilty mentioning it. :)
Post by: Calamity on April 30, 2023, 03:49:18 am
Does it run way too fast? Mine has been doing this since 253, I wasn't sure if it was GM or an Arch Linux update so I was just turning off switchres. Didn't want to bug Calamity about it until I was sure it was GM, and also because I use an LCD which isn't quite the target audience I felt a little guilty mentioning it. :)
So your issue is also with the lcd monitor preset, right?
Post by: schmerzkaufen on April 30, 2023, 04:43:46 am
Does it run way too fast? Mine has been doing this since 253, I wasn't sure if it was GM or an Arch Linux update so I was just turning off switchres. Didn't want to bug Calamity about it until I was sure it was GM, and also because I use an LCD which isn't quite the target audience I felt a little guilty mentioning it. :)
Nah it's just that the expected effect of the feature (running at correct refresh output) doesn't trigger anymore. Dunno which version introduced that bug though.
Note if need to repeat at least for some readers ; that allow_hw_refresh works for a few compatible flat panel displays, which you can only know by trying, and of course requires an AMD card.
Since I own a couple monitors with which the feature works I've been enjoying that, it basically provides the Groovy experience (smooth correct refresh and lag reduction) practically at the flick of a switch, no need for emudrivers nor any complicated set up.
So it's not for everyone but absolute gold when it works. :notworthy:
(haven't tried it with CRTs yet but it'll come, in any case for the many who don't own any CRTs nor VRR setups and have a basic flat panel and AMD gpu lying around, if not a pretty phosphor image* it means at least correct gameplay at zero cost and effort)
*PS: though we're limited to D3D in Groovy which means flat panel users only have ye olde HLSL if they want an imitation of CRT, with time I've come to learn tame it better and find reatively decent settings that work well-enough for the general use. HLSL may feel obsolete and unintuitive these days compared to some other shader chains performing a more convincing imitation, but hey flat panel peasant aren't 100% butt naked lying in the dirt using GM.
*PPS: I won't talk about the software BFI feature since I don't know how to use it properly, got improper results on so I'm not sure it works and last time I tried my high-refresh capable IPS monitor displayed persistent flickering for a while, even if after just a couple minutes. This monitor's got its own strobing feature working better but way too dark. So, if there's one aspect flat panels still won't compensate even reasonably for vs. CRTs, it's very much that: motion. Until we get something like nVidia's frame generation but for retro emulators I'm not touching this again lol.
Post by: RobeeJ on May 01, 2023, 01:51:54 pm
So your issue is also with the lcd monitor preset, right?
Yes, correct! Works fine if I turn off switch_res, problem began in 253 I think.
If I was to describe the symptoms, some games run way too fast, and others like Contra have very noticeable sound slurring.
Note if need to repeat at least for some readers ; that allow_hw_refresh works for a few compatible flat panel displays, which you can only know by trying, and of course requires an AMD card.
Strangely the only affect this had for me was make GM eat 100% CPU rather than 15% 🤷♀️
Post by: Calamity on May 02, 2023, 06:14:46 am
I'm happy to learn that some people are using the lcd preset haha.
Post by: schmerzkaufen on May 02, 2023, 07:56:51 am
BTW the 'LCD' preset isn't suspected to even exist, I guess. It's the one I've used the most goes without saying, but it felt lonely there.
Since the 'GroovyMAME is dedicated to CRTs' slogan is the only put forward, very few ppl know that it is also at the same time the most advanced MAME build for flat panel displays.
The CRT focus statement as I've seen even has adverse effects like I've read things like 'uh better not use Groovy if you dont have a CRT' or 'avoid because it is too esoteric if youre not a CRT connoisseur' kind of 'advice' certainly from non-users. :-\
There are sadly too many examples of how ill-known and misunderstood this build is. Same goes for the topic of lag I've kept an eye on it and today ppl are still globally confused about it (we gotta thank RA and YT snake-oil salesmen for that).
Even witnessed some braindead mofo once on a discord server saying frame_delay actually increases lag, I recommended him to quit smoking bizarre things, what can we do though really...
A lot of unaware ppl could have benefited from Groovy so many years, but in these internet-ruled times bullsh*t and prejudice always win. Welp. :dunno
Post by: Zebidee on May 02, 2023, 01:46:22 pm
I have occasionally had fun explaining the difference to people, that Groovymame is cool, essentially a "better mame", and can work on VGA & even LCD, it really depends on what the display can do (and the PC's ability to keep up), and watch their jaws drop as realisation dawns. If they still don't get it, well then at least persistent ignorance can be entertaining.
Now that I've dispensed wisdom, Ima gunna sit back in my armchair, grab a whisky and light up my pipe.
:cheers:
Post by: Calamity on May 02, 2023, 04:14:54 pm
https://github.com/antonioginer/GroovyMAME/releases/tag/gm0254sr002t
Post by: schmerzkaufen on May 03, 2023, 05:46:18 am
Purrfect once again. Thanks a lot. 8)
Must say, ain't it a shame in regards to VRR tech that I get actually even more perfect smoothness with Groovy's own implementation ?
Not kidding; either with FreeSync or G-Sync I see a faint hiccup once in a blue frame (very rare but it happens).
But GroovyMAME stays absolutely smooth at all times, would I spend scrutating scrolling backgrounds for hours. Flawless.
My newer monitor features WQHD and 170Hz VRR (free/Gsync compatible) and is faster, brighter, so it should be better, right ? Yet my older featureless slower, dimmer, glossy Full-HD 50-75Hz somehow makes the experience better, and the perfect scrollings smoothness is the cherry on top.
Post by: RobeeJ on May 08, 2023, 06:40:36 am
250 is perfect
251 is perfect
252 runs super fast, maybe twice speed, a frame delay of 9 slows it down but makes the sound speed wobbly
253 runs super fast, maybe twice speed, a frame delay of 9 slows it down but makes the sound speed wobbly
254 runs super fast, maybe twice speed, a frame delay of 9 slows it down but makes the sound speed wobbly
Not a major issue as I can turn off switchres, so more an FYI in case it's something obvious.
I appreciate all your work!
Post by: Calamity on May 08, 2023, 12:43:33 pm
Post by: schmerzkaufen on May 09, 2023, 06:45:56 am
Even in a vsync off or VRR scenario ?
IIRC by count this was what Oomek's dedicated lag test results were (+3 frames before lowlatency was introduced)
(and this is one of the reasons why Groovy still uses D3D ?)
If you go around reddit or whatever, ppl pretend BGFX doesn't add such lag, of course always stating so without context...
Post by: Calamity on May 09, 2023, 07:08:11 am
Quote
Even in a vsync off or VRR scenario ?
No. BGFX + VRR (vsync-off) + low_latency = no latency (equivalent to D3D + vsync + frame_delay 9)
At least when I tested it, back when low_latency was added to baseline MAME. My results were posted in the PR.
On the other hand, BGFX + vsync = LAG, ranging from bad to catastrophic, depending on the backend used.
Post by: schmerzkaufen on May 09, 2023, 08:22:15 am
Alright. So vsynced BGFX lags X frames depending on the backend. Which does it pick by default on W10 ?
d3d9
d3d11
d3d12
opengl
metal
vulkan
(don't even know if all of those are actually functional)
Post by: RobeeJ on May 09, 2023, 03:42:30 pm
I notice the SDL version compiled against is newer, no idea if that's a factor, may be a red herring.
Post by: Calamity on May 09, 2023, 05:30:46 pm
Logs as requested!
I notice the SDL version compiled against is newer, no idea if that's a factor, may be a red herring.
Ok, the problem is it's using the bgfx video backend on the second case (254). They made it the default recently. Not a problem with GroovyArcade since we're forcing -video opengl, but you're probably using another Linux distribution. So, force -video opengl in mame.ini.
Post by: RobeeJ on May 10, 2023, 04:06:10 am
Ok, the problem is it's using the bgfx video backend on the second case (254). They made it the default recently. Not a problem with GroovyArcade since we're forcing -video opengl, but you're probably using another Linux distribution. So, force -video opengl in mame.ini.
Interesting, I thought I was already using BGFX even in 251, I will post my mame.ini later. I'm using Arch Linux but not GA.
Post by: RobeeJ on May 10, 2023, 03:27:35 pm
Post by: schmerzkaufen on May 10, 2023, 03:38:19 pm
I'm not a Linux user, but I had to insist with many a new Groovy user on windows to not use BGFX. Even met more than a couple who actually tried to hide they were using it until the bitter end of the convo, because somehow they knew, but hoped someone would one way or the other make it work for them. Nope. :P
Welp, there's still GLSL I guess. Never used that but it's pretty much on par with HLSL iirc.
Post by: Calamity on May 11, 2023, 05:01:27 am
Here is my mame.ini! I do have bgfx enabled, so maybe it's not that?
It's that indeed. It was only working fine out of pure luck before. Probably vsync isn't locking the thread any more in the specific api that bgfx is calling, who knows.
I got tired of random api "improvements" breaking vsync long ago, that's why GM does vsync manually, but this is only accessible through the supported video backends: opengl and accel on Linux, d3d on Windows.
I wanted to extend support to bgfx at some point but now I think it won't be feasible/worth.
Post by: schmerzkaufen on May 11, 2023, 06:19:15 am
If ppl want BGFX with smooth correct refresh scrollings and no lag; they have to use a VRR setup, in which case Groovy doesn't offer much else vs mainline MAME in terms of features, aside from saving the main UI sliders, intoverscan (and the multimonitor specifics maybe?)
Groovy's smooth correct refreshes and frame_delay lag reduction work on flat panels, either partially or completely depending on the display's compatibility (unknown without testing)
AND that limits usage to the backends Calamity specified.
Therefore HLSL and GLSL for CRT look simulation.
[crt shader rant]
TBH I think what ppl have always been lacking for those CRT shaders to get more popular are good presets working for most display resolutions and orientations.
BGFX mode does provide a number of presets (some very questionable producing a blurry run-down crt look) so that's why ppl want to use it.
But IMO from the beginning when those shaders have been introduced, and without waiting for BGFX, MAME should have come bundled with ready generic clean RGB CRT presets broadly compatible with resolutions for use with HLSL and GLSL immediately.
The process of figuring what those shader settings do one by one to achieve an optimal effect is borderline unfeasible (plus the non-saving UI sliders and some mismatched settings names in the .ini and dealing with ini hierarchy after you finally figure that you have to delete the raster.ini to be free, dont help also), and being disappointed at settings other ppl share has also been commonplace since them too don't master it and have their own personal taste and hardware biases. That's already it for HLSL, and while I haven't used GLSL I've seen that it requires to figure out how to even make it work at all, so in short from the beginning the problem has been the same old MAME has been marred with: accessibility and user-friendliness.
Personally it took me a very long time to find even just generic settings for HLSL, not great but working anyway for most games I play and at whatever monitor resolution I commonly use (1080 & 1440) and now I think I could make it work for anything.
But I had to go through the five stages of denial, anger, bargaining, depression and acceptance that I would never manage to make it look good-enough and all i can afford to make work is a simplistic scanlined shadow mask with a bit of bloom and variation.
In short I can only use like maximum 10~15% out of the over 80 lines of settings found in the mame.ini dedicated to CRT simulation, only to achieve that simplistic but working basic effect.
I so wish we have had capable ppl who have made and implemented that feature, enlighten and guide, and share the best they could do with their own baby for the common good, and certainly for the good of MAME as a whole.
No surprise seeing the shaders feature of RetroArch, that the latter's become so dramatically popular in comparison, as it has long been way ahead in that department, the only thing it can boast about.
Post by: Robbbert on May 11, 2023, 07:14:35 pm
Post by: schmerzkaufen on May 12, 2023, 01:44:42 am
It seems incomplete, e.g for some reason the mask type isn't saved which of course forces you to set it again every time.
Defaults are stlll awful also.
Well, that'd be fine at least for ppl with a VRR setup since they don't suffer the lag with BGFX.
But it doesn't help Groovy users who can't use BGFX, and I doubt anyone will bother implementing saving sliders for D3D 's & Opengl 's HLSL and GLSL.
Features like that aren't the focus of mamedev anyway so I guess we should be happy that there is at least some movement in that area.
I guess, would baseline integrate Groovy's features, at least all those that regard flat panels, and help/accept making them work with BGFX by not killing it every few versions, finally fixing the vsync lag,
and expand the shaders offer, fix the default of the existing, and finish making all the saving sliders actually save (having even just one relmaining that doesn't save won't cut it)
THEN they'd have an attractive-enough competitor to RA.
maybe...
coz there are more things that confuse and irk too many users to make MAME their go-to even for just arcades emulation, the UI wouldn't be bad but it still has issues that make it a PITA, like the magnitude of romsets and wtf search results, even with filters it's still an everyday struggle.
You know well lots of ppl much prefer the old stype windows GUI, I still do too TBH.
Anyway personally I am happy-enough with how Groovy is, its lag reduction and correct smooth refreshes work, it attends to flat panels too, without much if any hassle at all now, and saves crucial sliders, so I can deal with what's left of baseline's weaknesses.
Post by: H@nzo on May 16, 2023, 11:17:48 am
My CRT is vertically oriented.
With the current version, the UI is very very small - you can't read anything anymore, unfortunately.
I think it's because of the super resolution (if turn it off in mame.ini everything in the UI is fine, but the games scale is wrong).
The games are displayed correctly.
Where is my error or what do I have to set so that the UI is displayed normally again?
Post by: Zebidee on May 16, 2023, 04:37:05 pm
Post by: H@nzo on May 17, 2023, 08:05:41 am
I have now helped myself in the UI options to use a different font. Unfortunately not an optimal solution: UI scaling is now okay. In the games, however, the menus are too large and confusing.
Post by: Calamity on May 17, 2023, 08:11:39 am
Post by: Calamity on June 10, 2023, 07:23:05 am
What's new in Switchres 2.002t (May 2023)
- [Windows] Fix rawinput for joysticks for certain devices [star69rem].
- Fix lcd_range operation.
Post by: RobeeJ on June 11, 2023, 03:30:41 am
Post by: schmerzkaufen on June 11, 2023, 03:47:12 am
Post by: monophonic on June 18, 2023, 06:46:56 am
Quick question:
I've been playing around with CRTEmudriver and it's been working great!
One specific thing I noticed however: if my desktop resolution is set to 2560x240 and I run a game that also has a vertical resolution of 240, then the refresh rate won't change at all.
For example: Tetris the Grand Master 2 runs at 320x240@61.681. When I launch it from the command line, system info shows 2560x240@59.996.
The same behavior also happens when my desktop resolution is set to 320x240.
Just to clarify, when my desktop resolution is set to 480i instead, it does change the refresh rate correctly to 2560x240@61.681.
I'm unsure if this is intended behavior or simply a bug with switchres as it happens on both Groovymame and Retroarch.
My setup is an AMD R7 260x connected to a Trinitron via SCART. Monitor is set to arcade_15.
I've included a log as well.
Post by: makya on June 19, 2023, 05:39:51 am
Hi Calamity,
Quick question:
I've been playing around with CRTEmudriver and it's been working great!
One specific thing I noticed however: if my desktop resolution is set to 2560x240 and I run a game that also has a vertical resolution of 240, then the refresh rate won't change at all.
For example: Tetris the Grand Master 2 runs at 320x240@61.681. When I launch it from the command line, system info shows 2560x240@59.996.
The same behavior also happens when my desktop resolution is set to 320x240.
Just to clarify, when my desktop resolution is set to 480i instead, it does change the refresh rate correctly to 2560x240@61.681.
I'm unsure if this is intended behavior or simply a bug with switchres as it happens on both Groovymame and Retroarch.
My setup is an AMD R7 260x connected to a Trinitron via SCART. Monitor is set to arcade_15.
I've included a log as well.
Hello, that's a well know behavior. You should use another resolution for your desktop, for example 2560x242 or try allow_hw_refresh option.
-[no]allow_hw_refresh: dynamically adds new modes or updates existing ones just like VMMaker does, even on stock AMD drivers. This feature is experimental and is disabled by default. It has the following limitations and problems:
Synchronization is not perfect yet and the new modes may not always be ready on time for mode switching, causing a wrong display output.
A plug-n-play audio notification will be present on startup and exit, if the explorer shell is used.
Refreshing the hardware is an expensive task that takes time, specially if the app has already entered fullscreen mode. This makes it unpractical for games that switch video modes more than once, unless -nochangeres is used, or alternatively super resolutions are forced (-resolution 2560x0) so that effective mode changes are neutralized (the later trick won't help for games that switch between interlaced and progressive).
When used on stock AMD drivers instead of CRT Emudriver, usual limitations apply: no support for low resolutions (below 640x480) nor low dotclocks. Not a problem however if you're using a 31 kHz monitor.
Still, this feature is interesting enough to be provided as an option, and is a requirement for the new automatic lcd preset (as it's what makes it possible to refresh the current desktop mode).
Post by: monophonic on June 19, 2023, 07:28:35 am
Hello, that's a well know behavior. You should use another resolution for your desktop, for example 2560x242 or try allow_hw_refresh option.
-[no]allow_hw_refresh: dynamically adds new modes or updates existing ones just like VMMaker does, even on stock AMD drivers. This feature is experimental and is disabled by default. It has the following limitations and problems:
Synchronization is not perfect yet and the new modes may not always be ready on time for mode switching, causing a wrong display output.
A plug-n-play audio notification will be present on startup and exit, if the explorer shell is used.
Refreshing the hardware is an expensive task that takes time, specially if the app has already entered fullscreen mode. This makes it unpractical for games that switch video modes more than once, unless -nochangeres is used, or alternatively super resolutions are forced (-resolution 2560x0) so that effective mode changes are neutralized (the later trick won't help for games that switch between interlaced and progressive).
When used on stock AMD drivers instead of CRT Emudriver, usual limitations apply: no support for low resolutions (below 640x480) nor low dotclocks. Not a problem however if you're using a 31 kHz monitor.
Still, this feature is interesting enough to be provided as an option, and is a requirement for the new automatic lcd preset (as it's what makes it possible to refresh the current desktop mode).
Thanks, that's good to know.
Post by: Calamity on July 01, 2023, 05:58:25 am
What's new in Switchres 2.002u (May 2023)
- Only save certain sliders: frame delay, vsync-offset, overclock and CRT geometry sliders. This avoids the problem with vector games not responding to ini settings.
Post by: schmerzkaufen on July 01, 2023, 03:04:30 pm
EDIT: all green ! sliders work as intended, including in non-VRR context using allow_hw_refresh with lcd_range, and frame_delay + vsync_offset + CPU% :applaud:
Post by: R-Typer on July 01, 2023, 03:55:13 pm
Post by: RobeeJ on July 02, 2023, 04:49:29 am
Post by: JPetersen on July 10, 2023, 08:14:30 pm
I was wondering if it would be possible to save the 'screen refresh rate' slider values as in previous GroovyMAME versions? I use this feature a lot and a lot of my cfg files are set up for it. It would be a shame to have to be stuck using v0.255 in the future!
Post by: Calamity on July 13, 2023, 02:33:28 pm
Hi Calamity.
I was wondering if it would be possible to save the 'screen refresh rate' slider values as in previous GroovyMAME versions? I use this feature a lot and a lot of my cfg files are set up for it. It would be a shame to have to be stuck using v0.255 in the future!
OK, I'll add this to next version.
You don't know for sure if people are using a certain feature until it's removed. :laugh:
Post by: JPetersen on July 13, 2023, 06:48:20 pm
Hi Calamity.
I was wondering if it would be possible to save the 'screen refresh rate' slider values as in previous GroovyMAME versions? I use this feature a lot and a lot of my cfg files are set up for it. It would be a shame to have to be stuck using v0.255 in the future!
OK, I'll add this to next version.
You don't know for sure if people are using a certain feature until it's removed. :laugh:
Thank you!
Yes, some of us use software in odd ways :D
Post by: Calamity on July 31, 2023, 08:10:45 am
What's new in Switchres 2.002v (July 2023)
- Also save Screen Refresh Rate slider.
Post by: Rion on July 31, 2023, 09:32:08 am
GroovyMAME 0.257 is out!
What's new in Switchres 2.002v (July 2023)
- Also save Screen Refresh Rate slider.
:applaud: :cheers: :notworthy:
Post by: haynor666 on August 03, 2023, 02:39:29 am
Post by: RobeeJ on August 03, 2023, 04:05:05 am
Post by: JPetersen on August 05, 2023, 07:54:30 pm
Post by: edomatic on August 29, 2023, 03:09:44 pm
I have a vertical Cab now with a new mame 0.257 thanks to Calamity and all involved here , works great !
Does anyone know if the UI can be turned vertically as well?
Post by: edomatic on September 02, 2023, 09:08:06 am
I noticed there is an option in there called "UI rotate" (default R ) but it does not seem to do anything
Post by: makya on September 03, 2023, 05:19:30 pm
Try this:
rotate 1
ror 1
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
or that:
rotate 1
ror 0
rol 1
autoror 0
autorol 0
flipx 0
flipy 0
It works here. UI is actually rotated.
Post by: edomatic on September 08, 2023, 12:05:01 pm
Post by: DJO_Maverick on October 01, 2023, 12:58:53 pm
*fingers-crossed*
Post by: schmerzkaufen on October 01, 2023, 02:00:04 pm
Surely we can deal with ~60ms lag as long as we get doubled motion perception, right ? :laugh:
EDIT: or FSR3 Frame Generation idk. AMD like to make their new features announcements as confusing as nVidia's apparently.
Quote
FSR3FG must be implemented in a game by the devs to be used, and it uses motion vectors to generate the interpolated frames. FSR3FG can be used on any GPU.
AFMF can be enabled on any game that runs on DX11/12, doesn't need to be implemented by the devs, but that means that it can't use motion vectors, so the quality will always be worse than FSR3FG. AFMF can be used only on RDNA3.
Post by: Calamity on October 03, 2023, 12:46:45 pm
What's new in Switchres 2.002w (October 2023)
- [Linux] Added Switchres fixes to drmkms backend to properly poll dri devices.
--------------
Note: As of 0.259, baseline MAME supports fractional steps in the cpu overclocking sliders, so there's no need for our previous thing since it's officially supported now. Notice that in order to apply fractional steps you must hold the shift key while you use the cursors. Please check that everything works as intended with your previous overclock settings.
Post by: Calamity on October 03, 2023, 12:50:42 pm
Any chance we'll see that H-Freq unlock you mentioned coming in this month's update? Maybe? Possibly? Pretty-please? :D
*fingers-crossed*
If you mean the pixel clock upper limit, unfortunately that's needs an important modification to the AMD adl backend. I'd like to say it should be addressed soon but I can't promise it.
Post by: schmerzkaufen on October 03, 2023, 02:28:04 pm
Post by: RobeeJ on October 03, 2023, 03:29:09 pm
Post by: DJO_Maverick on October 04, 2023, 07:39:14 pm
If you mean the pixel clock upper limit, unfortunately that's needs an important modification to the AMD adl backend. I'd like to say it should be addressed soon but I can't promise it.
Thank you. Looking forward to it, I think it's about the only thing keeping this monitor from its full potential.
For the moment, I've been messing around and finding kind of arbitrary 18:16 desktop resolutions that are just low enough to allow switchres to function correctly for refresh swapping, and then letting the display upscale it... not ideal, but, seems like the least-bad option?
Post by: Milsancho on November 20, 2023, 06:44:00 am
My card is an R7 200 series for a 15khz display and I can't get for the life of me full speed when I set frame_delay at 1 on relatively elementary games like Truxton or the Neogeo with a dual core Pentium G3258 at 4.2ghz, and I refuse to believe that's not enough for stuff like that! I'm not even using superresolutions and the only options I touched were the port audio settings. Am I wrong (and obsolete, lol)?
Post by: Recapnation on November 21, 2023, 07:21:20 am
Quote from: Calamity
In old versions, previous to the existence of fame delay, the emulation speed was assumed to be perfectly constant, so syncaudio was a good compromise to deal with situations where the speed was slightly (or greatly) off 100%, provided it was a constant value. This tipically happened when running vertical games such as 1942 or galaga on a horizontal monitor. The pitch was lowered as a trade-off.
Now, since the introduction of frame delay, it's become common to have "erratic" speed rates, even if just in a few situations. These speed drops cause annoying pitch variations. If these cases are common, it's a better compromise to dissociate audio from video, and just maybe just cope with an sporadic sample underrun that will probably pass unperceived.
Other sources of these speed fluctuations may be the actual apis used for timing in C++, that might be changing their behaviour over time and provide bad measurements on certain hardware. This would explain some appearently random speed flutuations on otherwise perfectly capable hardware.
For all these reasons I think nowadays it's better to leave syncaudio disabled. You'll just notice crackling when speed can't follow the original like with vertical games on horizontal monitor and progressive modes, that you can bypass by lowering -syncrefresh_tolerance.
Maybe it's normal behaviour? Your CPU should be fine.
Post by: Milsancho on November 21, 2023, 09:55:44 am
I tested it with an older Groovymame (previous to v0.220) and it doesn't happen, so I wonder if it's now a normal thing (or non-important stuff related to the apis as you posted)? Windows 7 and d3d ex (video auto) here.
Thanks.
Post by: Recapnation on November 21, 2023, 10:32:55 am
Quote
- From command line, run: groovymame.exe -v romname >romname.txt
- Attach resulting romname.txt file to your post, instead of pasting it.
Post by: donluca on November 22, 2023, 06:30:53 am
Is anyone else with oldish CPUs noticing performance issues with recent Groovymame versions?
My card is an R7 200 series for a 15khz display and I can't get for the life of me full speed when I set frame_delay at 1 on relatively elementary games like Truxton or the Neogeo with a dual core Pentium G3258 at 4.2ghz, and I refuse to believe that's not enough for stuff like that! I'm not even using superresolutions and the only options I touched were the port audio settings. Am I wrong (and obsolete, lol)?
Cpu should be alright, although... only 4.2Ghz?
When I had it for my GroovyMAME box, I had mine hitting 4.8Ghz with two cores and 5Ghz on one core.
You must have been really unlucky with the silicon lottery :/
Post by: RobeeJ on November 23, 2023, 04:52:57 am
Post by: Milsancho on November 23, 2023, 12:59:59 pm
Cpu should be alright, although... only 4.2Ghz?
When I had it for my GroovyMAME box, I had mine hitting 4.8Ghz with two cores and 5Ghz on one core.
You must have been really unlucky with the silicon lottery :/
Do you mean that the CPU should be alright even at 4.2ghz or that I should o'c it even more to be good enough? I'm not sure it'll be safe if I do it with mine, which I got second hand after reading here it was good for Mame, though not in a recent post.
When this happens to me it's usually because I've set the config to somehow not use any hardware video acceleration so the CPU is doing all the upscaling.
Well, I'm testing without any scaling involved, or so I hope. I'm using a CRT and the native resolution. Unless you mean the card config? I haven't even installed anything aside from Emu Driver, so other than Windows resolution manager, I can't tweak much.
Anyway, here's a log.
Average speed: 99.94% (59 seconds)
I used Truxton as it's likely the one I get more speed fluctuations with. To make sure it has nothing to do with scaling, I set the native 3:4 resolution and orientation. This is with frame delay at 2, but it doesn't matter if it's at 1 or at 7 as I mentioned. With this game, I also get speed fluctuations according to Mame's display with frame delay at 0, though a bit less.
Aside from adding some resolutions when launching VideoModeMaker, I followed the guides without touching mame.ini much. The log says also this though: Direct3D: HLSL initialized and I have hlsl_enable at 0, not sure if that's normal?
-With Groovymame 0260 from the github, in case the log isn't noting this.-
Post by: donluca on November 23, 2023, 04:15:25 pm
Do you mean that the CPU should be alright even at 4.2ghz or that I should o'c it even more to be good enough? I'm not sure it'll be safe if I do it with mine, which I got second hand after reading here it was good for Mame, though not in a recent post.
Your CPU should be plenty, I was just pointing out that the G3258 generally OC much higher.
By going higher with the OC, it will give you better performance in 3D titles and will allow you to push frame delay further.
Post by: Calamity on December 03, 2023, 06:31:34 am
What's new in Switchres 2.002x (December 2023)
- [Linux] Add new option -dri_device. Use to force vsync on a specific gpu, e.g. "card0", "card1", etc., or "auto" for automatic selection (currently it will pick the first device with a valid connector.
- [Windows] Raw input improvements. Workaround for devices with buggy drivers. PlayStation triggers hack removed. Should now be compatible with most existing gamepads. [star69rem]
Post by: Milsancho on December 20, 2023, 07:51:01 am
Hello and sorry to ask again about this, but I'm wondering how many of you also get speed fluctuations as mentioned the other day:
Quote
In old versions, previous to the existence of fame delay, the emulation speed was assumed to be perfectly constant, so syncaudio was a good compromise to deal with situations where the speed was slightly (or greatly) off 100%, provided it was a constant value. This tipically happened when running vertical games such as 1942 or galaga on a horizontal monitor. The pitch was lowered as a trade-off.
Now, since the introduction of frame delay, it's become common to have "erratic" speed rates, even if just in a few situations. These speed drops cause annoying pitch variations. If these cases are common, it's a better compromise to dissociate audio from video, and just maybe just cope with an sporadic sample underrun that will probably pass unperceived.
Other sources of these speed fluctuations may be the actual apis used for timing in C++, that might be changing their behaviour over time and provide bad measurements on certain hardware. This would explain some appearently random speed flutuations on otherwise perfectly capable hardware.
For me, the case where I get constant 100% speed has become odd, no matter if audiosync is enabled or not. Is this really assumed to be "normal behaviour"? I really don't know if I should worry about it and try to get new hardware at this point or if emulation isn't actually affected once you set the audio properly per game. No issues at all however with groovymame version 0.218.
Also, what's a good game to configure Port Audio settings in general? I many times get sound crackles, but some times syncaudio solves it. As some games sound better with syncaudio and others without it, should I also configure Port Audio individually?
Post by: Calamity on December 31, 2023, 10:34:08 am
- [nogpu] First release with GroovyMiSTer support. New video backend -video mister for RGB video through network.
More information coming in dedicated thread (http://forum.arcadecontrols.com/index.php/topic,168163.0.html).
Post by: Calamity on January 06, 2024, 01:35:31 pm
- [nogpu] Properly compute pixel aspect ratio of nogpu(MiSTer) screen.
Post by: Calamity on January 18, 2024, 11:28:00 am
- [nogpu]
- Add audio support.
- Various fixes to allow building on Mac [djfumberger]
- Fix blinking on internal FE with lz4
- Avoid modes bigger than RGB buffer (force 640x480)
- Add bilinear filterning, linked to -autofilterAdd audio support.
Post by: Marcoqwerty on February 13, 2024, 07:55:24 am
Im stuck wth the new 0.261 version with win7 and ATI RADEON HD 5450. I tried sever times to reinstall the driver but nohing, GM wont load and immediately close.
All the info and log file there.
https://forum.arcadecontrols.com/index.php/topic,168246.msg1770298.html#msg1770298 (https://forum.arcadecontrols.com/index.php/topic,168246.msg1770298.html#msg1770298)
Is the first time that happen, is the firt time that i will update the set to the last one included GM version.
Calamity told me to update the driver with the "for GCN* cards", but the new ones dont are supported by my graphic card so i cant install them.
Thank you for any kind of help!
Post by: Kabuji74 on February 19, 2024, 09:40:30 am
I've got a problem after jump from my 0.218 groovymame setup to recent 0.261:
My vertical games on my second tv crt screen (manually rotated on its right side) are no longer properly displayed, instead I've got strange behavior.
Game is displayed, stretched, on the first top half part of my first horizontal screen and of course not entirely displayed. Image on the second tv (the vertical one) shows the windows desktop but stretched too.
So my set is compose by two sony crt trinitron tvs, one horizontal and the other is vertical. The horizontal one is plugged on the DVI-I connector of my Radeon HD 7950 and the other on the HDMI one with HDMI to VGA adapter.
I precise that it works well on Groovymame 0.218.
----EDIT---
I added my ini files.
Thank you in advance for your help.
Post by: JPetersen on February 20, 2024, 07:34:07 pm
Post by: Kabuji74 on March 07, 2024, 04:26:17 am
Hi all and thank you very much to continue the excellent work !Hi all, sorry to insist but is anyone has inputs to how new switchres and groovymame versions deal with several crt screens and tate mode ?
I've got a problem after jump from my 0.218 groovymame setup to recent 0.261:
My vertical games on my second tv crt screen (manually rotated on its right side) are no longer properly displayed, instead I've got strange behavior.
Game is displayed, stretched, on the first top half part of my first horizontal screen and of course not entirely displayed. Image on the second tv (the vertical one) shows the windows desktop but stretched too.
So my set is compose by two sony crt trinitron tvs, one horizontal and the other is vertical. The horizontal one is plugged on the DVI-I connector of my Radeon HD 7950 and the other on the HDMI one with HDMI to VGA adapter.
I precise that it works well on Groovymame 0.218.
----EDIT---
I added my ini files.
Thank you in advance for your help.
Thank you in advance for your help .
Envoyé de mon iPhone en utilisant Tapatalk
Post by: Calamity on March 07, 2024, 05:04:31 am
Hi all, sorry to insist but is anyone has inputs to how new switchres and groovymame versions deal with several crt screens and tate mode ?
Thank you in advance for your help .
Hi,
Your log looks perfect. It should work just like it is. I work here with 2 screens and don't have that problem. Are you using a extended desktop on both screens, right? Have you tried moving the relative positions of the screens in Windows' display settings (moving [1] <-> [2] around)?
Post by: Kabuji74 on March 08, 2024, 08:43:51 am
Thank you for you reply.
Yes my desktop is extended on my two screens. screen 1 is the one in Tate mode (simply puted on its right side, i had not change the screen orientation in Windows)
Moving screens positions seems not to do anything
Envoyé de mon iPhone en utilisant Tapatalk
Post by: Kabuji74 on March 08, 2024, 08:46:14 am
Envoyé de mon iPhone en utilisant Tapatalk
Post by: Calamity on April 02, 2024, 04:11:53 pm
What's new with Switchres 2.220b:
[nogpu] New option -[no]mister_interlaced_fb: if enabled, odd and even fields of interlaced modes are sent separately (as in previous releases). If disabled, both fields are sent together and the fpga will pick the correct one based on its current raster status (this avoids field synchronization issues, but requires higher bandwidth).
[nogpu] New input backend -joystickprovider mister: allows using gamepads connected to the MiSTer (2 players).
Both features require up-to-date groovymister core.