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: GM ASIO ALPHA 0.171  (Read 93956 times)

0 Members and 1 Guest are viewing this topic.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #80 on: June 13, 2015, 02:27:49 pm »
I decided to test with direct draw again.  I can run for 30 minutes with zero issues with an ASIO latency of 96 and the following settings in sfiii3:

-video ddraw -asio_holdoff 1152 -frame_delay 1

I also checked the input lag.  I counted the first 20 samples in the video, and every single one reflected input on the 2nd frame after it was entered.  I still can't produce any evidence that it's possible to get next-frame response with ddraw in Windows 7.  However, I think these are the settings I will stick with this game, and most others.  Perhaps consistent 2nd-frame response is preferable to getting next-frame response 50% of the time anyway.

Also, with CPS2 games, I can run with the same settings and asio_holdoff 832 for 30 minutes and only get 16 underruns.  Very nice.  It will be interesting to see how d3d compares with the change that was mentioned.  sfa3 was actually the game that prompted me to reduce all the way to fd 1, because severe audio issues occurred with higher values when asio_holdoff was set to 832.  Since I get consistent 2nd frame response with FD 1 in both CPS2 and CPS3 games and can't get next-frame ddraw response even at fd9, using a higher setting than 1 seems pointless.  Of course, this contrasts with what we've seen with d3d so far, where it seems that using as high of an fd value as possible before issues occur is ideal.
« Last Edit: June 13, 2015, 02:34:49 pm by vicosku »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #81 on: June 13, 2015, 07:01:50 pm »
Sorry for a 3rd post in a row, but I just wanted to share some more of my direct draw results.  CPS1 tests give me a 3rd frame input result rarely when input was received at the very end of a frame.  CPS2 and CPS3 may be the same, but I didn't see any 3rd frame results in the samples I counted for those.  I can use frame_delay 8 in CPS1/2 only if I increase asio_holdoff to 1536 to eliminate sound issues, but I don't think I'm going to bother.  It feels good at frame_delay 1.

I also tested Neo Geo, which gave me more pronounced differences.  Frame Delay 1 allows input to be shown on the third frame 50% of the time.  Frame delay 8 reduced this to 1/20 samples, while still allowing for perfect audio at ASIO 96 asio_holdoff 832, unlike CPS1/2/3.  I'd also like to reiterate that I don't achieve next-frame input results with d3d in Neo Geo games either. All these settings really have to be evaluated on a per-game, or at least per-driver, basis.
« Last Edit: June 13, 2015, 07:06:39 pm by vicosku »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #82 on: June 15, 2015, 08:48:21 am »
Hi everyone, and sorry the late reply, been real busy lately. I removed the hack mentioned in the above post, and I've uploaded it to here: http://www.mediafire.com/download/9vuzpvsz8vg9u88/gmame162-asio-hack_removed.zip

I'm unsure if I need to change anything in the first code chunk (PresentationInterval), so that's left as is.


Edit: realized that more changes were needed, aside from just commenting out the snippet posted.

I should put together an updated diff so others can experiment with the ASIO stuff as well. Might put together a short tutorial how to get started with building with MSVC, could use a refresher myself.

vicosku: Thanks again for your tests, I'll read them more thoroughly the next few days.
« Last Edit: June 15, 2015, 09:04:01 am by intealls »

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: GM ASIO PRE-ALPHA
« Reply #83 on: June 15, 2015, 01:02:46 pm »
Hi intealls,

Is MSVC strictly required? Wouldn't it be possible to compile it with MinGW without major changes?
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

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #84 on: June 15, 2015, 02:02:37 pm »
Last time I tried, I was unable to build because of BASSASIO. But I'll give it a shot again, and report how it goes.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #85 on: June 16, 2015, 10:59:33 am »
Hi intealls,

Is MSVC strictly required? Wouldn't it be possible to compile it with MinGW without major changes?

Good news! It builds (both 32 and 64-bit). The last time I tried was at 0.156, and luckily lots have happened since then.

I'll have a patch ready sometime later tonight.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #86 on: June 16, 2015, 11:28:43 am »
I'll have a patch ready sometime later tonight.

Great news!  I'm greatly looking forward to testing the patch.  I'm having a bunch of people over this weekend and am excited to show off GroovyMAME in the best light possible.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #87 on: June 16, 2015, 11:51:48 am »
I'll have a patch ready sometime later tonight.

Great news!  I'm greatly looking forward to testing the patch.  I'm having a bunch of people over this weekend and am excited to show off GroovyMAME in the best light possible.

