GroovyMAME 0.171 - SwitchRes v0.015m

[Calamity]

Calamity, This section has me confused. Can you explain why this line uses OSDOPTION_SYNCREFRESH ?
ie. What is the difference between OPTION_SYNCREFRESH and OSDOPTION_SYNCREFRESH here?

Oops, that's obviously an error, I missed that one, thanks for finding it. It should be OPTION_SYNCREFRESH, according to the logic explained above. It has always been right in the previous patches, but because MAME has changed some options in this version my patch was messed up, I'll fix this in a while.

[ozfalcon]

Calamity, This section has me confused. Can you explain why this line uses OSDOPTION_SYNCREFRESH ?
ie. What is the difference between OPTION_SYNCREFRESH and OSDOPTION_SYNCREFRESH here?

Oops, that's obviously an error, I missed that one, thanks for finding it. It should be OPTION_SYNCREFRESH, according to the logic explained above. It has always been right in the previous patches, but because MAME has changed some options in this version my patch was messed up, I'll fix this in a while.

Hi Calamity, Thanks for the info - I think I understand how things are organized - Sorry for all the questions 

<removed unnecessary text>

[ozfalcon]

Calamity, One last question for the moment.

Anyway this doesn't change the fact that -syncrefresh is still defined in the osd side. And this is exactly the problem. IMHO, from a design point of view, -syncrefresh should have always been defined as a core option, just like -throttle is.
This is necessary so that -syncrefresh can be accesed from the throttling function in emu\video.c

<UPDATED>
I have had the Flu for the last week and not been thinking clearly.

What in video.c requires the -syncrefresh option to be in /emu/emuopts
I ask because I tried a compile with -syncrefresh option left in /osd/osdepend and it still worked (/emu/video.c that is).

<UPDATE>
A quick look mentions this in /emu/emu.h

Code: [Select]

// define machine_config_constructor here due to circular dependency
// between devices and the machine config
class machine_config;
typedef device_t * (*machine_config_constructor)(machine_config &config, device_t *owner, device_t *device);

And emu.h is included in /osd/osdepend.c

I now have an IDE setup, I'll need to brush up on my C/C++ to understand how everything is referenced.

[Calamity]

Hi ozfalcon,

Sorry for my late answer. Last couple of weeks have been crazy finishing stuff in order to get some holiday.

If you have a look at video.c you have this in the video_manager constructor:

m_syncrefresh(machine.options().sync_refresh())

The syncrefresh option is taken from there, then it's used internally by the class as m_syncrefresh, specifically in update_throttle is used to determine whether the function should exit immediately or not.

I'm going to fix the patches today, hopefully they'll be ready in a while.

[Calamity]

I've updated the diff and binaries for v0.154 - Switchres 0.015b, fixing the -syncrefresh error.

[cools]

AUR updated. https://aur.archlinux.org/packages/?SeB=m&K=cools

[Calamity]

AUR updated. https://aur.archlinux.org/packages/?SeB=m&K=cools

That was fast! 

[ozfalcon]

Hi ozfalcon,

Sorry for my late answer. Last couple of weeks have been crazy finishing stuff in order to get some holiday.

If you have a look at video.c you have this in the video_manager constructor:

m_syncrefresh(machine.options().sync_refresh())

The syncrefresh option is taken from there, then it's used internally by the class as m_syncrefresh, specifically in update_throttle is used to determine whether the function should exit immediately or not.

I'm going to fix the patches today, hopefully they'll be ready in a while.

Thanks for the reply, Your holiday is priority - Your a busy man and deserve the relaxation time!

----> m_syncrefresh(machine.options().sync_refresh())
Yes - I thought that was all that was used.
The code in video.c seems fairly straight forward.

I made a small diagnostic patch, and you can see the results below.
The patch simply shows the value of m_syncrefresh from within /emu/video.c
and is inserted in the update_throttle section (Hence the use of throttle in the test).

