So:
- Every browser now supports WebGL
- This would allow their customers to play Quake without plugins OR downloads (eg, this demo http://media.tojicode.com/q3bsp/)
and instead they ditch platforms and require an installer?
- Every browser now supports WebGL
- This would allow their customers to play Quake without plugins OR downloads (eg, this demo http://media.tojicode.com/q3bsp/)
and instead they ditch platforms and require an installer?
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.
The UI for example is mostly new, I am not sure about rendering, asset management etc.
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
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.
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.
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.
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.
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.
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.
With 2006's 3D performance and access to all source code.
Code access is to a minified client-only source * for an Open Source engine, gamers could possibly write their own backend matchmaking service and host and maintain it themselves, but I suspect this isn't worth most people's time.
(that said, anti-aimbot type stuff might be a real problem)
* As someone else pointed out, ASM.JS is more than just minified, it's unreadable. Eg, Epic have UE3 ASM.JS hosted online.
Doesn't have to be.
Only needs to be worth one person's time to render the effort commercially dubious.
WebGL runs at basically full speed on the GPU. And JS can run at about half the speed of native code, when compiling a C++ codebase like we are talking about here.
So this would be far faster than typical 2006 perf.
> and access to all source code.
Look at optimized+minified compilation output in JS, it is just as unreadable as a native binary.
Second, there's a lot of little fiddly bit-twiddling for certain parts of it, like the PVS sets and whatnot. I would be unsurprised if JS doesn't deal with that well.
Third, the level of play is such that stuttering, pauses, or hiccups, even if only on the order of tens or hundreds of milliseconds, can be unacceptable.
Of course stuttering is unacceptable, as you say. But it should not happen. If you see it in a browser, please file a bug.
Access to emscripten output is about as useful as access to disassembled native code.
There was always something special about the Quake 3 (and 2) engines - the fluidity, freedom and speed they provided in the games were unmatched. I don't know if it was the engine itself or the developers that flocked to these engines but the feeling of the shooting and movement on the games developed on the Unreal base is much more clumsy. Don't know exactly why.
There's a certain elegance and efficiency of movement the old arena shooters give you that's missing in many of the CoD clones these days--Painkiller has come closest to matching it, along with the Serious Sam tomfoolery.
Goddamn am I old or what?
Something like this for quake live would be cool.