Actually, MSVC seems to produce slightly faster builds. Building with MinGW is purely for convenience, since setting up MSVC can be quite a hassle.

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #88 on: June 16, 2015, 01:42:45 pm »
If you're using a newer version of the MAME build tools, you'll need to pacman -S the following packages:

Code: [Select]
mingw64/mingw-w64-x86_64-tools-git
msys/patch

Instructions:

download http://uk.un4seen.com/files/bassasio13.zip
unzip mame sources
unzip bassasio13.zip in [extracted root dir]\bassasio

start buildtools
go to root dir
run fix_bassasio_mingw.bat

if building for GM:
patch -p0 -E < hi_[ver].diff
patch -p0 -E < [ver]_groovymame_015x.diff
patch -p1 -E < asio_[ver]_gm.txt
make CPPFLAGS=-DGM -j[n], where n is the number of workers you want, usually number of CPUs + 1

if building for vanilla:
patch -p1 -E < asio_[ver]_mainline.txt
then make as you usually do

copy the right BASSASIO.dll to the root folder (32 = bassasio\bassasio.dll / 64 = bassasio\x64\bassasio.dll) and go

See the first post http://forum.arcadecontrols.com/index.php/topic,142143.0.html for the link to the latest patch
« Last Edit: February 25, 2016, 05:24:42 pm by intealls »

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: GM ASIO PRE-ALPHA
« Reply #89 on: June 17, 2015, 04:26:07 pm »
Hi intealls,

Great work, thanks for this, and very good news it can be compiled with MinGW. Compared with your old patch I've noticed you no longer modify some of the Switchres files (modeline.c, etc). I was curious about this at the time. Hopefully I have some time during the next weeks to test this combined with the patch I mentioned above (remove the frame queue patch and use d3d 9ex.)

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #90 on: June 17, 2015, 05:27:22 pm »
Yes, thanks again, Intealls! 

Calamity, I've compiled a binary with this patch and your suggested d3d changes.  I had to fix a couple of typos with the code you posted.  This is basically my first time doing this, so hopefully I haven't made any mistakes.  I won't be able to test until late tonight, but here it is, along with the code I used in drawd3d.c

Link removed.  Not properly built.

I assume you meant to comment this section out, so I used */ instead of /* at the end based on what notepad++ was telling me.
Code: [Select]
/*
// sync to VBLANK
if (window().machine().options().frame_delay() != 0 && ((video_config.triplebuf && window().fullscreen()) || video_config.waitvsync || video_config.syncrefresh))
{
D3DRASTER_STATUS raster_status;
memset (&raster_status, 0, sizeof(D3DRASTER_STATUS));

while (!raster_status.InVBlank)
{
if ((*d3dintf->device.get_raster_status)(m_device, &raster_status) != D3D_OK)
break;
}
}
*/

I couldn't get what you posted to allow compilation, so I just pulled this from the unpatched file.  I assume it was just forum formatting causing the problem.  This is what I used.

Code: [Select]
m_presentation.PresentationInterval          = ((video_config.triplebuf && window().fullscreen()) ||
video_config.waitvsync || video_config.syncrefresh) ?
D3DPRESENT_INTERVAL_ONE : D3DPRESENT_INTERVAL_IMMEDIATE;
« Last Edit: June 17, 2015, 05:58:06 pm by vicosku »

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: GM ASIO PRE-ALPHA
« Reply #91 on: June 17, 2015, 05:41:41 pm »
Yes, sorry for that, I didn't test the code. However that needs to be combined with the Direct3D 9ex link added in the same post, otherwise you'll be getting several frames of added lag due to the frame queue.
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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #92 on: June 17, 2015, 05:47:50 pm »
Ah, Koopah's stuff, right?  Sorry, I missed that.  Okay, I'll give it a try.

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: GM ASIO PRE-ALPHA
« Reply #93 on: June 17, 2015, 05:59:27 pm »
Problem is, there's not a diff but the actual modified files, so you need to compare those to codebase from February to figure out the changes.
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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #94 on: June 17, 2015, 06:04:56 pm »
Hah, I knew it couldn't be as easy as I thought.  Okay, I'll give it a shot.  Whether I succeed or discover it's beyond me, I'll post an update.  Maybe Intealls or someone else will beat me to it though.

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #95 on: June 18, 2015, 07:20:23 pm »
I think I have it.  D3D with Frame Delay 0 in sfiii3 with regular GroovyMAME typically gives me input results on the 5th or 6th frame.  With Koopah's changes, I get consistent results on the 3rd frame, which is basically what I get with ddraw and frame_delay 0. So, I think I got at least part of these changes right.  Also, I can now use frame_delay 8 in sfiii3 with only 1 overrun in 30 minutes with the same settings that produced over 100 before.

