Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Screenswitching with the Genesis driver (as an example)  (Read 3699 times)

0 Members and 1 Guest are viewing this topic.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Screenswitching with the Genesis driver (as an example)
« on: January 29, 2013, 11:20:21 am »
Hi Calamity,

I was thinking about the Genesis driver and how it works in GM. Currently it does work very nicely with it switching between 320x224_60Hz and 256x224_60Hz modes automatically. The only thing holding it back from perfection is the audio stuttering during the screen switching.

So I was thinking of methods to keep the screenswitching to a minimum, but keep everything else the same. Both the 320x224 and 256x224 resolutions are an integer multiple of 1280x224 (4x and 5x respectively). Now if we would run the Genesis driver on a 1280x224_60Hz screen, and have only the proper changeres scaling factor applied (4x and 5x), but not have it calling the screen switch, then we would have the perfect smooth Genesis experience (i.e. proper scaling and screenmode borders but no audio stuttering / delay on the switch)!

Now I tried this by forcing 1280x224 on the ini "resolution" parameter, but although it sticks for both Genesis screenmodes to the 1280x224 resolution it's still calling the physical screenswitch from "320x224 -> 1280x224" and "256x224 -> 1280x224". So even while the screenmode is already running at 1280x224, it's still calling a physical switch to the very same 1280x224 screenmode, inducing the audio stuttering.

Would it be possible to enhance GM's algorithm in a way that it detects whether or not the new target screen resolution is already open and if so, only applies the new scaling factor, but skips on the call for a physical screenswitch?

A good example / testcase is the game Mega Turrican (great game btw), which switches regularly between the two resolutions when going from the intro to the main game / title screen and vice versa.

Other drivers could benefit also, like the Playstation driver. But since this one uses even more resolutions, like 256x240 and 320x224 and 368x240, I guess we would need some additional way to tell the driver to pick a "magic scaling resolution" for some resolutions (like e.g. 256x240 and 320x240 -> 1280x240), but not for others...
« Last Edit: January 29, 2013, 11:23:20 am by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Screenswitching with the Genesis driver (as an example)
« Reply #1 on: January 29, 2013, 01:32:54 pm »
Hi Dr.Venom,

What you want is possible indeed but through a workaround that needs Direct3D instead of DirectDraw. See my attached log. Use these options: -video d3d -resolution 1280x224@60 -nocleanstretch

Notice the refresh value, it's required, otherwise the -resolution option is not considered by SwitchRes. Forcing a resolution automatically disables -changeres.

The trick involves disabling -cleanstretch, don't panic, the scaling will be clean either way as long as the scaling factor is integer (it is). In ddraw the scaling is managed in a different way and this trick does not work unfortunately (I'd need to have a deeper look).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Screenswitching with the Genesis driver (as an example)
« Reply #2 on: January 29, 2013, 02:43:30 pm »
Hi Calamity,

Thanks for your answer. I tried your suggestion and it makes the genesis driver pick the 1280x224 resolution for both the 320x224 and 256x224 modes and it also applies the proper scaling factor (5 and 4, see attached log). But, unfortunately it's still doing the screen switching / re-initialization on each switch, thus (possibly) suffering from the audio stutter.

What I was thinking of earlier is that -since the 1280x224 screen is already opened-, it should *not* be having to call the screen switch again. Instead it should only apply a new scaling factor without calling the screen switch (thus no audio stutter)?

So to walk through it step by step. What GM is doing now after starting Mega Turrican is:

1. Opening screen "SEGA" and "Data East" (resolution = 320x224):
SwitchRes: [genesis] (1) horizontal (320x224@60.00)->(1280x224@60.00)
   rng(0): 1280 x 224_60.000p 15.600 [integ] scale(4, 1, 1) diff(0.00, 0.00, 0.0000) ratio(4.000, 1.000)
*Changes screenmode physically on monitor to 1280x224*

2. "Factor 5" (resolution = 256x224)
SwitchRes: [genesis] (1) horizontal (256x224@60.00)->(1280x224@60.00)
   rng(0): 1280 x 224_60.000p 15.600 [integ] scale(5, 1, 1) diff(0.00, 0.00, 0.0000) ratio(5.000, 1.000)
*Changes screenmode physically on monitor to 1280x224*

3. "Intro starts" (resolution = 320x224)
SwitchRes: [genesis] (1) horizontal (320x224@60.00)->(1280x224@60.00)
   rng(0): 1280 x 224_60.000p 15.600 [integ] scale(4, 1, 1) diff(0.00, 0.00, 0.0000) ratio(4.000, 1.000)
*Changes screenmode physically on monitor to 1280x224*

