Integer Scaling Problem

[buvk]

hello - i am trying to setup groovymame on an lcd monitor.  i am having issues getting integer scaling working properly, however it is stretching so that there are no black bars on the top and bottom.

i only modified the following lines in mame.ini

monitor                   lcd
lcd_range                 144-144
cleanstretch              1

Code: [Select]

SwitchRes: v0.015l, Monitor: lcd, Orientation: horizontal, Modeline generation: enabled
SwitchRes: LCD vfreq range set by user as 144.000000-144.000000
SwitchRes: \\.\DISPLAY1: NVIDIA GeForce GTX 570  (PCI\VEN_10DE&DEV_1086&SUBSYS_35101458&REV_A1)
SwitchRes: Device key: System\CurrentControlSet\Control\Video\{A726570E-1DE3-4DD2-8BDB-7E492AC664D7}\0000
Video chipset is not compatible.
Switchres: Searching for custom video modes...
Switchres: [  1]  640x 480 @ 60 : system mode
Switchres: [  2]  640x 480 @100 : system mode
Switchres: [  3]  640x 480 @120 : system mode
Switchres: [  4]  640x 480 @144 : system mode
Switchres: [  5]  720x 480 @ 60 : system mode
Switchres: [  6]  720x 480 @100 : system mode
Switchres: [  7]  720x 480 @120 : system mode
Switchres: [  8]  720x 480 @144 : system mode
Switchres: [  9]  720x 576 @ 60 : system mode
Switchres: [ 10]  720x 576 @100 : system mode
Switchres: [ 11]  720x 576 @120 : system mode
Switchres: [ 12]  720x 576 @144 : system mode
Switchres: [ 13]  800x 600 @ 60 : system mode
Switchres: [ 14]  800x 600 @100 : system mode
Switchres: [ 15]  800x 600 @120 : system mode
Switchres: [ 16]  800x 600 @144 : system mode
Switchres: [ 17] 1024x 768 @ 60 : system mode
Switchres: [ 18] 1024x 768 @100 : system mode
Switchres: [ 19] 1024x 768 @120 : system mode
Switchres: [ 20] 1024x 768 @144 : system mode
Switchres: [ 21] 1152x 864 @ 60 : system mode
Switchres: [ 22] 1152x 864 @100 : system mode
Switchres: [ 23] 1152x 864 @120 : system mode
Switchres: [ 24] 1152x 864 @144 : system mode
Switchres: [ 25] 1280x 720 @ 60 : system mode
Switchres: [ 26] 1280x 720 @100 : system mode
Switchres: [ 27] 1280x 720 @120 : system mode
Switchres: [ 28] 1280x 720 @144 : system mode
Switchres: [ 29] 1280x 768 @ 60 : system mode
Switchres: [ 30] 1280x 768 @100 : system mode
Switchres: [ 31] 1280x 768 @120 : system mode
Switchres: [ 32] 1280x 768 @144 : system mode
Switchres: [ 33] 1280x 800 @ 60 : system mode
Switchres: [ 34] 1280x 800 @100 : system mode
Switchres: [ 35] 1280x 800 @120 : system mode
Switchres: [ 36] 1280x 800 @144 : system mode
Switchres: [ 37] 1280x 960 @ 60 : system mode
Switchres: [ 38] 1280x 960 @100 : system mode
Switchres: [ 39] 1280x 960 @120 : system mode
Switchres: [ 40] 1280x 960 @144 : system mode
Switchres: [ 41] 1280x1024 @ 60 : system mode
Switchres: [ 42] 1280x1024 @100 : system mode
Switchres: [ 43] 1280x1024 @120 : system mode
Switchres: [ 44] 1280x1024 @144 : system mode
Switchres: [ 45] 1360x 768 @ 60 : system mode
Switchres: [ 46] 1360x 768 @100 : system mode
Switchres: [ 47] 1360x 768 @120 : system mode
Switchres: [ 48] 1360x 768 @144 : system mode
Switchres: [ 49] 1366x 768 @ 60 : system mode
Switchres: [ 50] 1366x 768 @100 : system mode
Switchres: [ 51] 1366x 768 @120 : system mode
Switchres: [ 52] 1366x 768 @144 : system mode
Switchres: [ 53] 1600x 900 @ 60 : system mode
Switchres: [ 54] 1600x 900 @100 : system mode
Switchres: [ 55] 1600x 900 @120 : system mode
Switchres: [ 56] 1600x 900 @144 : system mode
Switchres: [ 57] 1600x1024 @ 60 : system mode
Switchres: [ 58] 1600x1024 @100 : system mode
Switchres: [ 59] 1600x1024 @120 : system mode
Switchres: [ 60] 1600x1024 @144 : system mode
Switchres: [ 61] 1680x1050 @ 60 : system mode
Switchres: [ 62] 1680x1050 @100 : system mode
Switchres: [ 63] 1680x1050 @120 : system mode
Switchres: [ 64] 1680x1050 @144 : system mode
Switchres: [ 65] 2715x1527 @ 60 : system mode
Switchres: [ 66] 2715x1527 @100 : system mode
Switchres: [ 67] 2715x1527 @120 : system mode
Switchres: [ 68] 2715x1527 @144 : system mode
Switchres: [ 69] 1920x1080 @ 60 : system mode
Switchres: [ 70] 1920x1080 @100 : system mode
Switchres: [ 71] 1920x1080 @120 : system mode
Switchres: [ 72] 1920x1080 @144* : system mode
Switchres: [ 73] 1440x 900 @ 60 : system mode
Switchres: [ 74] 1440x 900 @100 : system mode
Switchres: [ 75] 1440x 900 @120 : system mode
Switchres: [ 76] 1440x 900 @144 : system mode
Switchres: [ 77]  640x 400 @ 60 : system mode
Switchres: [ 78]  640x 400 @100 : system mode
Switchres: [ 79]  640x 400 @120 : system mode
Switchres: [ 80]  640x 400 @144 : system mode
SwitchRes: Found 0 custom of 80 active video modes
SwitchRes: Creating automatic specs for LCD based on VESA GTF
SwitchRes: Monitor range 169056.00-169056.00,144.00-144.00,0.372,0.460,0.832,0.006,0.018,0.532,0,1,1080,1080,0,0
SwitchRes: -resolution was forced as 1920x1080@144

SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[sfiii3ur1] Calculating best video mode for 384x224@59.583393 orientation: normal

SwitchRes: [ 640]x[ 480]_[60=60.000000Hz] - locked

SwitchRes: [ 640]x[ 480]_[100=100.000000Hz] - locked

SwitchRes: [ 640]x[ 480]_[120=120.000000Hz] - locked

SwitchRes: [ 640]x[ 480]_[144=144.000000Hz] - locked

SwitchRes: [ 720]x[ 480]_[60=60.000000Hz] - locked

SwitchRes: [ 720]x[ 480]_[100=100.000000Hz] - locked

SwitchRes: [ 720]x[ 480]_[120=120.000000Hz] - locked

SwitchRes: [ 720]x[ 480]_[144=144.000000Hz] - locked

SwitchRes: [ 720]x[ 576]_[60=60.000000Hz] - locked

SwitchRes: [ 720]x[ 576]_[100=100.000000Hz] - locked

SwitchRes: [ 720]x[ 576]_[120=120.000000Hz] - locked

SwitchRes: [ 720]x[ 576]_[144=144.000000Hz] - locked

SwitchRes: [ 800]x[ 600]_[60=60.000000Hz] - locked

SwitchRes: [ 800]x[ 600]_[100=100.000000Hz] - locked

SwitchRes: [ 800]x[ 600]_[120=120.000000Hz] - locked

SwitchRes: [ 800]x[ 600]_[144=144.000000Hz] - locked

SwitchRes: [1024]x[ 768]_[60=60.000000Hz] - locked

SwitchRes: [1024]x[ 768]_[100=100.000000Hz] - locked

SwitchRes: [1024]x[ 768]_[120=120.000000Hz] - locked

SwitchRes: [1024]x[ 768]_[144=144.000000Hz] - locked

SwitchRes: [1152]x[ 864]_[60=60.000000Hz] - locked

SwitchRes: [1152]x[ 864]_[100=100.000000Hz] - locked

SwitchRes: [1152]x[ 864]_[120=120.000000Hz] - locked

SwitchRes: [1152]x[ 864]_[144=144.000000Hz] - locked

SwitchRes: [1280]x[ 720]_[60=60.000000Hz] - locked

SwitchRes: [1280]x[ 720]_[100=100.000000Hz] - locked

SwitchRes: [1280]x[ 720]_[120=120.000000Hz] - locked

SwitchRes: [1280]x[ 720]_[144=144.000000Hz] - locked

SwitchRes: [1280]x[ 768]_[60=60.000000Hz] - locked

SwitchRes: [1280]x[ 768]_[100=100.000000Hz] - locked

SwitchRes: [1280]x[ 768]_[120=120.000000Hz] - locked

