Code question

Talk about anything concerning the source code.
User avatar
Zero
Posts: 68
Joined: Tue Aug 16, 2011 9:10 pm

Re: Code question

Post by Zero »

casio1987 wrote: No, not yet. My time is way too limited for another project right now. I'm currently still on uni, next to working on a major project as hobby, doing some freelance work and rl.
Cool, its been ages since I've played freelancer. :roll:
casio1987 wrote: Hmm, I don't like wrappers for the native code. They're always getting out of date and the effort it takes to keep up to date is not worth it imho. It's better to stick with Matlo's branch, also for performance.
The code that I wrote is not a wrapper.

casio1987 wrote: Besides that, I don't think it's possible to hook kb or mouse globally in mono (clr) or wine (boxed). The only way afaik know (no hard core linux user, so correct me if I'm wrong) is to capture it via x11 events. Otherwise you need to port the whole project to c# and p/invoke calls don't work either in mono (you can try com), so you may need wine. Wine on the other hand afaik does only support max .net framework 2.0 correctly.
Both options are poor options due to performance.
True ... and that's why I've already stated that I'm not targeting anything else but windows at least not with this C# project.
casio1987 wrote: So if you are asking for participation for Windows development only usinig a cli language, my answer is no, sorry. I tend to develop businss apps in c# nowadays (rad), but it's not smart to develop this solution in it, cause it's all about performance and you can't get it with jit, because of the natural overhead.
Partially true. Performance impact is not related to JIT, if anything a JIT compiler is a bonus to performance, due to the fact that when first executed it optimizes the code for particularities of the platform its running on.
The performance impact (in my code) comes because there is no reliable high resolution timer that I can use. I need something that will provide a trigger at exactly 4ms intervals. Currently I'm abusing the stowatch ... in not a very smart way. I will probably change this in the future and that will massively increase the performance of the current code.


Above all else, thees a little device I'm looking forward too (Raspberry Pi) running on a ARM11 chip. It should be out fairly soon and I do hope I manage to secure one ... tho I highly doubt that ...
It would be most interesting to see a version of gimx run on that ...
casio1987
Posts: 8
Joined: Thu Nov 10, 2011 5:53 pm

Re: Code question

Post by casio1987 »

@Zero
I love freelance jobs. Most of them are exciting, although I only pick interesting ones :D Too bad there is a low demand lately.

I see. I thought you wanted to wrap some functionalites, for instance the input. A total port would be nice, if you had the time 8-)

I don't agree with the performance part regarding JIT. You said that it's not related to JIT, which in fact it is.
JIT adds overhead, cause it needs to translate CIL bytecode, whereas C++ is already compiled. This takes extra opcodes to execute, so it will never be faster clock for clock than native C++ code.
The prove is in the pudding. Open up a debugger and look in the ASM and notice the amount of extra opcodes for managed code.

If you do port everything over to managed code, then I would advise you to take a look at the win apis, for SetWindowsHookEx and SendInput, respectively capturing keyboard and mouse input and emulate them (the latter for macros). For bounding the cursor I would use a picturebox and set the Capture property. Don't reset it's state, cause it adds extra overhead. Just use a simple algorithm that adds relatively to the previous capture.
I did this in the past and it worked flawlessly for a macro program I wrote for transport tycoon. Just make sure you add the captured keys and timestamp (or other objects) to a collection. You can limit the mousemovement speed by setting a timer if you really have a slow cpu. I never used the SDL lib, so maybe this is a option too for the advanced stuff. It might capture even lower level than SetWindowsHookEx (direct input), if you really care about minimal performance.

Good luck :)
User avatar
Zero
Posts: 68
Joined: Tue Aug 16, 2011 9:10 pm

Re: Code question

Post by Zero »