4. "Title Screen"
SwitchRes: [genesis] (1) horizontal (256x224@60.00)->(1280x224@60.00)
   rng(0): 1280 x 224_60.000p 15.600 [integ] scale(5, 1, 1) diff(0.00, 0.00, 0.0000) ratio(5.000, 1.000)
*Changes screenmode physically on monitor to 1280x224*

5. "Game Starts" (Resolution = 320x224)
SwitchRes: [genesis] (1) horizontal (320x224@60.00)->(1280x224@60.00)
   rng(0): 1280 x 224_60.000p 15.600 [integ] scale(4, 1, 1) diff(0.00, 0.00, 0.0000) ratio(4.000, 1.000)
*Changes screenmode physically on monitor to 1280x224*

So you see that this game switches the resolution 5 times. Especially (as an example) on the switch from [3. "Intro"] to [4. "Title screen"] you can hear an audible audio stutter. This is because (afaik) it's calling the physical screen switch again. (If you press start during the intro it will jump to the "Title screen").

My point is that, since the 1280x224 resolution was already opened at step 1, that it shouldn't have to call the screenswitch to the same 1280x224 resolution again, but it only needs to apply the new scaling factor.*

If it would behave like that than it would save you four subsequent screen switches in this sequence of 5. So to make sure I bring my point across, the screen switches marked in "red" should -not- be happening in an ideal world. At these points it should only do the scaling (marked in green), since the 1280x224 screenmode is already open, thus preventing any possible audio stutter that could be caused by physical screen switching.

(*PS. I'm assuming that when applying the new scaling factor, that the screen does not have to be re-initialized again. Maybe I'm mistaking that for a physical screenswitch on the monitor?)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Screenswitching with the Genesis driver (as an example)
« Reply #3 on: January 29, 2013, 03:33:32 pm »
Hi Dr.Venom,

I'm telling you that in my system it's working as you're suggesting, indeed, no screen switching. If you see my log, I have these lines:

SwitchRes: -resolution was forced as 1280x224@60
SwitchRes: Setting option -nochangeres

... but in your log, you have these:

SwitchRes: -resolution was forced as 1280x224@61
SwitchRes: Setting option -changeres

I'm almost certain that the reason is that you have the -changeres option defined as 1 in your genesis.ini, thus overriding SwitchRes option setting when it tries to disable it. Just delete this option in genesis.ini and it will work.

Options defined in drivers ini files have higher priority than SwitchRes option setting, as well as command line params. This was done to allow the user forcing things in some situations. SwitchRes priority is just above mame.ini, but lower than any other ini (if I remind right).

I understand what you're suggesting but I believe it's not straight forward to implement due to the logical order the things happen now (I would need to have a deeper look, too).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Screenswitching with the Genesis driver (as an example)
« Reply #4 on: January 29, 2013, 05:33:18 pm »
I'm almost certain that the reason is that you have the -changeres option defined as 1 in your genesis.ini, thus overriding SwitchRes option setting when it tries to disable it. Just delete this option in genesis.ini and it will work.

Perfect that did the trick! It's running great now, thanks :)

Quote
Options defined in drivers ini files have higher priority than SwitchRes option setting, as well as command line params. This was done to allow the user forcing things in some situations. SwitchRes priority is just above mame.ini, but lower than any other ini (if I remind right).

OK, that explains it. Overall that makes sense. Not sure though if command line parameters shouldn't have higher priority than the custom game ini files, as cmd often is "active" user input (making it useful to having it override any other setting). But I guess it doesn't really matter as long as we're familiar with how the priorities are now.. (and there are probably many other reasons why the priorities are what they are now... ;) )

Quote
I understand what you're suggesting but I believe it's not straight forward to implement due to the logical order the things happen now (I would need to have a deeper look, too).

OK, maybe it's worthwhile to have a look into it someday. Also with the recent Playstation driver progress (where most games do quite some switching) it would be cool to incorporate some functionality that minimizes the amount of real screen switching in the best possible way, while not compromising any of the pixel perfect aesthetics.

PS. If you didn't have had the time to check any of the Playstation progress, be sure to check out "Einhander"*, a great shoot 'm up from Squaresoft and its working nearly perfect in (Groovy)UME!  :P

* http://en.wikipedia.org/wiki/Einhander

PPS. And a short example of some of the music that you'll encounter in the game:

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Screenswitching with the Genesis driver (as an example)
« Reply #5 on: January 29, 2013, 06:02:10 pm »
That's good!

Here is the priority order. Notice command line is always top priority:

