- Joined
- Mar 8, 2006
- Posts
- 4,733
Last edited:
Thanks for posting that up Mike, and please correct me if I am wrong...
Lemony Vengeance,
With some tinkering with the source on your own, you could use all of the outputs of one of the joysticks and map them to the pins as you desired, everything is controlled in software for which button maps to which GPIO pin. When we started we agreed that the goal was to make it as plug and play as possible for the masses; once it was out the technophiles/experimenters could tweak it or change it and see what else they could do with it. Granted, changes to the code in this manner wouldn't be supported and Mike and I don't plan on providing tutorials on how to change the software to do this.
Jasen
How will the ground line be connected to the edge, or through the DB15 for each player? I personally don't anticipate modding the OS, unless the serial inputs are needed to upgrade the OS.
Gotcha. I know what it's like with the whole non support beyond stock thing. I think I'm going to take mike's offer of a bare board and build one out
What makes this different/better than undamned's board?
I can agree with this summary, save the free part. The information is free (which is awesome) but the hardware/setup cost will be a wash (comparing to two UD-USB decoders @ $35 ea.) after the cost of the Pi, add-on board, memory card, and time getting that whole setup programmed and running proper.Differences:
- Two Controller support
- This hardware hat allows inputs as well opening the aperture for other projects that require inputs into the Pi
- it's all provided free. You can make your own using all of the files provided and contribute to the project with tweaks to code (which we will be providing) to suit your needs. I want to look at the best way to allow people to do this via the freecade site.
Is it better?
- I think it's an alternative. Not better, nor worse. It's using an amazingly fast linux image and a super cheap platform to do something cool.
- I have on if UDs micro controllers and it's a good piece of gear. He did great work with it.
What controllers are supported, and is there lag?
In the first release, RC12, Wired XBOX 360 and Wired PS3 Controllers are working with no lag.
How was lag tested?
I can't notice any.
I can agree with this summary, save the free part. The information is free (which is awesome) but the hardware/setup cost will be a wash (comparing to two UD-USB decoders @ $35 ea.)
Please, for the love of science, do not claim zero lag based on the fact that you personally can't notice any. At best you could change your description to "no perceivable lag"
Also, the thinking that just being under 16 ms is good enough only works on paper.
You'd be shocked at some of the numbers (I have a Madcatz X360 stick with upwards of 14ms of lag).
Thanks, I love both science and English. Regarding my statement on lag, there's really no difference between saying "I can't notice any" and "no perceivable lag".
The customer doesn't care what you perceive. They're the ones using it.
Your product page actually says "no lag".
The original question was not whether there is or isn't lag, but how it was tested.
This is a valid point, precision of language matters. We'll make sure to update it.
The customer doesn't care what you perceive. They're the ones using it.
Interesting project, but without some more concrete evidence towards the no-lag situation, it's not all that appealing from a fighting game perspective, I guess. People are often very poor at perceiving lag, especially if there's confirmation bias
Aren't leg tests a catch-22 anyway since it relies on the user's reaction time? You can't think your way to a faster reaction time.
@Xian: Ip Man disagrees. Isn't lag a measurable thing? There's a difference between a delay in milliseconds on an action and opinion of when you should have reacted.
@Jasen and Mike: I'm not familiar with Pi. I've read that time sensitive projects are usually done with Arduino - since linux inherently adds a layer of processing time on the Pi. What made that different here?
@Xian: Ip Man disagrees. Isn't lag a measurable thing? There's a difference between a delay in milliseconds on an action and opinion of when you should have reacted.
I'm not familiar with the Pi. Could you:
1) Start a timer on the button press and stop the timer when the signal is done running through the Pi?
2) Use an oscilloscope on each end of the Pi to measure at what time the signal enters and exits the Pi? Then compare this with the unit not there at all.
That would get you the numbers. The second part is what is perceivable. You could do something like the "filtered vodka" classification test. You'd have a game people play and there would be a device in between the controls and screen that delays the signal a discreet amount of milliseconds. You'd test perhaps 10 different delay times and ask the gamer to put those 10 plays in order of how much lag they perceived (in the vodka study, this was "put the vodka in order by how many times you think the vodka was filtered - professional tasters actually got this 100% right, while average joes had a breaking point). You could then be able to determine A) a threshold for when people perceive lag or B) a likelihood they will perceive lag depending on a certain amount of actual lag time.
Something I'm currently working on is making me think out loud about this. If anyone is actually interested in this, feel free. The amount of actual measured lag time may be a nail in the coffin, anyway. It may not matter what we perceive if the time is so small.
@Jasen and Mike: I'm not familiar with Pi. I've read that time sensitive projects are usually done with Arduino - since linux inherently adds a layer of processing time on the Pi. What made that different here?
Since I used to study Kaji Kenpo I can tell you that there is a difference between reaction and anticipation. If you keep doing the same test over and over again you will anticipate a response rather than truly reacting to something.
If the lag is below 1 frame, then there really is no difference anyways. Your tv can't possibly refresh faster than that.
But computers process collisions between frames.
Edit: To mean, this isn't a rendering issue, right? Moreover, a collision never had to actually be visible in order for it to register as happened.