News | Forum | People | FAQ | Links | Search | Register | Log in
NetQuake.io Project Expanding WebQuake
Hello, my first post here, hope. I normally used to post on quakeone.com, but I think here is a better place for this kind of post?

A few users ago, a developer did a line by line conversion of the Quake source code to javascript. I've been intrigued ever since, this port allowed for browser based play like QuakeLive, and also allowed native clients to connect.

The original developer seems content with leaving the original source close to original, so I've forked it and have been quietly toying with it off and on the last few years. The last few months I've been really focused on making something that can be consumed by anyone, and that's the state of today.

Why? When I think of trying to get a friend to run quake, I think of having them install quake, maybe install a quake loader, getting a decent key map, maybe adding command line parameters to get the engine working correctly. WebQuake greatly simplifies all this by allowing me to send a simple link to someone and they can be instantly in-game running a demo, custom map, or multiplayer game. Did I mention platform agnostic? It even runs on mobile!

The downsides to WebQuake -
- Slower than native (this is running webgl, but everything filters through the browser's API)
- Browser may limit key configurations - you there's certain key commands that you can't override in a browser like alt+w
- Require an internet connection to run (can be run offline, might have some options here)

What I've added:
Async/IO - the original source used deprecated blocking IO which isn't compatible with other technologies such as IndexedDB
IndexedDB - Local storage to support adding client pak files. This allows the server to not make pak1.pak public, and allows the user to supply it from their local filesystem, "proving" they bought the game.
ES6 modules - allows the game files to be packaged up in modules

What NetQuake.io offers:
Frontend hosting webquake assets with pak0.pak so you can play shareware out of the box
Master server keeping track of server instances
A couple test instances running on my home server
A CTF server running in AWS Ohio

What I want to do:
- Demo Database - Ability to host/play demos
- Custom map lookup (based on quaddicted's database)
- Add more proquake features to the engine
- Make netquake.io "nicer" - it's currently just a prototype
- Move everything to AWS
- Support local mods

Anyway, that's all. I don't know how useful this might be, so putting out there to gauge interest. Would love to keep a project log here maybe?
First | Previous | Next | Last
Agree This Is Way Cool 
Please keep us up to date. 
 
Hmm yeah a demo browser/viewer could be cool, especially in conjunction with the ability to load custom maps.

I've seen this sort of thing before but it's still pretty trippy to watch the opening demo roll along in a browser window. My only request at the moment is to allow us to set the gl_texturemode. :-)

(FYI there's a few typos or missing spaces/words on the main page: "Tanks", "accessbile", "intomodern", "which I've wanted to ever") 
 
Oh heck you do have a config file in there for modifying. Never mind about my request. :-) 
 
also, if you use opengl, there are a lot of rendering glitches specific to GLQuake and that were fixed in Fitzquake that would be nice to see in here. 
 
Glad to hear there's interest.

The source and CI/CD is all hosted here:
https://gitlab.com/joe.lukacovic/netquake.io

Spirit pointed me to FTEQuake's webassembly port using emscripten so I'm going to look into using that instead of trying to re-invent the wheel in javascript. I can keep both engines open as an option too... But FTEQuake is pretty sweet, and around 8x faster. My main concern is integration with the web frontend - it'll have to be able to load pak files from IndexedDB, command line parms from the query string, and maybe config files from local storage.

I can make demos a #1 priority. Playing them is no problem, the question I would have is how to source them. I can provide an area for user uploads and maybe source from existing databases, provided I get permission. Would be nice to have video like progress bars too, but that's some engine work. 
 
I'll definitely check this out later, but probably won't understand any WebGL or WebAssembly parts. 
 
Thank you @Johnny Law, fixed the spelling :) 
Progress. 
I've made a few small updates such as fixing NAT and allowing native quake clients to connect to webquake servers, even running in AWS containers. To test this, I have the CTF server running in an Ohio datacenter in a docker container. You can connect to this server seemlessly just by using a URL link (assuming you have added a pak1.pak file in www.netquake.io):

http://www.netquake.io/quake?-connect=ws%3A%2F%2Fctf.netquake.io&-game=ctf

This server can also accept connections from native netquake clients that support the proquake nat fixes (I think most modern clients do now)

I've also spent some time trying to doll up quakeone.com, but that's another subject..

Anyway, next I'm working with Spirit to allow loading maps directly from Quaddicted without any setup (other than registered pak1.pak..). This will work like the QuakeInjector app, but will be totally web based.

This work is being done here:
https://gitlab.com/joe.lukacovic/quaddicted-maps-server

I attempted to compile emscripten for quake, but had difficulty keeping the compiler from eating up all my memory/swap before crashing.

I had another idea of using FTE for the AWS servers and adding the webquake protocol, but that's a lot of work... 
Efess 
This is great news. I sent you an email but thought I'd say congratulations here. The Quaddicted development is especially amazing news. I'm wondering if the system only needs your id1.pak location once?

Also a request for you: could you do another post re: QuakeOne I thought - and many others do as well - that the site was basically dead. Would love more details if indeed the site is not being actively maintained again. 
 
Impressive news. Now that there are free replacement assets for most of the registered version data, it should be possible to do stuff like playing usermade gameplay demos directly from the browser. 
 
@mankrip, this would be great, I wonder if the license would require you to replace all shareware assets as well since:

"User-developed/user-modified maps & utilities can only work with the registered version. (Just to be crystal clear on this point: user-developed/user-modified maps & utilities cannot work with the shareware version of Quake.)"

