Please help me finding what should be listed about them:
http://forums.inside3d.com/viewtopic.php?t=1053 

http://www.disenchant.net/engine.html 

Join the interesting discussion A new standardised protocol?
http://forums.inside3d.com/viewtopic.php?t=1095 

Tyrquake, fuck that, where's a new Tyrmap??!? 

plz 

If anything comes of his idea.

The 2 protocols that would be the best are:

1. DarkPlaces protocol 7, so coop play without lag is possible without an expensive dedicated server. (yeah, I know about ZQuake and FTEQW).

2. aguirRe's default protocol with the near infinite limits support. 

aguirRe's with qrack and joequake eyescandy

:p

and same menus to demos and stuff...

that whould take me out of joequake i think... 

I just stumbled onto a bunch of Linux engines and their sources:
http://icculus.org/~ravage/quake/ 

I always disable all graphic effects. But i can't turn off the green lightning of the scrags. XD
Not too fond of qrack, it think it's not that stable, but the packet overflow seems to be fixed. 

Is the screenshot function broken in tyr-quake 0.60 (sw, on Linux)? The PCX files I get from it look like this in GIMP:
http://s1.image.gd/o/4e/4ec35adfeae686b143bbf3d9facd3f0ce480ceef.png 

I have the same problem, I think it is the bit depth of the X server though (or of the framebuffer, or both). Didn't get it to work yet. Most sw renderers do that.

Tyrann seems to be MIA, so maybe we should ask sezero to fix that. I also have a heap of patches for tyrquake that I don't have anyone to contact about :-/ and a manpage O_o

Even for Joequake I have to start the X server in 8 bit mode to get proper screenies O_o

FTE does working screenies in software, though. Sometimes >:-) 

stable and mature software alright 

ah yeah please, bring it on. No, then again, don't.

Thing is, not many people even cared about Linux Quake in the last 13 years. Maybe 0.1 % did. Similar for software. So we have kind of a, umm, steep hill facing us.

Doing only Windows Quake sure was easier. It's 1999, man!11!1 

also, X11 and the GUIs have been rapidly changing. Unlike Windows.

Of course, that created other problems for Windows. :)

People just can live with no change much better than with change. It's easier.

Finally, someone could report a bug. O_o

:O 

There's always Fitzquake SDL... 

Yeah, thankfully :) 

TyrQuake 0.61 is out: http://disenchant.net/engine.html
Changelog: http://disenchant.net/git/?p=tyrquake;a=log;h=5e5603551ba619ff098977e8bb3abcafb949cf71 

What is the most "acceptable" engine (i.e. least offensive to us funcsters) that supports a model format with 16-bit vertex accuracy - either .md3, or a 16-bit vertex version of good ol' .mdl, or whatever.

Can anyone provide a list of such quake engines? 

i wouldn't mind at all if all engines moved to a 16bit model format. just sayin'... 

Among fitzquake-derived engines, RMQEngine supports IQM format (http://sauerbraten.org/iqm/). DirectQ also seems to support IQM. (I've never actually tried IQM support in these engines, though). 

Although, I can't find anything that mentions iqm support in DirectQ other than a post by mh here saying he doesn't think DirectQ will get iqm support...

http://forums.inside3d.com/viewtopic.php?p=36908 

The RMQ Winter 11 demo is a working example. 

Yeah, I coded up IQM a few times. I don't think it's a viable format for general replacement of MDLs for a few reasons.

Skeletal animation realy needs to run on the GPU otherwise it can get horrendously slow. That means that those working on software engines can't really join the party, whereas those using hardware accelerate may need to bump the entry level to a point beyond which they're comfortable.

Personally I don't think that's a big deal - it's 2014 and everybody has good shader support these days - but for some people retaining the old "Quake will run on anything" philosophy might be important. (There's an irony here in that Quake actually needed quite high-end hardware on it's original release, but that's probably a topic for a separate discussion.)

Also I favour taking a minimally invasive approach towards content replacement formats. Some of the thinking behind BSP2 was that it should be easy to add to any engine and/or toolset, that it should work in both software and hardware, and that it should use the very same map format as before. I think this really helps adoption - if someone can more easily add it to their engine and if it just works without compromise, then they're more likely to add it. On the other hand if it involves importing 1000s of lines of code they may not even understand well, if it doesn't play nice with existing code, and if half of it breaks in software, then it's not going to be as popular.

That's why BSP2 didn't get features like coloured light, 32-bit textures, surface flags, removal of fixed hulls, etc. All of these would have been cool to have, but they would have also been barriers to adoption. (The fact that it went from not even being on the radar to being fully specified and coded over the course of an evening or so also contributed, as well as explaining some weirdness like the fact that I missed out on switching node and leaf bboxes to 32-bit in the first version.)

A replacement format doesn't need to be perfect or have lots of extra features; it just needs to be sufficiently good enough and easy enough to implement so that it can drive adoption.

A 16-bit (or why not just go full 32-bit?) variant of MDL would meet that description. 

I'm sure I read a suggestion once before to bung the 16 bit info at the end of a standard mdl file, so essentially it's all in a single backwards compatible file. Just literally after the standard frame data (which is already at the end of the file) have a second set of vertex coordinates which "refines" the 8 bit data with a second 8 bits of precision:

pos_16_x = orig_x * 256 + refine_x

That kind of thing. I'd be able to create a test mdl or two like this pretty easy with qmdl at the stage it is now.

QME might choke on it though, as once upon a time that's where it stored extra metadata for editing models. On the other hand, the existence of QME created models that are carrying that kind of added payload does suggest most engines let you get away with extra data appended to model files... 

yeah that's totally what I was thinking. Just taking the existing model format and going from 8 to 32bit for storing vertices and skin coords. (like you said, why not!)

It means getting existing tools to work with the new format would be very easy too because it'd just be a matter of changing the header being used to read the files and changing the storage data types to 32 bit.

I think skeletal animation can be really cool, but straight up vertex deformations are no longer possible on the mesh and now need to be driven by bones which increases model and animation complexity by quite a bit.

For example, say you wanted to animate something weird like a tentacle that can stretch. You might go with splines if you were doing a normal .mdl, but the engine would not recognize that kind of skeletal structure, so you'd have to rig some crazy deforming bone hierarchy thing which, while possible, is nuts...

And under normal circumstances, the only real boon to be had by it is so you can get the feet to line up with slopes via IK.
Any mod that's going to do something really wild with the skeleton like having some kind of procedurally generated stuff would be some really heavy duty mod that'd be better off on a crazy modder engine anyway.