Build Your Own Arcade Controls Forum
Software Support => GroovyMAME => Topic started by: emubastard on March 12, 2016, 09:01:13 pm
-
Well got interlaced working on my 7970 with d3d9x. Thanks for that.
Crt emudriver 2.0 beta 7
Groovymame 0.171
Windows 7 64
Xfx 7970
Lcd on 1
Crt on 2
But man here's a weird one.
So if I DON'T use -verbose on the command line, I get some big black square areas over my LCD and CRT and no game image. If I use -verbose, all interlaced games come up just fine.
Also just launching mame64.exe with no options, going into the UI and launching any interlaced game will cause this black box issue. The only way to get an interlaced game (for me) to work is via the command line with the -verbose option.
The only thing I can even imagine is some timing issue. It's a devil canyon build with a 1TB SSD. Seems like running with -verbose, the steps that are takin while logging, slow down the process of setting up of the video mode. Not sure I explained that well.
I would post a log... but what log... without verbose is the only way to break it.
I should note this is repeatable and consistent, at least on this system.
-
Hi emubastard,
This sounds like an issue (another) with multithreading. Can you confirm it's not enabled?
-
mutlithreading is set to 0.
Now I'm having a new issue. My interlaced games are showing up at 2560x270p where as at least before Discs of Tron was showing up at 2560x480p and Tron was 2560x512p.
I'm sure I screwed something up again...
Related info is attached.
-
For some reason you disabled -modeline_generation, so GM can no longer transform progressive to interlaced.
-
For some reason you disabled -modeline_generation, so GM can no longer transform progressive to interlaced.
So that's what that does!
I should be able to write a ini guide at this rate. I thought that option was what created the modlines in the cfg directory.
Ug. Sorry to be such a bother.
I'll retest.
-
Well there seems to be some randomness to what I'm seeing.
I have been able to get horizontal interlaced games to work.
Journey, which is vertical, refuses to run at all, I've attached a log.
if I run tron, it works but the aspect ratio is broken and it's horizontally squished in the middle of the screen. However... if I run it with -verbose, the aspect ratio is correct. Seems to be an issue with vertical games?
This is all caused my multithreading?
EDIT: Pong is also horizontally squished in the middle of the screen, but the aspect ratio works correctly when I use -verbose
-
There is a mode switch in the middle, check your log. Is it a real mode change in the game, or something produced by previous video configurations (manual rotation etc.)?
Anyway, if you're planning to use super resolutions, config your mame.ini properly with the -resolution 2560x0 and -cleanstretch 2 options. That will prevent that mode change from happening in the first place.
-
Pong does mode switch constantly every second. I fixed that by creating a pong.ini containing changeres 0. Can't play it while the screen is constantly resync.
That doesn't do anythibg for journey though. It doesn't (to my knowledge) mode change during game play and unless I use -verbose the aspect ratio is totally squahed like 1:1 pixel ratio, however as of now the game screen doesn't come up at all (log previously attached). The aspect ratio issue happens for what seems like all vertical (rotated) interlaced games, like tron.
I will try changing the resolution in mame.ini from auto to 2560x0@0 but I dont get why I should need to use verbose to make the aspect ratio show up correcty on a vertical game like tron. Journey wont even launch anymore (the log is above). Is this all relating to multrithreading issues?
-
The use of verbose simply delays things slightly so the drivers have more time to rebuild the modelist and D3D doesn't crash because of that. This is telling you that your system is ill-configured. You shouldn't be using progressive modes if you're forcing GM to convert those to interlaced constantly, you're better off creating those modes as intelaced since the beginning.
Besides, your mode table is bloated. The point of using super resolutions is to have a system usable with only 10-12 modelines.
Finally, the reason why journey switches resolutions in the middle is probably either due some old video configuration (delete the .cfg files) or because there's artwork available.
-
At last count I had 58 user defined reaolutions. Thats because I've come accross 58 unique vertical resolutions with all the games I play. So this is a no no? I guess I must be misunderstanding the point. I'm trying to get as many native vertical resolutions I can for the many vertical fill and one to one pixel reaolution accross all games. I've read than 100 or 200 modes is a lot but am I already pusing that boundary?
Guess I am looking for some guidance here on how I should be doing this.
I'm assuming you are saying to cut down the number of modelines in which case I could have some scenarios with 4 or as many as 8 or more vertical line gaps depending on which resolutions I remove? I could be exagerrating the real impact of this. It may not be terribly noticeable and I haven't tried.
Progressive wroks fine, all these one to one vertical resolutions work flawlessly, but I should narrow that down if I want properly working interlace resolutions?
Well I would have to ask, is that bad? Could there be an option in The ini to make groovy mame a little more patient or am I just asking for too much bacon? I certainly could drop modes if thats what is going to work, or, drop interlace alltogether. That seems like a shame. I was able to get so many games and systems filling in the vertical resolution perfectly, but maybe that approach is to "anal", no pun intended. I thought it was awesome I could get so many one to one vertical resolutions.
So theres some kind of limit here.
-
At last count I had 58 user defined reaolutions. Thats because I've come accross 58 unique vertical resolutions with all the games I play. So this is a no no? I guess I must be misunderstanding the point. I'm trying to get as many native vertical resolutions I can for the many vertical fill and one to one pixel reaolution accross all games. I've read than 100 or 200 modes is a lot but am I already pusing that boundary?
Guess I am looking for some guidance here on how I should be doing this.
I'm assuming you are saying to cut down the number of modelines in which case I could have some scenarios with 4 or as many as 8 or more vertical line gaps depending on which resolutions I remove? I could be exagerrating the real impact of this. It may not be terribly noticeable and I haven't tried.
Progressive wroks fine, all these one to one vertical resolutions work flawlessly, but I should narrow that down if I want properly working interlace resolutions?
Well I would have to ask, is that bad? Could there be an option in The ini to make groovy mame a little more patient or am I just asking for too much bacon? I certainly could drop modes if thats what is going to work, or, drop interlace alltogether. That seems like a shame. I was able to get so many games and systems filling in the vertical resolution perfectly, but maybe that approach is to "anal", no pun intended. I thought it was awesome I could get so many one to one vertical resolutions.
So theres some kind of limit here.
-
Take this as an example:
Switchres: [ 38] 2560x 192 @ 60 : ATI ADL timing "2560x192_60 15.241000KHz 60.003937Hz" 46.700000 2560 2632 2848 3064 192 216 219 254 -hsync -vsync
Switchres: [ 39] 2560x 200 @ 60 : ATI ADL timing "2560x200_60 15.241000KHz 60.003937Hz" 46.700000 2560 2632 2848 3064 200 220 223 254 -hsync -vsync
Switchres: [ 40] 2560x 204 @ 60 : ATI ADL timing "2560x204_60 15.241000KHz 60.003937Hz" 46.700000 2560 2632 2848 3064 204 222 225 254 -hsync -vsync
Switchres: [ 41] 2560x 208 @ 60 : ATI ADL timing "2560x208_60 15.241000KHz 60.003937Hz" 46.700000 2560 2632 2848 3064 208 224 227 254 -hsync -vsync
Switchres: [ 42] 2560x 212 @ 60 : ATI ADL timing "2560x212_60 15.241000KHz 60.003937Hz" 46.700000 2560 2632 2848 3064 212 226 229 254 -hsync -vsync
Switchres: [ 43] 2560x 216 @ 60 : ATI ADL timing "2560x216_60 15.241000KHz 60.003937Hz" 46.700000 2560 2632 2848 3064 216 228 231 254 -hsync -vsync
Switchres: [ 44] 2560x 223 @ 60 : ATI ADL timing "2560x223_60 15.360000KHz 60.000000Hz" 47.310000 2560 2632 2856 3080 223 233 236 256 -hsync -vsync
Switchres: [ 45] 2560x 224 @ 60 : ATI ADL timing "2560x224_60 15.418000KHz 59.992218Hz" 47.490000 2560 2632 2856 3080 224 233 236 257 -hsync -vsync
Switchres: [ 46] 2560x 231 @ 60 : ATI ADL timing "2560x231_60 15.901000KHz 60.003773Hz" 49.230000 2560 2632 2864 3096 231 241 244 265 -hsync -vsync
Switchres: [ 47] 2560x 232 @ 60 : ATI ADL timing "2560x232_60 15.959000KHz 59.996239Hz" 49.410000 2560 2632 2864 3096 232 242 245 266 -hsync -vsync
Switchres: [ 48] 2560x 238 @ 60 : ATI ADL timing "2560x238_60 16.381000KHz 60.003662Hz" 51.110000 2560 2640 2880 3120 238 248 251 273 -hsync -vsync
Switchres: [ 49] 2560x 240 @ 60 : ATI ADL timing "2560x240_60 16.500000KHz 60.000000Hz" 51.480000 2560 2640 2880 3120 240 250 253 275 -hsync -vsync
You have 12 modelines defined that are *totally* redundant. It would work 100% the same by only creating one single 2560x240. The supposed padding you're afraid of takes place anyway to keep the ones below 240p inside frequency specs.
Do the maths:
15,725 lines per second / 60 Hz = 262 lines
262 - 22 blanking lines = 240 lines
Defining a 200p modeline is absurd because the modeline generator needs to add 40 padding lines anyway to keep the mode above 15.725 kHz.
-
So I think I have missinterpretted how groovy mame works by A LOT. So could I pick the lowest displayable resolution, say 224 or 240 and groovymame will create a "vertical resolution" as close as possible to the target game? I didn't know groovymame generated a vertical resolution as well as the vertical sync on the fly when executing a game. I though I had to provida ALL the vertical resolutions for the crt_range.
Well this could be a severe case of RTFM.
I just assumed that since switch res displayed the closest matching modeline in the info screen that, that was the actual modeline in use.
-
So could I pick the lowest displayable resolution, say 224 or 240 and groovymame will create a "vertical resolution" as close as possible to the target game?
No, that's not what I'm saying.
What I'm sayin is -attention-, believe it or not, 224 and 240 are *t-h-e s-a-m-e* vertical resolution.
I've explained this in a few dozen posts, it's a bit long, but once you fully understand this your eyes will open.
-
Ok... well... here is my user modes for 2560x224 and an attachment for ghost and goblins. I have NOT adjusted and picture adjustments between these pics. Ghosts 'n Goblins native 224p stretched to fit the vertical space on my monitor, no problem.
-
And here is my user modes for 2560x240 and ghost and goblins running at 2560x240. What I see, are black bars on the top and bottom. GNG is a 224p game. 224p and 240p don't look the same to me. I guess you might say this is my monitor doing this and all other monitors stretch it out to fill?
-
This is your custom range according to your log.
15200.00-20500.00,54.70-62.00,1.500,4.700,4.700,0.602,0.191,1.352,0,0,192,288,390,576
Those 2 values are huge. This is adding lots of unnecessary padding lines up and down. As a result your 240p mode is raising to 16.387 kHz. That mode should run around 15.7 kHz.
On the other hand, because your hfreq min is so low (15.2 kHz), your 224p mode is running at 15.31 kHz.
For this reason, your monitor is interpreting both modes as totally different. If take the resulting modeline in both of them, you'll see the vertical total is soo much different:
Switchres: [ 45] 2560x 224 @ 60 : ATI ADL timing "2560x224_60 15.418000KHz 59.992218Hz" 47.490000 2560 2632 2856 3080 224 233 236 257 -hsync -vsync
Switchres: [ 49] 2560x 240 @ 60 : ATI ADL timing "2560x240_60 16.500000KHz 60.000000Hz" 51.480000 2560 2640 2880 3120 240 250 253 275 -hsync -vsync
Now, this shouldn't be the case if you use a normal preset. If you change your -monitor option to arcade_15, you'll see how in both cases the vertical total is around 262. That's why I say they're the same mode. In a normal configuration, you'll expect to see those black bars on the 224p mode, which should be corrected manually.
This is how the actual hardware worked. E.g., Ghouls & Ghosts used to run at 15.7 kHz, not 15.31.
However, I see your point now. You intend to take advantage of your monitor's ability to auto adjust vertical size by creating a bunch of vertical total values that trigger this behaviour.
-
I tried the arcade_15 preset. After my initial re-adjustment of my vertical alignment at 240p, ghost and goblins (224p) still displays with black bars on the top and bottom but joust (240p) fills out top to bottom fully. Keep in mind this is the same test with the same user modes I posted on the last screen shot. I was just testing to see that 224p and 240p were the same with the arcade_15 but but the machine information says 240p is being used for both as in the last 2 screen shots... which of course I may never understand so I should go looking through some older posts.
## Desktop ##
640 x 400 @ 60.000000 desktop
640 x 480 @ 60.000000 desktop
960 x 720 @ 60.000000 desktop
1024 x 768 @ 60.000000 desktop
2560 x 240 @ 60.000000 super
So I went back and took out a lot of excessively anal resolutions I didn't need from my list of 58 modes, added back in 2560x224 and I was left with 30 modlines for now. I guess somewhere around 40 or 50 modelines you can't expect to keep your interlaced resolutions working reliably do to reasons you've expressed.
Interlaced is working just great now.
I will have to pick and choose the most common vertical resolutions and live with Y number of black vertical lines on the top and bottom of those games that are forced to choose a higher resolution. That is far more prefered over loosing an exact vertical sync!
It shouldn't be too bad, 2 to 4 extra black lines on top and bottom in few cases shouldn't be noticable to any one but psychotic me. The largest gammit of games are 224, 240, 256 (for vertical), 288 etc, 480p, 512p (vertical). I have plenty of room for compromise.