Stuff like DP dies on AD, down to 7fps. Other games, ie Q2, Q4 run much better at the same resolution with HD and extra effects cranked.

I've had the best luck with this engine and quakespasm spiked.

For instance ad_fuma... markv/dp = slowdown right at the start by the lift. markvDX9 = smooth.

I can see why that might happen - polygon counts are absolutely insane in this part of the map.

There are a combination of things going on here.

Insane polygon counts.

MarkV GL makes no attempt at draw call batching. That's going to mean that bigger more complex scenes will bog down more and more.

MarkV D3D9 takes those GL calls and batches them, so it can handle those scenes better. It's still transferring a LOT of data to the GPU every frame though.

Quake 1 map formats are working against you. There's actually not a whole lot visible in that start scene, but Quake 1 lacks the vis format enhancements that even Quake 2 had, so it's pulling in a LOT of hidden surfaces.

DarkPlaces + huge data set + bad vis format + bling is not a good combination.

Quake 2 doesn't have the bad vis format, so it's data set is smaller, so you can bling it without as much slowdown. Likewise more modern formats.

Putting your data into vertex buffers so that it's already on the GPU rather than needing to be transferred every frame helps a LOT with bigger data sets too.

It's like the Quake equivalent of death by a thousand cuts. 

"1) FVF running (-game fvf)
2) Single Player->New Game
3) fvfstart.bsp loads

99 of 100 people would call that perfect behavior"

Maybe, but I complain louder than those other 99 hypothetical people combined! :D

And the problem is that this same thing would happen no matter what mod you were running in "step 1." You'd get fvfstart.bsp no matter what mod, because it's first alphabetically....


Actually, in the FvF4 full version package, the mod is programmed to always start the fvfstart.bsp map when a player goes to start a new single-player game. Probably somewhere in the QuakeC it does that.... This is more like what Spike suggested. If the mod actually specifies a map to run, that's fine -- you give control of such things to a mod when you run a mod.


Though the automatic start map picking does not seem to occur when you are just running id1 Quake.... Why is that?

That actually seems backward, in a way....

I mean, if you're running a mod, the mod itself will usually contain some way of starting whatever map it want to start, if it doesn't want the default start map.

But if you're running just plain Quake and you have a single-player map pack installed... then you DON'T try to select the start map via the engine ?

Well, I don't understand the reasoning behind that, but I dislike the feature in either case.

I do love the "Levels" menu though. 

https://www.youtube.com/watch?v=EL8e2ujXe8g

;) 

My perspective most closely aligns with Spike's above about how mods should supply the information on the proper start map.

In a perfect world, that is the correct solution. 

Should always be the name of the start map imo

Anything else is asking for trouble. 

I can think of only one case where "start.bsp should always be the name of the start map" doesn't apply, and that's where a mod has only one map.

If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp).

We're conditioned to think of "New Game" as being the equivalent of "map start" but if you step back and think: "is it really?" you might get a different perspective. 

" mods should supply the information on the proper start map. "

Agree. But if they don't do that, then the default start.bsp should be used instead of just guessing at it.


"Anything else is asking for trouble. "

Completely agree. I have been running into said trouble in actual practice -- though it's not that it can't be worked around but manually changing levels after I get dropped in the wrong map; it's that it is a major change from Quake's expected default behavior.


"If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp). "

Actually, I don't agree with that, due to something I have done with FvF....

I have a modified DM6 map that contain an extra area which has nothing but a deadly lava pit with ledges above it, referred to as "The Purifier." When players vote to start a new Quest, I first transfer them to The Purifier area to kill them off before starting. The reason for this goes back to before I had the source code, and couldn't just strip everyone's weapons and frags from then without killing them... so the solution was just to kill them in a deadly trap before starting a new Quest game. At first, I had a separate small map for this, but later Orl modified DM6 to contain the Purifier in an extra area. This allows all players connected to the server to not be stuck in the console when The Purifier is called -- instead, if they don't have the modified map, they just feel like they are floating in space above DM6 while they die (the map on the server has the lava area, so the players can be in the DM6 map, inside that area, even if they can't see it). Of course, now I have the source code and could just strip the players' weapons and frags away before restarting Quest mode, but The Purifier became a traditional part of FvF, so it remains and is included with the FvF download files.

So, long story short (too late!), even though FvF has only one map included with it, it should never use that map by default when I go to start a new single-player game... because (before I had installed other maps in my FvF folder) I get put on DM6 when I try to start a new single-player game!

