Old Discussion Thread for all 3 motion controllers

[Gradthrawn]

Not too interesting, I hope. If that guy were a member of B3D I'd slap him with a trolling infraction!

You can't slap the VP of War. You just cant.

 

[Arwin]

Not too interesting, I hope. If that guy were a member of B3D I'd slap him with a trolling infraction! For those who haven't viewed the link, it's a Sony promotional video for Move with their character VP, Kevin Butler, extolling the virtues of Move with digs at the rivals.

It made me think of Reggie ... In terms of marketing, I think commercials like this are good pre-emptive strikes for what you can guarantee will come from the competitors (and in fact already has).

 

[patsu]

You can't slap the VP of War. You just cant.

The best one yet.

[size=-2]My wife will find it very familiar.[/size]

 

[liolio]

DF article about ps move latency is up:
http://www.eurogamer.net/articles/digitalfoundry-vs-playstation-move-article

 

[Arwin]

DF article about ps move latency is up:
http://www.eurogamer.net/articles/digitalfoundry-vs-playstation-move-article

Not the best DF article, but I can understand wanting to get it out asap. (it was up yesterday)
EDIT: there's an update now

It triggered me to think about this myself, and this is what I came up with. Anyone want to help check this/make it more precise? Maybe RL/grandmaster can use it for the follo- up article.

EDIT: when the article specifically says '133ms controller lag', that still refers to the lag in the complete pipeline. It's more interesting to speculate what the move adds, probably.

What we are looking at here is this:

1 The camera sends its picture data to the PS3 over the USB connector
2 The wand sends movement and position data to the PS3 over the BlueTooth wireless signal (based on its magnetometer, gyroscope, accelerometers and whatnot.]

(1) and (2) happen in paralel

3 The video input from the USB camera is streamed to the SPE that analyses the signal for the Move controller's led
4 The results of the analysis is used to enhance the precision of the signal from the Move controller

(4) is extra, and is what Sony is talking about when it says it can typically do this within one frame, I'm fairly sure

5 The video input is streamed on towards a framebuffer on the graphics memory
6 The graphics engine receives the controller input from the SPE and uses it to determine the location of the sword
7 The graphics engine renders the sword

(5) is probably done in paralel to (6) and (7)

(6) is the location where controller smoothing will typically be implemented, potentially adding some lag

8 The sword and video input are combined into a framebuffer
9 The framebuffer is switched to become the active displayed image on the screen

How the lag that is purely added by the Move controller is experienced will eventually depend on the functionality that is used inside the Move controller and the time it takes for the camera to grab an image to the SPE returning positional data from it that can be combined with the Move controller's input (1),(3) en (4)

Additional lag can happen in the smoothing fase (6)

The minimum amount of lag from the Move controller is probably in the 22ms ballpark as suggested by the screenshot posted earlier on in the comments.

How much this differs from, say, getting input from the analog stick of a dualshock3 controller I don't know off the top of my head, but there will be a difference, maybe 16ms or something similar?

Also interesting to note is that the button inputs may not be influenced by the input of the camera. This depends on how the threading and data stream model of the driver works, and that is currently anyone's guess I think.

 

[Lucid_Dreamer]

Grandmaster can still post a correction to the article, like he did to the Saboteur AA article; if he wants to. I'm sure he will, at least, post a clarification at the top of the article. Grandmaster isn't the type to let his readers be confused, when it's easily remedied.

 

[_phil_]

the 1spu treatment of the signals sent by the move is done in about 22 ms for 4 controlers.There shouldn't be much troubles with lag on finished products.

 

[Crossbar]

the 1spu treatment of the signals sent by the move is done in about 22 ms for 4 controlers.There shouldn't be much troubles with lag on finished products.

Interesting.

Playstation Eye delivers either 60 or 120 fps, which results in a max frame delay of 16 or 8 ms, then we have the USB transfer delay which with a worst case assumption has a delay of 16 resp. 8 ms.

So a worst case delay when running the PSEye at 640x480 resolution would be 22 + 16 + 16 = 54 ms. But that is when asuming the camera is max asynch with the app and the USB is saturated, on average the delay would likely be more like 22 + 16/2 (average asynch) + 16 - 4 (USB safety margin) = 42 ms. I think that is still pretty conservative.

 

[Arwin]

Grandmaster can still post a correction to the article, like he did to the Saboteur AA article; if he wants to. I'm sure he will, at least, post a clarification at the top of the article. Grandmaster isn't the type to let his readers be confused, when it's easily remedied.