However, frame_delay seems to have no effect now.  I get 3rd frame results with frame_delay 8 where I got 1st and 2nd frame results without these changes.  I hope I've done something wrong.  I think this is far as I can go for now.  I'll leave it to the pros from here.  I'll share what I've done in case it's helpful in any way, along with the resulting binary.

I first tried to copy Koopah's changes from the .158 to .162 source, and then performed the process outlined by Intealls, along with the addition of the changes suggested by Calamity.  The only part that tripped me up was some sort of change in drawd3d.c regarding"d3d::renderer::get_primitives();" from .158 to .162.  I tried what I figured the new value should be.  I had little idea what I was doing, so it's likely I didn't edit this part correctly.

ddrawd3d.c
d3d9intf.c
Build

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #96 on: June 18, 2015, 08:42:59 pm »
I think I have it.  D3D with Frame Delay 0 in sfiii3 with regular GroovyMAME typically gives me input results on the 5th or 6th frame.  With Koopah's changes, I get consistent results on the 3rd frame, which is basically what I get with ddraw and frame_delay 0. So, I think I got at least part of these changes right.  Also, I can now use frame_delay 8 in sfiii3 with only 1 overrun in 30 minutes with the same settings that produced over 100 before.

However, frame_delay seems to have no effect now.  I get 3rd frame results with frame_delay 8 where I got 1st and 2nd frame results without these changes.  I hope I've done something wrong.  I think this is far as I can go for now.  I'll leave it to the pros from here.  I'll share what I've done in case it's helpful in any way, along with the resulting binary.

I first tried to copy Koopah's changes from the .158 to .162 source, and then performed the process outlined by Intealls, along with the addition of the changes suggested by Calamity.  The only part that tripped me up was some sort of change in drawd3d.c regarding"d3d::renderer::get_primitives();" from .158 to .162.  I tried what I figured the new value should be.  I had little idea what I was doing, so it's likely I didn't edit this part correctly.

ddrawd3d.c
d3d9intf.c
Build

Great job! I can't be of any help when it comes to D3D/frame_delay (aside from testing), but I look forward to see how this affects the audio sample generation.

stellarola

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 644
  • Last login:June 24, 2020, 11:46:59 pm
  • .::For the love of the game::.
Re: GM ASIO PRE-ALPHA
« Reply #97 on: June 20, 2015, 11:36:56 am »
Hope this version is still active. Any builds for MAME 0.162? I've never had much luck compiling GroovyMAME myself.

Thanks  :)

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #98 on: June 20, 2015, 11:49:00 am »
Hope this version is still active. Any builds for MAME 0.162? I've never had much luck compiling GroovyMAME myself.

Thanks  :)

Sure, here's 0.162 built with MSVC: http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip

And here's 0.162 with koopah's D3D changes built with MinGW by vicosku. https://mega.co.nz/#!KdETRDQT!1jH0l6WuJ6a1QAw_GX6MnjbvqxanOji8ujb43UbAx70

stellarola

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 644
  • Last login:June 24, 2020, 11:46:59 pm
  • .::For the love of the game::.
Re: GM ASIO PRE-ALPHA
« Reply #99 on: June 20, 2015, 11:59:24 am »
You're great, intealls! :)

Much appreciated. Going to get this going today!

Thanks again! :cheers:

Hope this version is still active. Any builds for MAME 0.162? I've never had much luck compiling GroovyMAME myself.

Thanks  :)

Sure, here's 0.162 built with MSVC: http://www.mediafire.com/download/n2jyl6f773p530h/gmame162-asio.zip

And here's 0.162 with koopah's D3D changes built with MinGW by vicosku. https://mega.co.nz/#!KdETRDQT!1jH0l6WuJ6a1QAw_GX6MnjbvqxanOji8ujb43UbAx70

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: GM ASIO PRE-ALPHA
« Reply #100 on: June 20, 2015, 12:14:00 pm »
And here's the patch!

Thanks! :)


I think I have it.  D3D with Frame Delay 0 in sfiii3 with regular GroovyMAME typically gives me input results on the 5th or 6th frame.  With Koopah's changes, I get consistent results on the 3rd frame, which is basically what I get with ddraw and frame_delay 0. So, I think I got at least part of these changes right.  Also, I can now use frame_delay 8 in sfiii3 with only 1 overrun in 30 minutes with the same settings that produced over 100 before.

