666 replies to this topic

[fuzzel]

 

 

So when i use 9.2.824 or better my keys doesn't answer anymore. i tried to solve it test lot of things without success

 

so 819 works and 824 not?

cause that would be really really weird as no input code was touched in that frame..

 

 

oups sorry,

838 is ok, but 839 and better don't work.

 

hmm weird, it's hard to tell why this doesn't work on your adapter. Actually I just poll for mouse state changes and the new code is seperated from the keyboard code(which is untouched btw). Could it be that this GP-Wiz40 acts like a mouse in some way?

[toxie]

 

The other thing is that I have the feeling that the right flipper responses well to the oblique correction but the left one needs a much higher value. I think there is something wrong with that. I noticed it at a large variety of tables that it's possible to hit targets in the middle of the table with the right flipper but it's almost impossible to do the same with the left one. Why is that?

 

uhm, there is (at least in theory) no separate code for left and right flippers (its all the same), so either there is a pretty substantial bug somewhere that manifests itself here, too, or the setting is somehow dependend on the angles set for the flipper..

 

i just looked at the code again, and as long as the scatter angle and the oblique correction values are the same for both flippers, they should react exactly the same in this aspect..

[vulbas]

 

 

 

So when i use 9.2.824 or better my keys doesn't answer anymore. i tried to solve it test lot of things without success

 

so 819 works and 824 not?

cause that would be really really weird as no input code was touched in that frame..

 

 

oups sorry,

838 is ok, but 839 and better don't work.

 

did you test with the latest 845? I've changed some stuff lately...

 

 

i have tested with the 845. the problem is same 

[fuzzel]

Well then I think I have to add a switch to disable the mouse handling in the player. DX doesn't support multiple mice in that way so it's not possible to enumerate for the right mouse and use just that. Will add the switch tomorrow.

@fuzzel: browsing the net, seems like others need to do it the hacky way, too: https://github.com/l.../input/dinput.c
so maybe really just listening for the window messages, but putting them into the queue like the 'other' mouse events would be easy enough?

There is a way to poll the current mouse button state but I don't know if this also works on touch devices. Processing the window states would screw up the input system I guess

[vulbas]

ok thx fuzzel 

[toxie]

 

There is a way to poll the current mouse button state but I don't know if this also works on touch devices. Processing the window states would screw up the input system I guess

 

there are these special 'pointer' messages (WM_POINTERDOWN, etc) that should not influence the standard mouse input.. just look into the code on the retroarch page i linked, it seems pretty simple..

Edited by toxie, 06 January 2014 - 10:12 PM.

[toxie]

In F-14, here is the code. I am sure it is probably the same across all releases of the tables.

 

Unfortunately i couldn't really find any reason why this should happen with the new builds and not the older ones..

 

But maybe its also just due to the new version of F-14? Cause with the 'old' F14 version everything seems alright (diverter problem never happened during testing), testing the newest one, i saw it multiple times..

Very strange..

[chinzman93]

 

In F-14, here is the code. I am sure it is probably the same across all releases of the tables.

 

Unfortunately i couldn't really find any reason why this should happen with the new builds and not the older ones..

 

But maybe its also just due to the new version of F-14? Cause with the 'old' F14 version everything seems alright (diverter problem never happened during testing), testing the newest one, i saw it multiple times..

Very strange..

 

Yes...that is strange. I tested with both my version which is based off of the Rosve Mod and Maurders version which I believe is based off of JP's original table and both had the issue. I know in my version I didn't do anything on related to the diverters. I will download JP's original when I get home and test with that. I suppose it isn't a huge deal since the 9.2 standalone doesn't show the issue. If there is a problem it will probably show itself on other tables eventually. Now if it isn't present on JP's original version, the primary addition of difference between the new and the old version is the presence of alpha ramps. Is there something that was done in 811 related to ramps that would maybe cause the problem to show up all of the sudden? Also would it be possible to revert the changes from 811 to create a test module to verify that the problem still exists or goes away?

 

Thanks for taking the time to look into this!

[chinzman93]

 

 

In F-14, here is the code. I am sure it is probably the same across all releases of the tables.

 

Unfortunately i couldn't really find any reason why this should happen with the new builds and not the older ones..

 

But maybe its also just due to the new version of F-14? Cause with the 'old' F14 version everything seems alright (diverter problem never happened during testing), testing the newest one, i saw it multiple times..

Very strange..

 

Yes...that is strange. I tested with both my version which is based off of the Rosve Mod and Maurders version which I believe is based off of JP's original table and both had the issue. I know in my version I didn't do anything on related to the diverters. I will download JP's original when I get home and test with that. I suppose it isn't a huge deal since the 9.2 standalone doesn't show the issue. If there is a problem it will probably show itself on other tables eventually. Now if it isn't present on JP's original version, the primary addition of difference between the new and the old version is the presence of alpha ramps. Is there something that was done in 811 related to ramps that would maybe cause the problem to show up all of the sudden? Also would it be possible to revert the changes from 811 to create a test module to verify that the problem still exists or goes away?

 