Correct, he's changed it now.

One interesting aspect here I think is that USB camera-capture-to-framebuffer-display lag may actually be higher than the lag of the Move input method for augmented reality games, so that the drawing of the rendered sword may actually be slowed to match the video-feed.

Also, the movement of the sword here is probably smoothed out to prevent excessive jittering.

 

[patsu]

the 1spu treatment of the signals sent by the move is done in about 22 ms for 4 controlers.There shouldn't be much troubles with lag on finished products.

_phil_, in the average and worst cases, how much of the 1 SPU is used ? Does the Omega tracking run on the same SPU as well or is the head tracking load balanced out to multiple SPUs ?

EDIT: In general, it should be very very quick for an SPU to run through the color data. The problem should be I/O bound right ?

 

[patsu]

http://www.youtube.com/watch?v=w0puP8nrIU8

Surprisingly direct remarks about the competition. This will be interesting.

I just saw this. It's cheeky but won't do a thing to all 3 vendors.

 

[obonicus]

It's strictly for people who at least are aware of the Great Motion War.

 

[scently]

That's some pretty direct references.
A really bold move (no puns intended) from Sony.

 

[Crossbar]

One interesting aspect here I think is that USB camera-capture-to-framebuffer-display lag may actually be higher than the lag of the Move input method for augmented reality games, so that the drawing of the rendered sword may actually be slowed to match the video-feed.

You are assuming the bluetooth communication carrying accelerometer data is faster than the video feed from the PSeye, right? Quite possibly.

 

[Shifty Geezer]

You are assuming the bluetooth communication carrying accelerometer data is faster than the video feed from the PSeye, right? Quite possibly.

I think simply due to data volume. The MEMS data is a few values, whereas the camera data is a video feed that's going to take some ms to stream, irrespective of communication protocols (Blue Tooth vs. USB).

 

[_phil_]

_phil_, in the average and worst cases, how much of the 1 SPU is used ? Does the Omega tracking run on the same SPU as well or is the head tracking load balanced out to multiple SPUs ?

EDIT: In general, it should be very very quick for an SPU to run through the color data. The problem should be I/O bound right ?

IO delay for Move(blutooth) is the same as DS3.

I guess developpers are free to parallelise the treatment if needed.Head tracking and face recognition are independant of move tracking.
Just for move tracking there shouldn't be more than 22ms+ BT transfer in an ideal world.
That would be perfectly under a frame.

 

[patsu]

I got you, but is the head tracking done on the same SPU as the Move tracking stuff. It sounds like those PSEye tasks are run off a different SPU "kernel" or a pool of them. That way you can scale the framework based on needs.

 

[AzBat]

Some pretty interesting comments from Sega's Mike Hayes about both PS Move & MS Natal...

Part 1
http://www.computerandvideogames.com/article.php?id=239411

Part 2
http://www.computerandvideogames.com/article.php?id=239570

BTW, they did say they will have a Natal demo at E3.

Tommy McClain

 

[Silent_Buddha]

DF article about ps move latency is up:
http://www.eurogamer.net/articles/digitalfoundry-vs-playstation-move-article

Very interesting... From Sony's Mikhailov...

"The tracking precision is in the order of millimetres. The tracking distance is about 10 feet from the camera; we have a very wide range," he shares. "The camera's field of view is 75 degrees so you can easily fit one player comfortably and two players as well.

So basically PS3 Move games will be limited to 2 players, so unlikely for 4 player party type games.

This looks like a limitation of having the camera viewing the players rather than Wii with the infrared camera/sensor being located in the controller. So no matter how many people, the IR sensors in the Wii controller will be able to see the IR emitters near the TV. While with PS3 Move (and Natal also) you're much more limited in where people have to stand in order to be visible to the camera.

So that would go a ways to explaining why MS might be limiting Natal to 2 players rather than the previous 4 mentioned at the last E3.

That being the case, it doesn't look like either Sony or MS will be challening Wii in the 4 player party game market segment.

Regards,
SB

 

[patsu]

Move can support 4 players using the motion controller, and 2 players using the motion controller + subcontroller.

Games like Buzz don't require the players to move around. So 4 players -- if you are going to pay for 4 separate motion controllers -- should be possible.

For motion games, I suspect most living rooms can only accommodate 2 people swinging around (if they don't want to get punched or kicked).