..:: PCSX2 Forums ::..

@electrobrains, what i did i thought everything quite well, I modelled DS4Library to be similar in a way to DirectInput API, so functionality is very similar and usage. I designed so we have strict set of rules to talk to the controller. Any other tool can be using it while DS4Tool is running (in shared mode). Of course its not even close in complexity and error proof yet but its a good start. Maybe you should familiarize yourself a bit with DirectInput and how games use it before you draw conclusions. You might also checkout Scarlet.Crush's source as its very well designed.
We are using events because they allow flexibility and allow libraries to be not relying on directly calling each other as much. I am trying to have low coupling and tight cohesion

I have enough to worry about at my actual job, i don't want to deal and spend large periods of time arguing about something like this. I have pretty clear vision for the future (at least 2.0) of this, so either follow my lead, or take your own path.
And if you do and users will like your version better I will gladly wrap up my development and no longer be involved with DS4
Somehow i don't have any issues with HecticSeptic, though we are both more fresh to development and have more modern perspective on it, maybe its somewhat a reason.

See if you took time and came up with alternative architecture and proposed it to us, then we could have a discussion on which one better, or should take best of both. But instead you just keep writing code where its convenient at the moment, and that's is not acceptable.

On an off topic, been playing around with another unlicensed/original controller image (but better) which shows all the controls. Since I did this based only on photos I took myself I can't imagine anyone claiming copyright

Work in progress:



Thoughts anyone?

(03-14-2014, 06:55 AM)HecticSeptic Wrote: [ -> ]On an off topic, been playing around with another unlicensed/original controller image (but better) which shows all the controls. Since I did this based only on photos I took myself I can't imagine anyone claiming copyright

Work in progress:

Thoughts anyone?

Really awesome! Potentially could replace all buttons with place holder or have arrows to the assignment buttons. Kinda like Logitech Gaming Software does.



So when you click on one of the assignment boxes (icons) you will have a list of assignment options like i shown above

I'm completely aware that making certain kinds of design choices appears strange if you have never done driver development before. That doesn't mean it's not the best currently-known way to implement real-time I/O software. This is not like typical application development. It has real-time constraints. Scarlet.Crush can explain it to you if you are unwilling to believe me that this is not the same paradigm you use for software development in most places.

I am not okay with just randomly having several frames worth of latency on input or on output because the Garbage Collector is pausing our operation when we have no business dynamically allocating memory in the fastpath. What about that game player with finely-honed reflexes that can push the button in only 2/60th of a second? If we have processing delay in the wrong places, that entire input can be dropped. I take architecture cleanup very seriously. I can also go an entirely different route with my time and take the Scarlet.Crush tools and add standard Bluetooth adapter HID support to them for DS4, branch it and add keymapping support, motion control support for various games, etc. I will simply dedicate my time where it seems more useful.

(03-14-2014, 07:00 AM)electrobrains Wrote: [ -> ]I'm completely aware that making certain kinds of design choices appears strange if you have never done driver development before. That doesn't mean it's not the best currently-known way to implement real-time I/O software. This is not like typical application development. It has real-time constraints. Scarlet.Crush can explain it to you if you are unwilling to believe me that this is not the same paradigm you use for software development in most places.

And yes i try to take that into consideration, and been adjusting to writing code with less dynamic allocations, atm we have almost none. Here is for your knowledge though, most realtime systems use allocations. iOS touchscreen events work in similar fashion to mine (they do allocate new UITouch objects every time), SlimDX library uses allocation for every state it receives. Are they working bad? Don't think so. I measured performance of DS4 Tool and its running at maximum rate of the controller 1000HZ BT and 250HZ. My approach is almost exactly same as scarlet.crush's when it comes to events and thread.
Furthermore i did performance analysis and the most cpu samples occur in readFile / DeviceIOInput so we have not control over it.

Bad news I'm getting another issue on 1.3 RC3.

If I open the tool without turning on my controller, it crashes after about 10 seconds with a "DS4Tool.exe has stopped working" type error. Is it like this on Windows 8? I cannot believe the difference between 7 and 8 is this great in affecting a 3rd party app.