SwitchRes: [1280]x[ 768]_[144=144.000000Hz] - locked

SwitchRes: [1280]x[ 800]_[60=60.000000Hz] - locked

SwitchRes: [1280]x[ 800]_[100=100.000000Hz] - locked

SwitchRes: [1280]x[ 800]_[120=120.000000Hz] - locked

SwitchRes: [1280]x[ 800]_[144=144.000000Hz] - locked

SwitchRes: [1280]x[ 960]_[60=60.000000Hz] - locked

SwitchRes: [1280]x[ 960]_[100=100.000000Hz] - locked

SwitchRes: [1280]x[ 960]_[120=120.000000Hz] - locked

SwitchRes: [1280]x[ 960]_[144=144.000000Hz] - locked

SwitchRes: [1280]x[1024]_[60=60.000000Hz] - locked

SwitchRes: [1280]x[1024]_[100=100.000000Hz] - locked

SwitchRes: [1280]x[1024]_[120=120.000000Hz] - locked

SwitchRes: [1280]x[1024]_[144=144.000000Hz] - locked

SwitchRes: [1360]x[ 768]_[60=60.000000Hz] - locked

SwitchRes: [1360]x[ 768]_[100=100.000000Hz] - locked

SwitchRes: [1360]x[ 768]_[120=120.000000Hz] - locked

SwitchRes: [1360]x[ 768]_[144=144.000000Hz] - locked

SwitchRes: [1366]x[ 768]_[60=60.000000Hz] - locked

SwitchRes: [1366]x[ 768]_[100=100.000000Hz] - locked

SwitchRes: [1366]x[ 768]_[120=120.000000Hz] - locked

SwitchRes: [1366]x[ 768]_[144=144.000000Hz] - locked

SwitchRes: [1600]x[ 900]_[60=60.000000Hz] - locked

SwitchRes: [1600]x[ 900]_[100=100.000000Hz] - locked

SwitchRes: [1600]x[ 900]_[120=120.000000Hz] - locked

SwitchRes: [1600]x[ 900]_[144=144.000000Hz] - locked

SwitchRes: [1600]x[1024]_[60=60.000000Hz] - locked

SwitchRes: [1600]x[1024]_[100=100.000000Hz] - locked

SwitchRes: [1600]x[1024]_[120=120.000000Hz] - locked

SwitchRes: [1600]x[1024]_[144=144.000000Hz] - locked

SwitchRes: [1680]x[1050]_[60=60.000000Hz] - locked

SwitchRes: [1680]x[1050]_[100=100.000000Hz] - locked

SwitchRes: [1680]x[1050]_[120=120.000000Hz] - locked

SwitchRes: [1680]x[1050]_[144=144.000000Hz] - locked

SwitchRes: [2715]x[1527]_[60=60.000000Hz] - locked

SwitchRes: [2715]x[1527]_[100=100.000000Hz] - locked

SwitchRes: [2715]x[1527]_[120=120.000000Hz] - locked

SwitchRes: [2715]x[1527]_[144=144.000000Hz] - locked

SwitchRes: [1920]x[1080]_[60=60.000000Hz] - locked

SwitchRes: [1920]x[1080]_[100=100.000000Hz] - locked

SwitchRes: [1920]x[1080]_[120=120.000000Hz] - locked

SwitchRes: [1920]x[1080]_[144=144.000000Hz]
   rng(0): 1920 x1080_144.000000p 0.000000 [fract] scale(5, 4, 2) diff(0.00, 15.76, 12.4166) ratio(5.000, 4.821)

SwitchRes: [1440]x[ 900]_[60=60.000000Hz] - locked

SwitchRes: [1440]x[ 900]_[100=100.000000Hz] - locked

SwitchRes: [1440]x[ 900]_[120=120.000000Hz] - locked

SwitchRes: [1440]x[ 900]_[144=144.000000Hz] - locked

SwitchRes: [ 640]x[ 400]_[60=60.000000Hz] - locked

SwitchRes: [ 640]x[ 400]_[100=100.000000Hz] - locked

SwitchRes: [ 640]x[ 400]_[120=120.000000Hz] - locked

SwitchRes: [ 640]x[ 400]_[144=144.000000Hz] - locked

SwitchRes: [sfiii3ur1] (1) horizontal (384x224@59.583393)->(1920x1080@144.000000)
   rng(0): 1920 x1080_144.000000p 0.000000 [fract] scale(5, 4, 2) diff(0.00, 15.76, 12.4166) ratio(5.000, 4.821)