That is something that should never, never happen....

So yeah, default menu function for starting a new single-player game should start start.bsp EVERY time.

There are many different ways a mod can control that if it's not what is desired. 

Mark V's first priority is to play single player releases at Quaddicted and those released here. That first priority will never change.

FVF is not a traditional single player release like ARWOP, lunsp1, Travail, Marcher Fortress, Once Upon Atrocity, Grendel's Keep, Warpspasm, Soul of Evil, The Colony, GMSP1, Middle Evil, Rubicon 2, etc.

So yeah, maybe you have to add +map dopastart to the command line.

Oh the horror!

Mark V - #1 priority is Quaddicted/Func_Msgboard map releases. Feature is well suited to those.

But yeah, you can argue this until the cows come home and it will never change, because it is conflict with the stated goal of supporting single player releases conveniently. 

If I install ...

1) "game cda" - Castle of Dark Ages - Single Player new game should play the release.
2) "game lunsp1" - Single Player new game should play the release.
3) "game coagulatest" - Single Player new game should play the release.

I could name 200 more examples.

Now maybe someone like Gunter doesn't play single player releases off Quaddicted.

That's fine. But you have to remember that this engine is built to work in harmony with single player releases.

Arguing something in conflict with the #1 stated goal of the engine is just a waste of time. 

All that being said, what Spike said #1244 has been a low priority item to examine and possibly implement.

Not even close to the first time Spike has conversed about such a feature, it has come up at insideqc in the past on multiple occasions.

So possible future ability to specify what you think the start map should be for FVF via quake.rc or such doesn't seem like a stretch. 

No, I'm not familiar with all the single-player releases, but I have to ask, of those you mentioned, are they actual mods that should be installed to their own folder? Or are they just map packs?

Mods should have their own method of starting the correct map.

Map packs (like Terra and Iikka that I know of) are just installed to the maps folder, usually in id1.

In the former case, your map guessing isn't needed, and in the latter case it apparently doesn't function.

Let me check all the ones out you named, to be sure I thoroughly examine the issue.

CDS - pak file with progs included, so it's a mod, but it contains a readme with instructions: "3. Then load the map by typing 'map cda'."

lunsp1 - same, with instructions, "type 'map lunsp1'."

coagula - instructs user to use command line "-game coagula +map cogstart"

ARWOP - has instructions "Start a new game, and you will be taken to the start level of
'A Roman Wilderness of Pain'." So it's done the correct way, within the mod itself.

Travail - same, mod does it correctly/automatically.

Marcher Fortress - contains instructions to use command line "-game marcher +map marcher"

Once Upon Atrocity - starts the map in the included autoexec.cfg

Grendel's Keep - instructs to start map + mod by command line.

Warmspasm - looks like it does it automatically by the mod.

Soul of Evil - also done correctly by the mod.

The Colony - well, there is one "Colony" that is just a bsp with instructions to copy into id1\maps\ and run with "map" command, but there's also:

The Colony GMSP1 -- gives command line to start mod + map.

Middle Evil - instructs to use "map" command.

Rubicon2 -- apparently does it correctly in the mod.

So let me just tally this up.
Of the 14 potential things you mentioned (there were 2 Colonies):

5 of them do it the most correct way, within the mod itself, when you start a single-player game.

1 of them does it by an included autoexec.cfg, which is the second mostest correctest way to do it, I'd say.

1 of them is just a bsp which is placed in 1d1 with instructions to use "map" command (noted separately since the map-guessing feature doesn't work unless a mod is running).

3 of them have instructions to use "map" command.

4 of them provide a command line for the user to start the map + mod (oh, the horror of having to use the command line ;)


So, is the feature REALLY well-suited to these things?

In half the cases it either is completely unnecessary or won't work.

In the other 7 cases, if the user is following the instructions, it will never be used, (even though it would function correctly).

I'm sure there are many, many more map packs we could examine, and we could each look at the examples that either make it look good, or unnecessary, or bad.

But the feature is completely necessary in 0% of the cases, since all the map packs provide instructions for starting the map.

The feature is useless in 50% of the cases, because the mods either do it correctly already, or the feature doesn't work for maps in id1.

The feature is actually bad in some cases, such as ones I have mentioned....

So you've got a feature that's 0% necessary and only 50% useful, while sometimes actually being detrimental....

It's just not an overall good feature, even for the intended purpose of single-player maps.

Do I expect you to remove the feature? No -- I can tell you love it as your special child which you put time and effort and thought into creating ;) But I'm sorry, even though you love it, your special child is a tard XD

