What's new in SwitchRes v0.015m- (Windows 7+) Preliminar support for the new BGFX renderer
(currently only DirectX 11). Mode setting is implemented. Dynamic resolution switching may be buggy yet. Frame delay not implemented yet.- (Linux) New implementation of the SDL 2.0.4+ input fix
(Doozer).- (AMD ADL) Fix for refresh value being shown incorrectly on internal UI.
(Reported by haynor666).What's new in SwitchRes v0.015l-final (cumulative fix)- Added support for AMD HD 5000/6000/7000 series.
You'll need CRT Emudriver 2.0 for Windows 7/8/10
.- ATI legacy cards (HD 2000/3000/4000): fixed halved refresh of interlaced modes on vsync with Direct3D
(only if sync polarity is set to positive, details below).- Removed frogger/galaxian patch
. As suggested by haynor666.
- (fix 1-2) Correcty assign sync polarity to ATI legacy cards. This reverts initial 0.015l attempt to fix issue related to halved refresh of interlaced modes with Direct3D on Windows 7+. Now, manually forcing positive vertical sync polarity (+vsync) will effectively bypass the problem, although because most arcade monitors and TVs require negative sync polarity, this method won't work in most cases (out of sync video). However, if you use a device that properly handles the sync signals between the video card and the monitor, such as the UMSA, this method will work great.
- (fix 3) Solves crash affecting AMD HD 5000+ cards.
- (fix 4-5) (Linux) Fixes input for SDL 2.0.4 (Doozer). Caused by MAME window not receiving input focus in the absence of a window manager.
- (fix 5) (Windows) Fixes Powerstrip support.
- (fix 6) (Linux) Fixes bug with SDL build where GroovyMAME would freeze at the combination of -nomodeline_generation and -monitor lcd (reported by RobertJ)
- (fix 6) (Windows) Properly tell apart system modes.
- (fix 6-7) (Windows, AMD 5000+) Fixes crash caused by GroovyMAME attempting to switch the interlace feature of a given modeline in the same session, when using Direct3D 9ex (reported by intealls).- (fix 7) (Windows, AMD 5000+) Correctly assing sync polarity to AMD HD 5000+ cards.
Because AMD documentation is wrong, GroovyMAME/VMMaker where assigning the polarities the wrong way. This must be the direct cause of most out-of-sync issues reported till now. What happened is that GM assigned positive sync instead of negative, and vice versa. This is fixed now, but you'll need to update your crt_range definitions
, both in VMMaker and GroovyMAME. By default, negative sync (0) is what should be used in most cases. Thanks to intealls for doing proper checks with an oscilloscope and R-Typer for double-checking.
- (fix 7) Use 6 decimal figures for refresh values (Doozer).
- (fix 7) (Linux) Disable -syncrefresh when DRI can't be accessed (suggested by Doozer).
- (fix 7) (Windows) Properly report the refresh when using Powerstrip with a -ps_timing string (reported by sean_skroht).
- (fix 7) (Windows) Fixes bug preventing -nomodeline_generation from working (reported by Cisek).
- (fix 7) (Windows) Fixes issue with Attract-Mode front-end loosing focus on GroovyMAME exit (intealls).What's new in SwitchRes v0.015k- Improved audio/video synchronization [intealls]:
now the audio update code is called per frame, right after the video update, instead of being scheduled based on an alien timer. This is important for time-critical audio implementations such as ASIO.What's new in SwitchRes v0.015j- Direct3D9ex support [koopah, intealls] (new option: -video d3d9ex):
now GroovyMAME supports Direct3D9ex, which is present in all versions of Windows starting with Vista. This allows the application to take control of the frame latency and force it to the minimum allowed by the driver, avoiding the dreaded frame queues. This is specially useful in the situations where frame_delay can't be used reliably without tearing (LCDs, high resolutions). Besides, Direct3D9ex seems to perform better for certain hardware (Nvidia, Intel), so it may be preferred to plain Direct3D9 in general.- Frame delay (improved) [intealls, Calamity]:
now frame_delay polls the video driver for absolute scanline values, totally bypassing the default vertical synchronization functions. Some of the advantages are:
- Vsync offset [intealls] (new option: -vsync_offset):
- Improved stability of the vertical synchronization mechanism, that finally makes it possible to extend GroovyMAME's audio/video synchronization to the frame delay use case.
- Awareness of the raster position and notification of missed retraces.
- Allows for anticipating the vertical retrace accurately (see vsync_offset, below).
forces render to happen a certain number of lines before the vertical blank (e.g. -vsync_offset 200). At high resolutions (LCD, etc.), the time it takes the GPU to scale a frame starts being longer than the blanking period itself. This is specially true when HLSL is used. This appears as static tearing when frame_delay is used. To compensate this issue, vsync_offset forces the render code to be called a number of lines ahead of time. Ideally, using a proper value realigns the render completion with the end of the blanking period, cleanly removing all tearing, even on LCDs with frame_delay and HLSL enabled. In practice, you need a fairly fast card in order to fully remove tearing. The higher the tearing line appears on the screen initially, the faster your card is, and the more chances of completely hiding tearing through -vsync_offset. Notice that you'll need to lower your frame_delay value proportionally to the amount of lines you set in -vsync_offset.What's new in SwitchRes v0.015i
- Fixed broken mouse/trackball in SDL (VeS).
- Disabled prescale settings for vector games in SDL (now Windows and SDL builds behave the same).
- Fixed logging of option settings in SDL.What's new in SwitchRes v0.015h
- Forced prescale value to 1 when using HLSL and GLSL filters. Avoids warnings and problems.What's new in SwitchRes v0.015g
- Added support for video mode switching with the OpenGL renderer in Windows (-video opengl). Notice that in order to get any vertical synchronization through the OpenGL renderer, the WGL_EXT_swap_control
extension must be present in the system, otherwise the emulation will run unthrottled. This seems to be totally driver dependent. Not a real alternative to Direct3D at the moment.What's new in SwitchRes v0.015f
- Fixed bug in modeline scoring system that caused incorrect mode selection when running 60.606 Hz games (e.g. frogger) at their native orientation using certain monitor presets.What's new in SwitchRes v0.015e
- Starting from this version hiscore.dat must be placed in the same folder where mame.exe is
, instead of inside the .\hi directory as before. This is to avoid confussion to new users. Please make sure to move hiscore.dat to the right place if you're upgrading from previous versions.
- Now GroovyMAME code relies on a simplified osd-independent version of MKChamp's hiscore patch. It's purpose is to make it easier to update both patches on the new update schedule, by keeping their entanglement as shallow as possible.What's new in SwitchRes v0.015d
- Frame_update method slighty reorganized to improve -frame_delay efficiency. Should fix previous issues with analog controls.What's new in SwitchRes v0.015c
- Support for rotated desktops (Windows & Linux).
- E.g. if you have your desktop rotated 90º, launch GroovyMAME like this: groovymame.exe 1942 -monitor vertical -aspect 3:4
("Magic" resolutions won't work with rotated desktops. If you're still using them we encourage you to move to "super" resolutions).
- Finally proper support for "super" resolutions (Windows & Linux):
- Fix for modeline scoring to properly select the best available "super" resolution.
- Fix for blank UI due to wrong scaling when in rotated mode and using "super" resolutions.
- Fix for vector games that didn't show when using "super" resolutions.
- Moved our official build to SDL2 (Linux):
- Fix for SDL2 broken waitvsync feature, now we perform vsync through DRM.
- Fix for SDL2 broken mode switching feature while in fullscreen.
- Added support for asynchronous rendering (equivalent to -triplebuffer in Windows).
- Full logs back in working order.What's new in SwitchRes v0.015b
- New fix for Windows 7 progressive/interlaced mode switching with DirectDraw, now also works with ArcadeVGA 3000 (thanks to Sledge & sean_skroht).
- Fix in the modeline scoring system so that it properly accounts for the refresh rate when -nomodeline_generation is used (reported by Haggar).What's new in SwitchRes v0.015a
- Change that makes the built in UI useful for selecting games with a joystick. Now all games in the directory are listed in alphabetical order (patch by cools).
- Fix for mouse devices that stopped working properly since a previous change (reported by Endprodukt & sean_skroht).
- Fix for SDL Linux to allow dynamic refresh switching even when resolution doesn't change, required for variable refresh capable LCDs (patch by eldiau)
- Now the -prescale settings are not applied with HLSL on, this fixes previous video issues (suggested by lettuce).
- Now when using interlaced modes in Windows 7 -video ddraw is automatically selected, in order to avoid the refresh rate being halved.What's new in SwitchRes v0.015
- Automatic modeline generation now can be enabled/disabled (new option -modeline_generation)
: now GroovyMAME can pick your installed modelines as use them as read-only (-modeline_generation 0), or update them dynamically with its automatic modeline generation engine (-modeline_generation 1). In all cases, modelines are evaluated to check their frequencies against your defined monitor working ranges. This option is meant for users who have customized their modelines by using external software like Arcade_OSD, and want GroovyMAME to pick their modelines and only their modelines.
- User defined modelines (new option -modeline)
: now you can pass a raw modeline to GroovyMAME and it will use it! This makes full control of video timings possible for advanced users. Just add a line like this in your game or driver .ini file:
modeline "320x240_60 15.91KHz 60.05Hz" 6.62 320 344 376 416 240 244 247 265 -hsync -vsync
The only requirement is to have a modeline already available in the system with the same active width and height. Note that magic resolutions also work here, so it's enough to have a magic resolution with the proper height available. Warning: user defined modelines frequencies are NOT checked. Use it at your own risk. This option is provided to allow full freedom for advanced users. Your monitor settings will be overridden and a custom monitor range will be created on the fly to accommodate your modeline. As suggested by rCadeGaming.
- Cleanstretch feature (improved)
: now the -cleanstretch option admits these values:
* 0 (in mame.ini) = auto, this value allows GroovyMAME to decide whether to use integer scaling.
* 0 (in specific .ini or command line) = force fractional scaling.
* 1 = force integer scaling in both axis.
* 2 = fractional scaling for x-axis, integer scaling for y-axis. This option is manual only (can't be selected automatically). As suggested by Cools.
- Resolution masks (new)
: now you can specify resolution wild cards like this: -resolution 640x0 or -resolution 0x480, where '0' is a wild card value. As suggested by Dr.Venom.
- Changeres (improved)
: now dynamic resolution switching inside games only happens if the resulting modeline actually changes. Scaling options, on the other hand, are dynamically updated. This feature, in combination with resolution masks, makes possible to use "super-resolutions" to achieve seamless resolution switching for systems that change the active width frecuently, like the Megadrive. As suggested by Dr.Venom.
- Frame_delay (improved)
: reduced input latency thanks to improved -frame_delay option, check this thread for more information: http://forum.arcadecontrols.com/index.php/topic,133194.0.html
- Audio latency
now admits fractional values (e.g.: -audio_latency 1.5): this makes it possible to find the optimal system specific glitch-safe audio latency value with finer granularity. As suggested by Dr.Venom.
- Black frame insertion
(new option -black_frame_insertion): enables black frame insertion, to eliminate eye-tracking motion blur for both CRT and LCD monitors (more information: http://www.blurbusters.com/
). It requires a 120 Hz capable display. You need to define either a 120 Hz monitor preset in mame.ini or use a 120 Hz desktop resolution. Then set "black_frame_insertion 1" in mame.ini, this will allow GroovyMAME to enable black frame insertion when required.
- Multi-monitor support
: SwitchRes can only target one single monitor at a time, defined by index #0 of the per-window options (screen/aspect/resolution/view). But now, you can have two or more full screen displays at once: SwitchRes will operate on screen #0, and the other screens will be handled by default MAME video functions.
groovymame.exe orunners -numscreens 2
- LCD marquee support
: as a consequence of multi-monitor support, now you can use GroovyMAME with an LCD secondary monitor for marquees. You have to set "use_marquees 1" in mame.ini, use a layout that contains marquee artwork, and these options:
groovymame.exe 1942 -numscreens 2 -view1 marquee
- Video timings now saved in .cfg
: now GroovyMAME saves the modeline used in the game's specific .cfg file. This feature, combined with GroovyMAME now accepting modelines from .ini files, will allow future third party applications to interface with GroovyMAME's video timing configuration.
- New monitor presets
* pc_31_120: a preset for 120Hz capable PC CRT monitors, at 31kHz (VGA). Designed for hardware scanlines by frequency doubling. Black frame insertion recommended.
* pc_70_120: same as pc_31_120, but for monitors capable of up to 70kH (SXGA).
* r666b: Rodotron 666B-29 (by rock145).
- General re-adjustment
of existing monitor presets (specifically line boundaries between 24 and 31 kHz ranges).
- New option -ps_timing
. By using this option you can pass GroovyMAME a Powerstrip timing string, which GroovyMAME will pass to Powerstrip unmodified. This is meant to use modes that have been manually pre-adjusted with Powerstrip. One possible use of this feature is to allow ArcadeVGA 3000 users customize each mode, even have many instances of them with different refresh rates.
To get a timing string, select the mode in Powerstrip, and in "Advance Timing Options", click the copy to clipboard button, on the bottom right part of the window. This will copy this information to the clipboard:
PowerStrip timing parameters:
Generic timing details for 1366x768:
HFP=36 HSW=48 HBP=42 kHz=47 VFP=3 VSW=5 VBP=6 Hz=60
VESA detailed timing:
PClk=69,84 H.Active=1366 H.Blank=126 H.Offset=20 HSW=48 V.Active=768 V.Blank=14 V.Offset=3 VSW=5
Linux modeline parameters:
"1366x768" 69,840 1366 1402 1450 1492 768 771 776 782 -hsync -vsync
The line we're interested in is the first one. Just grab the row of numbers after the "=", and use it to fill in the ps_timing option in mame.ini, like this:
powerstrip 1What's new in SwitchRes v0.014b
- First version with native Windows 7 support, getting things ready for the advent of CRT Emudriver for Windows 7.
- Workaround for progressive/interlaced mode switching in Windows 7 and DirectDraw.
- Changed DirectDraw to use flipping surfaces with -waitvsync too, to allow bilinear filtering in Windows 7. Also fixes the problem of -waitvsync resulting in double speed in Windows 7. However, it may cause tearing on LCD displays when using DirectDraw, so make sure to use Direct3D with LCD monitors.
- Fixed crash on exit for 32-bit builds on Windows 7.What's new in SwitchRes v0.014a
- Fixed bug that made some games appear mirrored or upside-down.
- Fixed incorrect monitor presets: ms2930, k7000
- Added two new settings for the -orientation
. Use either one of those in case you have a vertically mounted monitor so to specify its correct rotation direction.
- Improved filtering of system resolutions to avoid triplicated enumeration in some systems.
- Now the GroovyMAME version is prompted after the main version so we no longer create conflicts with frontends which grab the version of MAME from the credits text.What's new in SwitchRes v0.014
- Fully rewritten modeline engine. Redesigned algorithm for resolution picking, now each resolution reported by the system is evaluated individually according to your monitor specs.
- Full PowerStrip integration, so at least in theory many more cards are now supported (i.e NVidia).
- Support for VESA generalized timing formula (GTF), this is to provide quick support for multisync PC CRT monitors (not for the ancient fixed-frequency ones!). Use the monitor presets labeled as "vesa".
- New monitor presets added. Check the most suitable for you:
custom Define your own custom by means of -crt_range lines
pal PAL TV - 50 Hz/625
ntsc NTSC TV - 60 Hz/525
generic_15 Generic 15.7 kHz
arcade_15 Arcade 15.7 kHz - standard resolution
arcade_15ex Arcade 15.7-16.5 kHz - extended resolution
arcade_25 Arcade 25.0 kHz - medium resolution
arcade_31 Arcade 31.5 kHz - high resolution
arcade_15_25 Arcade 15.7/25.0 kHz - dual-sync
arcade_15_25_31 Arcade 15.7/25.0/31.5 kHz - tri-sync
m2929 Makvision 2929D
d9200 Wells Gardner D9200
d9400 Wells Gardner D9400
d9800 Wells Gardner D9800
k7000 Wells Gardner K7000
k7131 Wells Gardner 25K7131
m3129 Wei-Ya M3129
h9110 Hantarex MTC 9110
polo Hantarex Polo
pstar Hantarex Polostar 25
ms2930 Nanao MS-2930, MS-2931
ms929 Nanao MS9-29
vesa_480 VESA GTF
vesa_600 VESA GTF
vesa_768 VESA GTF
vesa_1024 VESA GTF
Note: labels are no longer case sensitive
- New format for defining custom monitor specs, now the -crt_range0-9 options are used. This is the most important change in this version from the user's point of view, as the existing custom definitions will need to be modified. Not big deal however, but make sure you understand how this works as it will guarantee your success with GroovyMAME. The usual timing values remain the same, but the line limiters are replaced by four values: ProgressiveLinesMin, ProgressiveLinesMax, InterlacedLinesMin, InterlacedLinesMax. These are used to easily define the upper and lower limits of the total logical resolutions GroovyMAME should allow, both for the progressive and the interlaced range. You may leave either one of the two ranges set as zero in case you do not want progressive or interlaced modes to be generated. So the current format is as follows:
-crt_range 0-9 HfreqMin-HfreqMax, VfreqMin-VfreqMax, HFrontPorch, HSyncPulse, HBackPorch, VfrontPorch, VSyncPulse, VBackPorch, HSyncPol, VSyncPol, ProgressiveLinesMin, ProgressiveLinesMax, InterlacedLinesMin, InterlacedLinesMax
- Automatic LCD timings generation. This is useful in combination with PowerStrip. Your current timings will be read from PowerStrip and used to recalculate modelines from them. You just need to define the range for the vertical refresh your monitor supports:
- Improved rotation detection, now you can rotate the screen from the internal UI and the video mode will be recalculated properly.
- New priority system for option setting. GroovyMAME will set most of its required options automatically (-syncrefresh, -triplebuffer, -resolution, etc.), overriding the values in mame.ini. However, any other ini you create (rom, driver, orientation, etc.), as well as command line settings, will have higher priority than GroovyMAME's option setting, so you can always force something different if you feel GroovyMAME is not doing things right.
- Resolution forcing. As opposite to previous versions, now you can force the resolution that GroovyMAME picks. GroovyMAME will do its best to acommodate the game's resolution into the one you suggest.
- SwithRes video mode is shown in the Game Information screen. You're gonna love this.
- Automatic syncrefresh/triplebuffer selection. If you leave both options disabled in mame.ini, GroovyMAME will decide which one to use automatically. If the target refresh is achieved, GroovyMAME will select -syncrefresh. On the other hand, if we cannot achieve the desired refresh, due to monitor limitations, triplebuffer is used instead, so that speed is kept at 100% rennouncing to smooth scrolling. You can control how off the obtained refresh must be in order to trigger triplebuffering, by means of the new option -sync_refresh_tolerance. The default value is 2 Hz.
- Frequency scaling. Now GroovyMAME can use a multiple of the target vertical refresh if allowed by the monitor. This can be used in combination with PC CRT monitors which allow frequencies of 120 Hz, in order to achieve low resolution modes with true hardware scanlines. You need to create a custom crt_range for this. By now, -triplebuffer is used automatically for this mode. However, in order to achieve perfect scrolling you will need to use -syncrefresh in combination with -frame_delay 5, provided your system can deal with it.
- Interlace/doublescan modes can now be effectively disabled by means of their respective options. Be aware that SwitchRes does not support doublescan modes in Windows.
- Positive/negative sync polarity support under Windows.
- New option -lock_system_modes for mode filtering. In order to limit the possibility of selecting a potentially dangerous mode, the new option -lock_system_modes will prevent any mode not created by us from being picked. This will enforce GroovyMAME to use custom modes previously generated by CRT_EmuDriver. For non-ATI cards this option will block all modes actually since none of them is recognized as custom. This is the case of NVidia cards in combination with PowerStrip, or the ArcadeVGA 3000, where its custom modes are actually reported by the system as standard modes. So for these cases you should disable this option.
- New option -lock_unsupported_modes. You should only disable this option if you are possitive your system, based on your monitor's EDID, is filtering some modes that you actually created. Otherwise leave it enabled. This option only has effect in combination with -video ddraw.
- New option -refresh_dont_care. The new algorithm will filter resolutions that are out of your monitor specs. Old versions of the ArcadeVGA, as well as the Soft-15kHz program, label all resolutions as 60 Hz. This means that if this value were to be taken seriously, resolutions above 240 lines would be out of range for most arcade monitors. This option is provided in order to cope with this peculiarity, and it basically tells the algorithm to ignore refresh for range checking.
- New option -frame_delay. Delays the start of the emulation of each frame by an amount of time defined in tenths of the frame period length (0-9), in order to give a chance to the emulator to have the most possible updated input for that frame, as an attempt to minimize input lag. A value of 0 corresponds to standard behaviour. This option is experimental, and is known to produce tearing in LCD screens.