12 ms·

The QuakeLive team currently only has a single developer and it seems that they would have nowhere near the developer bandwidth to do a WebGL port (as great as

by prg318 13y ago

The QuakeLive team currently only has a single developer and it seems that they would have nowhere near the developer bandwidth to do a WebGL port (as great as a WebGL QuakeLive would be!)

azakai 13y ago
The Unreal Engine 3 was ported in one week by a few developers, so porting the much smaller Quake Live codebase should be reasonable. ( http://www.unrealengine.com/en/news/epic_games_releases_epic_citadel_on_the_web/ http://www.unrealengine.com/en/news/epic_games_releases_epic... ) As a long-time fan of the Doom&Quake games I would personally want to volunteer to help out on the JS porting aspect (I work on Emscripten, the compiler used in the Unreal Engine port and others). However, how feasible this would be would depend on how portable the codebase is and so forth, which is not publicly known.
- oomkiller 13y ago
  QuakeLive is basically Quake 3 right? They GPLed the source a while a go.
  - azakai 13y ago
    It is based on Quake 3, but it is unclear how much they modified it for Quake Live, that part is not public. The UI for example is mostly new, I am not sure about rendering, asset management etc.
- vinkelhake 13y ago
  The Unreal demo has some annoying micro stuttering that a Quake Live player would never put up with. Besides rendering there's also sound, input and networking to sort out. It's not insurmountable, but there's a big difference between a tech demo and a final product.
  - azakai 13y ago
    Not sure which stutter you refer to. Could be a bug in a particular browser. Sound and networking are certainly possible. Sound will use HTML audio or Web Audio, if the C codebases uses SDL audio (there is audio in the citadel demo). And networking is possible with not much effort, see for example https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread But I fully agree that a week for a tech demo is a small part of the work that a full product needs. Still, that it was just a week seems to say that a full product is feasible, probably months of work. Perhaps id doesn't want to spend that amount of time, and that's understandable if they have other priorities.
    - inolen 13y ago
      At this point (as you know), quakejs is a fairly ironed out port of ioquake3. I've just never released it due to assets. I wanted to finish cross-compiling quake3 QVM-based mods to JS in order to enable playing some of the popular mods (with their own assets), but that just never happened. I really wish some permission could be granted to use the original quake3 demo assets - it'd be great to have such a demanding gaming project for browsers to work on improving.
      - azakai 13y ago
        Yeah, definitely aware :) I didn't mention quakejs because I wasn't sure you wanted attention on it yet. If assets are the last thing missing for you to launch it, what would it take to resolve that (not using the official assets, but something else)? Perhaps I can help or we can find others that can.
      - thrillgore 13y ago
        Have you considered having contributors use the Xonotic assets? Would that even be possible?
- 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

by prg318 13y ago

The QuakeLive team currently only has a single developer and it seems that they would have nowhere near the developer bandwidth to do a WebGL port (as great as a WebGL QuakeLive would be!)

azakai 13y ago

The Unreal Engine 3 was ported in one week by a few developers, so porting the much smaller Quake Live codebase should be reasonable. ( http://www.unrealengine.com/en/news/epic_games_releases_epic_citadel_on_the_web/ http://www.unrealengine.com/en/news/epic_games_releases_epic... ) As a long-time fan of the Doom&Quake games I would personally want to volunteer to help out on the JS porting aspect (I work on Emscripten, the compiler used in the Unreal Engine port and others). However, how feasible this would be would depend on how portable the codebase is and so forth, which is not publicly known.

oomkiller 13y ago
QuakeLive is basically Quake 3 right? They GPLed the source a while a go.
- azakai 13y ago
  It is based on Quake 3, but it is unclear how much they modified it for Quake Live, that part is not public. The UI for example is mostly new, I am not sure about rendering, asset management etc.
vinkelhake 13y ago
The Unreal demo has some annoying micro stuttering that a Quake Live player would never put up with. Besides rendering there's also sound, input and networking to sort out. It's not insurmountable, but there's a big difference between a tech demo and a final product.
- azakai 13y ago
  Not sure which stutter you refer to. Could be a bug in a particular browser. Sound and networking are certainly possible. Sound will use HTML audio or Web Audio, if the C codebases uses SDL audio (there is audio in the citadel demo). And networking is possible with not much effort, see for example https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread But I fully agree that a week for a tech demo is a small part of the work that a full product needs. Still, that it was just a week seems to say that a full product is feasible, probably months of work. Perhaps id doesn't want to spend that amount of time, and that's understandable if they have other priorities.
  - inolen 13y ago
    At this point (as you know), quakejs is a fairly ironed out port of ioquake3. I've just never released it due to assets. I wanted to finish cross-compiling quake3 QVM-based mods to JS in order to enable playing some of the popular mods (with their own assets), but that just never happened. I really wish some permission could be granted to use the original quake3 demo assets - it'd be great to have such a demanding gaming project for browsers to work on improving.
    - azakai 13y ago
      Yeah, definitely aware :) I didn't mention quakejs because I wasn't sure you wanted attention on it yet. If assets are the last thing missing for you to launch it, what would it take to resolve that (not using the official assets, but something else)? Perhaps I can help or we can find others that can.
    - thrillgore 13y ago
      Have you considered having contributors use the Xonotic assets? Would that even be possible?
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