All Hail The Corporate Overlords
That just totally goes against the philosophy of Quake in general. God, I hate corporate meddling and their greed driven jealous guarding of things they could never understand just because "I-OWN-THIS-NOT-YOU". The only reason they'll be selling the numbers of the re-release they are is because of the openess of the community over the past couple of decades.
Honestly, the collapse of global capitalism can't come soon enough.
#144 posted by mh on 2021/08/28 18:45:18
Kex is a closed-source engine. The "philosophy of Quake" stuff is bullshit. Quake always had proprietary content, ID always retained closed-source licensing options after the original GPL release, and people really shouldn't be dreaming that any of this is something that it's not.
If you really wanted to go down the paranoid fantasy route, you could say that this is an evil corporate plot to Make Quake Closed Source Again. The irony is that under Microsoft ownership ID are now more open-source friendly than they have been in years, and new open-source released are now more likely to happen than they have in years. If you haven't updated your information since 1998, perhaps you should.
On the other hand you could stop whinging and start doing. The content is all there, there's already sample code, people have already done work on this stuff. Stop being a negative contributor and start being a positive contributor.
Macro$haft
#145 posted by Text_Fish on 2021/08/28 19:46:33
I heard Bill Gates hid a vaccine in the new Rottweiler skin which is going to turn us all in to face masks. YOU CAN'T PROVE HE DIDN'T.
Whisfull Thinking
#146 posted by madfox on 2021/08/28 20:11:25
I feel a bit sorry. I know I'm like the Old One, lame & quirky. I played Quake five years on a stand-alone system, never cared about DM.
I hate it to be adjusted to the net for many reasons. It isn't 1998 anymore, but I would have apreciated if I could get Quake-Rereleased on a CD in my hands, not an abstract phantom on the net. Maye someday.
#147 posted by Willow on 2021/08/28 21:26:49
Just saw someone is working on the progs.dat already:
https://quakeone.com/forum/quake-talk/quake-central/283211-quake-enhanced-is-out-now?p=283403#post283403
I'm not sure what it does exactly but there is a download at least.
#148 posted by mh on 2021/08/28 21:29:15
I've an update to my MD5 code up: https://github.com/mhQuake/MD5Stuff
This fixes a content bug in the Quake reissue. Some of the new MD5s were created with bad bounding boxes, so it's necessary to recompute them properly at load time. This was noticeable on the armor and backpack models; possibly others but I didn't check everything.
Progs.dat
To put it simple, contains all the code necessary to make game-related things work. Monster AI, weapons, player... you name it. If a mod contains this file, it means they modified original game behavior to some extent.
Normally, the only way to edit a progs.dat file is to decompile it and put it back together with the changes you need. This sounds easier than it is, I can tell since I have already done the same for Shrak, another (exotic) old Quake addon. I am surprised they managed to pull it off so quickly, but these guys are good at this and determined, so: hats off!
#144
Wow, dude, I think you read a bit much into my post. I never mentioned Id, the closed source that they used or anything to do with GPL. I spoke of the open community (which includes you) and how that community has kept the game alive and thus nurturing the huge interest that has been shown by the mainstream gaming press in recent weeks.
I am not a paranoid fantasist nor am I stuck in 1998. Sharing my negative feelings is not whinging. The real "bullshit" is people that respond to something with which they disagree with the over-used adage of "put up or shut up". My opinion whether negative or otherwise is valid. I disrespected no individual only a global philosophy that I find to be abhorent. Whether I code or not is irrelevant. If my statement had been positive I highly doubt anyone would shrug it off with "your positive opinion is ill informed, go code".
I try my best to share positive thoughts wherever applicable. In this instance I shared something negative. Surely, I'm allowed to do that on occasion.
Anyway, peace.
^
Actually, please disregard the above post. I should've kept my opinion to myself. These things never go well on the internets and the last thing I want is to derail this thread or detract from the fact that we got some lovely new content to play with.
I would delete it but there's no edit button. *shrug*
Apologies to all.
DOPA Patch V2
Updated my "DOPA Kex" patch in order to also add that missing "Congratulations" screen at the end. Get it here (142 KB).
Missed Opportunities
#153 posted by mankrip on 2021/08/29 17:28:59
I finally saw the new models (got the MD5->MDL conversions).
Sadly, they went through the hacky route of disabling interpolations instead of creating the models in an interpolation-friendly way. Most of the new viewmodels have bad issues with muzzleflash interpolation, and the new enforcer also has a problematic muzzleflash.
Sorry, but disabling interpolations to "fix" model animations is an ugly hack.
The new grenade launcher's muzzleflash has poor texturing, each side of it looks completely different.
The kneel animation in the new knight model has the wrong height; the original model also has this problem, but they could have fixed that in the remade model.
Most of the new models are perfect, but these technical issues could have been fixed.
We already fixed the muzzleflash for the RL in the AMQ which has the flash "travelling" through the model when firing. A mistake inherited from the md5, btw.
As for the Enforcer, Knight and GL, I have forwarded your feedback to osj over at QuakeOne. Fingers crossed!
Z-fighting
#155 posted by mh on 2021/08/30 10:59:08
The rebuilt maps aren't z-fighting fixed. Instead the Kex engine is using polygon offset on brush models. That's massively disappointing, if understandable enough given competing demands on limited time.
In the meantime, that QuakeOne patch for DOTM still has some flaws. Walking over corpses causes weird glitches (corpses are moving above you, so you basically walk underneath them, then they drop back down) and most ingame messages (e.g. for pickups) are still loca variables.
Re: #156
#157 posted by Kingold on 2021/08/30 14:14:13
Yeah, I found it still crashes QSS, so I have been using FTE for playing DOTM these days and am now at Episode 2. FTE supports dynamic lights so the fan shadow rotating effect in the hub map is preserved too. Don't know what other minor differences are there between FTE and KEX Engine, though. Loca variables are quite annoying for every slipgate tip, pick up tip, end message, etc.
Kex Engine Lighting
#158 posted by mh on 2021/08/31 20:32:16
I haven't yet figured out how it's doing dynamic lights, but for animated lightstyles it's using something similar to the GPU lightmaps technique I've used for years.
My normal approach is to have 3 textures, one for each of the red, green and blue colour components. Each component in a texture represents one of the Quake styles. Each of the final colour channels can then be composed by a texture read and a dotproduct with the surface styles.
The Kex approach uses a 4-slice array texture, with each slice representing a style, and each texture being an RGBX colour. These are conditionally accumulated when styles are not 255.
I use array textures to allow me to only have a single lightmap texture that's bound only once at the start of the frame. Kex can't so that as it already uses array textures for styles, so it just seems to pack each style into a really large texture.
My approach uses less texture memory, and performance is absolutely level, irrespective of the complexity of the lightstyles on a surface. An optimization path exists for surfaces with only one style, but it adds some code complexity and I generally don't bother writing it up.
The Kex approach has potentially fewer texture accesses, as a tradeoff vs some shader branching and using more texture memory. Performance falls off for more complex styles.
Both approaches mean that lightmap textures are never updated at runtime, lightstyle interpolation can be done without affecting performance, lightmap accumulation runs at full internal precision, the maximum light value is never clamped, overbright lighting just comes out naturally, and the runtime codepaths are considerably simpler.
On balance I favour my own approach, for reasons of performance levelling and being more economical with texture memory, but I can understand why Nightdive did it their way.
#159 posted by mankrip on 2021/09/06 05:31:22
Does any of the custom engines have the realtime ambient occlusion that the KEX engine has?
#160 posted by 7yn1c on 2021/09/06 14:39:45
why would realtime AO be useful on a game like Quake? baked has much better quality
#161 posted by mh on 2021/09/06 15:17:42
I disabled AO but I guess some people seem to like it. It does add a shadow around the edges of some moving objects, which can help make doors, plats, etc seem more grounded in the world instead of "floating there", so there is that. But for me it's one of those things I've never really paid much heed to.
#160
#162 posted by mankrip on 2021/09/06 15:59:31
As mh said, it helps with moving objects. See in the first demo, when the ceiling lowers to crush the player, the small shadows in the edges of the ceiling moves along the walls. It's a nice effect that I guess some people will demand custom engines to have.
However, I've noticed that in the Rogue mission pack the ambient occlusion is overdone, darkening wide angle corners that looks better without ambient occlusion.
#163 posted by mh on 2021/09/06 16:19:50
AO is also something that needs to be properly integrated into a post-processing pipeline, it's not a simple glEnable or anything like that. So what I'm saying is that doing it can be a very disruptive change to an engine, particularly if an engine doesn't already have a post-prcessing pipeline.
Engines like Unreal, Unity or even Kex already have all the groundwork in place for this; with Quake you have to do everything from scratch.
On the other hand you can do it wrong and crudely crowbar it in, which means that when people come looking for the next set of post-processing effects (and they always will) you'll end up with a mess to straighten out before you can do them.
#164 posted by mankrip on 2021/09/08 04:48:08
Silly question: I haven't looked into the MD5 code yet, but what would be the challenges to implement it in software-rendered engines?
MD5 In Software
#165 posted by mh on 2021/09/08 07:03:50
It should be very possible. Only the C code in r_alias.c would need additions, and that produces structures for use by the ASM code that are completely independent of any model format. The exception is R_AliasTransformAndProjectFinalVerts which consumes trivertx_t structs from the MDL, so that needs a C implementation for MD5s (unless you want to write an ASM version yourself).
It might be possible to combine this routine with the skeletal animation code as an optimization path, though.
The most important thing would be to get the bboxes absolutely tight. A hardware accelerated version is tolerant of loose bboxes, but a loose bbox in software means that you'll overflow the framebuffer pointer, write over and corrupt random memory, and probably crash. That was an issue when I wrote the software Quake interpolation code, but you might not even want to bother with interpolation.
MD5 In Software
#166 posted by mh on 2021/09/08 14:56:52
https://www.quaketastic.com/files/screen_shots/MD5_Software_Quake.pcx
This took me maybe half a day to do, and a good chunk of that time was spent trying to figure out a bug in skin texcoords.
I need to tidy up and comment the code a little, then I can release it publicly if anybody's interested.
MD5 In Software
#167 posted by mh on 2021/09/08 16:20:15
For anyone who's interested; you'll need to compile this yourself: https://github.com/mhQuake/MD5Stuff
|