However, frame_delay seems to have no effect now.  I get 3rd frame results with frame_delay 8 where I got 1st and 2nd frame results without these changes.  I hope I've done something wrong.  I think this is far as I can go for now.  I'll leave it to the pros from here.  I'll share what I've done in case it's helpful in any way, along with the resulting binary.

Thanks vicosku for your work, it's promising that at least d3d with frame_delay disabled works better than regular groovymame with framedelay disabled.

Too bad the framedelay now does not seem to work at all. This would also explain the sudden very low number of overruns on sfiii while using fd 8, i.e. it's actually not invoking framedelay thus being equivalent to fd 0 for sound stability.

Hopefully Calamity will find some time to run through the code and see what possibly may be wrong.

I decided to test with direct draw again.  I can run for 30 minutes with zero issues with an ASIO latency of 96 and the following settings in sfiii3:

-video ddraw -asio_holdoff 1152 -frame_delay 1

I also checked the input lag.  I counted the first 20 samples in the video, and every single one reflected input on the 2nd frame after it was entered.  I still can't produce any evidence that it's possible to get next-frame response with ddraw in Windows 7.  However, I think these are the settings I will stick with this game, and most others.  Perhaps consistent 2nd-frame response is preferable to getting next-frame response 50% of the time anyway.

Also, with CPS2 games, I can run with the same settings and asio_holdoff 832 for 30 minutes and only get 16 underruns.  Very nice.  It will be interesting to see how d3d compares with the change that was mentioned.  sfa3 was actually the game that prompted me to reduce all the way to fd 1, because severe audio issues occurred with higher values when asio_holdoff was set to 832. Since I get consistent 2nd frame response with FD 1 in both CPS2 and CPS3 games and can't get next-frame ddraw response even at fd9, using a higher setting than 1 seems pointless.  Of course, this contrasts with what we've seen with d3d so far, where it seems that using as high of an fd value as possible before issues occur is ideal.

Thanks again for all the testing you've been doing. I'm intrigued by your findings (also posted about previously) that ddraw never seems to provide next frame response, even when using high values for framedelay. For some reason it seems that with ddraw another video buffer is created, or that it somehow blocks the input polling longer than d3d.

Would you be willing to do another test for ddraw (using regular groovymame), involving the radeonpro tool (http://www.radeonpro.info/download/)? Basicly I would like to force the flipqueuesize to 1 while using ddraw with regular groovymame and fd 7 to 9.

There is however a little trick involved, as the radeon pro tool cannot take hold of a program running in administrator mode (such as groovymame for win 7).

The trick is to use a "dummy" executable that is started before groovymame, and triggers the radeon pro profile. For example you could use Soft15Khz as it just sits in the windows tray doing nothing. But if you add it to radeon pro it will trigger the radeon pro profile when started.

Could you test it this way, adding soft15khz to a radeonpro profile, and in this profile change flipqueuesize to 1 (found in the Advanced Tab), and disabling Aero (found in the Tweaks Tab).

It's important that you also disable aero, as it will give a visual clue that Radeonpro is actually activating the profile when you start the dummy executable (soft15khz in this example). If you're going to do this test, please make double sure it's triggering the profile correctly, as radeon pro itself will give no clue that it's activated. If you include the disabling of Aero, you'll see Windows switching from Aero to non-Aero desktop as soon as the dummy executable is started.

Once you're sure that the dummy executable is triggering the radeonpro profile correctly you can then start regular groovymame with ddraw and a high framedelay value. I'm very curious whether forcing the FlipQueueSize of 1 will cause next frame responses to occur in your test for ddraw.  It's a wild guess, but sometimes trying those may be worthwhile... :)

Of course when you're sure that manually everything is working as it should, you could create a little batch file to simplify things, for example (use your own paths):

Start Q:\Emulators\Soft15Khz\Quickres.exe
Timeout /T 1
start /min /wait mame.exe
taskkill /IM Quickres.exe


« Last Edit: June 20, 2015, 12:18:14 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: GM ASIO PRE-ALPHA
« Reply #101 on: June 21, 2015, 06:01:29 am »
I've just tried "official" GM 0.162 with -video ddraw -fd 6, I do get next frame response here in XP. I did have to lower the -fd value with respect to d3d. Notice in my modest machine I can only get next frame response when input is registered during the first 1/3 of the previous frame.

https://www.dropbox.com/s/k6kj90npzi930x1/sf2_ddraw_fd_6.MOV?dl=0
« Last Edit: June 21, 2015, 06:09:25 am 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

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: GM ASIO PRE-ALPHA
« Reply #102 on: June 21, 2015, 08:50:46 am »
Well I've created a diff to apply koopah's patch, this is better than having the whole source files and can be applied to future versions. It's meant to be applied after the groovymame diff (although the order might not matter).

I've created another diff, "fd_mod", this is experimental and an attempt to get next frame response with D3D9ex too. It will probably not do anything useful but it's worth a try. I've moved the manual wait for vertical blank *after* the present call*. This patch is to be applied after the koopah's one. I can't test it myself because my led-wired machine is still xp only.

I've uploaded a build for quick testing, this one does not include inteall's a asio patch, just plain GM with D3D9ex and the mod mentioned above:

https://www.dropbox.com/s/jv1jdk2cmgnce7z/mame64_d3d9ex.7z?dl=0

* Instead from manually calling GetRasterStatus in a loop as we do now, I also tried the "new" WaitForVBlank method that exists since D3D9ex, but it's damned slow, at least for the Intel drivers I'm testing with, so I discarded it.
« Last Edit: June 21, 2015, 08:55:49 am 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: GM ASIO PRE-ALPHA
« Reply #103 on: June 21, 2015, 09:02:43 am »
I've just tried "official" GM 0.162 with -video ddraw -fd 6, I do get next frame response here in XP.

That's great news! Was your test performed with sfiii (same as vicosku)?

It might be then that vicosku's results for ddraw are specific to Windows 7.  I wouldn't be surprised if there's some humpty dumpty extra buffering going on with ddraw in Win 7, or not... we'll find out hopefully ;)