Thanks for taking the time to look into this!

 

I just retested with JP's original version 1.01.  I am getting the same diverter issue with build 811. Both the second and third passes through the diverter have issues. You know, I can't know if the first pass has ever failed. This is with the full screen version, if that matters. Just thought I would let you know.

[toxie]

okay, thanks, i'll have another look..

[fuzzel]

Please check rev846. I added a switch under Preferences -> Keys... called 'Enable Mouse in Player' which is on per default. If you have problems with the your input adapter disable this switch but you're not able to use the throwing balls option anymore.
Another change is that VP doesn't use DirectInput for mouse states anymore. Instead I use the normal Win32 methods to poll the current mouse states. Please test this if it works with touch devices.

[Mitchell]

Can someone send me betas in my Dropbox please. It in my email account. Least in the PM or email. Cupid used send me VP betas. I don't even know what happen to this person.

[toxie]

Last time i've heard from him he was busy with real life..

Apart from that koadic now provides beta builds, just look into his signature, there's the link..

Another change is that VP doesn't use DirectInput for mouse states anymore. Instead I use the normal Win32 methods to poll the current mouse states. Please test this if it works with touch devices.

 

very cool, looking forward to those touch screen test results..

[bosvrucht]

I will try 846 as soon as it is compiled, in the meantime I tried gestureworks.  apparently this only works for dx9c+ applications.......... input does kinda work, but the overlay does not.  maybe due to the absence of an overlay,  performance impact was negligible. Much better than virtual gamepad! This may turn into a workable solution!

[vulbas]

Please check rev846. I added a switch under Preferences -> Keys... called 'Enable Mouse in Player' which is on per default. If you have problems with the your input adapter disable this switch but you're not able to use the throwing balls option anymore.
Another change is that VP doesn't use DirectInput for mouse states anymore. Instead I use the normal Win32 methods to poll the current mouse states. Please test this if it works with touch devices.

hello,

 

 

it does not work: (
with or without, enable mouse in player

[fuzzel]

Hmm sorry but I guess there is a problem with your system. If you uncheck the 'Enable Mouse...' option VP doesn't access the mouse at all like it was before I added the mouse handling.

[vulbas]

I do not understand why the 838 works, and not above.

it's annoying: (

[toxie]

rev 849 (finally) adds the per table adaptive vsync so many asked for a while back..

(-1 copies the global setting, 0 turns it off, 1 automatically detects refreshrate, anything else sets the refreshrate in Hz)

 

 

which reminds me of something: does anybody actually have a 100Hz Monitor (also enabled in the driver/windows settings), cause for this kind of hardware it should be pretty much perfect (as the physics also run maximally with 100).

[jpsalas]

rev 849 (finally) adds the per table adaptive vsync so many asked for a while back..

(-1 copies the global setting, 0 turns it off, 1 automatically detects refreshrate, anything else sets the refreshrate in Hz)

 

 

which reminds me of something: does anybody actually have a 100Hz Monitor (also enabled in the driver/windows settings), cause for this kind of hardware it should be pretty much perfect (as the physics also run maximally with 100).

I have a Benq XL2411T monitor which runs at 100, 120 and 144 Hz and the setting seems to work fine

[jimmyfingers]

rev 849 (finally) adds the per table adaptive vsync so many asked for a while back..

(-1 copies the global setting, 0 turns it off, 1 automatically detects refreshrate, anything else sets the refreshrate in Hz)

 

 

which reminds me of something: does anybody actually have a 100Hz Monitor (also enabled in the driver/windows settings), cause for this kind of hardware it should be pretty much perfect (as the physics also run maximally with 100).

This reminds me Toxie, I tried the latest versions with the Physics Max.Looptime changes you made and use a setting of about 4 with vsync enabled (hoping from my understanding that it would give me 4 times the physics of my 60 or 75 Hz monitor) in the physics "FPS", however, the flipper issues / physics issues still occur.  If you recall, flippers with higher speed were malfunctioning on a lot of hits and would veer off to the sides hard when the FPS on any table got below about 200 or so.  You can test this a bit on any table that uses a higher flipper speed (about .75 to .85) and strength around .2 - .25. 

 

It would be great if indeed vsync could be enabled without this physics bug.  Thanks for trying with the Physics Max.Looptime but the changes alone for that have unfortunately not remedied the odds physics / missed cycles it would seem when vsync is enabled and the FPS locked down to 60 or so - at least as far as the flipper mis-hits are concerned.