Fifth's joke was better. 

I shall prepare a PowerPoint Presentation to prove it was not.... 

Is 64-bit Linux support coming? That would be awesome. 

There is a Linux version available on the Mark V page for those interested in provided feedback and willing to experiment.

A few people have said it works very well. One person had some audio issues with their sound system. Tested on Ubuntu, told it works fairly nicely with Debian.

Your mileage may vary. 

No makefile for linux. :( 

I may have missed something in the avalanche of posts, but when Gunter started talking about having to unpack the id1 pak0.pak and pak1.pak files I started to wonder if there's a fact being overlooked...

The pak file precedence over loose files only applies within a game directory, right? I believe it is the case that a loose file in a game (mod) directory takes precedence over any file in id1, regardless of whether the id1 file is in a pak or not, correct? Is everyone on the same page about that? 

Post #874 has compile instructions. 

I believe you understand correctly how it works.

But say you want to only replace the player.mdl when paying standard Quake... with the one contained in this pack:

http://quakeone.com/forums/quake-mod-releases/works-progress/9573-authentic-model-improvement.html

That becomes rather annoying to do, since it's not as simple as just dropping the replacement model into progs\id1\, because the pak file will override it.

So you end up having to create whole new "mod" folder just to use one replacement model, then you have to create a batch file to run quake -game whatever, or you have to type "game whatever" in the console if your quake engine supports it....

What happened with me is that a player took that model and applied the FvF skins to it, so I wanted to try it out. The problem is that FvF already contains a reskinned player.mdl in its pak file in my FvF mod folder.... So again it was not so easy to just drop in the player.mdl and try it out.

So Spike suggested "stop using pak files" and that's why I described having to unpack the id1 pak0 and pak1 files too, because even if I'm not playing FvF (or any other mod with a pak file) I'd still have the same problem if I were trying to just replace the player.mdl (or some other model) for standard Quake. 

OK I'm going to try this one more time.

The way Quake has always loaded content goes like this:

- Gamedir 1/PAK files/Loose Files
- Gamedir 2/PAK files/Loose Files
- Gamedir 3/PAK files/Loose Files
- Etc.

(And yes, even stock ID Quake can load more than one extra gamedir; try -rogue -hipnotic -game XXX").

Here is the Quaddicted Single-player maps archive: https://www.quaddicted.com/reviews/

This is a repository of content all authored under the implicit assumption that certain Quake engine behaviours are consistent.

I say "implicit" because I'm absolutely certain that none of these authors (or at best very few of them) ever sat down and actually thought about this. But nonetheless the assumption is there, so please don't try to play silly buggers about it.

Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't. So they'll have to be tested, somebody's going to have to go over them and check that there's nothing in them that breaks.

What you have is one case, and it's not even a gameplay case - it's a test case. And you're behaving as though you believe that one case should take priority over everything else. You're jumping up and down shouting "I WANT I WANT I WANT" like a child, and not showing any awareness whatsoever that there is a whole body of existing content and Thou Shalt Not Break Existing Content.

One test case in FvF does not get to take priority over the body of existing content.

Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you. 

I don't think anyone has put much thought into that compatibility angle before.

Considering the volume of single player releases, it would require an enormous amount of effort to find the ones with conflict situations. 

This is the kind of thing I've been bitten by before.

Even what seems like quite simple changes, say something related to behaviour of the viewsize cvar, can explode spectacularly if a mod uses it in an unexpected manner.

I think the key phrase there is "in an unexpected manner". The definition of an unexpected manner is that you actually cannot predict in advance what the impact is going to be, so it's no good someone asking for a list of disadvantages to a proposal.

"When in doubt do what ID Quake did" is a good maxim for certain classes of changes. With the SP community having converged around FitzQuake and derivatives, "when in doubt do what FitzQuake does" is also a good maxim.

We're not just talking about engines either. I've seen enough content made with buggy tools that just happens to work because engine behaviours or quirks accept it. I've been in a "put the bugs back" situation more than once.

The onus is on the person asking for a change to demonstrate that the change is benign, or at least that's the way it should be. Changes to very fundamental behaviours of core subsystems should always be approached with extreme caution. 

Ok, I see it is IS personal for mh. I think he just dislikes me because I consistently out-argue him. Well, he's going to like me even less after this.

mh, you are just being a crybaby now, but let me address your actual "arguments."

"The way Quake has always loaded content"

Yes, that's been pointed out repeatedly. But as Pritchard said, that's like saying, "Quake for 20 years has done things the wrong way" Or, if not strictly "wrong," then certainly in-optimal.

"Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't."

I do know: Not a single damn thing. Nothing. Do you know what kind of contrived situation would have to exist for the loading order to break map packs? The mod would have to install both a pak file AND unpacked files with the same names, yet with the files in the pak being the only ones that are supposed to be used, because for some reason the unpacked files with the same name are not the same files....

Seriously, HOW ELSE could the file load order mess up a map pack? You probably can't even come up with a realistic situation where it would, without your user do really weird stuff (which could happen no matter the load order). Maybe if the map installs as a pak file in your id1 folder and you already, for some reason, have different maps with the exact same name unpacked in your id1/maps folder??

The fact that you don't see it wouldn't cause a problem except in an extremely contrived circumstances shows that YOU are the one who isn't thinking this through.

Your flimsy argument amounts to trying to whip up fear of a boogeyman which would never actually occur unless you intentionally tried to make it happen. "But something might break! You just don't know!! Think of the children!!!"

You're grasping at straws.

Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? No? I'm not surprised.


"What you have is one case, and it's not even a gameplay case ... One test case in FvF"

Uh, no. I said it could impact anyone playing any mod or standard Quake if they wanted to easily use replacement content. I've pointed that out repeatedly. Do you not comprehend?

"Not even a gameplay case?" What? This isn't some hypothetical thing I came up with out of nowhere -- I never would have brought up the issue if it had not IMPACTED MY ACTUAL GAMEPLAY. Do you not comprehend?

You characterize me as crying like a child, but it's you, mh, being the crybaby. You're just being ANGREH. You don't have actual good points to support your position -- just hypothetical boogeymen which it's clear you didn't even think through (or you would have realized how ridiculously improbable it would be to actually break any of the maps from Quaddicted).

"When in doubt do what ID Quake did"

See, that's rich, because in the past when I have argued for using Quake's Default Behavior instead of some change Baker has implemented (centerprint position, or start map guessing), you have thrown the same whiny bitchfit over it. So it seems it doesn't matter whether I'm advocating for Default or not -- you're just against whatever I suggest.

(Normally I like Default presentation to the user, but this is behind-the-scenes, to make replacements easier)

"Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you."

I can only laugh at this :D

You're not seeing a LOT of things, mh.

So don't even worry about it. If some weird, obscure issue pops up because of this change, you can bet *I* will be the one to find it! I'm the one who has been finding the weird, obscure bugs that result from the changes Baker has made, because I have an extreme eye for detail and a meticulous mind for thinking on many different levels. So just because you "sure as hell" can't see what might beaffected, don't worry -- I can. ;)


Now, was any this necessary, mh? Nope. Baker already decided to leave the default behavior in place and add an option for the user to change tit. Yet you still felt the need to make a fuss and post at me with silly arguments and insults, because, apparently, you are a sore loser. And like FifthElephant, you just didn't want to see me get what I want.

Now, I normally do not post at people in such a demeaning manner as I have at you here, but this is certainly how I respond when someone insults me the way you decided to. So, if you don't like this, then refrain from making such petty characterizations of me in the future :p and then I will stick to addressing your actual arguments as I normally do.


Baker, don't let the "compatibility scare tactic" dissuade you from this -- you know if it produces any unexpected negative issues, I WILL find them! ;) 

mh is relating his experiences involving the development of DirectQ. He is not referring to you at all.

I watched some of the DirectQ users "carp" on mh with insisting DirectQ must do certain things.

Something unseen here is that very few engines end up surviving compatibility.

I could tell you things that crash qbism super8 hard. I could tell you things that don't work right in FitzQuake. I can tell you things that don't work in Quakespasm.

mh and I work well together because we view compatibility as #1.

/So please leave mh alone. I already said what I plan to do. 

Might add that I also know single players that have problems with Mark V's automatic impulse 12 support. If you are serious about compatibility, you know your own engine's weaknesses as well. 

Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"?

https://www.quaddicted.com/engines/darkplaces 

Remove: "single players"
Substitute: "a couple of (rare) single player mods"

/Premature submit strikes again! 

Now, was any this necessary, mh? Nope. [...] And like FifthElephant, you just didn't want to see me get what I want.

I wish someone wanted my naked body that hard. Now I'll feel jealous of Baker too. 

@Baker "He is not referring to you at all."

Ah, well, then I must have misunderstood when he used my name ;)