Would it be possible for you to do the same test in your Windows 7 machine? 

Edit:  I just see your other post that you have your LED setup only on your XP machine..  too bad. 

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: GM ASIO PRE-ALPHA
« Reply #104 on: June 21, 2015, 09:38:57 am »
Was your test performed with sfiii (same as vicosku)?

No, I tested sf2, I don't have the chd for sfiii3 in my cab. Anyway, any game that's known to react in the next frame is good for testing.

Quote
It might be then that vicosku's results for ddraw are specific to Windows 7.  I wouldn't be surprised if there's some humpty dumpty extra buffering going on with ddraw in Win 7, or not... we'll find out hopefully ;)

ddraw is emulated to some extent in W7, probably through D3D, so maybe.
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: GM ASIO PRE-ALPHA
« Reply #105 on: June 21, 2015, 10:06:15 am »
No, I tested sf2, I don't have the chd for sfiii3 in my cab. Anyway, any game that's known to react in the next frame is good for testing.

I see what you mean.

I think it would be better if we all would settle on one particular game for all testing though, just to be 100% sure we are comparing apples with apples.

It would not be the first time a specific driver gets some extra buffer implemented in the driver itself, making comparisons worthless.  Would you agree? I would be fine with sf2 being that game though. 

Quote
ddraw is emulated to some extent in W7, probably through D3D, so maybe.

*IF* this would be the case, I have a hunch that what I outlined in one of my previous posts, may do away with this extra delay.

I've uploaded a build for quick testing, this one does not include inteall's a asio patch, just plain GM with D3D9ex and the mod mentioned above:

https://www.dropbox.com/s/jv1jdk2cmgnce7z/mame64_d3d9ex.7z?dl=0

A quick comment about this build, it seems it has an (the old?) issue with interlaced screens.

When I start Playstation Japan (driver "psj") it immediately complains with*:

Direct3D: Error 08760877 during device present call

I guess this is because PSJ starts with an interlaced screen? The regular GM 0.162 works without an issue with the same settings.

Maybe a silly question, but I see the log reporting "Direct3D: Using Direct3D 9", shouldn't this be reporting explicitly that Direct3D 9Ex is being used?


*Edit: I have interlaced enabled in the psj.ini
  Edit 2:  Indeed if I disable interlace in psj.ini ("interlace 0") then the issue does not occur. Just to be complete I have the following modeline for interlace in the config:
  crt_range2                "15525-15780, 49.00-63.00, 3.556, 4.741, 7.111, 0.064, 0.160, 1.120, 0, 0, 0, 0, 448, 480"



« Last Edit: June 21, 2015, 10:24:35 am by Dr.Venom »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #106 on: June 21, 2015, 12:55:58 pm »
This weekend is really busy for me, so I just have a quick reply for now.

Dr. Venom, I'm very interested in running the tests you described.  It will likely be a few days until I can, however. 

