I agree with mh. Vertex wobble is very noticeable. Took a short video of it in QSS.

https://youtu.be/VoxHGqptqFM 

Heh, reminds me of Kingpin! 

In an ideal world QuakeSpasm and derivatives would just load and use the MD5s directly. Now that they're official, and now that MD5 is an official MDL replacement format, this makes sense to do.

I know that QS hasn't released in a while, but cruising by it's Github page I see that it's still being actively worked on, and is starting to take up changes for the Quake 2021 reissue. Same with VkQuake. 

The new Quake Kex assets are NOT in any of the official AMQ releases yet. Your video footage does not show our latest models, I am afraid.

You must download the dev build from the Github page. To do so, click on "Code" (green button), then "Download Zip". THAT'S the way to get the new stuff right now since we aren't fully ready for a release yet, so it's NOT to be found under "Releases".

I admit that Github navigation can be confusing to people who aren't used to it, but that's the way it works. 

I admit that Github navigation can be confusing to people who aren't used to it, but that's the way it works.

It's confusing even if you are used to it (18 repositories and I still get lost).

Anyway, that is significantly improved, although I'm still seeing wobble compared to the source MD5s.

That's not a criticism of anyone's work, by the way. Vertex wobble is a "feature" of the MDL format caused by compressing positions to 8 bits, and that's just what it is. 

Has anyone done a detailed comparison of how the remastered version is implemented versus vanilla/derived? For instance, does the remastered still use QuakeC with progs.dat, or does it use something else? If it uses progs.dat, is there a formal source dump? Are the assets the same format or different?

I'd love to see a tabular breakdown/comparison. 

@mtp I agree. I'd love to eventually see some community documentation of the technical changes that are relevant for mappers, modders, and engine coders. Things like changes to the protocol (e.g. svc_achievement), new file formats (e.g. md5), new console commands or cvars (e.g. menu_credits), changes to how autoexec.cfg is handled, etc.

@mh, the work you are doing for md5 would be great as a sample implementation, unless it depends too much on each engine's model renderer. 

I could release my MD5 code publicly but I fear it would be of little use to people. It's all D3D11, buffers and shaders, that kind of stuff.

The code at http://tfc.duke.free.fr/coding/md5-specs-en.html is probably more useful to the Quake community. That's a working implementation that uses GL 1.1 code and that my own is based on.

The main thing missing from that code is generating normals. There is code in modelgen.c for this and that can lift over clean enough.

It also does it's skeletal animation on the CPU at draw time, whereas I've used the bones and frames to build keyframes instead. My way takes more memory but it's highly compatible with my MDL renderer.

An option is I could port an implementation to QuakeSpasm. Last time I publicly fiddled with QuakeSpasm I did have needy, demanding people descend on me practically ordering me to do Linux builds just for them, so I made the project private and I'm really reluctant to go there again.

I don't know, do people want the MD5 stuff? 

@mtp I think it uses QC progs.dat (but only 328KB instead of vanilla 411KB), for example it ran Team Fortress 2.8 alright, the centerprint menus are messed up (but they work) and the intro crashes the game after a few seconds, so I deleted demo1.dem from the fortress pak. I also experimented with FrikBots adapted for Clan Arena, but the game crashes when I try to load any map. :(
So, sadly there may be quite a few classic Quake mods that won't work properly. 

Not sure if your code would be generally applicable to other engines. Probably the loader and the code that bakes out the poses could be generally useful, even if the rendering part isn't.

Although I feel engines would be better off doing the skeletal animation in realtime, for fidelity reasons. Fast-rotating shapes tend to collapse if each vertex is lerped directly, whereas if the bone is rotating, then the verts could follow an arcing path, so the overall shape doesn't deform or collapse.

That link you posted also looks very useful, though. 

@mh, I am sure making it available in Quakespasm would be nice for folks. I have no problem with UNIX-like build systems; and for demanding/needy users who aren't, it's a good chance to learn how. ;)

@rickzeppelin, that somewhat matches my expectations. I wonder to what extent there are signature mismatches between the QuakeC interfaces or the in-engine hooks/stubs/thunks that the QuakeC code calls. Then comes the wire format used for demos and the network. Here be dragons.

I built a progs.dat decompiler in Go (almost finished) as a part of a self-study project. I was interested in trying my hand at decompiling qtest1's progs.dat, but that uses a different signature. Sadly I don't have a lot of time right now to inspect the header signatures of qtest1's progs.dat. I was mainly interested in trying to learn how the in-game logic differed from the public release à la The Cutting Room Floor.

I know it's naive, but I was really hoping that the remastered project materially was derived from the vanilla engine to preserve maximum compatibility. 

I'm working towards a standalone release of the MD5 stuff, derived from my engine, that people can use as a base rather than as a drop-n-go replacement.

That means that the renderer and some of the loader will be Direct3D 11, but it should be quite clear what's going on.

A very subtle bug in the new content.