But it's no big deal for me, really. I approach internet arguments like a Quake Deathmatch: whether you win or lose, it's all for fun, and it's not worth getting legitimately upset over. :D


@mankrip Yeah, I guess I really should have specified I was talking specifically about compatibility with Darkpalaces due to the unpacked file preference is has. I have no idea about all the many other differences in Darkplaces, and what compatibility issues they may cause.

Actually (side story), I remember several years back I tried using Darkplaces for the FvF server, but I encountered compatibility issues.... I think I emailed LordHavoc about it, and it was something about either checkbottom or some other way to see if something was on the ground, and what I was doing in FvF wasn't working in DP. LH said that code never really worked right in standard Quake or something.... In any case, I went back to proquake server, and I don't know if the problem would have been fixed by now or not.

So yeah, I understand compatibility issues are indeed important, but "compatibility problems have been caused by other things" isn't a valid argument in this specific case. Do we never try to change/improve anything due to fear of incompatibility? No, but of course, we do tread carefully. 

"I wish someone wanted my naked body that hard."

Well, just make a quake player.mdl with a skin of your naked body, and it will be REALLY EASY for people to drop it into their game once Baker makes the setting available!


(And NOW I see the downside!! What have I done!??) 

Ok, now that this is all settled ...

It's June. It's great weather and sunny ... 

