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. 

that is very clever, and I definitely see how it can be a good thing in that you only have one model that will automatically use better precision if available. 

I agree - my preferred choice would simply be a .mdl with more bits for vertices. Sounds like it's easy to implement and stands the highest chance of getting into as many engines as possible.

I'm not too into skeletal formats in quake, for the same reason necros describes.

Ok, basically I'm making monsters for a mobile game. I own the assets and can do whatever I want with them, so it occurred to me one day that I'm building these very quakey looking monsters with a very quakey polycount (about 400 pollies for most), and it might be nice to one day turn 'em into quake monsters, but then the quake 8-bit vertex thing rears its misshapen, wobbly head and kind of deflates my enthusiasm a bit. 

Preach, that's a cool idea of tacking the lower 8 bits of each coordinate on at the end of the file. Only concern I have is code to find that refinement block could be ugly; you'd have to parse all of the structures in the mdl keeping track of the largest byte offset from the start, then if that offset + 1 is still within bounds, try to parse it as the refinement data.

Perhaps a cleaner way would be just leave the mdl file alone and dump the refinement data into another file (.bsp + .lit style), so you'd have shambler.mdl + shambler.16b (or whatever). Whenever loading a .mdl, the engine could check for a .16b file, and if present, use it to enhance the precision.

It feels a little wrong to create yet another model format, but the beauty of this would be it would work on all quake engines from the beginning, just without the enhanced precision. 

I dig that, sounds like a nice way of keeping the fallback .mdls "pure".

best of both worlds! 

it would also avoid potential problems if the model was loaded into QME. you wouldn't have to worry about the old editor clobbering the new data. 

Actually, qme already supports 16bit mdls. If you use the 'save' option instead of the export option, it'll write out an mdl format with a load of qme-specific data on the end of the file.
figure out the extensions and get some engine authors to support it, as well as a blender exporter.

regarding iqm, there's no reason that an engine couldn't just transform verts on load and then interpolate from there the same as they do with mdl (or just skip interpolation completely, if you really like vanilla quake).
Even geforce2 drivers will emulate support for vertex shaders.

iqm omits skingroups, so cannot be used as a pure superset (ignoring animation differences). luckily these are rarely used, and where they are used, they're often better replaced with a shader instead anyway. assuming your engine supports shaders...

mdl has other issues, like texture coord positions precise only to a texel, a single surface, implied flood fill requirements, onseam stuff is ugly as hell (and unsupported in any tool but qme (which breaks when onseam stuff isn't used)), palette limitations.
but worst, many of the limitations of mdl are not with the format itself, but with the engine.
by the time you have 1000 verts, all of those glVertex calls will be a significant time waster.
frankly, if you're going to rewrite enough of the engine to remove those limitations, you might as well add support for md3 too, which is typically easier to export to anyway.
ultimately, I don't see any point in mdl extensions unless qme can write them. backwards compatiblity is pointless if its going to just look terrible anyway.