GroovyMAME 0.171 - SwitchRes v0.015m

[Calamity]

The build is done.

Great! Thanks.

[Doozer]

The build is done.

Great! Thanks.

Thank you for this release :Calamity -) Now I am impatient to go back home for some testing.

I have tested the Linux builds, they are fine. Enjoy and Happy New Year to all Arcade fans!

[haynor666]

I've tested some Taito Type X games and now SFIV and Battle Fantasia works, Spica Adventure force 640x480@60p so probably OpenGL fix was needed for those games.

[RobeeJ]

Having problems with 169, both the official 32 and 64 bit builds when launched run at 100% cpu and don't even seem to create a window, same result when I build it myself from source (with the missing define added).

groovymame debug log is as follows:

Code: [Select]

SwitchRes: v0.015l, Monitor: lcd, Orientation: horizontal, Modeline generation: disabled
SwitchRes: Using default vfreq range for LCD 59.000000-61.000000
SwitchRes: Found output connector 'DVI-I-1'
SwitchRes: Creating automatic specs for LCD based on VESA GTF
SwitchRes: Monitor range 73278.00-75762.00,59.00-61.00,0.696,1.044,1.740,0.013,0.040,0.510,0,1,1200,1200,0,0
SwitchRes: -resolution was set at command line or in .ini file as 1600x1200@60

SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[pacman] Calculating best video mode for 224x288@60.606060 orientation: rotated

SwitchRes: [1600]x[1200]_[60=0.0000Hz]
I'm running with:
modeline_generation       0
monitor                   lcd

168 and before were fine. :/

[Doozer]

Having problems with 169, both the official 32 and 64 bit builds when launched run at 100% cpu and don't even seem to create a window, same result when I build it myself from source (with the missing define added).

Not sure you are under Linux or Windows. But you have mentioned the need to include missing define which is only needed under Linux.

I have tested the 64 build with GroovyArcade and I am able to see the expected pictures from games. Nothing strange to report here.

[RobeeJ]

Sorry, yes its Linux. Arch Linux specifically if that matters.

[Doozer]

Sorry, yes its Linux. Arch Linux specifically if that matters.