Even the people who aren't complaining as much as I am have said that start.bsp should always be the default (with mh's note that this may not necessarily be the case if there is only one map).

Me? I'm a Default Purist. I still am bothered that your pitch settings are off by .17 from default Quake :D

But this -- changing a cardinal menu function? That's so much worse to me....

But no, I don't expect you will remove it.

What I ask is please, please, PLEASE for the love of cake give me the option to disable it! A console variable, a menu setting, heck, a command-line option, ANYTHING so that I can have my Quake and eat it too! Er, I mean, so that I can have my Quake default functionality restored to it's proper functioning like it did back in 1996!


Let me just quote you the words of a wise man, please consider them carefully ;)

"Mod authors almost never intentionally did wrong things, they only sought to provide a good user experience for their mod.

Nonetheless, there are toxic quake.rc and autoexec.cfg files out there.

And playing single player release with the player in control of his settings is #1 for Mark V."

I know you didn't intentionally do the wrong thing, but this setting is toxic to me, and you have taken away my control to even disable it.... ;) 

I would definitely count all instances where the user is instructed to use the "map" command as instances where automatically launching the map is desirable/necessary. Mark V is designed for a plug-and-play experience - you aren't supposed to have to leave the game/engine to read readme files, just like you don't have to with the Quake Injector. 

Don't know. I'm not going to be doing more engine coding until (probably) the spring, except anything I decide to do as a leisure activity or experiment for my own satisfaction.

I won't be making any kind of decisions right now. Nor thinking about the "to do" list.

If I code something before then, it will be a leisure activity or solving a complex 3d math puzzle or something.

Wallclimbing mod

Found the old pubdm mod pretty much written by R00k.

https://www.youtube.com/watch?v=AFtK36d4tpc 

I'd personally discount those that give instructions. People don't read readmes. Never have, never will, you can keep your credit card details in a file called "readme", perfectly safe.

Discount a mod that provides an autoexec. That's the LEAST acceptable method to me (of those you list, there are worse). The mod author is making a statement here: Their preferred settings are more important than mine. That kind of thinking can fuck off. I'm the player, the autoexec belongs to me.

So I make that 9 that are player-hostile (1 actively so) vs 5 that do the right thing. Almost two-thirds.

Now, I'm not saying that Baker's approach is the best. One useful purpose it has served is starting a discussion around this problem, because despite what you claim, it IS a problem. People have trouble getting the Quake executable into the right folder, so you cannot claim that installing and using a mod is an intuitive trouble-free experience for everyone.

Personally I'd love to see something built into the Quake Injector. Maybe something built around Spike's suggestion, or something else, so long as it can be standardized and adopted. 

What do you mean "built into the Quake Injector"? I thought that already handled loading maps without a startmap. 

I'm not familiar with the Quake Injector -- I've heard it mentioned, but have never used it. But I was just thinking, "maybe a good solution would be a stand-alone Quake runner, much like QView, but for running mods + maps.... Maybe that 'Quake Injector' could be made to do something like that."

So yeah, you could have a program that looks like Qview, only it scans your Quake folder for mod folders and asks you which one you want to run, and maybe it scans that folder for map files, and if there is only one it runs that, or it could use a similar "guessing" algorithm to select the most likely start map, perhaps showing a list of those maps with the default one selected. Then you click run, and bingo-bango, it automatically runs your selected Quake exe with command like automatically tacked on (similar to how Qview does it to connect you to a server), with -game +map automagically set for you. (Though Qview just tacks on "-exec Qview.cfg" and puts its settings in that).

Heck, someone should make an updated Qview that can both handle running local mods and connecting to online servers, perhaps with a master server list setting included....



You have a point about people sometimes not reading the readme.... Though I'd think in general if they were downloading the zip files manually and unpacking them, they know what they are doing and would likely check the readme, or would just check the map folder and see what's there. Though the Quake Injector thing might bypass that? in which case, yeah, the user may not check the readme.

Though, in that case, there is the wonderful "Levels" menu in Mark V so they can run the included map (I really like menu, and feel it is the correct and best way to handle maps).