I take "shareware" version to mean the pak0 assets? I'd assume once you have *all* non-copyright assets, you can do whatever you want with the engine. 
 
I take "shareware" version to mean the pak0 assets?
Not exactly. Shareware licenses usually requires you to redistribute things as originally packaged, which means that it also includes the original engine. But in practice, id doesn't enforce that, which is why some mobile ports automatically downloads the pak0.pak file alone.

Which means that the pak0.pak is part of the shareware distribution, but isn't the shareware distribution as a whole. Anyway, fair use policies probably covers this case.

I'd assume once you have *all* non-copyright assets, you can do whatever you want with the engine.

Yes. 
I Wonder... 
... how hard would it be to write id about their stance related to the Shareware episode. I mean, whatever their answer is, we should be able to publish it and have it handy as a definitive reference for each and every millionth time somebody asks for it 😂 
 
Id as a company will never issue such a statement in the open. But in the past they privately authorized everyone who reached out to them.

In 2000, DCEmulation released Titanium Studios' QuakeDC with the full game. Id Software contacted them requesting that the PAK1.PAK file was removed from it, and saying that distributing that port with the shareware pak0.pak file was fine. 
 
I've pushed the first working version of quaddicted maps. You can select a map from the Singleplayer page and play it without any additional configuration.

I created a maps service which scrapes the frontend and also uses the quake injector XML file for the map listing. This service also serves as a caching/proxy service for quaddicted map downloads. It's currently running in AWS.

The source for this service is here:
https://gitlab.com/joe.lukacovic/quaddicted-maps-server

I was pretty impressed at being able to download and unzip a zip file in the browser. It performs pretty well, although some maps will not work correctly and will throw engine errors due to requiring custom engine modifications. Also, some maps have dependencies such as quoth or Arcane Dimensions which isn't supported yet as well.

Next on the list is to allow the user to view their downloaded maps/assets and remove them, or add their own from their hard drive. Also need to update the webquake engine to support modern features such as BSP2. 
 
Small update, added rating starts to maps listing, fancy download progress bar, and ability to view/remove downloaded maps in setup.

Next I plan on tackling some engine issues with newer maps. MH posted a guide to adding BSP2 support to engines, so I'll take a look at that, and see if I can figure out other issues. 
This Is So Aweome 
congrats again! Plase let us know if we can contribute to the cost of AWS. I'd be happy to! 
 
Got a chance to try this today. Something to keep in mind is that the WebQuake engine cannot handle maps that require expanded limits. So keep that in mind when trying Quaddicted loading. I tried a 1997 map and it seemed to work well. 
 
@dumptruck_ds, yup, that's what I'm currently working on.

I was able to implement the enhanced protocol initially used in fitzquake - protocol 666. This allows sending larger data values used by modern maps.

When it comes to limits such as models, entities, etc - the javascript port uses dynamic array sizes to store all this information, so theoretically there should be no changes to the engine to allow parsing the larger maps. There is a 600 entity limit hardcoded, but I upped that significantly without issue.

After implementing the protocol and upping the entity limit, I've hit a limit with lightmaps. This engine parses lightmaps packes them into a single large texture to increase performance. This texture isn't big enough for some of the larger maps, and this causes the "Alloc block full" message. I've spent some time naively trying to increase this limit, but failed since it seems like there needs to be alterations in the way the coordinates map to the textures. This will take time understanding how WebGL works and how the texture packing algorithm works to correct this.

Ignoring the above issue, I've run into significant issues with the renderer not rendering certain entities and not rendering whole rooms. I'm afraid debugging this will force me to get my hands dirty with the guts of the engine, which means I'll have to acquire a deeper understanding of WebGL. which I'll have to do if I want to modify the lightmap texture anyway. 
Anti-spam Re-bump. 
 
 
Just a progress update, nothing big released yet. Still churning along.

I've spent the last month getting my hands dirty in engine code and world rendering guts. I've got a pretty good grasp of how WebGL works (and OpenGL too) and I'm pretty confident in making changes to the engine.

I've been sandboxing this work here: https://gitlab.com/joe.lukacovic/bsp-viewer

I'm using the QuakeSpasm engine as a reference (and in some cases, outright sharing code) since this engine seems to have decent support for modern maps.

I'm in the process of replacing the world/brush rendering code in the original WebQuake with the rendering code from QuakeSpasm and already see performance improvements, as well as the ability to use x number of lightmaps instead of one single large lightmap.

Also, fog was a fairly easy thing to add.

I've also added BSP2 support, which I've merged into Master and is live on netquake.io (but a lot of maps will still hit the current lightmap limit)

Next will be adding modern features as I find the lack of support in maps.. Things like alpha entities and ladders/fences come to mind. Any big things I need to keep in mind? 
Thanks 
I was justing thinking about this yesterday - glad you are still cooking along. 
 
I've seen some edgy stuff in DarkPlaces like bump mapping, stain decals where particles hit walls and full dynamic lighting, but I personally consider those to be more on the fluff side of things than anything imperative. 
 
I've replaced the world/brush rendering code and all lightmap rendering with code from quakespasm. This means most modern maps should load and generally work. Still have a few rendering bugs to work out, but it works pretty well.

Support also added for Fog, Fences, transparent entities, transparent water/lava/slime/teleporters.

I've also moved everything to AWS (Amazon Web Services) and off my home machine, so that should speed up downloads and also the multiplayer instances.

Next is fixing the few rendering bugs I introduced, and support for modern skyboxes 
@efess 
This is all great news. Thanks for all your hard work on this. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.