On Thu, 20 Feb 2014, Ashley Gullen wrote:
We're building a browser-based P2P multiplayer engine on top of WebRTC
DataChannels. You can try out our work-in-progress here:
http://www.scirra.com/labs/multiplayer/test1/
The first player in to a room is assigned the host, and all other
We're building a browser-based P2P multiplayer engine on top of WebRTC
DataChannels. You can try out our work-in-progress here:
http://www.scirra.com/labs/multiplayer/test1/
The first player in to a room is assigned the host, and all other
subsequently joining peers connect to the host with
On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote:
We're building a browser-based P2P multiplayer engine on top of WebRTC
DataChannels. You can try out our work-in-progress here:
http://www.scirra.com/labs/multiplayer/test1/
The first player in to a room is assigned the
Isn't setTimeout also clamped to 1s in the background? This alone would add
so much latency as to effectively hang the game anyway.
On 20 February 2014 16:18, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote:
We're building a
On Thu, Feb 20, 2014 at 8:23 AM, Ashley Gullen ash...@scirra.com wrote:
Isn't setTimeout also clamped to 1s in the background? This alone would add
so much latency as to effectively hang the game anyway.
Ah, I wasn't sure if anyone actually did that; I just tested in
Chrome, though, and it
On 2/20/14 11:18 AM, Tab Atkins Jr. wrote:
(If people used rAF for what it was *intended* for, we could probably
have stopped firing it *entirely* when the window isn't visible.
We do. At least Chrome and Firefox do.
Instead, we had to compromise with the 1s refresh rate instead.)
That's
On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote:
The host is effectively acting as the
game server, and this basically hangs the server. If there were 20 peers
connected to the host, the game hangs for all 20 players.
That's a bug in your application design. If one
The host needs to keep simulating the world even when no network events are
occurring. That can't happen if rAF isn't firing and timers only run at 1
Hz.
On 20 February 2014 17:56, James Robinson jam...@google.com wrote:
On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote:
On Thu, Feb 20, 2014 at 10:32 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Feb 20, 2014 at 12:02 PM, Ashley Gullen ash...@scirra.com wrote:
The host needs to keep simulating the world even when no network events
are
occurring. That can't happen if rAF isn't firing and timers only run at
On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier caban...@gmail.com wrote:
This sounds like work that should be done in a worker. Worker timers
aren't throttled when in the background, and this is exactly something
workers are for.
Is WebRTC available in a worker?
I don't know, but if not,
On Feb 20, 2014, at 9:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/20/14 11:18 AM, Tab Atkins Jr. wrote:
(If people used rAF for what it was *intended* for, we could probably
have stopped firing it *entirely* when the window isn't visible.
We do. At least Chrome and Firefox do.
There's a lot of worker features that aren't widely supported yet, like
rendering to canvas with WebGL and 2D, Web Audio support, inputs, various
APIs like speech and fullscreen, so I don't think that's practical right
now. I guess that's not a reason to standardise a new feature, but is there
not
On Thu, Feb 20, 2014 at 03:25:56PM +, Ashley Gullen wrote:
Users regularly switch tabs and probably don't expect that this hangs the
game for everyone. To prevent multiplayer games commonly hanging, perhaps
there could be a new API to request that a page can keep running at full
capacity
On Thu, Feb 20, 2014 at 3:29 PM, Ashley Gullen ash...@scirra.com wrote:
There's a lot of worker features that aren't widely supported yet, like
rendering to canvas with WebGL and 2D, Web Audio support, inputs, various
APIs like speech and fullscreen, so I don't think that's practical right
Since it's a peer-to-peer engine, the user acting as the server is also a
participant in the game. This means the server is also running the full
game experience with rendering and audio. The game logic is tied to rAF,
since we intend to step the world once per screen draw, including for the
On Thu, Feb 20, 2014 at 4:32 PM, Ashley Gullen ash...@scirra.com wrote:
Since it's a peer-to-peer engine, the user acting as the server is also a
participant in the game. This means the server is also running the full
game experience with rendering and audio.
The user is a client, and also a
On Fri, Feb 21, 2014 at 11:32 AM, Ashley Gullen ash...@scirra.com wrote:
One solution is to make web workers able to access many of the same APIs
the UI thread can, especially with WebGL, Web Audio, WebRTC and rAF. Then
it might be practical to move a full game engine in to a worker. If that
17 matches
Mail list logo
