MonitorMixer finds mixed multi-monitor layouts & shows layout specs.
(MonitorMixer. Helps you dream up your setup.)
Application
- Name: MonitorMixer
- Version: 1.0 Jan 20, 2016
- Language: AutoIT v3.3.14.2
- Author: Imurst
- Exe & source
attached in zip.
Description
MonitorMixer caters to the complex, varied user requirements of PLP. Mixed-LLL is also supported. Layouts found will visually line up pixels across all screens, once positioned.
Layout matches are found via user-entered monitors &/or the monitor-database. This database is quite thorough & accurate enough; user can update it as they wish (it's not hard).
Detailed results are given in the program-window itself, which can be pasted to e.g. Word. File-dumps are available for global Match ALL reports & monitor lookup tables (for viewing in e.g. Notepad or Excel).
The program's mixed-layout search is thorough. User may therefore need to sift through many mixed-layout results, in order to find the layout best-suited to their needs.
Installation
- Portable, no install. Unzip it (it has accompanying files) to a folder, maybe called MonitorMixer. Make a link to it.
- Manditory files (included in zip): MonitorMixer.exe, Monitors.txt, MonitorMixer_SourceCode.txt.
- Dumped reports & tables will be saved to MonitorMixer's folder.
Basic Usage
1. User can optionally enter their own monitor specs, for a more personalized search. Input boxes include:
A. Viewable size: the actual, measured, diagonal size of your screen. Allows a number up to 11 decimals (which is stupid high; just be accurate). Can be in inches or cm.
B. Resolution X & Y: e.g. 1920 & 1080. Layout type won't change how these should be entered (i.e. enter PLP the same as LLL).
2. Each layout search type will result in a detailed report of all possible mixed matches, based on all user-options chosen.
A. Screen compare: Clicking Run will check if user-entered Center & Side Screen will work as a layout. If successful, the layout specs are displayed.
B. Find side (screenshot at top): Clicking Run will find layouts that work with the user-entered center screen.
C. Find center: Clicking Run will find layouts that work with the user-entered side screen.
D. Match ALL: Clicking Run will search entire database of monitors, against itself. This finds all possible layouts, & dumps resulting reports to file (as it is likely very long). Two files are created:
- Layouts table: each row has 28 columns & includes all layout's specs required for accurate match-validation & reporting. Suitable for Excel. Sorted by layout-viewable-size, then by total-PPI.
- Layouts report: the verbose & formatted version of layouts-table. Designed for Notepad/Word. Layouts are listed & their specs described in readable form.
* Match ALL best-use:
- - Works best for PLP, for which it was created. Running it on mixed-LLL will result in the inclusion of tons of near-LLL layouts. Makes for a long boring report. But it works, & can be tweaked well with user's side-options.
- - Works best with user-option "Hang-by max" set quite high. This is because:
- - - bigger layouts look fine with longer hang,
- - - your huge-layout options increase dramatically.
3. Sift through the layout-results to find a layout that will work well for you.
- The report's descriptive text will help you choose, & disqualify inappropriate choices.
- For example, using a 4K side-monitor lowered to 1280x720 is not ideal, but it's a legit option; so it will show in layout-results, with a suitably negative description).
4. Further homework, once you have chosen a layout-result:
A. You can use SoftTH to see in picture-form what your layout will look like.
- Download SoftTH & use its graphical "SoftTh Config Tool.exe." Enter layout's Resolution specs (only). You can also show the Eyefinity H-shape version of a layout, by adjusting the Position input-box downward for Primary Head (i.e. center monitor).
- SoftTH will show you what layout will look like. Remember, all side-hang past center-monitor will be ignored by games.
B. Find monitor(s) online for purchase with the exact same specs.
- You may find it easiest to start this search at PLP Gaming wiki's Good Monitors pages, where monitors are listed by viewable size, & show brand-examples.
- Remember!
- - It is very important that "viewable size" (diagonal) be the same as shown in program's report. (Marketed "class" sizes can be quite inaccurate & cannot be trusted alone.)
- - If you can't find the viewable size for sale, back to the drawing board. (The database includes some hard-to-find sizes, & the rare one may not actually exist.)
Options
1. Layout type:
A. PLP: Calculations & validation are performed for a Portrait Landscape Portrait layout.
B. Mixed LLL: Calculations & validation are performed for a mixed-Landscape layout.
2. Units: inch/cm. Both user's monitor-input (for Viewable size & side-hang tweaks) & program's output will be in these units (unless specified. For example "PPI" is always inch-based).
3. Side Screen Tweaks:
A. Hang-by max:
Select or enter the maximum amount of extra physical material your sides are allowed to have vertically. I.e. Layout's sides can be #.# physically taller than center. Allows entry accuracy up to 8 decimals, & inch or cm.
Setting this too low will result in fewer search results, while increasing it will result in more. As layout-size increases, more side-hang looks acceptable.
If side-hang is too much, Eyefinity PLP is required to put half that hang on top.
But greater side-hang often increases overall side's width, making them fatter in-game. This is a great way to improve physically narrow-looking sides.
But setting max-hang too high (particularly on smaller layouts) will cause search-results to include ugly long-hanging sides. Very long-hanging sides are never ideal:
- Has 4 sizable mouse troughs to contend with (assuming Eyefinity PLP, where half the hang is stuck on top).
- Bit hard to mount with all that side-hang, unless you own a stand.
- Using a quite-short center with tall sides is a waste of central vision areas, low immersion.
- Works quite poorly in Manual PLP. Many gamers won't care, some will. Manual PLP requires the entire hang be on the bottom for proper gaming experience. So a massive hang quickly runs out of physical clearance, & requires reworking your layout-stand.
* The program's max-hang-check will include PPI variance in its calculation. I.e. the maximum side-hang allowed is a PERCEIVED amount, once layout is positioned. This allows program to accept the cases where a slightly-longer side with a certain PPI will NOT look longer, once positioned.
* When Match-ALL process is used, remember that max-hang is used as a constant while it searches through ALL layouts of all sizes. (Ideally max-hang allowable would slowly adjusted upward, as layouts grow in size; but it does not atm.)
B. Short-by max:
Select or enter the maximum amount that layout's sides can be physically shorter than center. It's a good option if you are in a pinch. Allows entry accuracy up to 8 decimals, & inch or cm.
But zero is the most appropriate value, always. Having sides shorter than center is not good, because gamer must decide one of two evils:
- Play game with its corners cropped off (since sides are too short). Not recommended unless it's a budget too-small overall layout.
- Play game with sides filled proper, but center is letterboxed (black margins top & bottom). This is pure evil, a waste of your center monitor & your central vision areas.
Increasing allowable side-shortness will result in more layout-results, but some will have bit-short sides.
* The program's shortness-check will include PPI variance in its calculation. I.e. the maximum side-shortness allowed is a PERCEIVED amount, once layout is positioned. This allows program to accept the cases where a slightly-short side with a certain PPI will NOT look short, once positioned.
* When Match ALL process is used, remember that it will use your max-shortness entry while it searches through ALL layouts of all sizes.
C. flexFit:
By default flexFit is True, which allows for a generally-suitable, reasonable amount of PPI variance in layout-search.
The amount of variance allowed is safe & good, being completely correctable via monitor positioning.
Some hide-a-bezel layouts will be included in search-results, but not very many (as they have higher PPI variance).
Setting flexFit to False will reduce search's allowable PPI variance. This will have the following effects:
- Far fewer overall layout-results, but the ones found will all be pretty close PPI matches.
- Monitors will either fit dead-flush or very near-flush, & will not need any special positioning to line up pixels.
- Zero chance of hide-a-bezel.
D. noGambler:
By default noGambler is True, which disables "gambler".
Setting this option to False will enable "gambler," which broadens PPI match-range.
This feature works with both flexFit True & False:
- If flexFit is False (i.e. user wants a tight monitor-match), then adding "gambler" will result in slightly less stringent PPI requirements (but still pretty tight).
- If flexFit is True (i.e. user wants a good match but it doesn't have to be tight), then adding "gambler" will result in REAL Gambler layouts being accepted in search-results.
REAL Gambler Layouts Described:
Useful option for either experienced or desparate users to seriously broaden PPI match-range.
PPI variance on gambler-layouts is pretty damn high, but still within reason for a gambler.
The goal of the serious gambling user is either:
- Experienced user: to find more hide-a-bezel layouts, particularly the ones that hide center's bezel (these are often gamblers). The experienced user will find these layouts with lower-chance for higher-awesome.
- Desparate user: to use more flexible PPI match-mechanics for user's problem monitor(s). An "it'll be good enough" mentality.
However, there is always a chance that REAL gamblers won't work out 100% ideal (regarding imprecise pixel line-up or un-ideal gap required for pixel line-up). Ideal outcome may depend on physical bezels' thickness.
E. allowAlt:
By default allowAltSide is True, which allows search-result to include side-monitors with lowered resolutions. This allows for many more potential layout-matches.
The resulting quality of lowering side's resolution is a bit reduced, being less crisp an image.
However, it still looks decent for work/surf & the quality-change is not noticed in game-session.
This is because gamer looks at center monitor, sides are primarily for peripheral vision. Side-quality therefore matters considerably less than center.
Setting this option to False will result in far fewer overall layout-results, but the ones found will all use stock/default side resolutions.
Command Buttons
1. Run: activates layout-search, using all user-input & options chosen. The resulting layouts-report will display in program's window (unless Match ALL, which dumps to file).
2. Copy report: copies program's results-window content to your clipboard (e.g. for paste to Notepad).
3. Clear all: clears these input-widget groups: Center Screen, Side Screen, & results-window.
4. Spec tables:
Dumps to file the monitor spec-tables which comprise the program's database:
- Aspect table (3 columns)
- Stock monitors table (9 columns)
- Alt monitors table (9 columns)
These tables are generated within the program, from the simple core data in Monitors.txt. Latter is easily editable, described somewhere below.
5. Help: puts this text in program's report-window. (Text-source is found at the top of file MonitorMixer_SourceCode.txt)
POWER-USER HELP
Database (tables)
1. Monitors.txt:
This user-editable "table" is the source of all MonitorMixer's internal monitor-specs. It includes ResX, ResY & ViewableSize (in inches) per-monitor, basically from 17" up to 84.6" (there is also a 15.43" & 97.5" included).
These monitors are grouped by same-resolution into sections.
A. Main sections: split by aspect, then numbered & titled e.g. ";1. 16:9, 1.78".
B. Sub-sections: split by resolution & titled e.g. "1.A.", "1.B." etc for all 16:9 resolution varieties. There are also two types of subsections:
- Monitors set at regular stock/default resolution.
- Monitors set at lowered resolution (i.e. "Alt" resolution). These alt-monitor sub-sections are titled e.g. ";1.E. ALT_1".
To update file's monitor specs:
- Close MonitorMixer & open the file (it's in path-to-program).
- Add a new line with your new monitor specs, pasting in where it logically would fit within the current monitors.
- Or remove monitor-rows you don't want to ever be searched, simply by deleting the line or prefix the line with a semicolon.
- Or edit existing monitor-row values, for example to make viewable-size more accurate.
- Rare more complex case: If your new monitor entry's resolution is different than all of the existing sections, you need to
- - Create a new resolution-section:
- - - Title the new section like this (resX,resY & you must use square brackets): [####,####]
- - - Add your new monitor-line beneath it.
- - Create new alt-resolution section(s), if they do not already exist:
- - - Jot down all the possible lowered-resolutions that this new monitor can handle.
- - - Look through the file's whole list of bracketed-lines & see which will need to be added (you want them ALL entered).
- - - If you find some lowered-resolution doesn't exist that should, create it:
- - - - Copy the new section (that you made), & paste it to make a new "alt section".
- - - - Fix this new section's title (to document what it is) & also its square-bracketed resolution (from stock-resolution to alt-resolution).
- Syntax:
- - The file's viewable-sizes must be entered in inches (not cm), which can have up to 11 decimals.
- - Semicolon prefix disables the whole line.
- - Blank lines are ignored.
- - Square-brackets are special. They denote which lines the program should use to create its Aspect table.
2. Dumpable Arrays:
- Aspect: includes ResX, ResY, AspectDec. Sorted by aspect descending. Inch units unless stated.
- Stock Monitors: includes ResX, ResY, ViewableDiag, AspectDec, ViewableWidth, ViewableHeight, PPI, OrigResX, OrigResY. The latter two elements are always zero here. Sorted by PPI descending. Inch units unless stated.
- Alt Monitors: includes same elements as Stock & sorted by PPI too (& uses inch units unless stated). But has two differences:
- - These are all monitors with lowered resolutions. None are stock.
- - OrigResX & Y stores the original stock ResX & Y for this alt-monitor. So ResX & Y are never zero here.
- Match ALL (layouts table): Sorted by layout-diagonal-inches, then by total-pixels, all ascending. Units are either inch or cm (chosen by user). Includes these elements:
- - Layout specs:
ResX, ResY, ViewableDiag, AspectDec, ViewableWidth, ViewableHeight, Ppi, PpiVariance, SID_AccumImg(vert_mm), TtlPxCount, TtlHang, sort
- - Center's specs:
CTR_ResX, CTR_ResY, CTR_ViewableDiag, CTR_Aspect, CTR_ViewableWidth, CTR_ViewableHeight, CTR_Ppi,
- - Side specs:
SID_ResX, SID_ResY, SID_ViewableDiag, SID_Aspect, SID_ViewableWidth, SID_ViewableHeight, SID_Ppi. Also OrigResX, OrigResY. The latter two elements store the original stock ResX & Y on an alt-monitor.
Layout Matching Mechanics (the main ones)
Program compares these key difference between center & side monitors:
1. Accumulated vertical image variance (let's call it "accum"):
It has been implied above that PPI variance is used for testing layouts. This is because no-one knows what "accum" is. But "accum" is actually being used, & not PPI itself.
A. Explained:
- Accum is the keystone of this program. It accurately brings a layout's pixel-lineup variance into real-world terms (in "millimeters of visible difference," positive or negative).
- It accounts for pixel-size's & pixel-total's physical-amplifying-affect on PPI-variance.
- It pinpoints how much more space the game-image will take up vertically, on side-screen VS center-screen, in any monitor scenario. Negative means side-image is shorter than center, & positive means side-image is longer.
- Accum is based partly on PPI. But PPI alone is not good enough for safe matching. PPI is an inaccurate matcher for many layouts, because "allowable" varies by monitor.
- Accum pseudocode (for inches): CtrResY / SidePpi - CtrHtInch.
- Since accum knows whether side-image is short or long, we can know whether to move the side-monitor forward or backward to acheieve perfect perceived pixel line-up. (Moving a monitor very-slightly toward/away from you strongly impacts side-screens' perceived PPI.)
- The amount that side-monitor must be moved is also trackable in an algorithm; though this latter is currently being done with a dictionary-lookup, based on real-world tests (because I didn't feel like making the algorithm, & the current dictionary-lookup works fine).
B. Settings Used: see _IsValidMatch() in source code.
2. Height (i.e. inches/cm):
- Sides are disqualified, for example, if they are either physically too short or aesthetically too tall.
- But the decision-making mechanics are more advanced: program instead uses PERCEIVED height variance. This is more valuable & accurate then a simple height-measurement.
- Perceived height variance is found by using "accum" in its calculation. This tells how much physical height variance will be perceived, once layout is positioned for perfect perceived pixel lineup.
- So for example if a slightly physically-short side-monitor is pulled slightly forward to lineup pixels with center, this side's perceived physical size grows to the eye. Once in proper position, this side could even be perceived as bit taller than center-monitor.
- So for program to be accurate & useful, it must be based on perceived height variance, & not actual measured height variance.
Accuracy
1. This program is a sliding or fuzzy variety, taking non-ideal values & using them to pinpoint good layouts with fairly accurate specs. For this reason, not all layout specs will be dead-on (but close enough).
A. The layout-report prefixes all not-dead-on values with "~".
B. Main e.g.: No length-related value will be dead-on, but close enough. These include heightInch, widthInch, viewableSizeInch, hang-by-amount, PPI & "accum"... think that's it.
C. Input e.g.: The worst inaccuracy source for this program (which is ok) is the original monitor's viewable-size, via user-entered or Monitors.txt.
- This input & table depend entirely on hand-entered viewable-sizes. These sizes are not going to be dead-accurate (but are close enough).
- This means that all values calculated with "hand-entered" viewable-diagonal-values will be as inaccurate as the original value was. However, Monitors.txt is deemed accurate enough, & user just needs to measure proper.
2. Rounding.
This program always rounds internally to 13 digits. That is ridiculously accurate, when you consider inaccuracy from #1 above, & also how little difference it would make to a layout.
This internal accuracy is comfortable overkill, included for future program potential.
But when a difference-value is likely to be very-very-near-zero, AutoIT requires we round to 8 decimals (or it formats). Having to round like this happens rarely & has no negative impact.
Known Issues / Future Improvements
1. Program is released with NO known issues. Program has not yet been thoroughly tested, but it appears accurate & is very useful. Developer will return eventually to test it more thoroughly.
2. Minor Oddities / Potential Improvements:
A. Match-ALL's logical side-hang.
- Max-side-hang (& max-side-short) user-option is a constant. But for a global-match-all, using max-side-hang as a constant is not logically ideal:
- - In this case, max-side-hang would ideally vary by center-screen size. This is because bigger layouts make a longish-hang look smaller & more acceptable.
- - FUTURE IMPROVEMENT?: For Match-ALL process, the hang-by-max should probably become a "class" of hang-by-max instead of a literal hang-by-max amount. Match-ALL's hang-by-max could then range higher as layout-size increases.
B. A layout's height is based on center-monitor's height, not sides. User should always use a full center, with sides tall enough for it.
But If a chosen layout's sides are bit shorter than center, program will still work well, with a minor inaccuracy:
Layout-height & layout-viewable-size are center-height-centric calculations & will be off a bit when sides are short (calcs assuming sides are long enough). Doesn't matter, it's close enough, & only affects output (not impacting actual layout-search).
C. One file-error-type will not get caught atm: if user can't save to disk. Program will just do nothing, but should rather give an error message. Would rarely happen, good enough. FUTURE IMPROVEMENT.
D. Mixed-LLL gets a lot more hits than PLP. This phenomenon is perhaps logical & appropriate, developer does not actually know. Mixed-LLL still needs to be tested proper. But the logic is sound, so mixed-LLL should be as safe as PLP.
3. This program's reports are slightly less verbose than PLP Gaming wiki's layout pages.
- Wiki flags a few more help-details to display. (But wiki is less populated with actual layouts, so program is far better overall.)
- FUTURE IMPROVEMENT?: More report-help-text could be added to this program, but it is very good as-is.
- Wiki help text that is NOT included in program:
- - Monitor type- & availability-related notes are not included in program-report (program has no access to this data, & likely will never be added. Way too annoying & data would get dated quickly).
- - Graphics card requirements lookup is not included in program. Developer decided it didn't fit here. A cleaner report, & gamer can figure card-requirements elsewhere. Plus extreme graphics cards are getting so strong now, makes it harder to describe what exactly is needed. The data gets dated.
- - Amount of hang is bit better described on wiki for small layouts, otherwise program-report is the same.
- - - Small layouts look worse with more hang & big layouts may look fine. So help-text ideally is based on layout-viewable-size. Program ignores this nuance atm. (Note to self: logic in colBJ, Func bones source bottom).
- - Center & side monitor shapes are described in text, but overall layout shape is not.
- - - Layout-shape is the least important to describe, as it has a clear feeling from surrounding report-specs. Layout shape could be coded, but low payoff, low priority. (Func bones at source's bottom.)
- - - Wiki vaguely describes overall layout-shape by grouping them into small/large etc. Program, however, displays layout-viewable-size (this is missing on wiki), & Match-ALL is simply one long list from smallest layouts to largest.
User Rights
- Freely offered code, change it how you want. If interest, there is room for general improvement (& cleanup), & there may be some other use for the code...
- Freely offered monitor specs, do anything you want. Specs have been researched meticulously, but there is room for improvement.
- If you improve either monitor specs file or program's code, please let developer know. Changes will then be checked & added to this original.
- This source code included in MonitorMixer's folder (MonitorMixer_SourceCode.txt).
Disclaimer
- Developer feels program output (with current specs database) is accurate enough to pinpoint good layouts. But developer takes zero responsibility if output is misleading in some way, causing user to either buy a layout that sucks, or miss a layout that's awesome.
- Bezel-3D-thickness is a minor but contributing factor to perceived pixel-lineup & related gaps (when significant PPI variance exists). It is therefore the user's responsibility to consider their own bezels while reading report's positioning instructions.
Login
FAQ
Search
Members
