Spring RTS Engine

Your average LCD monitor already has 10s of milliseconds of lag. A few more shouldn't be noticeable really. IF you really could get it down to some milliseconds, which doesn't seem too plausible for now.

Teutooni wrote:not with this set of physical laws.

and when we get quantum computing the whole point will be moot anyways

Teutooni wrote:

Licho wrote:What a BS .. it can't work even from quality perspective..

Atm I play games at 1920x1200 with 60fps easilly.

To achieve that without loss of quality, you need to transfer up to

1920x1200x4x60 bytes each second. In other words you need:

4216 MBit connection - thats well above total connectivity of many countries.

+1

The whole concept is sketchy. At the speed of light, the signal can travel 300km in a millisecond, and that's a direct beam of light. There will be a lot more lag due to compression, routing, packet filtering, packets getting lost, etc. Even a few milliseconds is noticeable in input lag. I just don't see this ever working, not with this set of physical laws.

Depends on the gametype. FPS games are simply not going to happen. Strategy/RTS are doable, as are Diablo and other roguelikes.

Remember they can do the mouse-pointer client-side.

Ok, so if you can tolerate either tiny resolutions or a lot of artifacts and variable input lag based on network traffic/time of day, OnLive will be awesome! ~~

Seriously, what's the point of having awesome graphic processors on a server somewhere if the graphics they produce is compressed in a lossy format and the result is ugly tiny resolution and/or visible compression artefacts? Modern smartphones are already capable of ogl rendering on their own... which is a moot point because wifi will have utter garbage response times anyway...