Actually, squall, naive person here is you. You sentence "driver level bugs should not be corrected in apps" shows that you know little about how real applications work. Simple example: ATI video cards and ATI OpenGL driver. You probably heard, that ATI OpenGL driver is, err, not-so-good as, say, Nvidia one. And this situation exists for years. May be this is problem not with all ATI cards and not with all driers, but it affects lot of users. We could say "reported to the product support team" and lost half of our users. Instead, we analysed the problem and re-wrote the code that it works for both ATI and NVidia. For some bad cases special workarounds were done, search for "ati_sucks" in the code. It's ugly, but this is how it works in reality. And if it is possible to correct this particular plugin to support more devices, better to do it, if it does not broke anything.
Then, if some apps works for you and does not work for others, it's not necessary bug in other device driver - probably your device drivers just have some hacks to avoid some common problems in badly written application. I saw such stuff. Other drivers don't have such hacks and can't avoid the problem.
--------------------
Sorry for terrible English, my native language is C++
Last edited by Gonetz : February 15th, 2010 at 05:09.
Actually, squall, naive person here is you. You sentence "driver level bugs should not be corrected in apps" shows that you know little about how real applications work. Simple example: ATI video cards and ATI OpenGL driver. You probably heard, that ATI OpenGL driver is, err, not-so-good as, say, Nvidia one. And this situation exists for years. May be this is problem not with all ATI cards and not with all driers, but it affects lot of users. We could say "reported to the product support team" and lost half of our users. Instead, we analysed the problem and re-wrote the code that it works for both ATI and NVidia. For some bad cases special workarounds were done, search for "ati_sucks" in the code. It's ugly, but this is how it works in reality. And if it is possible to correct this particular plugin to support more devices, better to do it, if it does not broke anything.
Then, if some apps works for you and does not work for others, it's not necessary bug in other device driver - probably your device drivers just have some hacks to avoid some common problems in badly written application. I saw such stuff. Other drivers don't have such hacks and can't avoid the problem.
Sorry but no, now go back to glide64 and stop messing with an api you have no idea about. OpenGL is not DirectInput, either the driver supports the feature or it doesn't. Hacking into a functional implementation only adds room for crashes. There is absolutely no issue with the Directinput code used in this plugin and its not up to the app to fix issues that the people who made the drivers for your device were to lazy to address. The fact that you only caused more issues in the Zelda game pretty much makes it a fact that there are underlying issues with your device driver (or device itself, as gamecube adapters are notorious for low quality and degradation) with which adjustments in the app will only cause more problems.
Quote:
I have checked and found that it supports 16 different ForceFeedback Effects and "Ramp Force" is one of them.
The rumble type being present in the driver does not mean it is supported, XBCD (IE Xbox Controls) display support for the same amount but only Constant, ramp and square actually work as the rest are friction types built into most feedback capable steering wheels.
As a test, get a hold of PCSX and the HariKiri plugin, in this you will be able to test each rumble mode.
The test button in the Device properties does not use the forcefeedback driver instead testing the rumble directly via the main .sys driver.
The fact that you only caused more issues in the Zelda game pretty much makes it a fact that there are underlying issues with your device driver (or device itself, as gamecube adapters are notorious for low quality and degradation) with which adjustments in the app will only cause more problems.
Which "more issues" you are talking about? The issue I described in my first post presents in the original code.
Quote:
Originally Posted by squall_leonhart
There is absolutely no issue with the Directinput code used in this plugin.
How can you be sure? Are you developer of this plugin? Do you understand, how its code works?
--------------------
Sorry for terrible English, my native language is C++
As a test, get a hold of PCSX and the HariKiri plugin, in this you will be able to test each rumble mode.
Tested and it doesn't work for Ramp Force.
Constant Force (working)
Square Wave (working)
Sine Wave (working)
Triangle Wave (working)
SawtoothUp Wave (working)
Sawtooth Down Wave (working)
How about you stop with that attitude and eventually check if Gonetz' changes actually broke anything.
It's not like hardware and hardware drivers do not have bugs. There are lots of end users that ended up with buggy, unsupported, legacy hardware and/or drivers for that hardware. Those people were not inside the hardware or something when they bought it to know how broken it is.
Support for this kind of broken stuff by active and/or open source applications is not required, but it is something nice to have. Even if the changes break stuff there is always the choice of using another version of the application, or better, having the developer(s) adding an option to either use the approach that works for most people, as well as the approach that works for buggy/problematic stuff.
--------------------
I'm not insane. YOU are insane... You are all insane!
I have fixed the last issue with NRage and my controller: rumble effect does not stop in some cases. It was with Zelda OOT, Paper Mario and other games.
That can happen when rumble effect stopped right after the start. I did not find in DirectX docs that this situation is illegal, so the issue was not caused by a bug in NRage, rather something is wrong with my hardware/driver, which sometimes ignores Stop command. Workaround for this issue is simple and rather harmless: I added a tiny pause before effect Stop.
Also, I got an advice from KoolSmoky: "the O2 or Ox compiler option should NOT be used to prevent ZeroMemory() from being ignored. If you need to use the O2 or Ox option, ZeroMemory() need to be replaced with SecureZeroMemory()". I followed this advice, since release version is build with O2. Nothing changed, but it's good to know that the code is more secure now
Download link is in the first post.
--------------------
Sorry for terrible English, my native language is C++
I have tried with SecureZeroMemory for the Input plugin but it seems to cause intermittent hang/freeze to Perfect Dark watching the intro movie or gameplay when moving the gamepad stick. Once I revert back to ZeroMemory, everything works fine again.
Tried your build and has been playing Aidyn with it. So far, it hang once when reading from Controller to display save files from Mempak(no such problem previously). It hangs another time during gameplay when browsing book by pressing A button(no such problem previously).
It may just bad luck but I have reverted back to (nRage + Xinput) plugin which works best for me so far. Of course, I included your fix for game crash if unplug(all other fixes don't seem to happen to me so far).
Linear Mode