It may be sunny now, but not for long!

Anyone else going to catch that full eclipse in August?

It is passing DIRECTLY overhead for me -- I am right in the center of its path.

I guess all those sacrifices to Shub-Niggurath are having an effect! 

I'm in the southern hemisphere, and it's winter now; no snow, though. 

"But it's no big deal for me" - Gunter after 3 scroll pages of bitching.

Please don't include me in your diatribes either, I was poking fun at you light-heartedly. Baker clearly got this. 

Ok, got it. You are allowed to "poke fun" at me, but I'm not allowed to mention what you said. That's a reasonable expectation. 

Might be time to move this to the beef thread as Pritchard has suggested. 

It's not an "internet argument" though. You don't seem to understand that, but it's not. This isn't an argument where somebody wins and somebody else loses. 

Then I'm not sure what it's about for you, mh.

From your first post on the matter ( #1574 ) you decided to assault my intentions and motivations and mis-characterize me in a poor light.

Even on a side issue you felt the need to make it about ME rather than what I was saying ( #1595 ), but I continued to address the argument rather than the arguer.

Then after the issue was settled (Baker decided to leave the default as-is, but to add a setting to change it -- a win/win situation) you again decided to post and complain and VICIOUSLY assault my character and motivations.

THAT is the point it became an "internet argument."

Now, I want to clarify: only my last post was what I was referring to as "an internet argument" in regard to having fun winning or losing -- normally when I say "argument" I am using the formal sense of the word: arguments and counter-arguments and making points in a discussion. But an "internet argument" (I probably should have said "internet squabble" or something) is more like a flame war.

Yeah, at that point it's more about "winning," but if you look back up to my post #1598 you will see I said just what are you saying now -- the point of me posting here is not about winning or losing, it's about helping to improve Mark V (and this feature will be an improvement to Mark V). I even said in that post that it wasn't personal with you.

If you believe in your position, you make good, valid arguments for your position. You don't start questioning the character of the person who is not for your position.


Now, I am a Quake player, after all, so when you fire enough rockets at me, I will fire a BFG at you ;)

This was the FIRST time I have assaulted your character in all of these Mark V discussions, but it is certainly not the first time you have questioned mine and cast me in a negative light.

If you want to avoid this again in the future... just stop doing that. Let your (formal) arguments stand on their own without making it personal. If your arguments are sound, then they are sound and they should hold up on their own no matter who you are arguing against. So how about you stop casting aspersions on my character?

Anyway, it STILL isn't really personal for me, despite me firing a BFG at you.

So let's be friends! 

 

Hi, I'm using the Mark V 1.36 source port and when I enter the exit portal of Gloom Keep, the game often (about 5 out of 10 times) crashes back to desktop with the "Mark V has stopped working" notication. This happens both with the regular gl version as well as with Dx 9. Is this a known issue? 

I can't remember if I have it fixed in the unreleased version or not. I'm thinking it is fixed whenever the next update will be released (date unknown).

That was a fun mystery, engine coding-wise.

When you go through the exit teleporter on Gloom Keep, there is a world brush model that has never been seen before and isn't visible in that frame either, but due a mirror surface in the area, the model comes into visibility but hasn't been precached.

I have to assume that since I know so many details about the circumstance that I have rectified the situation in the in-progress version. 

Thanks for the answer. I deactivated the mirrors via the console command mentioned above and now it works fine. 

Since this problem appears in a bunch of modern ports I will repeat my post of half-a-year ago

Quake is originally designed for 320x200 resolution to be run on 4x3 displays (just like Doom). This means, that whole screen should be stretched vertically. The original game nicely adjusts viewport so that actual gameplay window is always at true aspect no matter what resolution is set - 320x200 will look exactly like 320x240. But the UI is not. It is designed to be stetched, so it only looks right on 320x200 and 640x400 resolutions and is "squished" on every other.

So what's the problem? Mark V removed id's aspect corrcection and treat every resolution identically. Setting up 640x400 and 320x200 result in stretched in height gameplay window.

The ideal solution would be to add an option to make correct UI scaling. Here's some example shots of original winquake and Mark V scaled to 4x3 and upscaled

http://i.imgur.com/ZnPksXb.jpg
http://i.imgur.com/mJLsJH5.jpg
http://i.imgur.com/dWRoC5M.jpg
http://i.imgur.com/fj0f4aI.jpg
http://i.imgur.com/n8lznjF.png
http://i.imgur.com/tmH5eHL.png

http://imgur.com/a/jAW3U 

Nice to mention this, it's one of the most overlooked things in custom engines.

But I'd like to add that Quake is actually inconsistent when it comes to video aspect, because the 3D renderer was coded for a 320x240 4:3 screen (square pixels), while the 2D renderer (and artwork) was made for a 320x200 4:3 screen (non-square pixels).

Doom's "3D" renderer was indeed coded for non-square 320x200 4:3 pixels, IIRC, because it didn't support other resolutions (before WinDoom). Quake was the first id engine with multiple resolution support, so it's quite poorly coded for it in some areas. 

I'd be cautious about how this change would look in a hardware accelerated engine. On the surface it seems easily achievable by just rescaling your ortho projection and 3D viewport by the appropriate amount, but there's gonna be a whole lot of edge cases with texture filtering that will need to be worked over. 

But I'd like to add that Quake is actually inconsistent when it comes to video aspect, because the 3D renderer was coded for a 320x240 4:3 screen (square pixels), while the 2D renderer (and artwork) was made for a 320x200 4:3 screen (non-square pixels).
the only thing is that it wasn't. original software renderer actually could do a valid 3D picture with virtually any resolution and pixel aspect, and if you choose 320x200 (640x400) you will get just right picture in every aspect (no pun intended) 

The particle renderer, which is part of the 3D renderer, was explicitly coded for 320x240, with double height scaling for 320x480.

The underwater warp is also inconsistent across screen resolutions and was coded for a 320x240 video buffer, as explained in this standardized test. It also means that it's impossible to always get a fully aspect-correct image in ANY resolution in the original renderer, because while the HUD only displays properly in 320x200, the underwater warp's waves only displays properly at square-pixel screen aspects (320x240, 512x384, etc).

The original software renderer is not consistent even across multiple HUD sizes.

The software renderer also screws up skies and particles when the FOV changes.

But most people never pay enough attention to notice all the problems in the renderer. 

I... uh... um.. er.... :u

Ok, yeah, I'm bringing up the contentious topic that we just put to rest, but bear with me... you will NOT see the ending coming!

Ok... So, I was considering what mh was saying about "expectations" that people supposedly have about the loading order for content like models, in regard to the pak files vs unpacked files having preference (default from original Quake is pak).

Previously I pointed out why this isn't just for mods (mine or anyone else's) -- it's also for standard Quake if you want to use the player.mdl from this pack: http://quakeone.com/forums/quake-mod-releases/works-progress/9573-authentic-model-improvement.html