Hummm, it is really odd. I am doing my tests remotely under VMs.  I will do deeper testing next Sunday when I will have access to my cabinets. At the moment I cannot reproduce your behavior :-( sorry I am not helpful right now.

[RobeeJ]

No worries, I appreciate the help!

Perhaps its graphics card related, I have an nvidia card with the nouveau source drivers. Just updated arch and got the latest sdl/mesa drives in its repo in case that helped, it didn't.

[donluca]

EDIT: one quick question: do I have to update the CRT Tools and create the video modes again with the new VMMaker in order to use 0.169? (I'm using Windows XP 32bit)

EDIT 2: regarding HD5000, 6000 and 7000 series: are they affected by the low dotclock issue?

bumping my questions, since I edited my post I'm afraid you may have missed them.

[Calamity]

EDIT: one quick question: do I have to update the CRT Tools and create the video modes again with the new VMMaker in order to use 0.169? (I'm using Windows XP 32bit)

No.

EDIT 2: regarding HD5000, 6000 and 7000 series: are they affected by the low dotclock issue?

No.

[pakoman]

Hi.

Does it work with mobility hd5000?

Happy new year!

[Calamity]

Does it work with mobility hd5000?

Probably.

[Doozer]

@Calamity, The Linux/SDL version shows a horizontally compressed screen with bad emulation speed in every screen resolutions (15khz, 31khz, with/without interlacing). I can do specific tests/builds, just PM me.

@RobertJ, You are right, the Linux builds are not usable. The odd screen behaviour must first be fixed. Nevertheless, you should see a picture on the screen. I do not know why you have a black screen.

[RobeeJ]

@RobertJ, You are right, the Linux builds are not usable. The odd screen behaviour must first be fixed. Nevertheless, you should see a picture on the screen. I do not know why you have a black screen.

Glad it's not just me and you can recreate it.

Just to clarify, it's not that I get a black screen, its that I get nothing at all, mame creates no window or viewport or whatever it creates.

[Calamity]

Please Doozer, post a full log showing the problem, that will help me to find a quick solution

[Doozer]

From the log, it is clear that groovymame is not able to switch to  native game resolution based on its calculation. It runs using the X default resolution instead.

Code: [Select]

SwitchRes: v0.015l, Monitor: custom, Orientation: horizontal, Modeline generation: enabled
SwitchRes: Monitor range 15625.00-16200.00,55.10-65.00,2.000,5.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0
SwitchRes: Monitor range 15625.00-16200.00,49.50-54.25,2.000,5.700,8.000,0.064,0.192,1.024,0,0,192,256,0,0
SwitchRes: Monitor range 15625.00-16200.00,49.50-65.00,2.000,5.700,8.000,0.064,0.192,1.024,0,0,0,0,448,576
SwitchRes: Found output connector 'VGA-0'
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[cninja] Calculating best video mode for 256x240@58.000000 orientation: normal
SwitchRes: (   1)x(   1)_(60=0.0000Hz) - locked
SwitchRes: could not find a video mode that meets your specs


[timply]

I have an ATI 4350 video card with 1 vga port and 1 dvi port and just installed the new 2.0 drivers. Now the only way I can get my arcade monitor to work is to plug another monitor into the dvi port and my arcade monitor into the vga port and extend the display. Does that mean i will need to get an vga to dvi adapter and hook my arcade monitor up through the dvi port? This problem wasn't present before the driver update.

[Calamity]

This problem wasn't present before the driver update.

Indeed that was the problem we had before that we don't have now 

Anyway, you should be able to just remove the pc monitor from the dvi, tell Windows to only show desktop on monitor 2, and let the arcade monitor alone through the vga. I've done it this morning 3 times in a row with an HD 4350, it works.

[timply]

K thanks, I'll give that a shot.

[Calamity]

From the log, it is clear that groovymame is not able to switch to  native game resolution based on its calculation. It runs using the X default resolution instead.

Ok Doozer I can see the error, I'll prepare a new patch, thanks.

[Doozer]

From the log, it is clear that groovymame is not able to switch to  native game resolution based on its calculation. It runs using the X default resolution instead.

Ok Doozer I can see the error, I'll prepare a new patch, thanks.

Thanks Calamity. I have removed the non working versions from the drive and will upload the new versions when ready.

[Calamity]

Hi Calamity,

A constant is missing for the Linux build in switchres.h

#define XRANDR_TIMING   0x00000010

I am operating the build remotely over a very slow satellite link. Normally, the package will be ready this afternoon. I hope the upload will terminate before 2016 ;-)

Ok I think this is the problem, this constant needs to be redefined as:

#define XRANDR_TIMING      0x00000020

(check the new definition custom_video.h in the windows osd folder)

[Doozer]

Ok I think this is the problem, this constant needs to be redefined as:

#define XRANDR_TIMING      0x00000020

(check the new definition custom_video.h in the windows osd folder)

Indeed, the new value has fixed the issue with picture. Well done.

Unfortunately, I can see another strange behaviour with the keyboard detection. Time to time and for some games always, the keyboard inputs are not processed since the start of a game. I am currently compiling a stock mame for test to see if it is related to groovy or not. (wjammers log with keyboard issue in attachment)

[Calamity]

There is an error regarding xrandr mode setting, do you think it's related?

[Doozer]

It is not related. It is due previous killed execution leaving the video mode in xrandr.

[Doozer]

@Calamity

The stock mame is always detecting correctly the keyboard. The strange behaviour is reproducible on all previous groovymame version. I made some regression tests and I have identified that the issue is linked to the new SDL2 library (sdl2-2.0.4-2-x86_64 on ArchLinux). The sock mame does not have any issue, I assume it is linked to groovy patch in some way.

How does the groovy patch affect the keyboard code in mame?

[Doozer]

I am uploading the Linux builds, if you are using ArchLinux based distro (like GroovyArcade) keep sdl2 version until sdl2-2.0.3-1. Above version 2.0.3 keyboard will not be detected properly inside groovymame.

If you have already upgraded to latest SDL2 don't worry, here is how to downgrade to the right version.

Code: [Select]

# pacman -S downgrade
# downgrade sdl2
<select sdl2-2.0.3-1>


Code: [Select]

[root@cab1 ~]# pacman -S downgrade
resolving dependencies...
looking for conflicting packages...

Packages (1) downgrade-5.1.4-1

Total Download Size:   0.01 MiB
Total Installed Size:  0.10 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages ...
 downgrade-5.1.4-1-any                                                                5.9 KiB  0.00B/s 00:00 [################################################################] 100%
(1/1) checking keys in keyring                                                                               [################################################################] 100%
(1/1) checking package integrity                                                                             [################################################################] 100%
(1/1) loading package files                                                                                  [################################################################] 100%
(1/1) checking for file conflicts                                                                            [################################################################] 100%
(1/1) checking available disk space                                                                          [################################################################] 100%
(1/1) installing downgrade                                                                                   [################################################################] 100%
Optional dependencies for downgrade
    sudo: for installation via sudo [installed]
[root@cab1 ~]# downgrade sdl2
Available packages:

   1) sdl2-2.0.4-2-x86_64.pkg.tar.xz (remote)
   2) sdl2-2.0.4-1-x86_64.pkg.tar.xz (remote)
   3) sdl2-2.0.3-1-x86_64.pkg.tar.xz (remote)
   4) sdl2-2.0.2-2-x86_64.pkg.tar.xz (remote)
   5) sdl2-2.0.2-1-x86_64.pkg.tar.xz (remote)
   6) sdl2-2.0.1-3-x86_64.pkg.tar.xz (remote)
   7) sdl2-2.0.1-2-x86_64.pkg.tar.xz (remote)
   8) sdl2-2.0.1-1-x86_64.pkg.tar.xz (remote)

select a package by number: 3
######################################################################## 100.0%
######################################################################## 100.0%
loading packages...
warning: downgrading package sdl2 (2.0.4-1 => 2.0.3-1)
resolving dependencies...
looking for conflicting packages...

Packages (1) sdl2-2.0.3-1

Total Installed Size:   2.25 MiB
Net Upgrade Size:      -0.56 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                                                               [################################################################] 100%
(1/1) checking package integrity                                                                             [################################################################] 100%
(1/1) loading package files                                                                                  [################################################################] 100%
(1/1) checking for file conflicts                                                                            [################################################################] 100%
(1/1) checking available disk space                                                                          [################################################################] 100%
(1/1) downgrading sdl2                                                                                       [################################################################] 100%
add sdl2 to IgnorePkg? [y/n] n


[Calamity]

Thanks for digging into this Doozer. The only change that we do in GM is to poll input at a different place, just like we do in Windows. This shouldn't cause any issue, but input has proved to be extremely delicate under Linux.

[Doozer]

Thanks for digging into this Doozer. The only change that we do in GM is to poll input at a different place, just like we do in Windows. This shouldn't cause any issue, but input has proved to be extremely delicate under Linux.

Apparently SDL2.0.4 introduces the multi keyboard handling feature. This feature is if high interest for mame and some emulator to route/filter the controls. It was initially planed for 2.1.0, I am not sure mame does use/include changes linked to it but it is my best guess at this time.

[Calamity]

Hi Doozer,

When you tested 0.169 with the redefined constant (#define XRANDR_TIMING      0x00000020), did you do it remotely? Could you confirm if the fullscreen settings are applied properly on the real hardware?

EDIT: @VeS & Doozer. Regarding input, could you please test this? In the patched source tree:

src/osd/sdl/window.cpp
    OSDWORK_CALLBACK( sdl_window_info::draw_video_contents_wt ) --> uncomment    sdlinput_process_events_buf();

src/osd/sdl/video.cpp

    void sdl_osd_interface::poll_input(void) ----> comment    sdlinput_process_events_buf();

[Doozer]

When you tested 0.169 with the redefined constant (#define XRANDR_TIMING      0x00000020), did you do it remotely? Could you confirm if the fullscreen settings are applied properly on the real hardware?

I did the test with a solid real screen attached to the computer ;-) It is working as expected with 0x20 constant. Fixed.

EDIT: @VeS & Doozer. Regarding input, could you please test this? In the patched source tree...

I will test this tonight to ensure real keyboard usage and not VNC/X11 craps.

[Doozer]

Thanks for digging into this Doozer. The only change that we do in GM is to poll input at a different place, just like we do in Windows. This shouldn't cause any issue, but input has proved to be extremely delicate under Linux.

Apparently SDL2.0.4 introduces the multi keyboard handling feature. This feature is if high interest for mame and some emulator to route/filter the controls. It was initially planed for 2.1.0, I am not sure mame does use/include changes linked to it but it is my best guess at this time.

I made some investigation. MAME have already the multikeyboard feature implemented and SDL 2.0.4 handling is fully supported. Nothing to worry about from this side. My assumption is that the removed early processing of the keyboard events performed in the worker thread is causing the behaviour. This is aligned with Calamity proposed test.

[Calamity]

I've uploaded fixed versions of 0.169, notice the "_fix" ended files. These are meant to be used with the new tools:

http://forum.arcadecontrols.com/index.php/topic,141855.msg1553415.html#msg1553415

Important note:

With regards to the issue with halved refresh on interlaced modes (W7), the new builds revert the previous fix. In order to avoid the problem, do either one of these things:

1.- If your monitor worked fine with tools 2.0 beta 3, this is because it has no problems with positive sync polarity. Use the new beta 4 tools, and edit your monitor preset to force positive sync. e.g.:
   
    crt_range0  15625-15750, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 1, 1, 192, 288, 448, 576

    This must be done when creating the modes with VMMaker, not only in mame.ini.

2.- If your monitor failed to sync with tools 2.0 beta 3, you need to keep negative sync polarity (default). In order to run interlaced games at full speed, do either one of these things:

               a) Enable frame_delay (e.g. -fd 1) If you have a half-decent machine, this will work smoothly
               b) Force -video ddraw

[haynor666]

Eh, this will probably brake Taito Type X games, probably also Model2 emulator :/

[Calamity]

There is (yet) another problem with the "fixed" versions not properly updating modes. Please don't download until further notice.

[haynor666]

Ok, I'll compile latest GIT with previous code.

[Calamity]

Ok, I'll compile latest GIT with previous code.

All 0.015l patches contain the bug. Building a new binary right now.

[Doozer]

src/osd/sdl/window.cpp
    OSDWORK_CALLBACK( sdl_window_info::draw_video_contents_wt ) --> uncomment    sdlinput_process_events_buf();

src/osd/sdl/video.cpp

    void sdl_osd_interface::poll_input(void) ----> comment    sdlinput_process_events_buf();

A good guess but result shows still not response from keyboard (tested under wjammers). The early worker thread is not the issue. The last possibility is that poll_input is called too late to be taken into account in the treatment of the events.

[Calamity]

To completely revert the effect of the patch, in addition to those changes you need to leave empty the poll_input function, then move those calls where they belong, above in the video update routine.

[Doozer]

To completely revert the effect of the patch, in addition to those changes you need to leave empty the poll_input function, then move those calls where they belong, above in the video update routine.

I have already performed this test, No progress O_o issue is not linked to the input handler...