casio1987 wrote: I see. I thought you wanted to wrap some functionalites, for instance the input. A total port would be nice, if you had the time 8-)
It already is a "total port" :shock:
Did you even look at the code? I agree its a mess! :oops: with all the testing and unfinished leads :lol: but its way above understandable.
casio1987 wrote: I don't agree with the performance part regarding JIT. You said that it's not related to JIT, which in fact it is.
JIT adds overhead, cause it needs to translate CIL bytecode, whereas C++ is already compiled. This takes extra opcodes to execute, so it will never be faster clock for clock than native C++ code.
The prove is in the pudding. Open up a debugger and look in the ASM and notice the amount of extra opcodes for managed code.
True there is extra op-code being generated but most times that code will run faster (when your dealing with more complex application of course) because usually C++ code is not optimized for the wide array of hardware on the market.
As for "JIT adds overhead, cause it needs to translate CIL bytecode, whereas C++ is already compiled." this happens only once as that block of code is executed. After that the native machine code will be reused because its stored in memory. That's how JIT works in a nutshell. The only performance impact you get with JIT is application loading times and I don't care about them in this context.
Out of context buy you might wanna know this, there are ways to "fix the loading time" too by sacrificing the optimization that JIT compiling offers. Its called pre-compiled code or ... pre-jited. There is a tool from Microsoft called ngen that dose that for you but I've never bothered with it.
casio1987 wrote: If you do port everything over to managed code, then I would advise you to take a look at the win apis, for SetWindowsHookEx and SendInput, respectively capturing keyboard and mouse input and emulate them (the latter for macros). For bounding the cursor I would use a picturebox and set the Capture property. Don't reset it's state, cause it adds extra overhead. Just use a simple algorithm that adds relatively to the previous capture.
I don't like this approach and I've also used it reliably in the past. I love it because you can capture and handle that event in your code. However for this particular application I had to go a mile further and get the RAW input data (so I don't have to use "a simple algorithm that adds relatively to the previous capture").
The way I do that is by register to get the raw data from the mouse using "RegisterRawInputDevices" and all I have to do is clip and hide the cursor in the "Capture window". Its far more elegant/reliable and offers other advantages.

I did this in the past and it worked flawlessly for a macro program I wrote for transport tycoon. Just make sure you add the captured keys and timestamp (or other objects) to a collection. You can limit the mousemovement speed by setting a timer if you really have a slow cpu. I never used the SDL lib, so maybe this is a option too for the advanced stuff. It might capture even lower level than SetWindowsHookEx (direct input), if you really care about minimal performance.

OpenTDD? that game is awesome!
User avatar
Matlo
Posts: 5768
Joined: Wed Jul 06, 2011 7:01 am
Location: France
Contact:

Re: Code question

Post by Matlo »

Speaking about performance, SmartController actually eats 100% of a cpu core, which would result in a 100% cpu usage with a single core cpu. In comparison, GIMX uses less than 1% of a cpu core.
Zero wrote: It already is a "total port" :shock:
It's not a total port as it doesn't bring all the GIMX functionalities (no config editor, etc...).
Zero wrote: Fell like adding to the project?
If you really want someone to work on the SmartController, you really should document your work and write some wikis!

I still don't understand why you are building your own software instead of improving GIMX itself. Switching to C/C++ isn't a big overhead compared to all the code you'll have to write to get the same quality/functionality level.
GIMX creator
casio1987
Posts: 8
Joined: Thu Nov 10, 2011 5:53 pm

Re: Code question

Post by casio1987 »

@Zero
I downloaded your trunk and I agree with Matlo it's not a total port.
Next to that, BT address change can't be done in MS, as pointed out earlier, unless you write your own driver and the chip has eprom functionality.

Imho, I agree with Matlo that it's better to actually add functionalities into the core, instead of derailing intro seperate solutions.

Well, my performance is really good with SetWindowsHookEx on a centrino 1,5Ghz cpu using less than 1% capturing keyboard and mouse (absolute locs). There is no need to reinvent the wheel to handle the raw input, which I doubt will be any better in performance then the provided win api, as all input gets processed by it anyway, with the exception of directinput (ala dx; read sdl, xna, etc.). And you never get the performance with managed code what SetWindowsHookEx does for you, unless you strip everything off you don't need and write your own lib in c / cpp.

You said it yourself as I said what JIT does. This never can be more efficient than unmanaged c / cpp ever. Next to that, the memory footprints are way larger, for all the mess that using the framework gives you, next to extra instructions. There can't be a debate whether cli code gives you better performance than cpp ever.

The only thing where c# is better than cpp is for rad and simplicity. IMHO for sixemu it's not destined, because sixemu should be about performance from my point of view, which is a keypoint and what makes this project so strong. People can use it on lower end hardware without issues and maybe in the future as a standalone solution on a linux devboard. Just like you don't code firmware with c#, you do it with asm for performance. The processing can then be done on a higher level.

Just for kicks, I coded a simple key- and mouselogger and as I said, it uses less than 1% cpu on a old laptop cpu. The sendinput api also uses less than 1% even for 50 events per second. Using the c# eventhandlers for it and performance is down to over a factor 10...
If your app uses much resources, it's useless, cause the sync to ps3 will be garbaged and then there is no use in using a macrorecorder or -player.

OpenTTD is awesome indeed :) I still play it time to time. It never bores ;)
User avatar
Matlo
Posts: 5768
Joined: Wed Jul 06, 2011 7:01 am
Location: France
Contact:

Re: Code question

Post by Matlo »

casio1987 wrote:@Zero
Well, my performance is really good with SetWindowsHookEx on a centrino 1,5Ghz cpu using less than 1% capturing keyboard and mouse (absolute locs). There is no need to reinvent the wheel to handle the raw input, which I doubt will be any better in performance then the provided win api, as all input gets processed by it anyway, with the exception of directinput (ala dx; read sdl, xna, etc.). And you never get the performance with managed code what SetWindowsHookEx does for you, unless you strip everything off you don't need and write your own lib in c / cpp.
The whole point of using raw input is that it provides unmodified events (no OS acceleration or smoothing). With raw input you also can distinguish devices.
casio1987 wrote: 50 events per second.
The typical use case is 500 events/s (500Hz mouse).
GIMX creator
casio1987
Posts: 8
Joined: Thu Nov 10, 2011 5:53 pm

Re: Code question

Post by casio1987 »

@Matlo
I know. My point of using SetWindowsHookEx over directinput or rawinput is to indicate the performance of the use of it over the eventhandlers in a c# application itself (which he was making a port to) with a quick sample. The 50ms is part of the sample, not representative for real world, as I also could have cranked it up to max out the refreshrate of my keyboard supported in the hid's firmware.

To make use of the extra dpi, you need ofcourse raw input, because of the omitted ballistics.
However, also detecting keyboard layouts and types of events is a lot harder to implement in a efficient way, which I was referring too with reinventing the wheel. I should have pointed out earlier to make use of GetRawInputData instead of SetWindowsHookEx, so that also other devices are supported, which sixemu is also about (multiplexer).

This being said, I'm still wondering though why not continue with the current code, instead of derailing, because an implementation of raw or direct input is a lot of work. If he's using a lib - xna or sdl - especially the latter, I see no point in a port whatsoever.
User avatar
Zero
Posts: 68
Joined: Tue Aug 16, 2011 9:10 pm

Re: Code question

Post by Zero »

@Matlo Regarding the full port your right, it indeed dose not support a lot of GIMX functionality and I've already stated that I wont even bother adding it. The project has no particular aim, I'm just messing around.

Pff configuration editor :) That would be Notepad++ or a small console app that generates the xml struct 8-)
Stuff like macros are out of scope as I prefer to use the hardware in my possession. I'm currently rolling on G series mouse and keyboard and the support is adequate under windows. :mrgreen:

But now back to the topic at hand ...

Speaking about performance, SmartController actually eats 100% of a cpu core, which would result in a 100% cpu usage with a single core cpu. In comparison, GIMX uses less than 1% of a cpu core.

I know its because I'm abusing a timer object called stopwatch to send data to the PS3. The way it works now is by running a endless loop with no sleep and checking the time expired. That basically shoots one thread/core out of the water .... so you'd better not have a single core cpu :>


If you really want someone to work on the SmartController, you really should document your work and write some wikis!


True I probably should ... but I just cant stand writing anything resembling documents :evil:

I still don't understand why you are building your own software instead of improving GIMX itself. Switching to C/C++ isn't a big overhead compared to all the code you'll have to write to get the same quality/functionality level.