(03-14-2014, 07:07 AM)InhexSTER Wrote: [ -> ]And yes i try to take that into consideration, and been adjusting to writing code with less dynamic allocations, atm we have almost none. Here is for your knowledge though, most realtime systems use allocations. iOS touchscreen events work in similar fashion to mine (they do allocate new UITouch objects every time), SlimDX library uses allocation for every state it receives. Are they working bad? Don't think so. I measured performance of DS4 Tool and its running at maximum rate of the controller 1000HZ BT and 250HZ. My approach is almost exactly same as scarlet.crush's when it comes to events and thread.
Furthermore i did performance analysis and the most cpu samples occur in readFile / DeviceIOInput so we have not control over it.

There is just no avoiding the periodic GC lockdown, whether for Android Dalvik VM or .NET CLR VM or iOS Boehm GC ObjC bindings. I notice small delays regularly on pretty much any device; I'm one of those people that can see the full 120Hz of newer TV sets and says that it looks eery and wrong because of it.

Here is the proper way to analyze the latency performance: you do a timestamped log of operations over a long period of time. Basic profiling doesn't show it to you. It may not seem like a big deal to you, but it's random latency spikes that a standard XBox 360 controller will never have!

Edit: Here's some info on Microsoft's most-current GC. The key to removing GC slowdown entirely is just pre-allocating as many objects as you will actually need on the fastpath and essentially keeping local object pools. It really is not that much harder than using the new operator each time!
http://blogs.msdn.com/b/dotnet/archive/2...-apps.aspx

(03-14-2014, 07:21 AM)electrobrains Wrote: [ -> ]There is just no avoiding the periodic GC lockdown, whether for Android Dalvik VM or .NET CLR VM or iOS Boehm GC ObjC bindings. I notice small delays regularly on pretty much any device; I'm one of those people that can see the full 120Hz of newer TV sets and says that it looks eery and wrong because of it.

Here is the proper way to analyze the latency performance: you do a timestamped log of operations over a long period of time. Basic profiling doesn't show it to you. It may not seem like a big deal to you, but it's random latency spikes that a standard XBox 360 controller will never have!

Objective C only few years back added ARC (automatic reference counting) for GC. Before it was just like C++ before.

I can guarantee you i've done enough testing to be sure there is no latency, running over USB for long period of time i've seen only 3-4 ms (250Hz constantly )between each read, over BT i've seen spikes occasionally but BT technology is not perfect itself and not as reliable as USB (read about how the communication is handled) and you will understand why iit spikes and why it takes sometimes 1-2 seconds to connect to PC and sometime the it wil take 10-15s or even not connect.
So don't tell me about latency issues caused by tool. CPU usage on another hand is quite low i get 0.1.-0.3%, there might be possibility of lowering it even further but there will be always overhead

Trust me I understand all necessary elements pretty well, i can tell you that you won't achieve same performance ever because we're are using user-mode app, where as DirectInput most likely is kernel based and uses interrups instead of waiting for reports

Also i verified latest ScpServer and it seems running at about the same CPU usage, it might be slightly faster its bypassing HID, talking to driver

Please show me where new operator is being used in a reading report/sending report or mappping?
I know of touch events, but be sure if you comment out handleTouchpad you will not be able to notice performance change.

Anyways it's pointless arguing, I don't really want to go on. So you say i have a tunnel vision on thing, it seems like you have tunnel vision on another thing. So let's agree to disagree. I need to be up in 6 hrs.

Yes, and those "Bluetooth issues" are why simply doing stuff like isDirty is not really okay. Sometimes, that packet will be lost. You can handwave away every problem in the world, but they won't disappear. You keep making these very silly assumptions about me not knowing some detail of hardware or software design. I've been around the block more than once, in C, Java, C++, Ruby and JavaScript. I've done kernel programming with hardware drivers and networking, filesystem, even virtual memory. I've done Swing front-ends and X front-ends, SQL back-ends and the schema design itself. I've traced probes and reverse-engineered. I've designed software workarounds for library bugs when not at liberty to replace the library. I've done full desktop-style web apps with shared business logic on back-end and front-end.

TL;DR, I don't care for the know-it-all attitude you're espousing and I know better than to develop software the way you, with admittedly little experience, seem to think it should be done. Seems like I should go off and develop my own software, then. It's been fun.