Code: [Select]
// option priorities
enum
{
// command-line options are HIGH priority
OPTION_PRIORITY_CMDLINE = OPTION_PRIORITY_HIGH,

// INI-based options are NORMAL priority, in increasing order:
OPTION_PRIORITY_INI = OPTION_PRIORITY_NORMAL,
OPTION_PRIORITY_MAME_INI,
OPTION_PRIORITY_SWITCHRES,
OPTION_PRIORITY_DEBUG_INI,
OPTION_PRIORITY_ORIENTATION_INI,
OPTION_PRIORITY_VECTOR_INI,
OPTION_PRIORITY_SOURCE_INI,
OPTION_PRIORITY_GPARENT_INI,
OPTION_PRIORITY_PARENT_INI,
OPTION_PRIORITY_DRIVER_INI
};

The problem with the approach you suggest is that the -changeres evaluation is done in the emulation layer instead of the osd layer, based on the frame size of the target game. At that point the program is not aware of the system resolution. Moreover, once the -changeres event is triggered, the DirectDraw interface is destroyed before the resolution picking algorithm has a chance to determine that the resolution is not to change. Finally, we had to account for the fact that some games changed refresh rate while keeping the same resolution (zookeeper if I remind right) so this is a tricky case. Of course, everything is possible and things could be rewired so that everything is considered, but would required a some dirty patching. The best approach is to find a way so that the scale factors are recalculated dynamically.

Ah, I know that game, I remind playing that one on a friend's PS long ago...
 
« Last Edit: January 29, 2013, 06:05:11 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Screenswitching with the Genesis driver (as an example)
« Reply #6 on: January 29, 2013, 06:48:52 pm »
Here is the priority order. Notice command line is always top priority:

That's perfect.

With regards to the changeres functionality, thanks for explaining how it works. Given what you wrote I see it's not a straightforward case. Hopefully the dynamic recalculation of the scale factors provides a possible/feasible solution.

Quote
Ah, I know that game, I remind playing that one on a friend's PS long ago...

Ok, cool :)

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Screenswitching with the Genesis driver (as an example)
« Reply #7 on: January 30, 2013, 06:49:54 pm »
Further good news re the use of the "super resolutions" to minimize screen switching.

The Playstation (driver) is capable of many resolutions. Many games also make use of these various resolutions abundantly, which as a result causes a lot of screen switching with GM. The Playstation is capable of the following resolutions (NTSC example):

Progressive:
256x240_60Hz
320x240_60Hz
368x240_60Hz
512x240_60Hz
640x240_60Hz

Interlaced:
256x480_60Hz
320x480_60Hz
368x480_60Hz
512x480_60Hz
640x480_60Hz

Now interestingly, just as we used 1280x224 for the Genesis driver, there's two "super resolutions" for the Playstation driver that will fit 8 PSX resolutions, while using integer scaling only (CRT pixel perfectness), or will fit all 10 resolutions if we're willing to lose 2 pixels of the 368x240 screenmode. The "super resolution" is: 2560x240_60Hz:

Horizontal resolution and scaling factor:
256 = 10x
320 = 8x
368 = 7x (if we're willing to scale 368x7=2576 pixels and cut off or "lose" 16/7 = ~2 pixels horizontally from original 368 resolution).
512 = 5x
640 = 4x

Now I've just been running the PSX driver on a 2560x240_60Hz screen with some games and it's amazing! Complete smooth experience (no switching) for all progressive modes and CRT pixel perfectness!  :)

Short log from Ridge Race Type 4 shows how many times it changes resolution before getting to the first race:

SwitchRes: Resolution change from 640x480@60.000000 to 256x240@60.000000
SwitchRes: Resolution change from 256x240@60.000000 to 640x480@60.000000
SwitchRes: Resolution change from 640x480@60.000000 to 256x240@60.000000
SwitchRes: Resolution change from 256x240@60.000000 to 320x240@60.000000
SwitchRes: Resolution change from 320x240@60.000000 to 256x240@60.000000
SwitchRes: Resolution change from 256x240@60.000000 to 640x480@60.000000
SwitchRes: Resolution change from 640x480@60.000000 to 256x240@60.000000
SwitchRes: Resolution change from 256x240@60.000000 to 320x480@60.000000
SwitchRes: Resolution change from 320x480@60.000000 to 320x240@60.000000
SwitchRes: Resolution change from 320x240@60.000000 to 320x480@60.000000
SwitchRes: Resolution change from 320x480@60.000000 to 320x240@60.000000

This log is exemplary for a lot of PSX games, they switch screenmodes a lot, showing the benefit of using a "super resolution" to minimize the number of screen switches and bring the emulation experience on our beloved CRTs even more close to the real thing :).

Now the only thing is how do I get GM to choose between 2560x240_60Hz and 2560x480_60Hz (interlaced) mode appropriately when the driver switches between progressive and interlaced mode? Since currently we're forcing 2560x240_60 through the resolution parameter this will not work. I guess it would need some additional logic in GM, maybe something similar to the crt_range functionality?

