|Posted by Baker [220.127.116.11] on 2016/11/19 04:53:11|
* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")
Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy
And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.
/Mac version is not current yet ...; Linux will happen sometime in 2017
Is 320x240 Stretching In Hardware Mark V Possible?
I just tried out Arcane Dimension for the first time, and I'm just blown away by it. I really want to play through each and every level of that mod, but there is something preventing me from enjoying it.
Up until now I've used the winquake version for playing quake, and while that is perfectly fine for the official quake content and my own maps it doesn't get along with high-caliber stuff like AD very well. On one hand there are graphical issues with transparency that are to be expected, but the performance also takes such a drastic hit from all the cool effects and increased polycount in every level that it's just not playable any more.
The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse. Because unless I want to stare at a blurry mess, I need to render in my laptops native resolution of 1336x768 instead of stretched 320x240, which more than nullifies the benefit of hardware rendering in terms of raw performance.
Why is stretching only supported in the software version? I know that most gl-based engines only support 640x480 as the lowest output resolution you can select in the menu, but it's clearly possible to render the actual game in resolutions much lower than that since you can adjust the screen size in the menu to achieve just that. I took a screenshot of the smallest screen size in hardware mark v at 1366x768, which results in the actual rendering resolution only being slightly larger than 320x240. If you would implement a feature that scales this window to fit the screen borders again, that would have the same effect as the stretching feature in software mark v, right? Is that how the feature works in that version?
I can't judge how much work implementing this would be, or if it's even possible at all. It seems like it should work to me, but there very well might be hard limitations preventing the feature from being in hardware mark v in the first place that I'm unaware of. I just want to let the devs know that this feature would be huge to me and everyone else who loves chunky pixels coupled with smooth performance.
I'm surprised so little people seem to play quake this way to the point where there is pretty much no support for it, software mark v being a rare exception. Most players seem to prefer resolutions that utilize every pixel of their screen, but I just can't enjoy quake that way. It has nothing to do with nostalgia in my case, I missed the pixel-period of gaming by quite a bit since quake is actually slightly older than me. It just feels so much more alive in low resolutions. It has to do with how everything is constantly changing shape as you get closer or farther away from it, for example how particles blend seamlessly with the chunky environment, choppy animations seem to flow naturally, flames look like hand-drawn sprites at some distances or how you sometimes can't even tell what monster is waiting for you at the end of a dark hallway. Viewing lava and water at an angle also look incredibly organic due to this, even though they're just a single texture tile repeated over and over. If you look at all these things on a high resolution with interpolated textures and lerped animations, that magic feeling completely fades out of existence. You suddenly see everything very clearly for what it actually is: simple brushes, blurry textures, and crude animations. It feels like looking behind the stage even though you're actually still looking at the stage. That is apparently just what happens when you force a game two decades old to conform to today's graphical standards. It should look objectively better due to the modern improvements, but it just doesn't, not to me at least. I don't want to bash on everyone how enjoys quake at normal resolutions though, even if I'm coming on pretty strong here. I'm really happy that quake has evolved into something that can be so many things and has an engine for pretty much everyone and their personal preferences, and I'm thankful that even less popular ones like mine are represented to some degree in the community and in mark v, even if just in the software version.
I'd happily do the work of porting the feature myself, but I lack any kind of knowledge that goes beyond the very basic level of fiddling with quakec and have no idea where to even start tackling things related to rendering, making this plea to devs my best shot at getting the quake engine of my dreams for now. I'm gonna keep learning more about quake development and programming in general though, it's just going really slowly since I'm far from being a John Carmack and feel like I'm up against something my puny brain can barely comprehend whenever I look through the source code.
Guess that concludes this wall of text, thank you for sticking with it me the end. :)
This makes me want to try playing at that resolution. I hope you get your wish for increased support!
just a matter of turning on "pixels" mode? Forgot how to do it.
setting these cvars:
should make MarkV/Quakespasm closer to what you want, other than the resolution.
Yeah, this is a good request. So to summarize, the ability to render at a res like 320x240, and then scale (unfiltered) to a higher resolution (lcd native res).
It Already Does This
there is a gl version of Mark V winquake which has resolution scaling.
I didn't read the wall of text, maybe I'm missing something?
I tried it and I got a headache :(
I Can Relate
I read the whole text and @killpixel, yes, boristhesp1der did try running Mark V in Winquake mode. But that didn't run fluidly in AD. He's looking for a Winquake alternative that runs AD fluidly while playing in a Winquake 320:240 resolution. This is essentially what you wanted to say @boris?
320:240 is my thing as well, at least when I play the original maps from ID. I use the Mark V Winquake for that because it supports folder-music instead of CD. As for modern maps I use Quakespasm with
gl_texturemode GL_NEAREST_MIPMAP_LINEAR because everybody knows that GL textureinterpolation looks rubbish with Quake's low-res look.
The GL Version Of Winquake Didn't Run Fluidly?
bummer. Well, he could try Darkplaces. HEAR ME OUT.
there's a retro shader for DP floating around. along with that try these:
r_viewscale .5 (or .25)
gl_texturemode gl_nearest force
should give him a fairly retro look until he find a more faithful alternative.
The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse.
This is the way things are going to be so long as MarkV uses glBegin/glEnd code.
In an ideal world scenario: MarkV would move to vertex array and VBO code, the D3D version can be scrapped (because bad GL drivers are no longer an issue once you start coding sensibly to begin with) and better GL ES compatibility would come about as a bonus.
Resolution scaling won't help much with this. It will help with fillrate but with glBegin/glEnd code it would still be pushing the same amount of vertexes and draw calls irrespective of resolution, which is where the real bottleneck is.
Call to action: get on Baker's arse and get the glBegin/glEnd code killed.
Since rendering is the current topic, what are the chances of getting proper transparency depth in Mark V?
It's thankfully not too obvious in my map yet but it is pretty annoying.
@boris - I've been impressed by your ability to self-solve issues (main reason why I am posting since I'm mentally not here, yeah you really impress me). Open GL can't really scale pixels when rendering, although since I'm not AAA+++ in rendering someone may mention a frame buffer trick or shader trick with 6 asterisks next to it.
@pritchard - you didn't state the problem and I'm not level 25 at mind reading, only level 22 although I aspire to be level 25 some day. If it is depth sorting, the answer is yes! because that is on my list.
@mh - "glBegin/glEnd" It kills my soul somehow. I've actually not eliminated glBegin/glEnd for Open GL ES. I created an extra renderer Open GL ES "wrapper" that throws them in VBO. ;-) That being said, yeah I agree in principle. (Insert: I'm probably 6 weeks from doing an update even though technically I have one ready, is there is an update to remedy alpha entity for D3D? No need for an immediate reply, just planning ahead a bit).
@adib - "just a matter of turning on "pixels" mode? Forgot how to do it." --- It's in the video options menu.
@fifth - When Spike sees what I did, he'll fucking hate me. Spike's skill > Baker. Baker's creativity > Spike. I admire Spike. I plan to smoke him a bit. It's not all what your powers are, it is also what you can do with your powers.
@Spike - "oggs" --- In real life, no one has ever heard of an "ogg". It's a technically inferior poor man's mp3 used in a few Quake engines --- no where else in any game or any medium is an "ogg" a format a ordinary user has ever heard of. The mp3 patents have expired. Ogg have no future.
The Unreal Engine doesn't support ogg.
The iPhone can't play an ogg.
The Anroid phone doesn't do oggs.
There is no future for ogg.
The question isn't why DarkPlaces doesn't do mp3. No actually that is the question.
I like it when someone complains about the lack of ogg support in Mark V. When the next Mark V comes out, I expect mega-tons more complaining.
Complaining is awesome. Because complaining is the backbone of progress.
that makes OTP and Shambler the most progressive people on this forum... ;)
Nah seriously, can't wait to see what stuff gets added this year. I agree about Ogg. I used to be a fan when the MP3 patent was restricting people but it's served it's purpose now.
Keen Beer Moment
Yeah, there will be "mega-tons" more complaining.
Because the next release Mark V will be the first true "5 platform" engine. The iPhone/iPad and Android.
And for anyone who has watched any of the videos, yeah Mark V just happen to run on a mobile platform --- it will run fucking awesome on a mobile platform -- in a way no one has ever done.
And it will be a stealth release.
A. Like the past versions of Mark V, I will make nominally a zero effort to promote it. I'm not looking to mainstream Mark V, this engine is meant for those few of us left that enjoy Quake for what it is.
B. iPhone App Store. Yeah, I'm not doing that. Someone with a Mac doing a self-compile and share amongst friends is how that is going to work -- in a best case scenario.
/Six to Eight Weeks Probably a Ground Break Release. Six to Eight Minutes -- my ETA for a beer run. Ill-advised post? Aren't they usually? Haha. Cheers!
Pre-Beer Run: @ Fifth
Shambler is a complainer who has put blood and sweat and intellectual sophistication and effort into his passion. I once got into an argument with Mugwump and he said "You are the opposite of Shambler" and I was like "Well, I hate to say this but I probably agree with him on nearly everything ... my only difference would be that I place a high value on diversity".
/I now resume my end-of-night beer run.
I Often Share The Same Views
but it's usually the way things are said rather than what is said that can be irk-some. :P
I think if you're doing mobile platforms it will be interesting to some but control is definitely going to be the biggest hurdle to overcome.
I Was Going To Buy Myself A Gamesir G3 Bluetooth Gamepad
So another reason to get it sooner.
is there is an update to remedy alpha entity for D3D?
Remind me again of what the issue was? There's quite a bit of chatter about alpha stuff in this thread, with the most recent I recall being depth sorting issues, which aren't API-specific, so I'm unclear on this.
Thanks For The Answers Guys, Really Appreciate It
Kind of a bummer that scaling on hardware is out of the question though. I'm still gonna share the mockups I made though, so you can actually see what I had envisioned for yourself.
I just scaled screenshots from regular mark v down to different "integer fractions" (sounds weird but I don't know the proper term for that, I mean scaling in such a way that the resulting resolution contains no decimal numbers in both axes) of 1334x768 to make them look software-rendered. The result is actually pretty different from the real thing for a number of reasons, the most obvious being atmosphere. Coloured lighting and fog really make a world of difference, and this screenshot alone doesn't even do that statement justice.
In the unlikely case anyone is actually interested in this, I noticed a few interesting things making these mockups. Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software. The skill pillars and everything at their distance looks noticeably worse at 3x in reality because software quake starts to blur out the textures at a certain distance from the player, which is unfortunately not quite far enough away for the transition to happen seamlessly. (Fixing that would be a fun project, eh?)
You'll notice that as the scaler increases, there start to be more versions of the same mockup with numbers attached to them. Those signify how the picture was scaled from the original, which can make a world of difference in the end result. 1 means scaled down in 1 step from 1344x768, 2 means first down to half at 672x384 and then to the end result, 3 means first half, then third, and then end result, etc. Most of the time one step looks the best, but sometimes multiple steps actually preserve some details that would otherwise be lost, like the metal edge on the lower step of the stairs. I also had this anomaly for the 6x scaler where no matter whether I scaled from 1x or 2x, the result was exactly the same down to every last pixel. That doesn't happen in any other scaling scenario. Thought it had something to with scaling from an even to another even scaler at first, but it didn't work for 4, 8, 12, or 24. I used GIMP to scale the whole image without interpolation, so If anyone can explain what happened there I'd be interested to hear.
On somewhat of a related note, and since problems with transparency are hot topic right now, I'd like to present you the following:
Is there a way to get software mark v beefed up to deal with this? I don't know if the crash is actually caused by those transparent textures, but that level (foggy bogbottom) runs (for a few seconds at least) far worse than all the others and is the only one filled with them, so it's probably not that far fetched.
is a feature I wouldn't mind included if it was ever possible. I like the blocky aesthetic
Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software.
Heh, the candles don't change because hardware/software - they change because the candle entity is deliberately set up to spawn a random version each time (they come in many variations of tall/short/thick/thin)
The skulls changing size though is some funky shit - why is that happening?
For what it's worth, hardware resolution scaling is possible. Never said that it wasn't.
You do need render-to-texture to do it with best performance, which means OpenGL 3.0 or GL_EXT_framebuffer_object.
A slower GL1.1 path involves a glCopyTexSubImage call.
The point that I need to be absolutely clear about is that MarkV's bottleneck is elsewhere, so hardware resolution scaling would give marginal improvements to it. With e.g. QuakeSpasm it would be worthwhile for cases that are fillrate-bound, but MarkV isn't fillrate-bound. MarkV is CPU-bound.
Wait A Minute, What Do You Mean By Cpu-bound
Is regular Mark V also rendered on cpu? I just assumed a gpu was a requirement for opengl. So Mark V essentially emulates gpu-features on a cpu? Is that correct? I don't know enough about this stuff...
That certainly would explain why performance is so bad. Apparently my poopy laptop isn't at fault after all, I just tried running those levels in quakespasm and they run at a stable 60. I hadn't even considered that to be a possibility, mostly because my laptop struggles to run just about anything that came out in the last 15 years.
By CPU-Bound, mh means (I think) that the performance limiting factors in markv are operations that are always done on the CPU in all games.
I'm no graphics programmer, but as I understand it, the CPU has to explicitly ask the GPU to draw each frame. If it takes too long, it won't matter how fast your GPU is because it's just sitting idle a lot of the time.
Quakespasm sends it's draw calls in a different way to markv which means that the GPU can always be busy, or at least busy more often to the point where upgrading your GPU will make a difference.
I might be wrong about all this so take it with a grain of salt.
Thanks Pritchard, that explanation seems a lot more likely than mine. The difference it makes on my system is batshit crazy though, that's why I thought it had to be cpu rendered. While mark v sometimes dips down to less than 10 frames in busy areas you won't even notice as much as a hiccup in quakespasm.
I guess I'll have to switch engines for now, I'm gonna miss you zoom button... :(
Pritchard has the right of it.
When drawing objects, every single component of every single vertex has CPU overhead in MarkV that doesn't exist in QuakeSpasm.
For any given scene this overhead is based on the number of polygons and number of vertexes in the scene, so it's fixed irrespective of resolution.
Small scenes - like in ID1 maps - are barely affected, which is why it won't be noticeable if all you ever do is e.g play DM3.
As the polygon count goes up the overhead gets more and more.
Baker what features and stuff do you think you might want to implement in Mark V's next release?
(Crazy and Stupid) Ideas:
Atleast try to support orl's Zeangala map or what ever its called.Who knows,someone might make an adin1 like bbin1
Create feature like in reQuiem
(Might need to check this one)
Music command like in QuakeSpasm
Some proper coding!
So far I know 4 coders doing engine stuff
Re: Post #1504
Does anyone know why the skull models change size between the different resolutions? That's some crazy beans...
Sort of, at least. In a proof-of-concept way.
The video makes it look pretty crappy and stuttery, but it actually runs and feels awesome. The only real downside to this method is that you have to be incredibly careful not to make any sudden mouse movements, that causes the borderless window to stop capturing the cursor for a fraction of a second and the magnifier will register that movement, jerking the viewframe in whatever direction you happened to be aiming.
Keyboard aiming it is then! I can handle that. Probably.
That Looks Mighty Sexy
You could always use a joypad?
So you mentioned that 4-player splitscreen is a thing you want to implement in the future? How about 4-player splitscreen that also allows people to join from the internet?
I have been playing a bit of the remastered Turok 2 from Nightdive and this has the same feature. It's a good way of getting people online and playing!
You could always use Audacity or any sound tool to export to mp3.
... is also good at that: I created some custom sounds and background loops a while ago with it.
It is not a freeware, but it has a lot of interesting features.
Feature Suggestion For More-legible Text
How about a Text Contrast adjustment that will only affect the text (maybe like the texture baked-on gamma/contrast).
The dull text can be hard to read in front of all the other dull colors in Quake.... I don't want to universally ramp up the contrast for everything, so it would be nice if I could just adjust the text contrast alone.
Kustom Conchar, Hudnum, Conback
I was running an ancient version of dp then fte before mkv. in those I was using a conchar file that had black outlines and cleaned up characters, the diamond grip numbers, and conback from qtest. I had obtained these from gfx.quakeworld.nu quite some time ago all for clarity and legibility sake. Is there any way to have mkv load external wad assets, or does it perfer certain fyle tipes such as pcx?
Mark V only supports .tga, uses the DarkPlaces way of naming replacement textures.
For instance, throw this file in quake\id1\gfx folder (conchars.tga).
Random comments: Gunter should be using a custom charset ;-) He could adjust the contrast in an image editor and self-serve.
If your custom gfx are in .lmp format:
DP/FTW will use a loose id1/gfx/conback.lmp (conchars, etc.) in preference to the one in id1/pak0.pak, but vanilla engines including MarkV require you to put them in a pak file (e.g. create a pak2.pak) in order to override the stock ones.
Everything was in a portable network graphic format so I just used gimp to patch them over to targa. I also increased the color saturation levels of everything and added black borders to the hudnumbers as well. Another thing I noticed after this was if you disable the start demos it just dumps to console, is there any way that it could pop the main menu up as well? I also saw a sort of custom start demos command but I couldn't get it to operate.
Akira, just put "menu_main" at the bottom of your autoexec.cfg file if you want it to pop up automatically upon game start.
Wow, that custom conchars.tga is definitely high-contrasty-more-legible in the game... buuuuut it doesn't look like Quake, heh.
I guess I can mess with the contrast and make my own custom conchars, but it would still be nice to have such a feature built in.
edit: what you CANT see by that image is that the characters have a thin black outline around them.
Unless I selected the wrong file. Or just look in Qrack's pak0 for charset-3.
Not bad... (had to convert to TGA for Mark V, but it works). That's more Quake-like than the one Baker linked, but I'm very picky in that regard, heh, and it's still not quite right.
I came up with this one by just ramping the hell out of the brightness/contrast so the text really stands out, but it's otherwise still the original Quake characters: http://fvfonline.com/conchars.tga
Just a heads up, Baker. Looks like the cvar scr_clock still allows the game time to be drawn when set to -1 if playing DM (it does disable in SP).
Wouldn't normally bother me but it overlays on top of the player colors (the mini-scoreboard when viewsize is set to 120).
EDIT: sorry, I meant when viewsize is 100 or less, in regard to the above post
Using The Dx9 Render
I've come across a few bugs. The first one is in mutiplayer the ping command doesn't seem to work, I tried ping 100 and ping +100 but I don't see any changes on the scoreboard or latency. It seems to be in there though as it doesn't come up as an unknown command. The second is single player that when you die and instantly hit space to respawn your view remains sideways, I'm not sure if it has any relationship with quicksav or being splattered. The last one I've had happen a couple times first on some map from 1996 then in ad monsters spawned like brushes I was using quake injector.
1) There is a loadgame + death bug reported by Pritchard. Will be fixed in the next release (already fixed in unreleased code). Results in the deadness issue you outlined above after loading a save game.
1) ping +x is not supported (ability to lag yourself). Feature exists in ProQuake/DarkPlaces/Qrack, but adds some complexity/ugliness to maintaining the network code. Possible it may get added at some point.
is there any portal culling for VIS like in DP?
Doesn't have such a feature, which AFAIK is intended for real time lighting.
Arcane Dimensions quake.rc has r_useportalculling 0 and Map Jam 8 users needed to turn off r_useportalculling to avoid issues with DarkPlaces.
Arcane Dimensions finds it necessary to turn off r_useportalculling in the quake.rc file for gameplay or visual compatibility reasons.
yeah, "r_useportalculling 2" breaks map if you have some Warnings/clipped portals during VIS. It's very annoying, but 50% of fault lays on mappers side ;)
I was just curious if there are any VIS improvements in your engine, or do you plan any?
As we know VIS in Quake is very primitive and does it's job poorly, so you have to do tricks etc. to limit r_speeds.
The idea the engine would do the same thing as vis (which can take untold hours to run in some circumstances), and do it better and do it instantly on map load doesn't make sense.
I'm just saying ... if the engine could do that, why wouldn't you take those calculation and throw them into the vis tool instead?
Yes Quake vis sucks terribly, especially at open maps. Kills frame rate, makes demos huge --- like the 10 GB "I played Arcane Dimensions!" demos, makes QuakeC slows, makes map uncoopable with enormous network traffic.
The correct solution is improvement of map compile tools.
/Maybe you should get together with other interested parties and raise a $2500 bounty and try to induce someone who writes tools either in Q1 or in Q3 or at id Software or for another game engine to get Quake vis right or vastly improved.
/One idea. I'm often wrong about these kinds of things.
I agree Baker, the only problem with vis, IMHO, is the thing where certain uses of func_detail can cause vis to see through your map where it shouldn't. I'm not sure exactly where the problem lies (qbsp or vis) but I'm sure it's fixable.
Unless the problem I mentioned leads to exaggerated PVS in AD maps in a lot of places, vis is not really to blame for large demos in AD and the large unreliables, that's just the particle system based on entities and lack of use of static entities combined with protocol 666.
Yeah, my main complaint are open spaces. I know how to optimize vis for indoor maps.
I did hedge maze and of course everything is rendered, because of open space above it... I'll have to add some obstacles to separate sectors better, or try some hint brushes, but I think hint won't help in this case.
Best option would be occlusion culling like modern engines do, but of course it's impossible with BSP.
Anyway thanks :)
Btw. how different is Q2's VIS? (except doors blocking it) and how much we can borrow without a need to upgrade BSP ? :D
ericw, you've done awesome work with the tools so this isn't directed at you. It isn't your responsibility to fix vis. You are a volunteer. This isn't a reflection on people that do the great work on the tools.
But yeah ...
vis is certainly to blame. It is supposed to block faces and entities from being drawn. That includes things like AD particles.
/I don't like thinking about it because it is very disappointing. Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.
Dead horse, I don't wish to beat it. I won't be bringing up, and I didn't raise the topic this time either.
Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.
Yeah but I haven't brought it to blame you guys, but to ask if there are some better solutions on the horizon and what can we do to improve this situation.
I saw that Mark V has some nice features, so I thought I'll ask if there are some features supporting VIS...
Speaking of raising a bounty I'm in, but...
Considering I'll give $100 I'll have to find other people willing to pay $$$ to get $2500 in total, which probably is impossible, so I think it's time to finally dive into code and see what we can do in that matter.
Nah It's Cool
Reporting problems is only a good thing in my book.
Wow, ad_mountain's vis looks really broken. Assuming the player was in-bounds and then you used lockpvs and noclipped outside?
The ARWOP screenshot doesn't look too bad to me.. assuming the player was at the start position when pvs was locked? Also I am 99% sure ARWOP predates func_detail being used commonly so it would be immune to the bug that can cause total breakage (vis seeing into entirely separate areas).
The last one of ionous/pulsar's map, I'm not sure there is much unneeded stuff, that's a big open arena type area.
Another point to remember at least with Quakespasm, it has the anti-flickering patch so if an entity exceeds MAX_ENT_LEAFS, the server will always send it. So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render, and it'll look like VIS messed up but it's just a server quirk.
So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render
Yeah, I wasn't trying to draw attention to the bmodels.
Although those aren't Quakespasm screenshots Mark V uses the same mh/spikey solution.
@kreathor. Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch (files on the Mark V page).
Mark V supports sv_cullentities 2 -- which on poorly vised maps can cut-down on network traffic substantially and (sadly) increase rendering speed.
sv_cullentities from essentially borrowed from FTE (although I may use R00k algo?) and DarkPlaces has a similar feature.
It also has r_lockpvs and r_lockfrustum borrowed from DirectQ which mh said he borrowed from Quake 2.
I think I mentioned before that there should be some kind of brush that mappers could place that allows more freedom over culling.
Unreal Engine used to have "visibility culling" that you placed a brush to give hints for vising purposes. Maybe Quake has something similar (is this how hint brushes work??).
I would assume that if they're supported at all, hint brushes work like described here:
I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile.
Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch
Thanks, I'll have to check this feature out
I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile.
If you do it correctly then yes. Problem is if you have big open spaces, then it won't help you much... although in my case I used it to cut portals behind big building standing in center of open space.
I like this "tutorial". Explains it properly:
What did more modern engines such as Source do to improve their VIS? Half Life 2 has plenty of huge open spaces that run well.
Half Life 2 (Source) is using PVS and occlusion culling for outdoors.
So how is PVS (Potentially Visible Set) different from VIS? The Valve Dev wiki describes PVS as a collection of visleaves which might be visible from a given location. Isn't that just how VIS works?
VIS is just a tool/process of creation of PVS, so to be 100% correct with nomenclature, we shouldn't use it to describe PVS ;)
Anyway we are OT a little, maybe we should move with this conversation to Mapping Help, before Baker gets mad :P
Old Mirror Control Complaint
I needed to look at a modified FvF player model in a mirror today, but could not do so because Baker took away the mirror control from the user....
"The Id1 Mirror Texture Only Works With Id1 -- It's Intended Behavior
if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell ... "
But r_mirroralpha is a user-controlled variable, and if a user wants it on, it should be on, no matter what mod they are running. It should also be defaulted to "off" ("1"), so if it IS on, then it's definitely intended to be on.
I had to load up FTE to look at myself in a mirror in FvF, and even that engine wouldn't let me activate it in Multiplayer mode, telling me it was a cheat. Boo! (I'm the server operator -- I am the one who should decide what is or isn't a cheat on my server, and I don't feel mirrors are a cheat). But at least I could use mirrors to look at the modified player.mdl in FTE Single Player mode.
I dislike when engines decide for me what settings I am allowed to use in what modes.
I may end up coming up with a method to allow a gamedir mod to enable that as choice.
Does Mark V supports scrolling textures? What's the name convention?
Yeah, type "find scroll" in the console.
It's only in the GL build.
sv_cheats 1; restart;
then you can do whatever you want.
and so can other users on your server, so have fun with that.
unfortunately nq doesn't do serverinfo, so that'll only work with an fte server.
use mirror_* for mirror textures in future. those should always be mirrors, and need not be considered cheats. window02_1 on the other hand is present on many maps, and in many of those it potentially exhibits serious graphical glitches that allow it to act as a wallhack or whatever. so yes, its generally considered a cheat unless the mapper explicitly intended it.
for similar future needs, you might want to consider using chase_active or equivalent (most engines support it to some extent), or maybe try fte's splitscreen.
its generally easier to look at it from other angles then.
His server coops existing maps. He doesn't have any choice in what the texture names are so he doesn't have the option to change the texture names to mirror_ *
I've tried to test it by entering "r_texprefix_scrollx wizmet", but it didn't work. I'm using the version 1.36.
That feature was slated for removal, looks like is broke. I probably was working on mirrors and removed it, but forgot to nuke the cvar and friends.
It works in this ancient build binary + source
The reason that feature is slated for removal is largely because:
1) I can't imagine a scenario where it could be turned into a standard.
2) This method has no ability to control the speed.
3) You can do animated textures in maps using the +[texture name] animated textures method in regular Quake and it works on everything, although it is jerky and has a 10 frame limit.
4) Low interest in porting scrolling to WinQuake, hehe.
There's also probably better ways to do it too.
Was a nice experimental feature back at the time, I just wanted to see what it would look like.
Retroquad uses the [
characters to prefix parameters for scrolling.
The first of them in the texture name indicates horizontal scrolling. The second one indicates vertical scrolling, and it's optional.
The second one must be followed by a number indicating the speed. The first one only must be followed by a number if the second one is omitted.
If the speed value is omitted in the first one, both will use the same speed:
horizontal scrolling, 1x speed
horizontal scrolling, -1x speed
vertical scrolling, 1x speed
diagonal scrolling, -1x horizontal & 1x vertical speed
diagonal scrolling, 1x horizontal & -2x vertical speed
Retroquad's texture naming parser can also recognize parameter prefix characters anywhere in the texture name, allowing for multiple effects to be combined. The water in this video
uses 20 textures named from *watersa]0]1+00
. The parser reads it as:
it's a water texture
the texture's individual name
zero vertical scrolling
horizontal scrolling at 1x speed
animated frame index
The only thing I couldn't decide is whether the speed value should be in units per second or in loops per second. In the first case, big textures would need big numbers to fully scroll, and in the second case, small textures would need fractional numbers to scroll slowly. However, the first case also makes it easier to sync multiple scrolling textures with different dimensions.
The reason for all these is to make texture naming as economical as possible while still being flexible, since vanilla Quake only allows 15 characters per texture name.
4) Low interest in porting scrolling to WinQuake, hehe.
Getting it to work properly in the software renderer takes a lot of work, so it's understandable.
A cheap way would be to scroll the texture per-texel in the surface cache. WinQuake uses a similar method to scroll the sky overlay, which is why its movement is so jerky. This would only look good on fast scrolling textures, but at least it would work.
Your video certainly looks very nice.
By the way, Retroquad animates sky & liquid texture frames at 15 fps, rather than the default 5 fps of regular animated textures. Alphamasked "fence" textures are animated at 20 fps. This was hardcoded just for that demo, but a standard for custom timing of texture frame animations would also be a good thing.
However, the 15 character limit for textures makes it a pain to add more customization. The name "*watersa]0]1+19" is 15 characters long already, and even if we remove the "sa" characters from it, there would be no room to define a 15 fps interval, which would require a special character plus two numeric characters (e.g. *water]0]1+19,15).
By the way, sorry for hijacking the thread, but I'm just trying to encourage more coders to implement such features, and maybe define some standards for them.
Engine issues and engine support of mapping enhancements are always on-topic. Not sure what you are apologize for.
Your results look nice and are smooth.
It seems wrong to put the timing in the text name, yet with Quake we do water, alpha masking, animated textures, etc. by the name .. so ...
The naming convention you are using seems quite sensible.
In my config file, I use:
...just for the nifty effect (scrolling EXIT signs).
Though in some places where the mapper uses the texture somewhere else (like the start of terra4) it looks... odd. Like only the fullbright part is scrolling, and not the rest of the texture. Not that I'm complaining -- I like experimental features to play around with (as long as they default off!)
And yeah, I used chase_active, but I wanted to see myself from the front too. Mirrors were (well, they should have been...) the quickest way for me to do that, heh. I did not know about the various FTE features (splitscreen, eh?).
Oh, something else....
I found that my player.mdl in \fvf\progs\wasn't even loading in Mark V, because there is a player.mdl in the fvf pak0.pak file.....
But the replacement player.mdl did load in FTE when running FvF.
I believe, no matter what the original default was in this case, that if a user has replacement content in a folder, unpacked, it should override anything in a pak file.
FTE seems to have made that choice, and it's a good choice.
I remember the complaints about "toxic settings" in an autoexec or other file inside a PAK file, and how that completely takes control away from the user (and placing those settings inside a pak is like the worst case scenario). Well, giving preference to any unpacked files, rather than what's in a pak file, would fix that issue too.
It seems obvious that if a user places some files into folders in their mod/id1 directory, they want to use THOSE files rather than anything that might be in a pak. And a pak is the hardest thing for a user to actually modify... so it's hard to work around.
If You Don't Like Mushrooms, Don't Order The Pizza With Them ;-)
Is your current mission to make FvF no longer work with traditional style engines?
If you want the best of both worlds, do what Arcane Dimensions does and simply not use pak files at all!
Then you won't even have the issue you are describing, haha ;-)
Do you see what I mean? You are mixing pak files and free standing files, but no one is making you use pak files at all! That's a choice.
The logical thing is to not use pak files if you don't like Quake's loading order.
Sock never has this problem because he doesn't use pak files.
All you have to do is make a FVF2 folder with everything unpacked, and you can play around as much as you like.
You could be living the high life in 5 minutes!
It's not an FvF issue. It's a Quake issue.
The same problem exists if someone wants to use a replacement model in their id1 folder. The pak file overrides the unpacked replacement stuff, and that's not what should happen, because if a users puts a new model in his id1\progs folder, he WANTS to use THAT one. Why make it more difficult for him?
Would your suggested solution here also be to unpack all the id1 pak files, then remove the pak files, so only the unpacked files exist in id1, so a user can then use replacement content?
Or make them run a separate mod just for 1 replacement model?
What a hassle. FTE does it correctly, in my view, and allows the user-content to take precedence. Can you explain why is it better for pak files to take precedence? They are the most difficult for the user to modify. I can understand why they may have made it that way back in 96 -- maybe they didn't want the user to be able to easily mess with Quake.... But we are way beyond that now. People created programs to get to the goodies in those pak files. There's no reason to make it so difficult anymore for people to drop in replacement things.
When a mod has a lot of files, sticking then into a pak file is the most convenient and tidy way for a modder to package the mod. If a modder chooses not to do that, it may be for the very issue I'm describing here!
Of course a pak file does take control away from the user, though, which is mostly fine, because that's what mods do -- they change stuff. But then if a user WANTS to change something himself, it would be nice if he could easily do that -- like in this case, if he just wants to replace a certain model by dropping it in (a player created a new player.mdl just for FvF).
giving precedence to unpacked files
pros = More convenient for the user to drop in replacement content. Protects against toxic settings in a pak file overriding user cfg files.
cons = None ?
giving precedence to pak files
pros = None ? Slightly helped id keep Quake from being altered back in 1996?
cons = prevents easy drop-in replacement content. You have to use a new pak file instead. If a mod contains toxic settings in a pak file, there is no way to prevent them from being initialized.
Am I missing something?
If files in a folder override pak files, why have the pak files at all?
Quake for 20 years has had pak files have the precedence.
FVF is fully under your control. If you don't like the behavior of pak files, do them free standing files like Arcane Dimensions.
Arcane Dimensions, because it uses no pak files, doesn't have the issue.
If you don't like the behavior of pak files with your mod, then don't put the files in a pak.
1) Doesn't require anyone to do anything.
2) Compatible with every engine!
...Quake for 20 years has had pak files have the precedence...
To me this reads as:
...Quake for 20 years has done things the wrong way...
It seems pretty obvious to me that whatever is included with the game (pak0.pak, pak1.pak) should be overridden by any new content.
It's 100% true that if you really want to solve this problem in your own mods which use their own folders, you should not use .pak files. There's no changing the way that some engines will behave at this point.
But why make using them so difficult in engines which are under active development? pak files keep things neat and make it harder for unwitting users to break your mod and so on, but the penalty a mod author incurs when using them is unnecessarily great.
Where do you stop?
DarkPlaces loads every single .pak file found in a folder. And loads .pk3. And loads the pak files in alphabetical order. And supports a rainbow of file format from .tga to .jpeg to .png and probably others like .dss. And a rainbow of model formats.
Others want things simple.
Like the Quake way.
Spike will say with pride that FTE loads external replacement textures from, I believe, 132 different possible folders -- supporting all the various replacement texture schemes. There are also different replacement model schemes.
A conservative engine wants 1 folder where something goes and one set of rules where that set of rules = QUAKE.
There isn't a right or wrong. Just an approach.
A conservative engines wants to stick with simple.
For every one person who wants something done one way, there's going to be five others who want it done five different ways.
The only thing you get by asking multiple people is multiple answers.
The closest thing to any kind of community consensus is "do it the way [Popular Engine X] does".
Gunter in particular has a very bad habit of "what I want for my mod is more important than anything else", then causing drama and outrage over it. I'm not certain that's useful feedback.
Quake already has an established way of allowing standalone content take precedent over pak files - put it in a gamedir of it's own. Multiple gamedir support is trivial to add to engines (and far more useful than arguing the toss back and forth over things like this).
A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy.
The PAK file precedence is part of Quake's copy protection. One of Quake's selling points was: if you want to play custom content, you must buy the game.
PAK0.PAK has its CRC value verified by the engine. If the proof-of-purchase file (from PAK1.PAK) isn't found in the path, Quake refuses to load anything but the unmodified PAK0.PAK file, which contains the shareware episode.
The PAK file precedence also served to prevent users from creating custom maps using the same names of the original maps and complaining that the original maps didn't work anymore... And to prevent users from going full "FreeQuake" and replacing the episodes 2-4 with custom maps.
id Software already had people selling shareware Doom CDs full of custom content, and they decided to prevent that from happening to Quake.
Cracked Quake Torrent When?
Is there any particular reason why this behavior should be continued today in engines, aside from respecting id's desire to, y'know, actually sell a game and make some money from their hard work? In the modern world of filesharing, it's such a lackluster form of copy protection that it may as well not be there at this point.
DarkPlaces has its own set of special rules for content, which you have to learn. Many modders for DarkPlaces struggle to make Quake compatible mods because they have habits that don't work with Quake.
(you Knew This Was Coming! :D)
"Where do you stop?"
You stop at making unpacked files take precedence over pak files. That's it. Don't use a fallacious "slippery slope" argument like, "but if I make a reasonable change, then I'll also have to make every unreasonable change everyone else wants!" This has nothing to do with supporting all the formats Darkplaces or FTE uses. You still haven't explained the benefit of leaving it "the way Quake has done it for 20 years?" That's not a reason. How many other non-optimal Quake behaviors have you already changed?
"It's Quake. For every one person who wants something done one way, there's going to be five others who want it done five different ways."
Well, so far you've got more than one person wanting unpacked files to take precedence, and NO ONE wanting it the other way, other than people just saying, "that's the way it has always been" without providing any benefit for that approach.... How many other non-optimal Quake behaviors have you already changed?
Will anyone step forward and say they prefer pak files to take precedence, and give an actual functionality reason for that?
"Gunter in particular has a very bad habit of 'what I want for my mod is more important than anything else', then causing drama and outrage over it. I'm not certain that's useful feedback."
Oh, bite me, mh :P
I just said this isn't an FvF issue -- it's a Quake issue. This would be better for everyone. I have laid out my actual arguments for why, and you have not provided a single counter argument to support your position other than, "I don't like when people want different things and I don't like Gunter because he always out-argues me" ;)
"A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy."
I completely agree with you, mh! But that supports my (and others') position in this case that the behavior should be changed, because it would indeed be a general solution that would be useful to everyone!
I am dramatically outraged that you would think otherwise!! :D
Can you explain who it's useful for to leave pak file preference in place? Modders who want to inflict unavoidable toxic settings on the user?
I'm aking the same question as Pritchard here, "what benefit is there to keeping this behavior?"
Nobody is answering except to say, "it's always been that way and I don't like the complicated things Darkplaces does."
We're not taking about Darkplaces. We're talking about this ONE behavior. That's where it stops (in regard to this issue). This isn't a change that's going to cause any compatibility problems either....
Please describe the benefits of pak file preference. mankrip did a pretty good job of describing the benefits id saw back in 1996.... Now what is the benefit in the modern day? Isn't the whole point of engine development to improve on the original things that might not have been optimal for the users? I mean, why didn't we keep id's original network code? ;) Would it still serve any useful purpose today, or would it just make things more difficult for the user?
In regard to why I, as a mod author, use a pak file to distribute the FvF client files? Because it's the most tidy, convenient way to distribute a mod, instead of using multiple files and folders. AND it also keeps the user from easily being able to nose around in the files to swipe them for their own use! Heh. So yeah, a pak file still serves as a slight (very slight, really) deterrent for pillaging my content, however, I don't mind if the user wants to use other replacement content on top of mine, and I see no reason to make that a difficult process for them.
Again, this isn't just for FvF -- it's for anyone who wants to use replacement content for Quake with or without mods.
If you're looking for some form of consensus, why not run a poll on Quakeone? Then maybe someone would give an actual functionality reason for preferring pak file precedence....
You are new to a discussion about this topic.
I've read or even participated in this same exact discussion 6-8 times, including a couple of times at Inside3D and a couple of times at QuakeOne.
I used DarkPlaces before I ever engine coded and experienced firsthand the pros and cons of the functionality. I also like DarkPlaces as a total conversion engine and both Mark V, and before it, ProQuake acquired several gems from DarkPlaces.
It is safe to say my opinion of that DarkPlaces feature is due to knowing a lot about it works.
Typically, the those arguing for the DarkPlaces way of doing things is inexperienced with using the the feature, and unable to describe the downsides because they don't have the experience to understand the other side of the coin.
And perhaps I'll try to explain again. But probably not today.
Seems like no one is reading or making an effort to understand what I am trying to communicate in my replies.
I may be typing this post just "for fun" as it seems the other ones went unread.
But I hope it does get read ...
OK, I'll bite.
The upside of having loose files take priority is that the user can easily replace PAK file content.
The downside of having loose files take priority is that the user can easily replace PAK file content.
Think about that - and if you don't have a Zen moment when it becomes clear, you haven't thought about it enough, so think about it some more.
This isn't just about copy protection, it's also about protecting users from malicious (or just plain old badly designed) mods and from themselves.
Whether you like it or not, the way Quake has done it for 20 years is the EXPECTED behaviour. Mods are made and released on the assumption that this is the way it behaves, experienced players run Quake on the assumption that this is the way it behaves, experienced players help out struggling newbies on the assumption that this is the way it behaves.
If it's in a PAK file it takes priority. This isn't about advantages of one vs advantages of the other. PAK files taking priority may even be the inferior option but that doesn't actually matter (I have an opinion too but it's irrelevant). It's about what everybody expects to happen.
You may have a different expectation but don't be so arrogant as to presume that your expectation should overrule 20 years of everybody else's experience.
The way Quake works, if you have a mod with a pak0.pak in the folder (let's say -game zer) you have 100% assurance the mod will behave properly.
With the DarkPlaces way, a user will say "I don't know what is wrong? I have pak0.pak in place, but some weird model is showing up!"
Later they will say ... "Oh, sorry. I was doing XYZ and forgot to delete it."
The DarkPlaces way takes away the security of knowing a pak file containing a mod is a complete and full assurance of proper installation and running.
I should add.
I do understand your frustration to a certain extent. I am the person who fought, and lost, the stuffcmd wars a few years ago, and stuffcmd is actually potentially dangerous to your PC, never mind just being a squabble-fest over file loading order.
just stop using paks. you complain that paks taking precedence makes it hard for users to replace files, but you forget that any paks make it hard for the user to know which files they need to replace (and the form of that data too).
that's not to say that I agree with Baker, frankly I see his argument as user-hostile that further discourages people from grouping their content thereby making it MORE likely that people will be stuck with content that they forgot to delete on account of not being able to separate it so easily.
quakeworld downloads often REQUIRE files outside of paks, or at least maps.
The singular exception is when you have md3s or q3bsps that depend upon shaders and external textures that the client won't know to auto-download. In these cases, pk3 is a superior format that offers compression and is easier for people to open. Essentially, such content should be treated basically like q3 content is treated. But until then, just don't use paks.
PAK files also serves as a versioning system.
If your mod is fully contained in a PAK0.PAK file, you can make an update for it by storing the updated files in a PAK1.PAK file. And then, you can revert to the previous version by simply removing the PAK1.PAK file. I've actually done this in one of my mods, because it gives the advantage of knowing that the PAK0.PAK will likely always be the same, no matter the version of the mod.
Loose files doesn't use a cascaded versioning filesystem, so they require you to remove all previous versions of the files, which makes it impossible to rollback a bad update.
Anyway, a command-line parameter to control the precedence could be nice for development purposes.
Why Is This Getting So Much Attention?
Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual.
We are reading what you write, Baker, but you're just talking vaguely about Darkplaces. I don't use DP. I just happened upon the functionality in FTE, and I liked it -- actually, I didn't even realize it was different; I just knew that FTE did exactly what I wanted/expected it to do -- it used the player.mdl file that I dropped into a folder.
Now you're saying that pak files are good because they let the modder know 100% that the mod will work for the user, but you've previously been talking about how Arcane Dimensions installs everything unpacked, so it doesn't have the issue of pak files overriding user content.... It's like you're telling me I should do it two different ways! Why can't I have both the convenience of putting my mod files in a pak to ensure easy/correct installation, and also have the ease of letting more tinkery users drop in their own content if they want to?
Sure, they might mess things up, but this is the same issue as any other piece of software you give to a user. The user might mess things up. If they do, they can just delete and re-install the thing....
What I'm now hearing from you and mh is, "protecting the user from himself."
Like if the user installs some replacement content, then later derps out and forgets he installed some replacement content, and can't figure out why there is replacement content in his game....
Would not the same thing apply if he were using extra pak files?
Is Quake 1 really a game for derps? Is that the kind of user you are designing Mark V for?
Everyone derps out sometimes, but unpacked replacement content would still be easier for a derp to find/remove than stuff in a pak file, because it's all easily visible unpacked. In a pak it's hidden.... "What is this pak4 thing I have in my folder? I do not know. And why is my player model so weird?" vs. "What is in this progs folder? Oh, there's a player.mdl in it. Oh! That's why my player looks so weird!"
So, mh says for both pro and con, "it makes it easier for the user to change things."
I don't know why you're not having a zen moment about that yourself.... You strike me as the kind of person who would use linux because you'd hate Microsoft always "protecting you from yourself" and not allowing you to change things you want to change.... This reminds me of an old commercial: https://youtu.be/FxOIebkmrqs
So do you think it should be easier or harder for a Quake user to change things? Apparently "harder?" So you're a Windows guy, eh? :D
(I'm actually a Windows guy myself, but I'm a superhacker, so I make it do what I want ;)
Ya know, the whole reason that Quake is still alive after 20 years is because it was relatively easy for users to modify stuff.... Zen moment? Should it be easier or harder for users to modify stuff in Quake?
You also throw in that it's about protecting from malicious/badly designed mods... Uh, isn't that backward? Unpacked file preference would help protect from bad mods, because the user could easily see/change unpacked files or replace stuff in a pak file with their own stuff (a bad autoexec in a pak file, for example).
As far as "expected behavior," well, it's "expected behavior" (how it has "always" been) that you must put the Quake CD in the drive to play the soundtrack. But now we can drop mp3 files into a folder and play the soundtrack.... That "expected behavior" was changed to make it easier for the user. This is the same concept: let the user easily drop in files for Quake to use. Should we not allow that because some derp might drop in the wrong mp3 files and then wonder why Ace of Base is playing when they start Quake? :D
And I have to ask, "expected behavior" of whom, really? Certainly not any new players, or other people who have never messed with this stuff in detail. Heck, I don't regularly mess with it in detail, and I actually expected a player.mdl to be used just by dropping it in a folder! Then I was like, "Wait, why is this not working? Oh crap, the pak file overrides it."
So I ended up having to stick my single replacement model into a pak file.
What a hassle. I can't imagine that's good for anyone, no matter what they expect.
And being that many experienced users will be using other engines like Darkplaces and FTE, well, their "expected behavior" would not conform to the 20-year-old way either.
So maybe some old Quakers are "expecting" it, but I bet if you gave them the option, they would prefer it to work in a different, more convenient, way.
Actually, Baker, if you have links to the multiple discussions of this issue you've had in the past, I'd be glad to look them over to see what else I may be missing.
mh, I'd probably be against you on the stuffcmd issue, heh. It is a useful tool for modders -- aure, abuse is possible, but I use it to bind the FvF chat impulse so players lower their gun and blow smoke while chatting. But I think Mark V has some cfg protection for stuff like that.
"just stop using paks."
Sounds so easy, but in practice that means I'd have to completely unpack my id1 pak1 and pak0 files. That's a mess of files! (I'm not just talking about my mod, but every mod with a pak, and also standard Quake.)
And just because I might want to use a replacement player.mdl ?
Heck, it's actually easier to complain a lot about it and hope Baker might consider changing it ;)
(But really, it's not just to make things easier for myself, but for other people as well).
Low Brow Vs. High Brow @spike Mostly
There are low-brow engines and high-brow engines.
Low Brow Engine - Your TV remote has 4 buttons (Mark V)
Favors an uncomplicated and reliably smooth and enjoyable experience and will sacrifice options, capabilities and preferences to get there.
Assumes the user knows nothing, has guard rails. Caters to the user that knows nothing -- protects them. Most features are obviously exposed, few features beyond core feature set.
When no one has any questions or problems, the Baker feels like "Mission Accomplished!" It's reliable and intuitive!
High Brow Engine- Your TV remote has 106 buttons (DarkPlaces/FTE)
Caters to advanced users. Plenty of settings. Plenty of capabilities. Support for cutting-edge techniques. Boundless depths, options, abilities.
Assumes the user knows everything and caters to the user that knows everything. Has layers and layers of features beyond the obvious ones.
When a user has something sophisticated they want to do and realize that FTE can do it, Spike feels like "Mission Accomplished!" It helped someone with sophisticated needs execute their idea!
(This is why Spike and I seem to argue a lot about some things, but agree about others.)
"Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual."
I've laid out clear, concrete reasons why it "makes sense," which have nothing to do with my whims.
And I'm going to count at least 3 people here that might prefer it the way I am advocating for. Make that 5:
mankrip (for a command line parameter to allow the option)
And I will count:
(their creators obviously preferred this functionality)
You see me arguing for it, but I am arguing as "the user" and not just for myself. This would make it easier for every user.... It's just that every user doesn't read this forum. Do as I have suggested -- make a poll on Quakeone where there are more users, and see what everyone else actually thinks.
Count me in with mankrip re: the command line switch to change the behavior. Why not give the user the option? I don't see the downside.
I hadn't really considered the "versioning" aspect of pak files, but it certainly does make it easier when, on the rare occasion, I update the contents of the FvF client pak file, to know that all the user will have to do is replace their pak file with the new one and they will be correctly updated. If I were handing them the mod as unpacked files, that could be messy and tricky if I ever removed some of the files.... I'd have to give special instructions to delete certain files during the copying of the new files.
So that's another reason why I use a pak file for FvF -- easier/more foolproof updates for the user.
And I too would be happy with a variable to alter the file/pak precedence. That would still make it easier for people, because I could tell them, "you need to set this variable to let your replacement model work correctly."
A command line option doesn't seem objectionable. I'll consider it without making a promise as to when.
So it is very likely to happen, unless it somehow interferes with something else. Which doesn't seem likely.
Having the option available would be nice, there are sometimes it is nice to change things on the fly easily.
I just don't like that as normal default behavior.
Excellent. Thanks for considering it.
I'd also hope it will includes a console variable for easy setting, even knowing that would be something like, "this setting will not take effect until you restart Quake/the map/whatever is required."
I wouldn't dare suggest a menu setting, knowing how much you hate menus ;)
But then again, a menu setting would make it easy for the low-brow derps who Mark V is intended for!
*Throws an FvF ninja bomb and runs away*
I Wouldn't Have Submitted
I'm disappointed Baker.
Nice denial of service you have going there.
You see Gunter - you need to think beyond what you immediately want.
Yes, I already agreed that abuse was possible. I just said so.
But do you remove all the potential valid, good uses of the command because of hypothetical bad uses? (Has your example ever actually been used in a mod?)
Hey Baker, I think mh is asking you to prevent screenshot from being used in a stuffcmd!
Mark V already protects your cfg file getting messed up by stuffcmds.
I can't think of a legitimate reason to allow stuffcmd screenshots.... So that's something that could be prevented.
But removing the whole stuffcmd functionality would be throwing out the baby with the bath water.
There's no simple way to implement a cvar for it, because config files are only loaded after the filesystem is initialized. It's impossible to make a cvar change the filesystem initialization behavior.
Now, if such a cvar would be used to change the filesystem behavior on the fly, that would open a can of worms, specially on engines that supports changing the game directory on the fly: Set a mod dir, change the precedence, and add another mod dir; the precedence of the previous paths gets screwed.
And that's why you wouldn't make a good engine coder.
In the end, Baker is interested in improving his engine for the users, and not just winning an argument for the sake of winning an argument.
Actually, that's why I post here too -- not to "win arguments" but to improve Mark V for the users, of which I am one!
My ideas of what might be an improvement may not be the same as other people's ideas, so we argue about it, but it is not personal, not even with mh for me (he's done great things for Mark V), though sometimes I can't tell if he gets caught up in just wanting to win the arguments or not ;)
In the end it would be silly to stubbornly refuse something that several people are stating a preference for, if the only reason is "don't give in to Gunter." Baker is not that petty!
And I'm certainly glad other people do speak up to state their preferences here, so that mine is not the only voice.
I Dunno Man
It's not about whether I would make a good engine coder. I probably wouldn't but not for the reasons you gave.
It just appeared, from an observers POV, that you basically bullied and harassed Baker into adding a feature after he gave you plenty of well-reasoned answers as to why it wasn't a good fit for the engine.
I mean, I have asked him to include stuff from time to time but I am in awe of the relentlessness of your stubborn pleas.
Maybe I am just better at taking no for an answer.
There were wins here.
Gunter did argue annoyingly hard.
Then again, he did eventually suggest a viable solution -- which no one has ever done before -- in the idea of making off by default but with ability to opt-in.
mh signaled he had complicated feelings on the subject and I've used DarkPlaces before for some deep modding where the functionality was helpful.
I've also seen DarkPlaces beg and scream for help because they messed up something so terribly bad and no ones wants to reply to them because usually it's a super-newb who barely can find their Quake folder so they get the "leper treatment" or insightful advice like "delete your Quake and reinstall".
So ... I think I'll have a beer and hope to laugh about this in the future. ;-)
/Gunter has found some very, very obscure bugs in the past. And spotted inconsistencies few would notice, allowing them to be resolved.
You surrendered like a Frenchmen! D:<
"Gunter did argue annoyingly hard."
I do everything annoyingly hard!
(That's what she said!)
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.
@ Johnny Law
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:
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
(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"?
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!
Theres A Reason Why The Quake Mod Scene Is Dead
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.
UI And HUD Aspect Correction
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
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.
...back To Sanity...
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.
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.
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:
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.
Tool_inspector, Why Are You This Way?
Mark V Question
How can I keep Mark V from messing up my Quakespasm cfg? I switch back and forth between these engines and right now I exec a specific config for QS after using Mark V but it's still a bit messy. I gather that this is some kind of anti-cheat thing from some research here.
What am I missing? How can this be more seamless?
two separate quake directories.
alternatively change all your config.cfg files to readonly so that nothing can overwrite them.
Meh. Well, at least I have options.
I gather that this is some kind of anti-cheat thing from some research here.
I don't think it's anti-cheat, what happens is when you exit an engine, it overwrites config.cfg with only the cvars / keybindings that engine is aware of.
So it's more of a limitation of the original quake config system, when extended to engines with diverging sets of cvars/keybindings.
I'm not too familiar with what has been tried to remedy this.
Would be nice if the engines had their own sub config.cfg for the "new" non-vanilla id, non-standard cvars it has implemented.
...and so on. That way we could keep my vanilla config and each engine looks for that and then loads theirs. Even if there is overlap the engine in question would ignore the others. I assume it's not this simple and would require co-operation to make it a "standard."
No, it actually is that simple. It's something like 4 lines of code. In Cmd_Exec_f detect config.cfg and write in the engine cfg, in Host_WriteConfiguration write out the engine cfg.
I have no idea why it's not done. I'd love to see it done.
and write both a config.cfg and config-engine.cfg with the same contents, as encouragement for other engines to follow suit... well, that and so new engines pick up usable defaults too.
however it would also need to be gamedir aware for all those mods that came with a config.cfg provided, so they don't read settings from id1/config-engine.cfg in preference to those in mod/config.cfg.
if engines had done the same with config.cfg vs default.cfg, we wouldn't have mods doing the stupid thing of including config.cfg files!..
Is the most recent MkV release capable of running "The Forgotten Sepulcher" from Arcane Dimensions v1.6?
The main engine-breaker in Sepulcher appears to be the leafs count; this is used for several hard-coded arrays in the engine and even the extended max in Fitz or earlier versions of QuakeSpasm is insufficient for Sepulcher, which needs 73755 leafs.
Personally I think that engines should be dynamically allocating these instead of using big static arrays, because otherwise it's an arms race: an engine will bump the max, a map will overflow it, an engine bumps it again and so on.
Anyway, the latest MarkV bumped MAX_MAP_LEAFS to 65535 for the Rubicon Rumble Pack, so it too is insufficient to run Sepulcher.
Other Ad_sepulcher Limits
193 lightmaps (assuming 128x128)
2877 static ents
For QS I made efrags dynamic, and was going to do the same with static ents (although 3k is about the upper limit with protocol 666 because of 64k signon)
Sky Visible Through Water
Very nice engine. Just one thing. When you set the water to be opaque like the original, the sky is partly visible through it in the hardware renderer. But not in the software renderer. This seems to be the only noticeable discrepancy between the two, apart from affine mapping not being possible in hardware either. How hard would it be to fix this?
Here is me on E1M2 looking at the sky with opaque water using the hardware renderer. The sky isn't partly visible.
Hardware renderer, opaque water, looking at sky -- none seen
Maybe a screenshot of what you are referring to would help?
I believe he's referring to the same issue some of us have reported before: shadows and the sky are visible through models (and water surfaces it seems) in the DX9 version. (see #1098 #1206 -- mh knows about it: #1109 ).
I jumped in the pool on e2m1 and saw the effect he's describing.
Hello i have problem with Dissolution of Eternity HUD.
"The armour / ammo icons displayed do not match the actual armour or weapon you have equipped."
This person has the same problem,he is using a PSP port,im using a Mark V.Is the problem on my side or Mark V? How do i fix this?
What command line are you using to launch it?
Using -hipnotic the command line? Yes/No?
Probably your problem. Let me know.
@gunter - ok, r_shadows 3 option. Maybe a week later after his post I realized that was likely the issue he was experiencing.
I meant -rogue, not -hipnotic.
No More Vsync In Mark V WinQuake?
WinQuake runs with constant stutter but I couldn't find any way to turn on vsync. Can anyone help?
I don't know of any WinQuake that ever vsync since that is a Open GL feature.
That being said, if you really want a WinQuake with vsync ... here is a slightly older beta with vid_vsync 0|1 capability:
It is the WinQuake-GL.exe in that .zip that has vid_vsync because it renders the buffer to an texture and then draws it on the screen through Open GL.
Thanks Baker, I found that build last night and it's fantastic for playing Quake as authentically as possible.
Is there a reason why this .exe is no longer included or being worked on? It's really the best of both the GL and software modes, since it has no graphic glitches and z-fighting like the GL version, while retaining it's best features such as UI scaling and vsync.
It just makes no sense to me at all.
The regular WinQuake can hit higher frames per second, doesn't matter much for small resolutions but if someone decides to max out in a very large resolution there is a gap.
It is actually maintained because the Linux and Mac versions of Mark V WinQuake are WinQuake-GL builds, I just don't put a Windows one in the Windows .zip because it would confuse most people.
Are you planning to put WinQuake_GL.exe's in future builds?
I could make it available somewhere on the page in the future when new releases happen.
Also, there have been two longstanding bugs to do with monster spawns that have been around since the original WinQuake - one in e3m3 where the fiend spawns midway in the air in the circular lava room when the final bridge activates and another in e4m7 where the zombies spawn after killing all the underwater zombies in the first circular room. In both cases the monsters are stuck in the air after spawning when they should fall to the ground/water and start attacking. Could you look into fixing these issues?
Are you sure that these are engine and not QC bugs? My recollection is that they happen in all engines, not just WinQuake. If QC bugs it would be inappropriate to modify this behaviour in the engine.
There's definitely source ports out there that fix these issues, but I admit that most I've seen don't.
Why would it be inappropriate to modify this behaviour in the engine? They are gameplay bugs after all so shouldn't they be fixed?
If the bug is due to bad QC code or mapping errors, then changing the behaviour of the engine to work around the bug does carry a risk: some mods may be using this behaviour of the engine intentionally to create a desirable effect. The fix for the bug in vanilla will break those mods in your engine. Which isn't to say that it's never the right choice to make those kinds of change, but you have to be thinking about the potential cost as well.
QuakeC is game logic in a progs.dat, found in Quake pak0.pak. It exists outside the engine and is the game logic program. It can be compiled with a QuakeC compiler like fteqcc.
Some people (like preach) are really into QuakeC, he is the main author of Quoth and was involved in Arcane Dimensions.
Concise version: QuakeC behavior isn't related to the engine.
Quake Info Pool - Currently not researched Quake bugs
"Right in the beginning on E4M7 some Zombies start spawning after you kill the ones in the water. If you stay under water as you kill them, the new ones will spawn above you, and fall down into the water. However, if you kill the ones already there under water, and get back up on the ground level, the Zombies will spawn in the ceiling, and just hang there."
Reported by Alexander "Prodigy" Møller
Demo is available for download (e4m7zombie.zip)
I bet it's a bug in the map itself. Some trigger misfiring or something.
The zombies' teleport entry points in e4m7 are just too close to the ceiling.
But if you have an online server with a sys_ticrate of 0.1 then they fall just fine, because the server doesn't check their position fast enough to know they are stuck before they fall far enough to not be stuck. sys_ticrate .05 or faster and they get hung up.
It can be fixed directly in the map or with QuakeC by altering the locations of the teleport points.
Sounds like a mapper or advanced user could make an external .ent file if that is what is going on.
Hey, *I* am an advanced user!!
Uh, is tool_inspector broken? it seems broken (in both GL and DX 8, 9). I had to go back to version 1.27 to make it work again. It did not work for me in 1.28
Ok, here is what the zombie problem is, I believe:
In triggers.qc, info_teleport_destination function raises ALL teleport destinations by 27 units upward. I think this is to get them off the ground a bit, to make sure monsters don't get stuck in the floor, hah. Well, the problem is that it causes the zombie teleport destinations in e4m7 to move too close to the ceiling. Though oddly, it's not completely consistent that the zombies get stuck. Sometimes they seem to fall just fine in single player, other times they may get stuck.... Maybe it has something to do with whether they are moving or seeking a target or something when they teleport in. Or it could even have to do with the FPS you are getting in Quake....
Yeah, that might make sense -- if you are getting really high FPS, then Quake checks sooner to see where the zombies are, and determines they are partially in the ceiling. If you are getting a lower FPS, then the physics check doesn't happen quite as fast, so the zombies fall down a bit and free themselves. That may explain why the original Quake people didn't catch the problem; they weren't getting a really high FPS back in the 90s!
But that's just a guess on my part, knowing that Quake physics are dependent on your frame rate.
In any case, lowering the teleport destinations should fix the problem.
So load e4m7, then type in console: copy ents
Go paste those ents into a text file: \id1\maps\e4m7.ent
Go to line 883, 889, 895 and change the "origin" Z values from 136 to 100, just to be safe. Save the file. Problem solved.
The problem is solved!
We solved the problem...
So ev'rything is awesome!
Yes, you are certainly an advanced user, haha.
You might consider uploading that file to somewhere for jayoo.
If you do, I'll mirror a permanent copy of the file.
ericw may interested in it as well.
/Yeah, Pritchard pointed out I messed up the inspector.
As a quick double-check, playing it with a sufficiently low host_maxfps should be enough to confirm the theory
That sounds like a very plausible cause Gunter (though I am far from an advanced user!).
I'd really appreciate it if you could run me through the steps to fix this and the other instance of the bug I mentioned.
Thanks for looking into this everyone!
I'd really appreciate it if you could run me through the steps to fix this
He did just that in post #1686...
I'll give you some pointers since you are passionate about this stuff.
That being said, after this initial information I'll leave it to others to give you tips or answer any follow up questions you have --- mostly because I'm largely "engine-only" and this is more QuakeC (gunter/preach) and mapping territory.
In that Mark V 1.25 or up to 1.27 in the Open GL version ONLY, there is tool inspector.
Activate it by typing tool_inspector 1. Type "impulse 9" and switching weapons with change information. https://www.youtube.com/watch?v=_QplswG5umo
For the map you want to fix, like Gunter said, load the map and type "copy ents" in the console. Open a decent text editor like TextPad or NotePad++ and paste that text into the editor. Then save the file as c:\quake\id1\maps\e4m7.ent.
From the information for tool inspector (you may need to type like "edict 3" (where 3 is an entity edict number) in the console, you can find out enough information to locate the mapping entity information in the .ent file.
Doing anything with this information, it is very helpful if you are a mapper (what this site is all about) or QuakeC master (gunter is).
But what Gunter did was edit some spawn point coordinates.
A .ent file is an external entity file recognized by all modern engines (DarkPlaces, FTE, Quakespasm, Mark V, others), it overrides the maps information.
You might struggle with this at first if you aren't a mapper.
Yep, setting host_maxfps 16 or slower does indeed make them fall down, even if they are currently stuck.
But even host_maxfps 20 is making them stick....
Ah... that's why they were falling last night on me -- I had tool_inspector enabled, and that was killing my FPS, haha.
And as I have pointed out, sys_ticrate of .1 makes them fall correctly on a server, and that's the equivalent of 10 "server frames" per second, isn't it?
But in the end, it's a bad interaction between QuakeC and the map itself.
The instructions I gave should be pretty simple to follow to fix it with an .ent file....
Though it would probably be better if someone really wanted to test to see EXACTLY how far the zombies need to be moved down to still fall correctly.
Don't look at me; I don't care that much. I run my server with .1 ticrate ;)
Guhhh... who am I kidding? Now that I said it, I can't not do it... heh.
Oh, well, it looks like they only need lowered by 3 units to work correctly (from 136 to 133).
Do I really need to upload the .ent file somewhere? I've already done all the hard work and told people exactly how to fix it! ;)
I Didn't Know QS Supported .ent Files
I thought only the spiked version did. Thanks for the info, Baker.
I managed to fix the issues. Still need to trial and error the E3M3 fiend spawn position but the zombies in E4M7 were an easy fix. Thanks again!
OK, after much messing around with an .ent file for E3M3, I'm unable to find the "info_teleport_destination" for the fiend who spawns stuck in midair. I've determined that the line 2164 corresponds to the fiend in question, but there are no matching teleport coordinates to the "target_name".
Maybe I'm missing something obvious so any help would be appreciated.
Perhaps I should try reading instructions more carefully in future...
I used tool inspector to find the offending fiend's actual target_name and changed the teleport coordinates to fix the spawn.
e3m3 Line 1244 "origin" "-832 416 140"
Mark_v And The Demo Fov
heres the demo of two bots dueling each other on zed2 - the vondurs property
i'm using mark_v to record the demo, and my fov is something like 135/145
but when i try to replay the demo something's strange has happened to me, using mark_v 0/99
the latest ad_1/60 engine(quakespasm-admod) has been playing the demo ok
you cannot change the fov value while watching the demos in mark_v
Downloaded zed2.bsp map
and played your fbots20.dem.
Changed fov several times ok, didn't experience any problems.
I believe you, but I can't reproduce what you are experiencing but maybe something will come to mind eventually.
take a look at these screenies
yeah i can change the fov value, but the viewing perspective is a very weird in mark_v
My initial guess works like this:
Mark V has angle smoothing, which is not obvious in single player. An online player can immediately tell.
It looks like Frogbots use some sort of QuakeC evil to move the camera around (jerky style) that isn't compatible with camera smoothing.
I didn't invent camera smoothing and in fact several engines have it, Quakespasm isn't one of the engines that have it.
It is possible you found a special case no one noticed before.
Crash When Trying To Play Demo
I get a consistent "Mark V has stopped working when trying to play a demo. Doesn't seem to matter what, but specifically now I am trying to play jam 9 demos.
Windows 10, 64-bit using latest MarkV release.
Happens in any version (DX9, 8, markv.exe)
Let me know what else I can provide!
Ugh annoying when the solution comes to you moments after finally giving in to ask for assistance.
I attempted to switch to jam 9 using the game command in markv. But running a shortcut with the -quoth -jam9 is what worked.
Happens. Glad you figured it out.
there's this Admer guy at QuakeOne having trouble running Mark V. I told him I'd drop you a line, so for troubleshooting purposes you might wanna check posts #55-58 here
Also, a few posts above those, Dutch states that he's experiencing a notable performance drop with the latest DX9 exe.
I look at issues posted in this thread by the individual having the issue. There is a link to this thread on the Mark V page.
Keeps everything organized.
Dutch probably made some setting that harms his FPS. Like r_shadows 3
He should try a clean install.
Same with the other guy who it won't run for -- completely new install in a new, clean Quake folder.
Looks like an experimental map (an awesome looking one at that).
If that map gets released I'll see what is going on.
It could be one of a million things (vis, a texture, a skybox, external textures, a lit file, entity error, parsing issue, a texture name, a setting in Mark V even.).
Hello, Baker. I'm the guy who can't run Mark V.
I tried what Gunter said, but the same problem still happens:
- I open the .exe
- RAM usage is at 9628KB
- After 15 seconds, the RAM usage jumps to around 46MB (I'm assuming it loads some game files)
- The .exe simply exits without a warning
In short, it won't run at all.
Sometimes, this happens:
Yeah, it was a clean install, straight outta the box. New directory and everything. No old cfg files, lifted it all off my quake CDrom from '96. It's probably the r_shadows cvar.
There should be a qconsole.log file in your Quake folder after you start Mark V.
Can you paste the text of that?
That Microsoft crash report, could you post the text of that as well. Often the crash report text can indicate where something crashed.
What version of Windows are you using?
And I assume you are using current version of Mark V?
Dutch, if you happen to be testing in the Start map, make sure to set r_mirroralpha 1 to disable mirrors. Mirrors are enabled by default (really shouldn't be). They are bad for my FPS.
I don't think any other FPS killing settings are defaulted on. r_oldwater 0 is another one that harms my FPS, but that isn't set by default. Assuming the secret hidden cfg file isn't retaining any non-default settings when you do c clean install....
You couldn't possibly be using a slower/older computer than I am (XP Netbook!).... I get between 40-75 FPS on the Start map, depending on what the lava balls are doing, as long as I don't have too many extra features enabled.
Hm, and if you happen to be running in a window, and you have some other program on screen that is drawing stuff, that could cause a problem too. I have a program called BitMeter, and it will destroy my FPS if I have it showing while running DX Mark V in a window....
I'll see about the crash report later today, because I'm currently using my phone. I remember it was referencing 3 files located in Appdata/Local/Temp.
My OS is Windows 7 (32-bit) and yes, I'm using the current version of Mark V, or at least that's what I think.
I've downloaded it here: http://quakeone.com/markv/
Slight correction: Windows 7 SP1.
I copied the 3 files in another folder:
Should I send the .mdmp file? I'm a noob at debugging.
I am on Windows 7, although not 32-bit.
The quake\id1\qconsole.log would be helpful. It is the log file Mark V writes out.
Here are its contents:
Command line: [ ]
Log file: C:/Games/Quake/id1/qconsole.log
Sat Sep 09 18:17:08 2017
Mark V Windows (Build: 1036)
Exe: mark_v.exe (1327 kb)
Exe: 22:32:27 Jan 19 2017
Caches: C:/Users/kliker/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY, 192.168.x.xxx
IPv6 Initialized: [fe80:0:0:0:a59f:53f6:4528:9fe7%41]
Exe: 22:32:00 Jan 19 2017
256.0 megabyte heap
1) Do the WinQuake or Direct3D versions run?
2) Is there an opengl32.dll in your Quake folder?
I know Quakespasm runs on your machine, so it shouldn't be an Open GL issue although Mark V uses some Open GL capabilities that Quakespasm doesn't.
If there is an opengl32.dll in your Quake folder, you should delete that. But since DarkPlaces seems to run for you, I can't see how you could have a (toxic) opengl32.dll in your Quake folder.
Baker, compile a debug build for him, keep hold of the exact pdb file that msvc generates when compiling said debug build.
Send him the debug exe, get him to send you the resulting .mdmp file.
Open the mdmp in msvc.
Then you can see the stack etc, and inspect many of the variables that might be relevant etc.
That or rip the stack trace code out of FTE's win32 port. That would allow him to simply paste you a whole list of function names which is usually enough to figure out where it crashed (although not always what actually went wrong).
This of course requires no pdb files, so hurrah for that, but it won't show line numbers etc.
Still, if you expect your code is going to crash then its quite handy...
Ywah, the strangeness/uniqueness of Admer's problem is has been making me think about improved crash data.
Can't do anything tonight, but I'll ask you questions tomorrow or Monday about what you are referring to in FTE.
1) Yes, but they crash the same way.
However, the WinQuake and DirectX versions don't give any crash reports. That only happens with the original Mark V .exe. :P
2) I'm sure there is, I'll still check to make sure.
Mentioning OpenGL reminded me of something:
My GPU only supports up to OpenGL 2.0. This gave me lots of compatibility issues with programs that require OpenGL 2.1.
1) No, they crash almost the same way.
(I misread what you wrote up there, sorry)
If WinQuake or Direct3D are crashing, your OpenGL drivers aren't involved in this. Neither use Open GL. WinQuake doesn't use anything at all ;-)
So it is something else.
I never actually suspected a drivers problem, mostly wanted to rule it out. It but seems unlikely.
I have couple of suspects.
I imagine in the next 72 hours or less, I'll make a special build with some of Spike's inventiveness, and then exactly what is going will be clear.
Thanks for the feedback ;-)
Well, I was wrong. There was no such file as opengl32.dll in my Quake folder. :P
Been looking for an update of WinQuake and so happy to see you giving it some love, Baker! The original software renderer is still very charming. I love that washed out shading, you can't replicate it in Quakespasm.
Tried loading Arcane Dimensions with this and was surprised to find out that it mostly works. The engine even auto converts the full color skyboxes to 8 bit! However some textures with alpha channel are broken, the fog in ad_necrokeep looks especially bad, and ad_swampy crashes when you get to the main area. Anyway, what I'm getting to is, any chance your version of WinQuake could be fully compatible with Arcane Dimensions? AD is probably the best benchmark for the modern map packs, so it'd be a good milestone to achieve, I think.
I am sure Baker will eventually provide builds for *all* MkV builds that fully work with latest AD additions. Maybe even Ter Shibboleth. These days, mappers are doing everything to push Quake map specifications beyond any previously known limits. I hope that eventually we'll have a solution which won't require updating ports over and over again to make maps work.
Fog in custom Quake maps is usually too subtle, to disguise the fact that it's not volumetric.
Custom Quake maps can "fake" volumetric fog by making some areas small enough for the fog to not show up, and making other areas large enough for the fog to cover them. Combining this with strong shadows in the small areas and very subtle shadows in the large areas makes the global fog seem to have different densities in each area.
The thing is, subtle color translations are very difficult to pull off in 8-bit color palettes. Large areas of the screen ends up being rounded to similar color values, resulting in huge color banding if not dithered, or heavy graining if dithered. This gets even worse when the raw color of the fog doesn't exist in the Quake palette.
Making fog look good in 8-bit color renderers requires design restrictions that the mappers won't adhere to. Just like transparencies usually looks awful in 8-bit color, fog and colored lighting will usually look awful too.
A fun thing is that the same principles applies to regular lighting. Vanilla Quake maps features mostly strong shadows, because subtle shading has lots of banding in the software renderer. But newer Quake maps usually disregards this limitation, because they're usually only designed for hardware renderers. Most of the awfully looking maps from the 90's usually failed to understand this limitation too.
Another reason for the subtle fog in custom Quake maps is to disguise the fact it's not spherical. Thick flat fog looks bad when turning the camera.
Transparency In WinQuake
I've done some more testing in Mark V WinQuake and turns out the water/teleporter transparency (r_wateralpha) actually works, via dithering. I suppose the same effect could be applied to the fake fog layer in ad_necrokeep. It just seems like the engine has no support for alpha channel in textures, e.g. various trees and vines in AD and Jam 8 are broken, with solid white where they should be transparent.
Put these guys in the maps folder and you'll have transparent water on the stock id1 maps
External .vis files for original Quake maps
They should work in DarkPlaces as well.
The original Quake maps don't treat water as transparent.
Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).
It actually works for .mdl models, but few maps use that although it might be visible in Arcane Dimensions in some cases.
Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).
The BSP renderer sorts depth by edge at the spans level, rather than at the pixel level. To avoid this, I've tried partially reinitializing the BSP renderer upon rendering each alphamasked BSP surface, but this resulted in massive slowdowns. Now I only reinitialize it once for each BSP entity containing alphamasked surfaces. Qbism did something similar in Super8, IIRC.
Quake's spans-related code needs a lot of work. It's non-intuitive
and has bugs such as this
I don't fully understand it yet either, but I'm sure the reinitialization overhead can be eliminated almost completely. I should only manage to do so after fully rewriting it, though.
Thanks for the link. Looks like a good read.
I had determined that some sort of reset was required, but either I did it in the wrong place or performed it incorrectly. Or the third possibility of something I am not considering and wasn't on my radar.
Some day in the future I'll make another attempt. Last time I almost got "serious" (I was piece by piece reimplementing qbism super8 in WinQuake until I isolated what I didn't understand), but then something more shiny to me pulled me away (probably something Spike did in Spiked Quakespasm like single port server).
Network code to me > everything else ;-)
One more thing, does WinQuake Mark V support any kind of HUD scaling? Integers like 2x, 3x etc would look quite good even in software rendering I'd wager. The usual scr_*scale commands don't seem to work.
In the video menu, stretch is as close as it comes, emulating 320x240 or 640x480 as best it can depending on your current display mode.
It isn't exactly the same thing as scaling the HUD, and for most people it is probably "good enough" -- although as a purist I don't feel it is good enough.
But since it would be quite time consuming and effort to implementing true scaling (aka FitzQuake) in the software rendering with the appropriate alpha masking support, such a thought sits somewhere closer towards to the back of list rather than the front.
Keep in mind a trule scaling solution needs to handle all 2D graphics like the menu, scoreboard, etc. otherwise it would be quite silly.
Hmm, seems like the original renderer is pretty limited.
For the record, I've tried Qbism, and it does have HUD scaling and alpha channel support for textures, but I get heavy FPS drops in Arcane Dimensions, when there are any alpha channel textures in my line of sight.
Could we do this another way around and emulate the original paletted 8 bit look in OpenGL? In particular the lighting color map.
Crash To Desktop
....on trigger_changelevel - is this a known issue or could it be my map?
It's happened multiple times and on demo playback as well.
I know exactly how do it. It isn't a question of that at all. The question is, of the things I can do, would I find that interesting enough to want to do before the 25 things that do interest me. If you understand.
Ask Spike or mh or ericw or metlslime or qbism or mankrip, part of an engine coding for a leisure activity is wanting to do the task.
@dumptruck_ds .. don't know. If it progresses to become a released map, I'll make a mental note of it after it is confirmed it doesn't crash any other engine.
paletted look with gl = fte with r_softwarebanding 1 (or just use the softwarey preset).
re: the map. tested on Quakespasm-admod last night and it was fine. I will do some further tests with other clients this evening and report back but for now at least that engine behaves as intended.
My trigger change level is made up of some weird shapes as you can sort of see in the screenshot. Not sure if that could be a cause or not.
it seems the tool_inspector is broken on your latest release v36
also i've got a new video card gtx1070, and noticed a very weird video gliches with the fog enabled
there's no such gliches if i'm using quakespasm engine tho
There Ain't No Gliches Either If I'm Using Dx_9 Engine
Yeah, Pritchard reported the tool inspector issue a while back and then a couple of others later on.
I saw the glitching in your video. Could you give me "viewpos" coordinates and map name (or as an alternative the demo which gets me the same information).
I'm guessing since it only happens in certain frame, it occurs when a lavaball pops into view.
Quakespasm and Mark V and Mark V D3D all draw very differently, so the different behavior isn't unsurprising.
I'll make a note to try to recreate the next time I have my hands on a NVidia card machine. Since NVidia updates the drivers all the time, it is a possibility that this is a driver issue that will go away in a future driver update, but I'm not going to make that assumption.
Thanks for the high detail issue report.
Yeah, After I'm Getting The New Card
i've updated nvidia driver to the latest version
this glitch is only happens when the fog is enabled, disabling the fog removes the problem
would you mind if i'll send the map
to your mail?
Spy, you know I think you are awesome.
I am email free! And I love it!
If it needs to be done privately, I guess you could send a private message at QuakeOne.com.
i cannot reach you at QuakeOne.com
btw, fitz08, has the very same issue
I deleted some private messages over there, you can try again (but really since they upgraded the forum there, I don't know if that was problem or not) or upload to Quaketastic.
My gut instinct is that I think this is a driver issue that will magically disappear at some point once nvidia does an driver update or 2 on your machine.
They probably introduced some sort of stencil bug they introduced since ...
1) It doesn't happen in Quakespasm which doesn't use stencil by default.
2) It doesn't happen in the Direct3D version.
3) Didn't happen on your previous machine, no one else has reported a glitch like that.
Hello, it's me again. :)
I've tried out a few older versions of Mark V, and the problem is still the same.
Now I'm starting to think that it's definitely up to my hardware. Certainly my GPU, because the drivers are so poor. Yes, the latest ones are from years ago.
In the near future, I might install modded drivers to see if it helps. Intel GMA 965 is a special snowflake among the 9xx series, haha.
You might try the sdl_mark_v_gl.exe in this beta ...
Will it work? Who knows!
Had several beta testers with really, really bad/old computers, some which can't run Open GL but the Direct3D works and getting terrific fps.
Worth a shot anyway.
Yes, the Intel 965 is pretty damn special - it was Intel's first hardware T&L part, the drivers are absolute cack and the hardware itself is actually slower than the prior (software T&L) generation.
As far as I'm concerned: weirdness, crashing, general bad stuff - that's expected behaviour under OpenGL with this part.
I've tried out the SDL .exe, and just as I thought...
There's no hope. My GPU is the lottery in terms of incompatibility. :P
I'm not giving up yet, though.
I'll just wait until I build my new PC by the end of this year. Modern hardware will definitely handle it better. :)
1036 Is Giving Me Problems
Wonder if anyone else is having issues running it. I'm testing a map so haven't had time to really document things but it seems to stutter quite a bit after running for a few minutes. Can't even finish a play-thru.
Before I dive into reporting wondering if anyone else is experiencing the same behavior?
SO far it's just the main mark_v.exe
dx8, dx9 and winquake are behaving.
Found A Really Weird Bug
The following bug happens in all current versions of Mark V:
- Quick save and quick load at least once.
- Die and press space to restart the level.
- You respawn with death camera (slanted view).
Also, all versions of Mark V are stuttering for about 3-5 seconds every time I launch the game, sometimes also with cracking sound, usually when loading the first map. It's like it's caching something really bad. My machine is pretty modern, so it shouldn't be related to specs. The game is very smooth after it's done that initial bout of stuttering.
Also please consider adding support for OGG tracks. it's more common than MP3 nowadays and seems to be standard for Quake. Also PNG instead of TGA as well, most HUD/GFX graphics seem to be using PNG.
P.S. And maybe don't try to re-route when an opengl32.dll is put inside the Quake folder. I'm just trying to use a wrapper for some extra graphical effects. This one in particular. It works great with Quakespasm.
The death cam respawn was reported (by me :D) a while back.
I don't think that ogg is more common than mp3 now... in fact i'd say it's even less common than it used to be, now that the mp3 patents are starting to expire.
I think the reason to avoid loading opengl32.dll is this
Well, I've got about a dozen Quake soundtracks (id1, hipnotic, rogue, shrak, malice, impel, xmen, n64 etc), all of them in 256 kbps VBR OGG, de-emphasized where necessary. I'm pretty happy with this collection as it stands and don't feel like repeating the process for MP3. I've read about Baker's reasoning on how MP3 is faster to access, but I'd still like an option for OGG support. And who knows, we might all switch to FLAC at some point.
Yeah, I get the reasoning behind avoiding opengl32.dll, in the old vanilla installations of Quake (and other games from that era) it's a 3dfx wrapper, which causes problems on modern systems. But I feel like the current solution of removing the option of using any wrapper at all is a bit too heavy handed.
In theory MarkV already has .ogg support provided you have a DirectShow-compatible codec installed. As a rule of thumb, if you can play it in Windows Media Player, you can play it in MarkV. I know that for a fact because I'm the original author of that code.
In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension, but I didn't originate that part of the code (or at least I don't recall doing so) so I can't say what kind of work would be involved in this change.
Ogg Vorbis Is History, Use Opus Like QS
Ah, ogg files.
Supported on Windows, the Mac, the iPhone. Widely used in the commercial games industry and in the music industry. Supported by the Unreal engine and the Source engine.
Oh wait. That's mp3. None of the above support ogg.
My Android phone can play ogg. If you open an ogg file in Google Music, it will convert it to mp3 and then play it ;-) That's Google's idea of ogg support.
Ogg fits in nicely in the category containing 8-Track, BetaMax, Laserdisc, Zip drives, the Zune, PlaysForSure, HD DVD, Windows Mobile, Windows Phone.
Short version: Oggs? Fuck, no! Plus you don't even know why you are using ogg, Quakespasm supports mp3 -- so what was it that made you think "ogg" to begin with? Answer: You don't know, because no one using ogg ever knows why they are using ogg, especially because in the real world, no one is ever doing oggs because nothing supports them.
/Against my better judgment, I click submit!
In practice MarkV is hard-coded to only search for files with a .mp3 extension. Supporting .ogg as well should be just a matter of adding support for the other extension
Thank a lot for this tip, turns out Mark V DOES play OGG if you just open the .exe in a hex editor and search and replace all instances of .mp3 ASCII text with .ogg. Really makes you wonder, why not just add literally 3 extra characters to the source code to enable OGG support? It really seems like Baker's got some personal agenda against it, since literally every other modern Quake engine supports OGG, because why not. Oh well, I suppose there's no need to discuss this further.
The Smell Of Napalm On The Forum
There's something wonderful about reading Baker raging against ogg, and then immediately afterwards reading about how despite Baker's strong desire to prevent it by explicitly coding it out, someone has hacked it to work with a find+replace.
It makes you wonder what ogg did to Baker - murdered/kidnapped family I guess - in the past to make him think "I have this perfectly good DirectShow support in my engine. I should ruin it and only use it for mp3 format music to ensure that my users have to work harder than with other engines!"
Doesn't Sound Complicated At All?
Implement a generic audio library and comment out ogg from the list of supported formats.
why not just add literally 3 extra characters to the source code to enable OGG support
I obviously can't speak for Baker but this wouldn't be just 3 extra characters. It's only 3 characters if you directly replace the existing .mp3 support with .ogg support, but of course you then lose .mp3 support.
Adding multiple file format support would involve enumerating files of multiple extensions, sorting them into lists, making decisions such as which format has priority over others (not so clear-cut - how do you decide between a high bitrate inferior format vs a low bitrate superior format?), and how to handle the inevitable crazy-assed situation where someone has multiple formats in the same folder (some of which may even be multiple versions of the same file in different formats).
I absolutely do think that people should make the effort to do all this, of course. But it would need some guidance as to what the end-user expected behaviour is. Multiple end users pulling an engine in different directions is something I can personally vouch for as never ending well, and it would be nice to see players striking up a discussion among themselves about how they'd like to see these kind of decisions work out.
Funny thing is, OGG is actually already listed in Mark V's file extension look up table:
But there must be some code that explicitly ignores or forbids it. Seriously though, just why. It's a relatively popular file format for video game audio.
To enable OGG support find the above bit in a hex editor and replace mp3 with ogg. Simply renaming your OGG tracks to MP3 should work as well, I guess.
I'm confused... Isn't engine inter-compatibility something to strive for? Considering that all other engines support the format AND the fact that most soundtracks available online are in .ogg, it strikes me as odd that Baker would want to force the user to convert the files in order to use them with his engine. Plug'n'play, man, plug'n'play...
Probably doesn't want bloat.
Ok Baker, I NEED ogg support!
I tried the hacks mentioned above (either renaming my ogg to mp3, or hex-editing mark_v), then, after installing the ogg directshow filter ( http://www.vorbis.com/setup_windows/
), Mark_V does play ogg.... and it loads in a FRACTION OF THE TIME as an mp3 file of the same file size!
Do you remember a while back, me going through a LOT of testing because I have an issue where loading an mp3 file causes Mark V to freeze up while the file loads? (mentioned in #651 above)
After some encoding gymnastics I managed to get that loading time (during which everything freezes up) down to only like 4.2 seconds for track04.mp3.... Well, I converted it to an ogg of the same bit rate and file size, and it loads in only 1.23 seconds!
So... yeah. That would be the reason to allow ogg files to be found by Mark V (since it is already capable of playing them).
You really don't have to do all the complicated stuff mh mentioned. Just state, "Mark V supports the following formats, in the following order of preference: mp3, ogg."
And let the users sort their own files and formats and bitrates.
Indeed, there's no need to compare bitrates or anything, just let it read formats A|B|C in the priority of A, B, C. And the game folder should take priority over id1, e.g. say you have OGGs in id1 but e.g. Travail comes with an MP3 soundtrack, disregard the OGGs in id1 then, unless there's not enough tracks in the game folder, in which case read the missing ones from id1. I think that's how Quakespasm handles it anyway, correct me if I'm wrong.
is there a way to set the fog value via an cfg file or fog depends on qc?
Just use an external_entity file(yourmapname.ent) Put the fog command in there.
I Don't Quite Sure What You Talking About
why would i put the fog command in the external ent file? and where exactly should i put it?
i'm using the fog value via the worldspawn. AD mod supports this and shows fog correctly, but it seems kinn's old mod (bastion/marcher) doesn't support fog from the worldspawn, as there's no fog after loading map.
i'm just wondering :)
The worldspawn "fog" key is handled by the engine, it should work in id1 with MarkV (and most engines). Maybe bastion/marcher is resetting it via QC.
My answer was for the simple question of setting fog values via an external(.cfg) file, now I see your problem!
i have a map with a worldspawn settings something like
fog_colour x y z
and after loading this map in AD the fog appears correctly, then i put the very same map in the id1/maps folder and run it from the vanilla game
there's no fog at all
until i manually set the fog numbers in the console, what gives?
those are AD-specific fog keys.
Try: "fog" "density r g b"
Have You Just Tried...
"fog" "Density R G B"
All on one line for stock id?
Try: "fog" "density r g b"
i put this line fog 0.015 0.35 0 0
into an *cfg file without the quotes, but no avail.
Sorry, put it in worldspawn, not a cfg file :) i.e. the worldpawn key is "fog" and the value is "0.015 0.35 0 0"
yay, it's working this way. silly me. Thank you Eric and damage_inc
Hey, I require help
Whenever I try to launch any of those 2 executables using:
./mark_v_linux or ./mark_v_winquake_linux
I get following error:
bash: ./mark_v_winquake_linux: Permission denied
Double-clicking doesn't work either
On manjaro, hope anyone can help
chmod +x mark_v_winquake_linux
Has done the trick for me, it works now!
Marcher / Bastion Imps Sprite Issue
I was playing back some demos of Spy's work-in-progress map in 1.36 and the final frames of the imp fireball (the impact only) show up as non-transparent. If this is not a known issue, or repeatable I can try a screencap to make this a bit more clear. Works fine in other engines. Notably Quakespasm-admod
I've ran into this.
Which sprites are you using?
Kinn original: uses black for transparency requires enfine with support for .png override textures (e.g. Darkplaces) and additive mode.
AD: Not sure.
Keep: I converted all mine to use pink transparency for full support on all engines.
It's actually an older map of Spy's that he's working on getting ready to release pretty soon. Not sure what assets he was using.
@Spy are you using the same assets from the original Bastion/Marcher maps?
@dumptruck_ds Kinn Sprites
Mark_V enables external textures by default, so set external_extures to 0 and reload the map
or just delete all of *.tga files from the sprites folder, they are absolete now
Mark V's adaptive FOV calculation method seems to be quite different from QuakeSpasm and original FitzQuake. I need to increase FOV by about 6 to get the same field of view as in QS (using a 16:9 display). Of note, QS just does vert- when you set scr_sbaralpha 1, while Mark V does hor+. Not sure which method is preferable, however, it's possible that Baker based his adaptive FOV calculation on specific scr_sbaralpha and viewsize values. In particular, setting scr_sbaralpha 1 and viewsize 100 gives about the same FOV as in QS with full screen view point (that is scr_sbaralpha 0). But nowadays most people are probably playing with the transparent HUD, so this just results in smaller FOV.
I have finally come across a solution to my problem. It turns out that I actually didn't have pak1 and pak0.pak. I thought I did, but I didn't check my ID1 folder. Long story short, I found something which contained both pak files and copied them over.
I love it. It runs like a charm:
I'm so sorry for wasting your time over such a dumb mistake of mine.
>looks like glquake
Missing PAK files was the problem?
How does that happen? If I remove my PAK files and try to run Mark V, I immediately get a popup error message saying it can't find the pak files.....
Maybe corrupt pak files?
My laptop is 10 years old, I'd rather not...
Also, it's my first time using this sourceport, so I haven't tweaked all of the settings yet. Though, I'd love that to change. :)
Funny thing is, there were no .pak files at all in my ID1 folder.
The .pak files' contents were actually extracted to my ID1 folder, but the .paks themselves weren't there. Interesting.
Interesting! You may have found "an issue."
I tested with unpacked pak files, and Mark V does indeed just crash without any meaningful error message.
These alternate engines I tested work just fine with unpacked pak files:
Unpacked pak files should be an acceptable setup... so... Mark V should be able to handle that.
Anyway, if you're interested in tweaking Mark V with all kinds of setting which make it look better (in my view), I have a page with downloads and settings to alter: http://www.fvfonline.com/fitzquake.php
Then come play FvF :D
Any interest in bumping Mark V's limits to make it Sepulcher-capable? cf. comments 1661/1662 above.
Also, can anyone say "sepulcher-capable" five times fast?
@Johnny - Some day ... whenever I do the next version of Mark V, which doesn't feel soon.
So It's Dead Huh?
And just when I finished compiling a nice list of bug reports and suggestions. Disappointing.
Gotta love the internet.
So Baker writes "not yet but I will" and you interpret that as meaning "it's dead", eh?
What's this I hear about Quake finally being dead? Oh well, it was fun while it lasted. I guess we can all move on to Unreal Tournament now.
You Mean UT2k18 Aka.....
....Quake Chumpions lololzor
I think you've posted some well thought-out comments, including some refreshingly detail oriented ones. This thread is intended as permanent record of feedback so none of the information is lost.
NightFright could tell you stories, there is an obsolete older Mark V thread here with 2500 posts and his observations about obscure mods + crashes, a few which have led to improvements in Mark V and also Quakespasm -- over time ... it was not quick at all! Ironically, maybe 2 which ericw pointed out solutions, ericw didn't actually do them in Quakespasm until way, way, way later.
In free projects the author is always vastly outnumbered and with limited time and a real life.
@adamer - I'm glad you determined what was up with that (your pakless setup). Sure, in theory it "should" work (except it doesn't in Mark V) and it sounds like it works with other engines, but in practice an actual Quake install whether from Steam or the CD or shareware has pak files -- so yeah ... I'm glad that mystery is solvd.
@QMaster - re:Marcher --- I like the attention to detail/testing/thought it sounds like you are doing with your Uber mod.
I hope that one day I can do another test run as intense as the one I did before that big Mark V update back then. ^^ IIRC there is still at least one issue kinda pending with the final map of Malice when fov changes after reloading the game. It must have to do something with the boss attack and how the port handles the short-term fov changes. It was supposed to be fixed, but a few months ago I managed to get the problem again/still. Need to see what became of it.
is the mod adjusting the fov or is it standard quake
oh reread the post i guess its an evil thing malice does
mods shouldnt ever change the users fov. could bean easy fix
|3 posts not shown on this page because they were spam|
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.