SwitchRes: Modeline "1920x1080_144 0.000000KHz 144.000000Hz" 0.000000 1920 0 0 0 1080 0 0 0   -hsync -vsync
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -autoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -nomultithreading
SwitchRes: Setting option -triplebuffer
SwitchRes: Setting option -nosyncrefresh
SwitchRes: Setting option -nowaitvsync
SwitchRes: Setting option -nohwstretch
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -filter
SwitchRes: Setting option -prescale 3
Video: Monitor 000000000E353128 = "\\.\DISPLAY1" (primary)
Video: Monitor 00000000084DEF48 = "\\.\DISPLAY2"
Direct3D: Using Direct3D 9
window_proc: WM_NCACTIVATE
blit_lock = TRUE
Physical width 1920, height 1080
Direct3D: Configuring adapter #0 = NVIDIA GeForce GTX 570
Direct3D: Adapter has Vendor ID: 10DE and Device ID: 1086
Direct3D: Using dynamic textures
Direct3D: Using StretchRect for prescaling
Direct3D: YUV format = RGB
Direct3D: Max texture size = 16384x16384
Direct3D: Device created at 1920x1080
Direct3D: First scanline: 0, Last scanline: 1079, Break scanline: 1079, Delay scanline: -108
blit_unlock = TRUE
RawInput: APIs detected
Input: Adding Mouse #0: HID-compliant mouse
Input: Adding Gun #0: HID-compliant mouse
Input: Adding Kbd #0: HID Keyboard Device
Input: Adding Kbd #1: HID Keyboard Device
DirectInput: Using DirectInput 8
Input: Adding Joy #0: Saturn_Adapter_2.0
window_proc: WM_PAINT
blit_lock = FALSE
window_proc: WM_PAINT:END
stream_buffer_size = 37888
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels
Region ':bios' created
Starting Street Fighter III 3rd Strike: Fight for the Future (USA 990512) ':'
Optional memory region 'user5' not found
Optional memory region 'user4' not found
  (missing dependencies; rescheduling)
Starting SH-2 ':maincpu'
Starting SCSI Port ':scsi'
Starting SCSI Connector ':scsi:1'
Starting SCSI CD ':scsi:1:cdrom'
Starting CD-ROM Image ':scsi:1:cdrom:image'
Starting CD/DA ':scsi:1:cdrom:cdda'
Starting SCSI Connector ':scsi:2'
Starting SCSI Connector ':scsi:3'
Starting SCSI Connector ':scsi:4'
Starting SCSI Connector ':scsi:5'
Starting SCSI Connector ':scsi:6'
Starting SCSI Connector ':scsi:7'
Starting 33C93 SCSI ':wd33c93'
Starting Video Screen ':screen'
Optional device 'finder_dummy_tag' not found
Starting NVRAM ':eeprom'
Starting palette ':palette'
Starting gfxdecode ':gfxdecode'
Starting Speaker ':lspeaker'
  (missing dependencies; rescheduling)
Starting Speaker ':rspeaker'
  (missing dependencies; rescheduling)
Starting CPS3 Audio Custom ':cps3sound'
Starting Fujitsu 29F016A Flash ':simm1.0'
Starting Fujitsu 29F016A Flash ':simm1.1'
Starting Fujitsu 29F016A Flash ':simm1.2'
Starting Fujitsu 29F016A Flash ':simm1.3'
Starting Fujitsu 29F016A Flash ':simm2.0'
Starting Fujitsu 29F016A Flash ':simm2.1'
Starting Fujitsu 29F016A Flash ':simm2.2'
Starting Fujitsu 29F016A Flash ':simm2.3'
Starting Fujitsu 29F016A Flash ':simm3.0'
Starting Fujitsu 29F016A Flash ':simm3.1'
Starting Fujitsu 29F016A Flash ':simm3.2'
Starting Fujitsu 29F016A Flash ':simm3.3'
Starting Fujitsu 29F016A Flash ':simm3.4'
Starting Fujitsu 29F016A Flash ':simm3.5'
Starting Fujitsu 29F016A Flash ':simm3.6'
Starting Fujitsu 29F016A Flash ':simm3.7'
Starting Fujitsu 29F016A Flash ':simm4.0'
Starting Fujitsu 29F016A Flash ':simm4.1'
Starting Fujitsu 29F016A Flash ':simm4.2'
Starting Fujitsu 29F016A Flash ':simm4.3'
Starting Fujitsu 29F016A Flash ':simm4.4'
Starting Fujitsu 29F016A Flash ':simm4.5'
Starting Fujitsu 29F016A Flash ':simm4.6'
Starting Fujitsu 29F016A Flash ':simm4.7'
Starting Fujitsu 29F016A Flash ':simm5.0'
Starting Fujitsu 29F016A Flash ':simm5.1'
Starting Fujitsu 29F016A Flash ':simm5.2'
Starting Fujitsu 29F016A Flash ':simm5.3'
Starting Fujitsu 29F016A Flash ':simm5.4'
Starting Fujitsu 29F016A Flash ':simm5.5'
Starting Fujitsu 29F016A Flash ':simm5.6'
Starting Fujitsu 29F016A Flash ':simm5.7'
Starting Fujitsu 29F016A Flash ':simm6.0'
Starting Fujitsu 29F016A Flash ':simm6.1'
Starting Fujitsu 29F016A Flash ':simm6.2'
Starting Fujitsu 29F016A Flash ':simm6.3'
Starting Fujitsu 29F016A Flash ':simm6.4'
Starting Fujitsu 29F016A Flash ':simm6.5'
Starting Fujitsu 29F016A Flash ':simm6.6'
Starting Fujitsu 29F016A Flash ':simm6.7'
Starting Street Fighter III 3rd Strike: Fight for the Future (USA 990512) ':'
Optional memory region 'user5' not found
Optional memory region 'user4' not found
  (missing dependencies; rescheduling)
