Yesterday evening, I began to work on the core functionalities of the configuration GUI:
read a configuration from a filedone edit a configurationdone save a configuration into a filedone
I hope to have this done later this week.
I decided to postpone the macro edition.
36 Replies to “Now working on the core of the configuration GUI”
Everything in its own time 😉
Keep up the work! Looking forward to see it 🙂
Je tiens Ã donner mes encouragements pour ce projet, moi aussi.
Cependant je tiens Ã ajouter qu'avec le crackage rÃ©cent de la PS3, il y aurait peut-Ãªtre encore plus (ou au moins autant) urgence Ã dÃ©velopper une Ã©mulation Sixaxis via le payload…
Bon courage !
J'ai dÃ©jÃ Ã©voquÃ© cette possibilitÃ© dans un post du 15 septembre.
Pour l'instant je ne me risque pas Ã hacker ma console, et je ne le ferais pas dans l'Ã©tat actuel du hack.
Je prÃ©fÃ¨re continuer l'Ã©mulation externe qui est compatible avec toutes les consoles qu'elles soient hackÃ©es ou non.
I too agree that this project has more value.
Sony will eventually patch the crack or do it so that it will no longer be possible to use.
This method has a long term solution and I like it.
Looking forward to the cross platform project.
Will you code it using Java or will you continue using C?
I will continue using c/c++, since there is no obvious reason to change.
Cool, I might do some objective base coding if I will have some free time.
May I ask where/how did you get the info regarding how the controller communicates with the PS3?
What kind of software do you want to develop?
As explained in the tutorial, the sixaxis emulator I am developing is derived from the work of Jim Paris. Therefore I didn't worked a lot on the sixaxis protocol. I did some work with the sixaxis proxy developed by Mikael Bouillot.
I was looking into processing mouse and keyboard and then sending a signal to the PS3 to "fool" it into thinking its the PS3 controller. Similar to your work.
Until now I've looked into the possibility of building a micro-controller solution but I cant find a good resolve.
I'm trying to find out if I can force a high polling rate. I'm not sure how many inputs the PS3 will take/second. Also the only way this is achievable without buying really expensive electronics is using a PC/MAC. I currently have mouse and keyboard on 1000Hz = 1ms. I'm hoping I can achieve around 250Hz/4ms at least.
I will have a look at the material you've linked, hopefully it will share some light on the workings of the PS3
I've looked around your blog and I see you've managed to talk to the PS3 via Bluetooth. That's quite impressive :D.
How are the inputs? Responsive? I think Bluetooth devices can get just a bit over the PS/2 input, around 100-150Hz.
Also I've noticed you've build a Teensy board that should have around 10~20 MHz process speed. I think that would be the way to go if I wana get high input speeds. How far were you able to push the input speed on the Teensy board?
You should try the sixaxis emulator first. Bluetooth is not that bad.
I think you are wrong, it will be more expensive (money+time) to build something using a Windows or MAC.
The best way to get a low report rate is to use a wired solution. I suggest you to read this post if you want to read some response time measures (a difference of response time gives a controller latency difference).
10ms is nothing compared to the response time of the game (>100ms) plus the response time of a human (>100ms). It's probably not relevant to get better.
I bet a teensy++ can achieve a 1ms report rate, but I don't know if the ps3 will take all reports at this rate.
I planned to design a wired solution for the xbox360, and I probably will design a wired solution for the ps3 with the same hardware.
Ya I've noticed that the teensy++ is surprisingly a lot more powerful, as I stated in the second message I too now think that it would be the best solution. Sadly I'd have to build my own because they don't have any boards for sell until January.
Also regarding your statements of response times, the game should have a very low response almost instantaneous. What creates input lag is the medium(wire,wireless,etc.). Its true that in some games there might be blocks in the game code to process input "slower" tho that should normally not be the case.
The PS3 might not have a high input rate adding to the input lag, in my opinion it might be the main culprit …
Also I totally agree with you that keyboard input is acceptable at 100ms as key-press have that physical human dampening time. But the mouse "movement input" dose not. If you wana know/feel what I'm talking about plug in a gaming/grade mouse and select the pooling rate via its software. Change to 1ms (1000Hz) play with it for a little then go to 10ms (100Hz) and you will feel a major difference. The mouse will feel like it shutters/lags, its best noticeable when doing fast direction change movements. That's why there is this feeling of input lag with consoles.
Anyways I'm really being picky about this as mouse and keyboard on a console is better then without. But I wanna see if I can nail down this issue as it really makes a world of difference when playing fast games like FPS.
It's a common mistake to think the game has a low response time.
I suggest you to have a look at this article and this other one.
wow, nice articles.
I forgot consoles have a "caped" FPS. Yes if you use 2-3 frames to process and execute the input you would get a lag of ~50ms that adding to other interference you could end up around 100ms.
But that's not how input is processed. The input thread is independent, or should be, of other game threads (or should be). So in the time that it takes for the box to process and render other input events could be processed. For key-press this is not a issue but if you have something like mouse/touchpad inputs that can change direction spontaneously the input must be processed at a high rate.
Because ever "1ms" you could change direction slightly and that should register, even if you process once every 16ms(1 frame at 60fps) you might lose 15mm of surface traveled (pretending you do 1mm/1ms :p). Even if the screen render happens after x frames the input is constantly processed to avoid the "lag". At least that's how it should be, that's what I'm trying to find out.
So I think that the display lag talked about in the articles dose not tackle the input issue in great detail just the overall lag issue.
The only way I would imagine testing this is using something like a teensy++ and a really fast mouse keyboard and see how they feel.
I think you misunderstood the explanation.
Figure1 doesn't detail all the stuff performed by the box at the same time: there are different processes running at the same time (multi-core).
The figure only details the actions of the game process, and does not show the actions of the OS process(es).
The OS process is in charge to get and register all events from all input devices. Applications subscribe to these events, and can read all of them on-demand.
"Read inputs" doesn't mean "read inputs status", but "read all queued input events".
I know but the same principle applies to the box, the OS could potently follow similar patterns.
I'm not sure after all that's what I'm trying to find out. Your test show response time of 100ms+ and I wanted to brake it down to what might the culprits be.
Anyways until I get a teensy++ I cant do much. I will have a look at the Bluetooth method you've described.
The teensy board is in stock and might be enough.
don't I need a teensy++ to have enough ports?
I need like … 3 usb ports 2 for keyboard and mouse and one for the PS3
The teensy and teensy++ have a single usb port.
You need extra hardware to get more usb ports.
well yes, I need to get more usb ports and attach them to the board pins.
I'm not really good with microcontrollers tho a couple of years ago I have done some projects involving some.
I only used analog input. I would ove it if you could fill in some blancs for me regarding this. Could I add 2 more USB ports to a regular Teensy board? Do I need additional hardware except the USB ports?
Read the specs of the atmel chips, and you will see that it's not that easy to get more usb ports.
You need something like that to get more usb ports:
no wonder I couldn't find anything on google about teensy and more usb ports.
This complicates stuff a bit. I have to look into it.
Well, going through the homebrew (maybe after your current ambition is satisfied !) would avoid the hassle of having a dongle, linux, maybe some lag… Hacking is always the long term destiny of consoles…
Anyway I'm still interested and I would like to ask :
– Is there a possibility to make your program work through an cable (usb I guess)
– is there a possibility that my integrated bluetooth on a quite old laptop works ?
It's possible to emulate a sixaxis over usb, but a cable isn't enough, it requires some specific hardware (a programmable device with 2 usb ports).
It's possible that your integrated dongle works. If it doesn't allow the bdaddr modification, it's still possible to make it work thanks to a teensy++ (or any other at90usb chip): see this post. Anyway, as said in the tutorial, some cheap bluetooth dongles allow the bdaddr modification.
Well I think I will just wait until your gui is completed and try out your tutorial with my embedded bluetooth.
P.S.: have you had nice results with New Vegas ?
I suggest you to test without waiting the configuration GUI, because it may take some time to get finished.
I haven't bought New Vegas.
100ms is too high. my component over hdmi adds 30ms. i can see and feel the difference in fighting games.
i think you should make an adapter that allows remapping buttons and macros. for the controller, not mouse. that would be awesome. no one has made one yet. except for mayflash macro adapter for the ps2. please make a ps3 one!
I agree that >100ms is high for a game response time. But this isn't the controller latency. The sixaxis emulator only adds about 15ms latency compared to the usb wired sixaxis.
cool. well i hope it work good. i dont know if you are familiar with this software, but it works with blutooth, and the sixaxis works good. i own it.
This stuff probably will be usable if I port the emulator to windows.
But as it's not free of charge, I probably will not test it either support it officially.
There's another sixaxis tool for windows, which is free of charge (but afaik it's closed source).
Here is a interesting read on communication with the blu ray remote control:
Just thought I'd share!
yea i use motioninjoy too. works better with pinnacle gaming software.
i thought you were already doing this for windows? your new gui is for windows, right? please do windows.
@Jacob: thanks for the link. I may work on a bt remote emulator some day, but currently I don't see the end of my current task list…
@Derek: this only is a cross-platform CONFIGURATION gui. The emu process is not ported yet and can't be run in windows for now (except in a VM, but that decreases performances). Making the whole stuff cross-platform is one of my many tasks.
I read Derek writing about some lag but under technical terms I'm not aware of. Simply but, is there a chance to get a nicely playable experience by just following your tutorial ? And by the way, is there any way to test if my embedded bluetooth support the bdaddr under Windows ?
The only way to know if it fits your needs is to try it. I suggest you to use a Ubuntu Live USB Persistent Flash Drive.
Again, there's no suitable windows solution yet.