I looked at the readme file included with that, and it just says, "To use these new models place the 'progs' folder inside the 'Id1' folder in your Quake directory."

Ok, so it's apparently not the model creator's expectation that pak files should take precedence, so he must have been using one of the modern engines that changed the behavior.

So then I did a web search to see how other people might answer the question, "how to replace player.mdl in quake." The first link that pops up is a Quakeone forum post (naturally) where someone was asking just that: "Easiest way to replace player model?"

On page 1 of that topic, someone mentions creating a mod folder and dropping the file in the progs folder of the mod, and another person mentions something about looking in the pak file.

Then at the top of page 2 of that thread: http://quakeone.com/160346-post11.html

the guy is told, "Yes. You can just create a "progs" folder into id1, drop the model into and you're done."

Ok, so again, expectation seems to be that just dropping in the unpacked model should work, and the final post in the thread has the guy saying he did just that and it works... with DirectQ....

Yes, that's the kicker. The guy asking the question said he was using DirectQuake (he said that on page 1 as well).

DirectQuake is mh's own Quake engine, and IT HAS UNPACKED FILE PREFERENCE. :u

I decided I'd better test this for myself, so I found and downloaded DirectQ (for some reason it's not that easy to find), version 1.8.8 (because 1.9 crashed for me), and sure enough, it's just as simple as dropping the unpacked player.mdl into id1/progs/ and it works in DirectQ!