The patch leaves the sync_refresh option in /osd/osdepend.c
While it does work, I am still to learn how the reference to sync_refresh is available in /emu/video.c

Code: [Select]

diff -Nru old/emu/video.c src/emu/video.c
--- old/emu/video.c 2014-07-22 08:14:56.000000000 +1000
+++ src/emu/video.c 2014-08-09 22:50:15.042927000 +1000
@@ -86,6 +86,7 @@
  m_overall_valid_counter(0),
  m_throttled(machine.options().throttle()),
  m_throttle_rate(1.0f),
+ m_syncrefresh(machine.options().sync_refresh()),
  m_fastforward(false),
  m_seconds_to_run(machine.options().seconds_to_run()),
  m_auto_frameskip(machine.options().auto_frameskip()),
@@ -726,6 +727,9 @@
  3,4,4,5,4,5,5,6, 4,5,5,6,5,6,6,7, 4,5,5,6,5,6,6,7, 5,6,6,7,6,7,7,8
  };
 
+ // if we're only syncing to the refresh, bail now
+ osd_printf_verbose("(/emu/video.c/update_throttle) m_syncrefresh = %i \n", m_syncrefresh );
+
  // outer scope so we can break out in case of a resync
  while (1)
  {
diff -Nru old/emu/video.h src/emu/video.h
--- old/emu/video.h 2014-07-22 08:21:56.000000000 +1000
+++ src/emu/video.h 2014-08-09 22:31:41.231600000 +1000
@@ -145,6 +145,7 @@
  // configuration
  bool                m_throttled;                // flag: TRUE if we're currently throttled
  float               m_throttle_rate;            // target rate for throttling
+ bool                m_syncrefresh;              // flag: TRUE if we're currently refresh-synced
  bool                m_fastforward;              // flag: TRUE if we're currently fast-forwarding
  UINT32              m_seconds_to_run;           // number of seconds to run before quitting
  bool                m_auto_frameskip;           // flag: TRUE if we're automatically frameskipping
(The patch is really just to see the code inserted, Not actually to be compiled)


RESULTS

$> ./mame xybots -verbose -throttle -nosyncrefresh
...
(/emu/video.c/update_throttle) m_syncrefresh = 0
Average speed: 100.00% (8 seconds)

$> ./mame xybots -verbose -throttle -syncrefresh
...
(/emu/video.c/update_throttle) m_syncrefresh = 1
Average speed: 100.00% (6 seconds)

[Calamity]

Hi ozfalcon,

Thanks for the test, it's interesting. If the new osd options are accesible from the core side then there's no need to move them around anymore. This will simplify the patch. I'll keep this in mind when doing the next version of the patch.

[lettuce]

AUR updated. https://aur.archlinux.org/packages/?SeB=m&K=cools

Whats AUR?

[cools]

http://lmgtfy.com/?q=what%27s+archlinux+aur%3F&l=1

[Ansa89]

Got some problems with groovymame 0.154, more info here.

[Calamity]

Hi,

Just a quick message to say that I'm back and will be answering your posts soon.

[Ansa89]

@Calamity: you are my savior .

[NightSprinter]

Whats AUR?

It's short for the "Arch User Repository".  Basically a place where users can upload and maintain their own customized branches of packages for Arch Linux.  Cools has a repository there that has the custom builds of the kernel, along with groovymame/ume, attract-mode, switchres, sdl1.2, and the patched version of the X drivers for ATI and nVidia cards (open-source version).

[Lenin Stimpy]

I hope its okay to put a second post on this issue but I've got this version of GroovyUME running with Soft15Khz in 'read only' mode here -

http://forum.arcadecontrols.com/index.php/topic,141288.0.html

I'm suspicious because it all seems to easy compared to the experiences of others

[Dungeonsdeep]

Sorry to be a noob, but will this be compatible with my 0.152b romset?

[Sledge]

Sorry to be a noob, but will this be compatible with my 0.152b romset?

Mostly
But to be COMPLETELY compatible, you'll need to update

[blontic]

AUR updated. https://aur.archlinux.org/packages/?SeB=m&K=cools

This looks great. Nice to see the updated files. Is there an option there to download a complete image with everything in it or are you just hosting all the updates in one place?

Or am I blind?

[cools]

You need to compile & install them yourself by grabbing the packages from AUR.

[Elaphe]

Calamity, I've successfully applied the hiscore and groovymame patches to the 0.154 source. I've created mame.ini and I've configured it. I must say I'm testing this in a LCD monitor.  I know it's not the perfect environment for GroovyMAME, but I'm interested in some features such as soundsync, etc. The problem I have is that I have not managed to get bilinear filtering by no means. I've tried many things with mame.ini. I've set the monitor line as lcd and I'm using d3d. With the standard MAME, there's no problem. What could I do?

Since I'm not interested in the modelines stuff, etc. could you please release a diff with the soundsync features alone? Or does the recent MAME releases already sync audio and video when the emulated game at 5? hz is forced to 60hz with syncrefresh?

I also like the idea of reduced input latency. Is it the same patch as this one?: http://www.systempixel.fr/extra/nobuffer/

[ozfalcon]

Calamity, I've successfully applied the hiscore and groovymame patches to the 0.154 source. I've created mame.ini and I've configured it. I must say I'm testing this in a LCD monitor.  I know it's not the perfect environment for GroovyMAME, but I'm interested in some features such as soundsync, etc. The problem I have is that I have not managed to get bilinear filtering by no means. I've tried many things with mame.ini. I've set the monitor line as lcd and I'm using d3d. With the standard MAME, there's no problem. What could I do?

Since I'm not interested in the modelines stuff, etc. could you please release a diff with the soundsync features alone? Or does the recent MAME releases already sync audio and video when the emulated game at 5? hz is forced to 60hz with syncrefresh?

I also like the idea of reduced input latency. Is it the same patch as this one?: http://www.systempixel.fr/extra/nobuffer/

You can find the patch here: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=42

The explanation of how Syncrefresh & DirectDraw are broken was very helpful.

[lettuce]

So what is the best way to play GroovyMame on a Arcade Monitor, Windows or Linux?

[Calamity]

Here's updated diff for v0.155, in case someone wants to roll his own binary. Bear in mind this is NOT tested. During this week (hopefully) I'll update the patch to include some pending fixes.

[yakk11]

Every time I try to compile groovymame .155, it crashes.  Can anybody share their build?

[Andypc]

I had a few issues, but have now compiled Groovymame .0155 and  it's working fine. You need to apply the "hi_155.diff" before the groovymame diff. You now need to run the three batch files in the mingw directory, before you compile. "setenv.bat", "setup-python.bat" and "setup-qt.bat"

[yakk11]

Thanks Andy, but I have already tried that.  The error I am getting is:

Compiling src/emu/cpu/g65816/g65816o4.c...
Generating H8-300 source file...
process_begin: CreateProcess(NULL, python src/emu/cpu/h8/h8make.py src/emu/cpu/h8/h8.lst o obj/windows64/emu/cpu/h8/h8.inc, ...) failed.
src/emu/cpu/cpu.mak:650: recipe for target 'obj/windows64/emu/cpu/h8/h8.inc' failed
make (e=2): The system cannot find the file specified.
make: *** [obj/windows64/emu/cpu/h8/h8.inc] Error 2
make: *** Waiting for unfinished jobs....
Finished!

[Andypc]

Yes, that is the error I was getting when I hadn't run the "setup - python. bat". Make sure you open the "Command" box as administrator and run the .bat files from within the command box after setting the paths

[blontic]

I got it working.

Are you using groovy with win7 by any chance? I can't get my Hyperspin working and was wondering what you did to fix it? thanks

[lettuce]

Here's updated diff for v0.155, in case someone wants to roll his own binary. Bear in mind this is NOT tested. During this week (hopefully) I'll update the patch to include some pending fixes.

Has GM 0.155 got officially complied yet??

[Calamity]

Has GM 0.155 got officially complied yet??

No.

[Sledge]

Has GM 0.155 got officially complied yet??

No.

you MUST COMPLY !!

however if you want to compile it you can do that too

[yatzr]

Here's updated diff for v0.155, in case someone wants to roll his own binary. Bear in mind this is NOT tested. During this week (hopefully) I'll update the patch to include some pending fixes.

Any chance that includes a fix for the in-game menu not working when in vertical mode?

[Calamity]

Any chance that includes a fix for the in-game menu not working when in vertical mode?

The reason for the delay on releasing this version is that I need some time to fix the existing issues (it will be Switchres 15c).

[yatzr]

Any chance that includes a fix for the in-game menu not working when in vertical mode?

The reason for the delay on releasing this version is that I need some time to fix the existing issues (it will be Switchres 15c).

No worries.  I ask about that particular issue because it's currently my biggest pain point in my latest setup.  I'm getting ready to either try to fix it myself (which may be a really dumb idea  ) or try to find a solid workaround.  However, if it's going to be fixed in your next version, then I'll just wait.

[yatzr]

Any chance that includes a fix for the in-game menu not working when in vertical mode?

The reason for the delay on releasing this version is that I need some time to fix the existing issues (it will be Switchres 15c).

No worries.  I ask about that particular issue because it's currently my biggest pain point in my latest setup.  I'm getting ready to either try to fix it myself (which may be a really dumb idea  ) or try to find a solid workaround.  However, if it's going to be fixed in your next version, then I'll just wait.

I spent a little time last night messing with the code and traced this bug down to ui_aspect() in emu/render.c.  It was returning a value of 85 for me (which makes sense with the super resolution) and that was messing up all the calculations for how big to draw the box and characters.  I just commented out the following lines to make it fallback to clamping the aspect ratio to 1.5, and now it works perfect for me.  It's probably not the proper fix you'd want, but it works for me.

Code: [Select]

// if we have a valid pixel aspect, apply that and return
// if (m_ui_target->pixel_aspect() != 0.0f)
// return aspect / m_ui_target->pixel_aspect();
The issue was also causing some things like save/load state to not work.  Mame would just freeze up when trying to display the "Select slot to save to" message.  Those also work fine now with this change.

[Calamity]

Hi yatzr,

Thanks for sharing this. The bug is fixed in the build I'm working on at the moment, fortunately it is not necessary to hack the pixel aspect once the "cleanstretch 2" behaviour is properly implemented.

There're still some things I need to fix before releasing the new patch however.  I'm adding support for rotated desktops and it's proving to be a pain. Hopefully will be ready in a few days, please be patient.

[cools]

My neck cheers.

[premuto]

i have a polo 2  25"
in archive.ini what type of monitor write?

polo o generic_15?

[sean_sk]

I'm having a little difficulty getting the "ps_timing" option working in GM 0.154.

Up until now I had created and saved a custom profile for 352x256 within Powerstrip to solve refresh rate issues with Phoenix. Because I play a few games at that same resolution but at different refresh rates I would much rather user the Powerstrip feature in GM so I can create a unique mode within each games ini file.

I have created one for Phoenix but whenever I run Phoenix I get an error from GM: "SwitchRes: could not find a video mode that meets your specs." Powerstrip is also running in the background, but I should note that I deleted 352x256 profile from Powerstrip itself to see if the "ps_timing" settings in the ini file would have an effect. I followed the instructions in the first post but I'm sure I'm probably not doing it right, so some guidance would be wonderful.

I've included a log, my ini's as well as the exported settings from Powerstrip in a text file.

Thanks for that.