Starting Speaker ':lspeaker'
Starting Speaker ':rspeaker'
Starting Street Fighter III 3rd Strike: Fight for the Future (USA 990512) ':'
Optional memory region 'user5' not found
Optional memory region 'user4' not found
Average speed: 100.00% (55 seconds)
window_proc: WM_NCACTIVATE
blit_lock = TRUE
window_proc: WM_DESTROY
blit_lock = TRUE

anyone have any ideas?

[schmerzkaufen]

I can only tell you what Calamity told me recently;

So, am I correct in assuming cleanstretch only works in specific situations ?

Yes, that's correct. IIRC GM allows a maximum of 10% of borders on the vertical, 15% on the horizontal. If borders resulting from integer scaling are bigger, fractional scaling is applied. If you want higher tolerance you'll need to recompile it with new values. At some point this should be added as an option (maybe for Switchres 0.016).

Personally I'm getting around that by setting values manually via the ingame UI (TAB -> Slider Controls -> Horiz Stretch & Vert Stretch)

It's a bit troublesome to try and find the right values for all the hardwares you're emulating, but the settings will remain saved in each game's individual .cfg so it's a one time job.

We could make lists, sorting by common lcd monitor resolutions and desired integer scaling factors by emulated hardware, but that will take a lot of time lol.

An important note though; just finding the correct integer values for a given base emulated hardware resolution doesn't mean it will hit perfectly every time with every game sharing the same characteristics.
Some games must have been designed with a slight offset, or they're not using the hardware's full available resolution, dunno.
(which is why it's good that each game's settings are saved individually)

An example of x3

Neo Geo 320x224
H. Stretch: 0.942
V. Stretch: 0.876

When you've got more real estate or if you don't mind the picture expanding out of screen limits, then find the values for x4, x5, etc...

To check visually I just slap a 3x3 grid in .PNG over it (or 4x4, whatever the factor of choice) with simple dark grey lines, to see if the pixels are the right size and no scaling artifacts are visible when it's scrolling.

Of course it'd be better to use factors more appropriate to some hardwares, for instance the Capocm CPS1-CPS2 look funny in 3x3, all sguished;
CPS1-CPS2 384x224
H. Stretch: 1.130
V. Stretch: 0.876
... it fits my little hd-ready tv, but not looking right of course.

[buvk]

thanks for the reply.  i was going crazy trying to get it to scale properly.  glad its not just me.