P.S. I don't see the 512x240 and 368x240 screenmodes used very often, so for most usage I guess the "super resolutions" of 1280x240 and 1280x480i would do for the PSX driver. Performance wise for older cards that could have some benefits also.
« Last Edit: January 30, 2013, 06:53:24 pm by Dr.Venom »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Screenswitching with the Genesis driver (as an example)
« Reply #8 on: January 31, 2013, 08:53:23 am »
I'm thinking of a way to implement this...

When we force resolutions, the -changeres option is disabled accordingly so something else is required. It can't be as explicit as forcing stuff, but somewhat more indirect.

Normally, we give a better score to resolutions that have a horizontal scale factor closer to 1, for obvious reasons. We could make this scale factor user selectable, so that you could enter a preferred horizontal scale factor of 5, or 10. This would ensure that the widest available resolution is selected. Leaving the algorithm pick resolutions freely would solve the 240/480i issue.

On the other hand, I've been having a look and think we could easily bypass the physical mode switch if the recalculated modeline is the same as the previous one.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Screenswitching with the Genesis driver (as an example)
« Reply #9 on: January 31, 2013, 10:41:49 am »
... but unfortunately this wouldn't work fine on the Linux side, because there are no predefined resolutions there (e.g. 1280x) to check scale factors against (we just create any resolution that we want).

So probably a better approach for both systems could be adding resolutions masks, like this: 1280x0@0, where '0' means 'any'. In Windows, these would be used to trim or filter the list of available video modes. In Linux, they would mark any of the fields of a video mode (xres, yres, vfreq) as non-editable.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Screenswitching with the Genesis driver (as an example)
« Reply #10 on: January 31, 2013, 11:07:03 am »
So probably a better approach for both systems could be adding resolutions masks, like this: 1280x0@0, where '0' means 'any'. In Windows, these would be used to trim or filter the list of available video modes. In Linux, they would mark any of the fields of a video mode (xres, yres, vfreq) as non-editable.

This is sounding like an excellent solution!  :applaud:  At least as long as you'd be able to combine that with the possibility of bypassing the physical mode switch as you pointed to earlier?

On the other hand, I've been having a look and think we could easily bypass the physical mode switch if the recalculated modeline is the same as the previous one.

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Screenswitching with the Genesis driver (as an example)
« Reply #11 on: February 13, 2013, 11:03:41 am »
Hi Calamity,

So probably a better approach for both systems could be adding resolutions masks, like this: 1280x0@0, where '0' means 'any'. In Windows, these would be used to trim or filter the list of available video modes. In Linux, they would mark any of the fields of a video mode (xres, yres, vfreq) as non-editable.

Out of curiosity ( sorry ;) ) , are you planning on adding the mask functionality in the next GM update?

Related to this, I gathered you might be adding the functionality to have modeline values to be used/entered directly in GM / driver configs. Will that include the possibility to define more than one modeline, for example one for progressive modes and one for interlaced?

Looking forward to the next update btw!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: Screenswitching with the Genesis driver (as an example)
« Reply #12 on: February 13, 2013, 12:12:18 pm »
Hi Dr.Venom,

Out of curiosity ( sorry ;) ) , are you planning on adding the mask functionality in the next GM update?

Yes, that's my intention. The thing is that a heap of to-do features have accumulated since the rewrite and the heap has become so big that it's something I can't manage in a couple of evenings, and I definitely want to address all these stuff in a single update because it's the only way I can guarantee a clean design.

As for my real life I've got a new son since Saturday so free time is far shorter these days  :D

Quote
Related to this, I gathered you might be adding the functionality to have modeline values to be used/entered directly in GM / driver configs.

Yep :)

Quote
Will that include the possibility to define more than one modeline, for example one for progressive modes and one for interlaced?

That's indeed a problem, I had thought about that and can't imagine a decent solution. The problem is I'd need to create a bunch of options like modeline0, modeline1, modeline2,... and I really hate the idea. Morover, handling an array of user modelines internally will make the current implementation unnecessarily complicated.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Dr.Venom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 270
  • Last login:May 08, 2018, 05:06:54 am
  • I want to build my own arcade controls!
Re: Screenswitching with the Genesis driver (as an example)
« Reply #13 on: February 14, 2013, 05:42:43 am »
Yes, that's my intention. The thing is that a heap of to-do features have accumulated since the rewrite and the heap has become so big that it's something I can't manage in a couple of evenings, and I definitely want to address all these stuff in a single update because it's the only way I can guarantee a clean design.

Thanks for the update, we will all be patiently waiting :)

Quote
As for my real life I've got a new son since Saturday so free time is far shorter these days  :D

That's a big real life event, congratulations!! I can imagine free time getting a "bit" shorter ;)