Calamity, that's excellent news the next frame response with DDRAW is possible.  I may need to put XP on my secondary machine again, if only for testing.  I loaded up official GM .162 in a completely fresh directory with ddraw and FD6.  I still can't get next-frame response on Windows 7 on either of my machines.  FD9 is the same.

Thank you for providing the diff and build with the D3D9ex changes so quickly!  I tested sf2 on your fd_mod build with frame_delay 9 in a fresh directory and get next-frame response again!  However, I didn't realize until reviewing the video that I still had ddraw set from the previous tests, and I am out of time to do more tests this morning.  So far, it seems something about this build is allowing me to get next-frame response in Windows 7 with ddraw, unlike the current official build.  I should be able to test d3d with this one tomorrow and post some videos. 

*Edit - Please ignore lazy testing.
« Last Edit: June 22, 2015, 08:51:26 am by vicosku »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #107 on: June 21, 2015, 01:35:44 pm »
Awesome stuff here :)

To add further fuel to the confusing array of builds currently flying around this thread I applied the patches Calamity posted earlier to the ASIO build. It can be found here: http://www.mediafire.com/download/ra59b1etw50rst7/gmame162-asio-calamity-koopah.zip

However, currently, it seems sensible that all purely frame-delay related tests should be performed against vanilla!

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #108 on: June 22, 2015, 08:48:43 am »
Thanks, Intealls!  I'll test this too.  I hope you don't mind all this input delay discussion in your thread. I think we all are in search of the same thing - lowest possible input response while using your patch to achieve perfect audio.  I took some time this morning to properly organize my input delay test results for use as reference in further discussion.  I've left the ASIO patch out of the results for now, though my earlier testing gives me confidence that it is not responsible for significant input delays.

Calamity, I'm sorry, you can get next-frame response with ddraw in Windows 7 with official GM .162.  I didn't count enough samples before.  However, based on several tests, I cannot approach the next-frame response percentage I get with d3d in official GM with frame_delay 9, which is now nearly 75%.  DDraw gives me about 25% out of 40 samples among two tests (1 official, 1 d3d9ex_fd_mod).

Here are links to videos of 6 different tests and a spreadsheet counting the first 20 responses from each.  Unfortunately, the D3D9ex/FD_mod build did not allow next-frame response on any of the 40 samples I counted (half fd6, half fd9). Most were 2nd frame though, which is better than the 3rd frame results my sketchy build produced.

Spreadsheet
official .162 ddraw fd9
official .162 d3d fd9
d3d9ex_fdmod_Ddraw FD9
d3d9ex_fdmod_Ddraw FD1
d3d9ex_fdmod_fd6
d3d9ex_fdmod_fd9

*edit - Formatting.
« Last Edit: June 22, 2015, 08:52:12 am by vicosku »

intealls

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 318
  • Last login:Yesterday at 08:31:25 pm
  • I want to build my own arcade controls!
Re: GM ASIO PRE-ALPHA
« Reply #109 on: June 22, 2015, 09:54:27 am »
Thanks, Intealls!  I'll test this too.  I hope you don't mind all this input delay discussion in your thread. I think we all are in search of the same thing - lowest possible input response while using your patch to achieve perfect audio.

I certainly don't mind, you're absolutely right. :) It was frame delay that triggered me to start developing the ASIO patch.

Also, if you're using the ASIO build and want to know more about how a game performs, as well as more info about sample generation and under-/overruns, you can use the attached Octave script. I found it extremely useful when testing various frame delay settings.

Octave can be downloaded from here: ftp://ftp.gnu.org/gnu/octave/windows/octave-4.0.0_0-installer.exe

Simply download l.txt and rename it to l.m. Run the game with -asio_log set, then start Octave, browse to the folder you placed l.m in in the top left file browser pane, and issue l('path to asio.log')', e.g. if asio.log is placed in c:\asio.log, you should issue l('c:\asio.log'). You should receive four nice graphs detailing emulation speed, as well as information about the number of samples in the left/right channel. The fd9 example picture shows bad results, the fd8 example picture shows OK results. Ideally, all the plots should be straight (like the first ~8000 samples in the fd8 example).
« Last Edit: June 22, 2015, 10:07:55 am by intealls »

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: GM ASIO PRE-ALPHA
« Reply #110 on: June 22, 2015, 11:54:52 am »
Vicosku, thanks a lot for your tests.

It's a relief to see that ddraw still works as supposed. Knowing the code in there, it was hard to explain that any hypothetical frame queue could be causing that. The worse result compared to d3d is expectable if ddraw stalls longer than d3d. Having that clear, I'd recommend that we focus on d3d because ddraw is dead and it won't even work with W8/10. I see moving to D3D9ex or higher an attempt to make ddraw absolutely unnecessary as we are not going to have it available anymore.

