5 ms·

Many Quake players play at such a high-level of play, that the limitations of the web would instantly make the game unplayable to them. There's an awesome proje

by sponge 13y ago

Many Quake players play at such a high-level of play, that the limitations of the web would instantly make the game unplayable to them. There's an awesome project at http://www.quakejs.com http://www.quakejs.com that have basically done this with emscripten (I'm friends with inolen, you've probably already talked to him). Problem is, websockets are currently TCP only (TCP is unacceptable for a fast-paced real-time game). I guess there's WebRT but the support for that is not very widespread. Chrome and Firefox render webgl using vsync, which adds an unacceptable amount of mouse latency to mouse input. Chrome apparently won't render at 60hz+ even if your refresh rate is above it. I'm sure there's some additional latency between mouse events and updating the game too. It's a very compelling tech demo, but not something at the level that could be sold as a complete product yet.

azakai 13y ago
WebRTC works well in Firefox and Chrome, and provides UDP networking. See for example https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread - so we should definitely be able to do that in quakejs. Totally agree that TCP is not great for FPS games. About vsync etc., I am not an expert on those. But the game should be able to render at 60fps (equal or better to consoles), see the demo above and also Epic Citadel etc.. Any worse means there is a bug, and we should file an issue and try to get it fixed.
- sponge 13y ago
  Sorry, I meant to say greater than 60hz. QuakeJS certainly hits 60, but 60 is often considered the minimum, especially as 120hz LCDs become more popular. (Most QUAKE LIVE LAN tournaments are played on 120hz LCDs, and there is still a small but loud segment of players that will play on CRTs to get 144hz) Disabling vsync in about:flags definitely works, although it's an ugly thing for end-users to have to do. I've benchmarked 100> FPS by quake3's timedemo command through this method, although I don't recall trying to play the game and determining if the frames are actually being painted at that rate.
  - azakai 13y ago
    Yeah, I guess for that community super-high refresh rates can matter. But I think it's reasonable for those types of users to know how to change an about:config option ;)

by sponge 13y ago

azakai 13y ago

WebRTC works well in Firefox and Chrome, and provides UDP networking. See for example https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread - so we should definitely be able to do that in quakejs. Totally agree that TCP is not great for FPS games. About vsync etc., I am not an expert on those. But the game should be able to render at 60fps (equal or better to consoles), see the demo above and also Epic Citadel etc.. Any worse means there is a bug, and we should file an issue and try to get it fixed.

sponge 13y ago
Sorry, I meant to say greater than 60hz. QuakeJS certainly hits 60, but 60 is often considered the minimum, especially as 120hz LCDs become more popular. (Most QUAKE LIVE LAN tournaments are played on 120hz LCDs, and there is still a small but loud segment of players that will play on CRTs to get 144hz) Disabling vsync in about:flags definitely works, although it's an ugly thing for end-users to have to do. I've benchmarked 100> FPS by quake3's timedemo command through this method, although I don't recall trying to play the game and determining if the frames are actually being painted at that rate.
- azakai 13y ago
  Yeah, I guess for that community super-high refresh rates can matter. But I think it's reasonable for those types of users to know how to change an about:config option ;)