In regard to mods including autoexec.cfg, that actually seems like one of the best ways to handle it to me (even better than just having your map named start.bsp) for the very reason you mentioned, mh -- "the autoexec belongs to me."

Meaning I can edit the file easily to include or remove whatever settings I want. I don't mind the mod author putting his suggested settings in there, because, again, they are easy to change (assuming they don't commit the terrible sin of sticking the autoexec in a pak file, but that is rare).

It actually seems handy to me that the mod author would include an (easily editable) autoexec which will automatically start the intended map.



But yeah, I agree that it would be nice to have something for noobs built into Quake Injector for running mods/maps (if it doesn't already?), or just a new version of Qview with that functionality included, or just a new little stand-alone app (which would be pretty simple, really) that could run mods and/or maps with a few mouse clicks. 

Just a couple unrelated observations because I was starting up the Soul of Evil mod while testing the map running stuff. This mod uses its own start.bsp map.

I use an old version of Fitzquake (.85) for comparison, and I noticed two things:

1. Mark V is smart enough to not use the default start.lit file from my id1 folder.... Fitzquake does use that file, resulting in some... unusual colored lighting effects, heh. It doesn't look bad, it just look different, with strange colored lights splashing on the walls from no apparent source. But yeah, Mark V is probably correctly doing this.


2. Even upon first running the mod (by command line), so there would be no cfg files to read from in the mod folder, Mark V carries over some settings from id1. This can be good or not so good....

It doesn't seem to carry over the resolution settings -- that would actually be a good one to set....

It does carry over controls I have set up, which is good for basic movement controls, but not so good in that it keeps keys bound to aliases which are now no longer set (by the autoexec in id1).

It also grabs the settings I have made in the menu, including disabling the demo playing... and in this case that turns out to be bad, because the mod has a little "intro screen" demo that runs by default.



This is a tricky thing, because it's either "all or nothing" using the settings from id1 (or its hidden cfg file somewhere?) as the defaults in a case where you run a new mod... (weren't me and someone else complaining about that previously? heh).


On the one hand, it's handy to not have to set up your controls again, but on the other hand, generally you should be starting from scratch (with the actual Quake defaults) when you run a fresh mod (or delete your cfg file)....

Of course, knowledgeable users will have their basic keybindings in a separate cfg file which they can exec to set up all their default controls and preferred settings....

I think in this particular case, despite the user setting his id1 Quake to not run demos (because he's seen those 1000 times before), upon running a mod where the setting has not been previously made, the demos should default to play (it's actually an intentional part of this mod's experience).


Hm, yeah, this is tricky. There are good and not so good points about it... in which case I start to lean toward sticking to the default behavior (no cfg? default settings apply).

Perhaps there would be some middle ground where keyboard bindings were retained (not much problem with that), but default settings such as "play demos" are not taken from id1 when a new mod is ran. 

so the shadows(3) sometimes go through walls and floors. bug or a byproduct of the mentioned overdrawing by quake?

I could take SS if needed. For instance dead ogres on top of a bridge are casting shadows on the ceiling when you walk under. 

Bit of both.

It seems possible that this is related to the draw order, and I'm going to work out what the possible best compromise is.

Assuming it can be fixed it will be in one of Baker's spring updates. Until then you need to accept it as a choice between 2 imperfect shadow options.

I think this is the fifth time I've said this... :) 

sorry, i tried going through the whole thread and must have missed it.

Documentation is a little sparse, maybe I'd have a better idea of all these things if I checked the source. 

I thought I would raise this subject here because it seems like Mark V is one of the few engines currently under active development that isn't DarkPlaces.

What do people think about supporting lighting on water surfaces? Personally, I think it's a very nice visual effect and I'd quite like to see it in more engines *wink wink nudge nudge*. As far as I know compilers like ericw's tyrutils suite fork can support it, but I've never played with an engine that actually renders it...

Sorry if this has been brought up before. 

The other thing I thought of asking about is if it's possible to disable the Gamma Protector Clock? It makes my screens flash when it fights with f.lux. 

Go to video options and switch hardware gamma off? 

I'm currently using Mark V 1.20 (not sure if that's the latest version), there's only 4 options under Video Options - Resolution selection, Fullscreen on/off, and apply and test buttons. The only thing I've seen relating to gamma is the slider, but that doesn't sound like what you mean. 

That menu item was added in the current version, 1.36. You'll probably prefer the DX9 build over the traditional Open GL version since it is much faster (nearly 3x faster in many situations), but both are available.