It's certainly a big disappointment that D3D9ex doesn't allow next frame response out of the box. This will require either to stick with hacks by now, which make the timing unstable for something like asio to work properly, or rennounce to next frame response.  I have a theory of what could be happening with D3D9ex, it'd be good to confirm that D3D9ex *without* the fd_mod diff actually lags a frame more (in other words, that the fd_mod actually does something).
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: GM ASIO PRE-ALPHA
« Reply #111 on: June 22, 2015, 02:27:31 pm »
Great stuff guys, loving it!! :)

Also, if you're using the ASIO build and want to know more about how a game performs, as well as more info about sample generation and under-/overruns, you can use the attached Octave script. I found it extremely useful when testing various frame delay settings.

Thanks for pointing this out. I look forward to running some of these analyses myself, and reporting back course!

Calamity, I'm sorry, you can get next-frame response with ddraw in Windows 7 with official GM .162.  I didn't count enough samples before.  However, based on several tests, I cannot approach the next-frame response percentage I get with d3d in official GM with frame_delay 9, which is now nearly 75%.  DDraw gives me about 25% out of 40 samples among two tests (1 official, 1 d3d9ex_fd_mod).

Here are links to videos of 6 different tests and a spreadsheet counting the first 20 responses from each.  Unfortunately, the D3D9ex/FD_mod build did not allow next-frame response on any of the 40 samples I counted (half fd6, half fd9). Most were 2nd frame though, which is better than the 3rd frame results my sketchy build produced.

Thanks for your relentless testing,  awesome to get to the bottom of this :)

Dr. Venom, I'm very interested in running the tests you described.  It will likely be a few days until I can, however.
 

Hopefully you have some time left to do a test while forcing the FlipQueueSize to 1 and disabling Aero through RadeonPro as referred to in my previous post (see here).

It will be interesting to see whether it can improve the next frame response significantly above the 25%, for Windows 7 at least. Could you possibly perform the test with both regular GM and the new one?

If you have any questions or doubts about setting up RadeonPro correctly as described, then please let me know.

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: GM ASIO PRE-ALPHA
« Reply #112 on: June 22, 2015, 02:50:25 pm »
Hopefully you have some time left to do a test while forcing the FlipQueueSize to 1 and disabling Aero through RadeonPro as referred to in my previous post (see here).

It will be interesting to see whether it can improve the next frame response significantly above the 25%, for Windows 7 at least. Could you possibly perform the test with both regular GM and the new one?

If you have any questions or doubts about setting up RadeonPro correctly as described, then please let me know.

My understanding is that as long as you're getting next frame response, even if it's 25% or 90% of the times, there can't be a frame queue. Which I consider that has been demonstrated for the ddraw case.

The RadeonPro tool FlipQueueSize must be the same as the SetMaximumFrameLatency method but operating externally, in the same way that you can override the vsync settings of any app. I'd be surprised if it did something different (I'd be forced to reverse-engineer it), obviously it's worth a try.

I'm afraid the problem is that even when the queue is set to its minimum (1), d3d/ati insists on scheduling the flip instead of performing it immediately during next retrace. I've tried to compesate for this by inserting an additional vertical retrace sync after the present call (in case this was the problem). Ideally this would need to be done only after the first present call, assuming there's only one frame mismatch.

Modern video APIs suck big time.
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
« Last Edit: June 22, 2015, 05:44:59 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: GM ASIO PRE-ALPHA
« Reply #114 on: June 22, 2015, 06:22:33 pm »
The RadeonPro tool FlipQueueSize must be the same as the SetMaximumFrameLatency method but operating externally, in the same way that you can override the vsync settings of any app. I'd be surprised if it did something different (I'd be forced to reverse-engineer it), obviously it's worth a try.

In theory they would be the same yes. But I've learned to distrust the theory with regards to PC's and Windows.

Why I think this could be different is that
- calling SetMaximumFrameLatency() will only really do something if it's correctly implemented in the video driver, which is an unknown. Especially since it's ATI. Remember your finding on hardcoded flipqueuesize in the ATI drivers for XP?
- setting the FlipQueueSize is an undocumented feature of -earlier- ATI drivers, such as the one CRT Emudriver is based upon (catalyst 13.1 for Win 7).
Note that in one thread at the radeonpro board someone had asked ati for what the different flipqueuesize values meant and he got answered "I got in touch with AMD and they refuse to answer me because changing the queue size is not supported officially by AMD".