The Grunt's gun has a red light that uses fullbright texels on the original MDL skin, but the Nightdive guys missed it on their MD5 replacement. 

Presumably NightDive could have replaced the vanilla cube hitboxes with much more accurate ones if they'd wanted to. It'd be interesting to know if they even considered it, or just instinctively knew that the community would reject it. Personally I think it would be quite a good way to raise the skill ceiling of the game and prevent players from picking off Shamblers and Vores from around corners, but would it detract from the Quakiness of the reboot? 

....would it detract from the Quakiness of the reboot?

I think it's the kind of change that would have gotten colossal pushback from the community.

As it stands they're already getting a rough time from some, and I think a large part of that is down to the fact that ID had neglected Quake 1 for so long that the community feels a stronger sense of ownership towards it, and any changes are maybe viewed as a challenge to that sense of ownership.

I think a new "Ultra-Nightmare" mode incorporating this kind of change would be good though, and maybe would have been the right thing to do for the changes they made to the existing Nightmare mode as well. 

Check out those red fullbright pixels on the Red Armor! 

I made a quick patch to get the new DOPA release playable in other ports. Get this file (54 KB) and follow the instructions in the readme. I already tested it in Quakespasm-Spiked. All maps work, the only thing you won't get is the "Congratulations" screen at the end of the episode - but in return, you won't get any crashes (if you follow the readme instructions properly). 

Sorry, you're right. I didn't even look at the date on the release.

Grabbed the latest from the repo and took a short vid. The vertex wobble definitely isn't as bad as the older ogre model, but it's still noticeable.

https://youtu.be/QL9MP7TRbbo

As mh said, probably not much you can do about this in MDL format. 

They're pretty much all over the ring too. 

Considering these are mostly untouched MD5 to MDL conversions, results are still quite good and well within acceptable limits for gameplay purposes. For some reason, view weapons won't convert that well though, at least in some cases. 

> I know it's naive, but I was really hoping that the remastered project materially was derived from the vanilla engine to preserve maximum compatibility.

FWIW a developer has said that it is still the original C code when it comes to the game-logic loop. The "Kex framework" is their term for the adapter/shim code they wedge in all around that to interact with modern systems (for rendering, neworking, etc.). 

Thanks for confirming that. I kind of assumed that was the case because someone said they were getting a hunc_alloc error.... which should not even exist if the engine was not largely still quake under the hood. 

I still suspect at least some of these "remastered" models were ripped from the community, especially the ones made by capnbubs (Rottweiler, Grunt, Player, unreleased Ogre).

As for the sounds... I somewhat doubt they found all the sound sources all of a sudden in higher quality. Many of these are just upmixed with filters.

I mean, it's still great it has been done and all that. But... maybe less effort went into it than it looks at first. Just check the state of the SoA and DoE mission packs. Those were left mostly untouched compared to the rest. 

Eh, these are the kinds of things you can directly talk to these guys about in various places (mainly id dev "sponge" on Quake-related discords and the SA forums, and some Kex devs on SA-related discords and forums).

id did have higher-quality versions of most of the sounds in their archives, which were used here. IIRC only 22 kHz though, so they're still being upped to 44 kHz. And for a few sounds no higher-quality version was found.

The person who made the models has been credited as Jonatan Pöljö (@eldrone on twitter).

I dunno that we need to immediately get all cynical about the exact amount of "lazy devs" stuff involved here. :-) 

...because I want this to be more generally useful to everyone...

I'm implementing it in stock FitzQuake 0.85; I've lightly modified the code to get it to compile in Visual C++ 2008 Express, and run clean in my setup. Otherwise it's totally unchanged and you should be able to diff it against the original code and see what the additions for MD5 support were.

I'm doing full skeletal animation in this version, but on the CPU. That's obviously not the fastest code path, but you'll get to see everything in the one place and in simple C code.

It uses vertex arrays, not glBegin/glEnd. It would be trivial enough to modify it for glBegin/glEnd,

Right now I'm brute-forcing normals calculation at run time instead of precomputing them for the base frame. It still runs fast enough, and I really just did this to get something working.

A full implementation of all the options and toggles of the FitzQuake renderer will be left as an exercise for the reader. This is just a techdemo sample implementation, and people really shouldn't get any other expectations from it.

Progress? It's almost all done, actually. I do need to spend some time on those normals, but otherwise I could make the code public over the next few days. 

With original levels, they have the .MAP sources. As for upsampled with filter sounds, if they did, they sound a lot better than two fan-made HQ-sound packs, I compared all of it with each other just the other day. The 'remaster' team did go to the archive storage folder and dug up what they could find. Then they just batch-converted all the sounds into 44/16 which I guess is better for this KEX engine thing, for one reason or another.

They couldn't go over DOE stuff because they couldn't find the source assets for it. With SOA I think they actualy found if not all, then most (but maybe I misunderstood from the Discord chat).