anyways, when I use the built in scaling the image does not look as crisp (at least i don't think it does?).

i am scaling horizontal and vertical to 0.83 since i want to keep maintain the aspect ratio

[schmerzkaufen]

The horizontal value is not the same you have to set the proper otherwise you'll see scaling artifacts when it's scrolling, for Capcom cps1/cps2/cps3 on a 1920x1080 display it's H. Stretch 0.800 (x4) I believe, or something close, play Progear for instance and you'll see if it's right or not.

And if you decide to go big (out of screen limits) it is;

H. Stretch 1.066 (x4)
V. Stretch 1.036 or 1.038 (x5) -> there's a problem here as it's still off by something like a single pixel. the sliders only work by 2x increments unfortunately.

You'll lose a bit of the game's picture on all sides but depending on the game you're playing it is perfectly acceptable, like playing on a crt with slightly too much overscan.

PS: by the way regarding the horizontal stretch and going beyond limits, I never knew until I've tried that MAME had internal 'borders', like it's displayed inside an unseen 4:3 frame.

[Calamity]

I'm thinking there's another way to force integer scaling even in cases where it leads to huge borders. Sorry I didn't think of it before.

So say you have a 1080p LCD. GM will use fractional scaling for 224p games, because 224 x 4 = 896, that leaves 184 lines for borders, a 17% which is considered excesive by GM. Until we have an option to set what is excesive for us, we can do the following.

Run this command (this assumes monitor is set as "lcd"):

Code: [Select]

groovymame.exe sfa3 -v >sfa3.txt
Now open the resulting log. At some point you'll find a line that looks like this:

Code: [Select]

SwitchRes: Monitor range 66375.00-68625.00,59.00-61.00,0.593,0.297,0.998,0.059,0.074,0.534,0,0,1080,1080,0,0
That's a dummy monitor range GM builds in order to represent your LCD. What we're going to do is to use this line as a custom crt_range, editing crt_range0 in mame.ini, with this:

Code: [Select]

crt_range0                66375.00-68625.00,59.00-61.00,0.593,0.297,0.998,0.059,0.074,0.534,0,0,896,1080,0,0
Notice that I've changed the first 1080 value by 896. This tells GM 896 is a valid vertical resolution.

Finally, we must edit these options:

Code: [Select]

monitor custom
resolution 1920x1080

The "monitor custom" option is needed if we want GM to actually use our custom crt_range. The resolution option is required to replicate our previous "monitor lcd" setting we're bypassing.

This will work for resolutions as low as 224p. If you want to go lower than that, just use a lower value in the crt_range. Obviously, it will produce huge black borders.

[schmerzkaufen]

Oh nice ! I will try it.

... Is it possible to use the same trick to do it the other way too ? (bigger than screen)

On a side note, while I was looking for proper values in the UI, I was wishing there were two more 'sliders' allowing to select "H. Stretch x2 x3 x4...," and "V. Stretch 2 x3 x4..." instead of those obscure values that don't even tell the current achieved stretched output.
But that's a UI thing so maybe it's impossible without big consequences. Also there'll be a new UI soon so I can't even.

[buvk]

so i have this:

Code: [Select]

SwitchRes: Monitor range 169056.00-169056.00,144.00-144.00,0.372,0.460,0.832,0.006,0.018,0.532,0,1,1080,1080,0,0

i edited mame.ini as follows:

Code: [Select]

monitor                   custom
crt_range0                169056.00-169056.00,144.00-144.00,0.372,0.460,0.832,0.006,0.018,0.532,0,1,896,1080,0,0
resolution                1920x1080

i get these errors:

Code: [Select]

SwitchRes: hfreq_min 169056.00 out of range
SwitchRes: Error in monitor range (ignoring): 169056.00-169056.00,144.00-144.00,0.372,0.460,0.832,0.006,0.018,0.532,0,1,896,1080,0,0
SwitchRes: could not find a video mode that meets your specs

the game launches but fills up the entire 1920x1080 window

[Calamity]

That's because 1080p@144 Hz hits GM's sanity checks for hfreq, I need to fix that. Just try with the range I posted, it should work.

[buvk]

thank you.  using your range works.  vertical looks good now, however the picture stretches horizontally.  i've tried toying around with the aspect ratio but have not been able to get it right.

i am also limited to 60hz refresh as opposed to 144 (i think this is due to the sanity checks?).

[Calamity]

I doubt it stretches it horizontally. Integer scaling works in both axes. The issue is big top/down borders must be ruining aspect ratio. That's why GM is not applying integer scaling in the first place.

(Let me ask why you guys want to force integer scaling in all situations. You need a really high resolution monitor for this to be possible without big compromises)

The refresh limitation is indeed due to the hfreq check I mentioned. I believe I set the limit to accommodate 1600p@60Hz which was probably the highest thing at the time. This value needs to be updated. It's an easy fix if you can roll your own build.

[Calamity]

Oh nice ! I will try it.

... Is it possible to use the same trick to do it the other way too ? (bigger than screen)

On a side note, while I was looking for proper values in the UI, I was wishing there were two more 'sliders' allowing to select "H. Stretch x2 x3 x4...," and "V. Stretch 2 x3 x4..." instead of those obscure values that don't even tell the current achieved stretched output.
But that's a UI thing so maybe it's impossible without big consequences. Also there'll be a new UI soon so I can't even.

Yeah in a future iteration of Switchres I'm planning to provide full control on the scaling factors, although I was thinking of making them normal mame.ini options rather than sliders. I believe this is necessary, even if only for testing purposes.

Regarding the possibility of GroovyMAME clipping the game frame, this has been suggested before, but it's difficult to make it work with the current implementation without major changes. Basically the problem is the whole modeline engine is built on the premise that the frame must fit in the screen. In other words, negative borders are not possible. From GM's perspective, borders have a "physical" meaning, in direct relation with the resulting frequencies. Negative values are absurd from that point of view. I don't mean it would be impossible to implement but it'd require important changes with great probability of breaking lots of things.

[schmerzkaufen]

Yes even I can understand it is unconventional and unexpected. It's not a big problem if those inner borders remain, it's only the vertical ones that get in the way, but if my horizontal factor of choice makes a lot of the picture disappear behind those then it means I'm too far off a decent factor or ratio anyway.

One thing I don't get though is how the UI settings let me stretch beyond (it's good because I want it sometimes) without breaking Switchres's job, is it because the OSD video is somewhat not 100% tied together with it or something ? (maybe the same reason why I can set some things in separate higher priority .INIs)