Just for the kicks of it ... I just wanted to write some code for myself but ... I'd figure id make it public. I will probably switch to assisting you on GIMX ... I'm hoping to get my hands on a Raspberry Pi in the near future :?

@casio1987
Regarding the total port thingy ... ya true its not suppose to be a total port. Tho you misunderstand because you don't know the purpose of the project, its not suppose to be a GIMX alternative.

Regarding SetWindowsHookEx, like I've stated before and like Matlo's added. Its not required or advised in this particular scenario. It seems that you think the performance hit is related to the input processing but that's not the case. See above.

Regarding the JIT compiler again :| there are advantages and disadvantages ... I was not aiming to run this code on my microwave oven .... memory footprint and loading times don't matter. There probably is a performance hit, there's probably a gain compiling code at run-time on a particular type of hardware in the end its the least of the worries. Especially when there are things like all the marshaling going on and some of the objects are not blittable. Lets not talk about all the abstractions that I should probably have not put in place :cry: ...
Tho you have finally touched upon what truly matters. The main drawback of writing things in C#, particularly for this type of application, is the distance between you and the hardware. To provide all the "comfort" there indeed is a price to pay however that price is well within acceptable boundaries.
casio1987
Posts: 8
Joined: Thu Nov 10, 2011 5:53 pm

Re: Code question

Post by casio1987 »

@Zero
True and that's where c# shines, I agree :)
We can make nice guis for the core functionality written in unmanaged code compiled in dlls, if Matlo wants to go that way.

Did you watch the video where Anders is introducing c# 5.0 and the roslyn project? It's so awesome! You can import c# code anywhere and execute it while your assembly is running. It has c# <-> vb conversion, interactive cli, asynchronous keyword for any method (where we now need to nest threads firing child threads which is on its turn also firing child threads), etc.
C# is going strong! Just imagine you can load scripts anywhere. No need to obfuscate or insert extra bytes (to get a new checksum) when writing obscure apps. All checkings can be done on the host to prevent prompts.


@Matlo
A bit off topic... Did you manage to get the hid descriptor for a real ps3 wired controller?
I just browsed the source and performed a quick analyzing of your code. I see you are using the descriptor for the atmel chipset:

Code: Select all

        .VendorID               = [b]0x03EB[/b],
        .ProductID              = [b]0x2043[/b],
Then I saw the magic packet which should fire up the PS Button on the controller

Code: Select all

static uint8_t PROGMEM magic_init_bytes[] =
{
  0x21, 0x26, 0x01, 0x07, 0x00, 0x00, 0x00, 0x00
};
I did a bit of searching and noticed you used the right descriptor for the bt department.

Code: Select all

        idVendor           [b]0x054c[/b]
        idProduct          [b]0x0268[/b]
So in essence, when connecting via usb, the ps3 sees the controller as an Atmel chip.
A qoute from the LUFA lib creator:
The descriptor is read out by the USB host when the enumeration process begins.
Thus patching the hexcodes with the "official" ones would fix it or does it only rely on the bt hid? If the latter, than "official" controllers like the streetfighter ones "should" work?

Second, I've read that the magic packet works for the PS button, by sending more bytes than actually expected. One have managed to get it working. Google search:
Will this be implemented in the next revision (v0.24)?
User avatar
Zero
Posts: 68
Joined: Tue Aug 16, 2011 9:10 pm

Re: Code question

Post by Zero »

casio1987 wrote:@Zero
True and that's where c# shines, I agree :)
We can make nice guis for the core functionality written in unmanaged code compiled in dlls, if Matlo wants to go that way.

Did you watch the video where Anders is introducing c# 5.0 and the roslyn project? It's so awesome! You can import c# code anywhere and execute it while your assembly is running. It has c# <-> vb conversion, interactive cli, asynchronous keyword for any method (where we now need to nest threads firing child threads which is on its turn also firing child threads), etc.
C# is going strong! Just imagine you can load scripts anywhere. No need to obfuscate or insert extra bytes (to get a new checksum) when writing obscure apps. All checkings can be done on the host to prevent prompts.
At first I was like Image but then I was like Image
Post Reply