Those one-letter filenames look intimidating. :D 

hey i think it's cool.

#1 feature is probably make watching a quake demo as easy as watching a video on youtube.

Playing in the browser is cool too but has some UX issues like you described -- but might still be good as an entry point for first time players, they can sample the game easily and then install a native client once they decide they like it. 

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 :) 

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... 

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. 

... 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. 

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. 

 

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? 

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.