So... like... um.... Do I need to repeat that? mh has been BLASTING me for daring to ask for a feature THAT HE ALREADY PUT IN HIS OWN ENGINE :u


So yeah, Baker, please import this wonderful feature that mh was wise enough to implement in DirectQ :D

;) 

I have admitted that I've been wrong about things in the past. DirectQ was riddled with mistakes, I freely admit it, and that's one reason why it's no longer developed. You don't get to score points that way I'm afraid. 

I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind, rather than any specific resolution. 320x200 is just an accident of history.

I did code up aspect adjustment just to see how it looks and as expected it's pretty crap when texture filtering kicks in.

It might be OK as an option but otherwise I'd leave the default alone. 

I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind

Look at the pentagram icon. It should be a perfect circle, which only happens at 320x200. At 320x240, it becomes oval.

Also, the console background itself was obviously made with a non square pixel aspect in mind, and it has text pasted over it by the engine. With square pixel aspect, that text's aspect becomes different from the aspect of the rest of the engine's texts.

The help screens, which were made to cover the whole screen, are also 320x200.

And lastly, enlarging the 2D art vertically when using square pixels makes more sense than reducing the 2D art vertically when using non-square pixels. If the 2D art was reduced vertically, the help screens wouldn't cover a whole 4:3 screen. 

By the way, non-square 2D pixels should be optional, because several mods uses custom GUI artwork with square pixel aspect.

When rewriting the GUI renderer, I'm going to make it use an optional non-square scaling enabled by default. 

I think about the 2D rendering differences.

As there is no separation between the software renderer vs. the Open GL build -- it is FitzQuake calling the shots and saying what to draw and the location -- using a canvas system that WinQuake never had.

The source code in Mark V doesn't actually trace back to WinQuake, not even for the WinQuake build.

Which is way different than mankrip's engine or qbism super8 or engoo.

It is also why Mark V has immensely more versatile video capability than any other WinQuake. The video code is literally 100% FitzQuakian.

Shorter version: Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming. 

Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming.

Same thing here about colored lighting. It would be a pain to implement it now, only to rewrite everything when the new color transformation system gets implemented. 

Just to clarify what I mean: here's som screenshots with various combinations of aspect correction and texture filtering.

The "200 Height" shots are using the old 320x200 resolution but at a 4:3 aspect.

Pay particular attention to the menu slider bars. This is what I mean by a 1:1 mapping of texels to pixels.

http://www.quaketastic.com/index.php?dir=files/screen_shots/200_Height_Tests 

Oh, yeah. Now I know what you mean.

When you said "1:1 mapping of texels to pixels", you didn't limit the meaning to square pixels. A 4:3 320x200 screen will have non-square pixels, but the texels also have the same non-square aspect, so the screen will display the texels in a square ratio to the pixels.
A 4:3 320x240 screen multiplies the rows to compensate for the "non-square texel to square pixel" aspect when necessary.

Yes, such scaling generates notable artifacts at lower resolutions, which is another reason to make the 2D aspect correction optional. But at higher resolutions, the artifacts becomes unnoticeable. Also, some custom texture filters may help. 

You don't really get to do custom texture filters with hardware acceleration though. Well you can, but you have to write them yourself in fragment shaders so a lot of popular engines don't get to play. Otherwise texture sampling is fixed functionality.

Forgot to mention - one thing I really like about Quake's 2D graphics is the fact that they're so crisp and clear, and this is as a result of the precise pixel work that went into creating them. It's something that you might not notice at first, but any kind of texture filtering on them blurs out a lot of the fine detail. 

*shudders*

Would be nice for some maybe to have a gl_hudfiltermode convar. 

If there was a Quake engine that supported temporal antialiasing (TAA), then texture filtering would be completely unnecessary. 

I've cropped your unscaled screenshot to 320x200, and did some tests using The GIMP:
320x200 source

320x240 mockup, nearest scaling

320x240 mockup, bilinear scaling

Bilinear scaling in The GIMP shows that it's possible to scale Quake's 2D GUI in a way that looks good. It may be complicated to get that same quality using hardware rendering, but it's definitely possible.