[buvk]

I doubt it stretches it horizontally. Integer scaling works in both axes. The issue is big top/down borders must be ruining aspect ratio. That's why GM is not applying integer scaling in the first place.

(Let me ask why you guys want to force integer scaling in all situations. You need a really high resolution monitor for this to be possible without big compromises)

The refresh limitation is indeed due to the hfreq check I mentioned. I believe I set the limit to accommodate 1600p@60Hz which was probably the highest thing at the time. This value needs to be updated. It's an easy fix if you can roll your own build.

the picture does indeed stretch horizontally.  following your instructions i get black bars on the top and bottom, however the picture stretches fully horizontal (no black bars on the sides).

to answer your question, integer scaling produces the sharpest possible picture in my opinion.  i'm not really concerned about black bars on the top or bottom.

[schmerzkaufen]

Mmh *scratching head* lets see if we're seeing the same thing;

So I was talking about the case when we stretch with factors beyond the screen (so we don't have black borders but the opposite: lines left out);
- Vertically we hit the upper and bottom limits of the screen, and go beyond (x5), so no black bars.
- Horizontally at some point (x4) we hit an inner border (what's making the video zone the 4:3 pillarboxed required by Switchres if I understood correctly) and here in my case I'm seeing portions of the picture disappear left and right behind the inner black pillars.
But you're saying you don't have those pillars ? (or maybe you haven't yet tried the 'bigger' factors I'm talking about)

But if that's the case maybe it has to do with the screen resolution and screen aspect ratio I've set in the .ini (resolution auto , aspect 16:9) ?

I should draw the stuff I'm talking about sometimes and post screenshots instead of trying with words. 

And yes naturally integer is better, that's why I too am always going for it.
Even the crude bilinear filter looks better when the image under it is scaled properly, scanlines/mask overlays become immensely easier to use, and well it's even useful for many post-processing scenarios.

[Calamity]

Just to clarify: I know what's good about integer scaling. What I mean is: unless you have a very high resolution (much higher than 1080p) you're not going to find nice integer multiples for many resolutions that at the same time preserve the aspect ratio.

Regarding buvk issue with horizontal stretching, I gues he didn't set the correct aspect ratio in mame.ini (aspect 16:9).

[buvk]

Just to clarify: I know what's good about integer scaling. What I mean is: unless you have a very high resolution (much higher than 1080p) you're not going to find nice integer multiples for many resolutions that at the same time preserve the aspect ratio.

Regarding buvk issue with horizontal stretching, I gues he didn't set the correct aspect ratio in mame.ini (aspect 16:9).

hello.  doing this does scale the game to 1536x896 (4x integer scale), however, in doing so, GM no longer enforces the 4:3 aspect correction to display the game the way it was meant to be displayed.

[schmerzkaufen]

Just to clarify: I know what's good about integer scaling. What I mean is: unless you have a very high resolution (much higher than 1080p) you're not going to find nice integer multiples for many resolutions that at the same time preserve the aspect ratio.

Personally I think it's still useful in many, many situations, even with small screens, like yesterday I've tried the Cave shooters on my laptop with its 1600x900 display, quite the low vertical real estate, hard to enjoy vertical games on it. (no before people ask I don't physically rotate my laptop ^^)
So I've integer-stretched the games to 720x960, losing 30 lines of the picture on top and bottom, but those are the areas where the score and stocked bombs are usually displayed, so I didn't lose much vital information for playing the games. But I've gained room horizontally, bigger sprites and bullets.
Then I've applied bilinear, or just a simple scanlines overlay, and both looked excellent despite the small size. Bigger, cleaner, prettier, even with a small display = more playable.
Of course using my small hd-ready TV with 768 lines I wouldn't find the same advantages, but in this case it's all other vertical shooters with 384 H. size that will look good.
PS: plus I bet there's no need to detail how good the ton of 224 V. sized games in normal landscape orientation look when integer-scaled on that puny 1600x900 screen.

Regarding the ratio; since I don't necessarily need square pixels, again with the example of the capcom games on a 1080p display I do either 3x4 or 4x5, it looks 4:3-enough in the end and the benefits of integer scaling remain, super clean and perfect for any kind of filter or overlay or post-processing. It's a only a 1080p display and yet integer scaling gives me two valid size options, one surrounded by black on all sides but still very reasonably sized, one that goes slightly over limits filling the screen vertically and hiding just a few lines.

Don't worry about my rant I'm not trying to sell integer scaling, we obviously all know its worth of course, let's say I'm an integer scaling ultra-liberal; as I'm promoting free access to it in any situation and without limits.  [/quote]

hello.  doing this does scale the game to 1536x896 (4x integer scale), however, in doing so, GM no longer enforces the 4:3 aspect correction to display the game the way it was meant to be displayed.

That's strange I've tried the same and it didn't work for me, the vertical inner 4:3 pillarboxes were still here, I'm missing something...oh well.

There's one thing though I've noticed when disabling forced 'screen aspect' in the .ini by setting it to 'auto': it can wreck integer scaling !! (saw it while slapping an overlay grid over)
It might depend on the screen resolution and all, but keep an eye on it.

[Calamity]

hello.  doing this does scale the game to 1536x896 (4x integer scale), however, in doing so, GM no longer enforces the 4:3 aspect correction to display the game the way it was meant to be displayed.

Do you see my point now? In order to enforce 4:3 aspect correction, fractional scaling is required, for that given combination of monitor & game resolutions.

Fractional scaling and bilinear filtering are different things. If bilinear filtering is what bothers you, try disabling it (put "filter 0" in both horizont.ini & vertical.ini files). That will give you crisp block-looking pixels provided the prescale factors are high enough.

[Calamity]

Regarding the ratio; since I don't necessarily need square pixels, again with the example of the capcom games on a 1080p display I do either 3x4 or 4x5, it looks 4:3-enough in the end and the benefits of integer scaling remain

Yeah but that involves applying arbitrary scaling factors on both axes, that's something I'd like to implement in the future.

GM currently applies separate factors for vertical and horizontal axes. However these factors are not calculated based on the bitmap aspect, but on the monitor aspect.

Based on the Capcom games example, buvk wants GM to apply 3x4 -> 1152/896 = 1.28 that is nearly 1.33. But those are bitmap figures. GM doesn't work with bitmaps, it works with monitors.

GroovyMAME applies 4x4 in the Capcom case because 4x384 = 1536 is the closest multiple that leaves the black pillars required to provide 4:3 aspect for a 16:9 1920 pixels wide screen. The problem is this is only true if the vertical size fits the screen, with no borders. The reason is that GM is meant to work with CRT monitors, where the vertical size is adjustable with an analog control, to always fit the screen vertical dimension. So no bitmap aspect ratio calculation is performed because the user is supposed to correct aspect manually as arcade operators do with real pcbs.

[schmerzkaufen]

Yes that requires separate controls and somehow overriding the normal behaviour, I have no idea about the programming challenge with this but I wish you good luck ! ^^

On the topic of arbitrary controls I've mentioned it already but have you tried custom integer scaling in RA ? (activate integer scaling in settings then apply multiples in 'options').
Of course it was never intended to work like GM so it doens't have these specific limitations, zero aspect /video area requirements, more importantly you can freely set V & H integer factors for any running game, though last time I checked settings don't get stored so it's not convenient at all (one of the few actually good aspects of RA and again they managed to make it unpractical and annoying) in that aspect GM is already superior.

I realize people like me are being pushy, somehow we're expecting GM to be an 'LCD-convenient' build, which is the opposite of your project's original purpose, but it's your fault for bringing such attractive improvements to baseline MAME ! 

Thanks again for your help and enlightenment as always.