So it's just healthy scepticism which makes me think that we shouldn't rule out some wonky stuff with the video driver. Using the undocumented feature** to force the driver to using a FlipQueueSize of 1 seems like a sensible test to do.

**From reading comments of the programmer of RadeonPro, the -early- Catalyst drivers look for a registry key that may override the default FlipQueueSize value. It's actually this undocumented feature that RadeonPro uses to change the FlipQueueSize.

Hopefully vicosku's tests will provide us with the necessary evidence on its effectiveness.


An additional thought:

Apparently during 2013 this undocumented feature was removed from the ATI driver.  So for Catalyst 13.1 (our current one) the RadeonPro tool works, but for Catalyst 13.9, the last driver released for HD4XXX cards, the feature apparently will not work anymore.

This sparks another thought, maybe in Catalyst 13.9 (released at the end of 2013) they not only disabled the undocumented registry key feature for the FlipQueueSize, but may actually have changed/improved the way it works for Windows 7? Possibly (small chance) the call to SetMaximumFrameLatency will do things differenty in this driver?
« Last Edit: June 22, 2015, 06:24:59 pm by Dr.Venom »

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #115 on: June 22, 2015, 07:04:23 pm »
I have a theory of what could be happening with D3D9ex, it'd be good to confirm that D3D9ex *without* the fd_mod diff actually lags a frame more (in other words, that the fd_mod actually does something).

I compiled with your d3d9ex_koopah.diff (No fd_mod) and ran a test with -video d3d -frame_delay 9.  18/20 inputs registered on next-frame!  I wonder if I somehow did something wrong...the two source files show the d3d9ex modiciations though, so I figure it must be correct.  I also removed the mame.ini I used in my previous tests in order to rely on switches entirely.  I thought this change might be somewhat responsible, but running the fd_mod version you posted in the same way gave the same 2nd frame results I posted earlier, so I don't think my mame.ini affected the results at all.  Here's the video.

d3d9ex_only

Dr. Venom, I also tried the RadeonPro tool you mentioned.  I used the official .162 build with ddraw and fd9 and used the soft15khz trigger you outlined.  To my surprise, this also produced excellent results, with all but two results showing next-frame response.  Were there other variables you wanted me to test with?

RadeonPro

I need to test these variables some more with the asio patch.  I've only done a little and need to quit for the day, but initial results are still requiring that I increase audio latency greatly when using high frame_delay values with either solution above depending on the game, of course.  For example, I have to pull all the way back to Frame_delay 1 to stop severe audio issues with sf2 at lower ASIO latencies with ddraw, and I don't get next frame response with this low of an FD setting.  I'm also getting similar buffer overrun/underrun results from the d3d9ex version as I do with the official version, so I'm still a little suspicious of the build I compiled. I'll let you know how it goes.
« Last Edit: June 22, 2015, 07:06:07 pm by vicosku »

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: GM ASIO PRE-ALPHA
« Reply #116 on: June 22, 2015, 07:09:01 pm »
The RadeonPro method is definitely worth a try. Just a bit too pessimistic due to the 9ex fiasco.

Just made another attempt, this time flushing the command queue after presenting, as the second link I posted above suggests. Here's the binary:

https://www.dropbox.com/s/qp1b0t4v8sbcl8i/mame64_d3d9ex_flush.7z?dl=0

(the patch is to be applied right after koopah's one, the old "fd_mod" is no longer necessary)
« Last Edit: June 22, 2015, 07:16:13 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

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: GM ASIO PRE-ALPHA
« Reply #117 on: June 22, 2015, 07:15:17 pm »
Vicosku, I'm afraid if you only applied koopah's patch then old frame delay code is still present, which has the hack that allows next frame response but causes unstable timing. The "fd_mod" patch removed that hack.

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

vicosku

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 107
  • Last login:November 25, 2020, 10:02:52 am
Re: GM ASIO PRE-ALPHA
« Reply #118 on: June 22, 2015, 07:41:42 pm »
Thanks for the new version! I'll try it out tomorrow.

And thanks for the explanation.  I guess I misunderstood your comment about confirming if d3d9ex without fd_mod lags more.  Let me know if there's something else you'd like me to try.

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: GM ASIO PRE-ALPHA
« Reply #119 on: June 23, 2015, 03:31:22 am »
I guess I misunderstood your comment about confirming if d3d9ex without fd_mod lags more.

I'm sorry I made you waste your time, my fault. I meant without fd_mod but also without the hack that GM applies (the code snippet just above the present call). Anyway you'd need a custom build for that. Nevermind.
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