Maybe I'll have to something to go with it soon. 

A workaround might be to disable polygon offset for sprites in the D3D9 build. Only temporary, of course, and it would cause z-fighting, but that seems less objectionable. 

I don't notice any z-fighting disabling polygon offset just for D3D9 -- perhaps because the decals are small, but the decal can slightly protrude off an edge.

Thought I might be able to be clever and switch it to glDepthFunc (GL_EQUAL) but didn't cause the "clip to surface" draw behavior.

But those decals are tiny.

/Causes me to wonder if hipnotic is the only mod that uses them. Almost certainly can't be the case, but I don't believe I have ever run across another mainstream mod that used them. 

A rather heavy update is coming in the next 2-3 days. I've stalled a bit on doing an update because I want the update to have what I want rather than do it in pieces.

(I've also had trouble merging code together with QuakeDroid ... some of merging it hasn't been entirely pleasant.)

Amongst other things, I have controller support which is causing me to debate whether or not do 2 player/4 player split-screen now.

(Except that would push things back maybe a week and I really want to do an update this week ...) 

THEN prioritize your split screen addition. I suggest this for selfish reasons. I've basically switched to using Mark V as my go-to engine over the past few weeks. I'd like to do a video on Mark V as part of my tutorial series and would love to do that over the upcoming weekend. (if the release is ready and stable ofc)

My 2 cents. I'll be doing a QuakeDroid video as well when that is updated. 

Split screen is a significant enough feature. If you're going to do it, if you're going to do it right, then it's worth a release in it's own right and IMO you shouldn't hold up what might otherwise be a significant essential release for the sake of it. 

Good to hear about a new release coming in for a landing!

Controller support is pretty cool. I'm in a phase of playing some couch/TV Quake, and Quakespasm is great for that but it's a little tedious to not have a level-select menu there.

Of course the complete set of "controller support" features would include a menu-y way to also choose the mod and any necessary game switches like hipnotic/rogue/quoth/nehahra... just putting that out there. :-) I know there are reasons that this has not been done by most engines, especially as a top-level menu item. 

Just fyi, my short list of things I consider must have in the release is fixing the unpacking bugs that you pointed out in a couple of .zip files that were packed differently than traditional .zip file releases. 

Ah interesting, yeah please let me know if you make changes in that regard (or just point me at the relevant sourcecode). I want to make sure my little batch file installer continues to work.

If you want to see the current list of things that it works around, you can have a look in https://github.com/neogeographica/quakestarter/tree/release/1.8/installers

There's three kinds of situations where I do something to change/fix files after doing the Mark V install:

1) The special case of making sure that quoth2pt2full gets put in a folder just named "quoth".

2) If the install puts things under id1, I move them into their own mod folder instead. Various reasons for that, but this is not necessarily a problem with the installer (unless there was a start.bsp, like with QUMP for example).

3) If the install fails to extract all the necessary stuff, or extracts some things with a truncated filename because of assumptions about folder structure.


Cases of #2 with a start.bsp: mapjam6, qump, rmx-pack

Cases of #3: arcanum, apsp3, dm4jam, func_mapjam1, func_mapjam2, mapjam6, nehahra, warpspasm 

Very helpful.

I think what I'm going to do is get an update out with what I have done now (I have 2 qmaster items I need to wrap up) and then next do a release with robust installer that handles edge cases and then go from there.

@mh - Yeah, I think I'll just get out what I've got rolling and due to the scope of 2 player/4 player split screen, do it separately. 

if the release is ready and stable ofc

The next release is going to need tire kicking before I'm satisfied that it is "stable".

But the next release should be incredibly robust and might even solve real old mysteries like killpixel's issues with WinQuake version lag (I hope).

I'll be doing a QuakeDroid video as well when that is updated.

Ironically, there is no way to do a QuakeDroid video myself. My phone ... which I love ... is an Android version that can't support video without rooting (which I'm not willing to do).

So a video of QuakeDroid would be nice because I simply cannot do it myself. :(

I went WAAAAAYYY out of my way, to make QuakeDroid as potent and usable as possible ... especially the console (<-- !!!) and the menu.

In past mobile Quake engines including other Android Quake engines, the console is microscopic, the menu non-interactive, poor ability to tune settings, etc. etc. 

controller note - a few days ago, I had the DirectQ source code open was about to more or less take the DirectQ controller support and put it in Mark V.

Then I had a funny thought, could the original Quake joystick code work if sufficiently enhanced. The answer was surprising.

I took the original joystick code and bashed it into a form almost indistinguishable to the very nice ericw/Quakespasm controller code, except it uses the original Windows API functions for axis/button reading. 

When the fov cvar is changed, which player will it affect?

Quake has several client-side cvars that were never designed to automatically handle multiple clients. chase_active, cl_forwardspeed, crosshair, r_drawviewmodel, and so on. And they're usually not binded to any keys, so there's no way to track from which client their value came. Also, some mods uses different default values for them, so if you create multiple copies of those cvars with different names for each player, those mods will be broken. 

You'll be able to look through the source code when it is released. 

Thanks to qmaster for the push to do this. I hadn't considered that idea before he brought it up.

In a non-supporting engine like Quakespasm, trying to load a Mark V multiplayer save will gracefully fail rather than crash the engine.

The awesome thing about Mark V multiplayer save games.

If there were 4 players in the save in let's say it a co-operative game, you can load it with only 2 players if you want.

Or load it with 1 player, haha!

Spike can't even do that :D 

/Jokes aside, the reason that Mark V can load a multiplayer saved game with less players than actually the save game is because I force it to always reserve 16 entity slots, this makes it so the player count not being the same isn't a deal breaker to QuakeC. 

huh? so you reserve a fixed number of player slots exactly like QW does, but still limited to less players?
The down side of that is that it makes servers with up to 255 players wasteful if you're running singleplayer or whatever.
So FTE defaults to 32 slots. If a saved game had a different number (like 255) then it just dynamically resizes the svs.clients array, but most of the time it just uses 32.
Frankly, loading a saved game with a different maxplayers limit is trivial.
The real challenge is making sure the players got the right slot, if eg they connected in a different order (or if someone has since disconnected, leaving a gap in the saved game, etc).

But yeah, I'm unsure what 'I' can't do here. Are you alluding to an FTE bug?
Or is the joke the idea that FTE might not be able to do something?.. I'm confused. 

Haha, maybe the joke is on me because I am now rememebering that conversation. Sounds like you told me the solution and then I implemented it -- and proceeded to forget how I got the idea in the first place.

On the plus side, I went out of my way to make sure the multiplayer save games aren't toxic to other engines.

/Yeah, I considered the issue of future higher max player limits (32, 64, 255, etc.) but realistically my main preoccupation is with co-operative play and I cannot imagine cooping a map with more than 6 players and even then players would have to fight each other off just to get kills. 

Might add, that the multiplayer save games store a bucket of cvars that are traditionally used by servers to use to add an extra level of game state preservation above and beyond the norm.

Quite a weakness in the original Quake save game format is the lack of better preservation of game state, which is more likely to be relevant in a multiplayer game. 

hey, maybe in future we'll see maps with 255 coop starts, and 255 deathmatch starts too.
but probably not.

I agree with the cvars, but you do need to balance between useful cvars and fucking over all the server's settings... obscure stuff like samelevel might sound good to save, but loading a multiplayer game then trying to start a singleplayer game could then screw stuff up, in a way that the user might not be aware of nor know how to fix. One solution is to latch the cvars to their saved values, and unlatch on map changes, but latching cvars gets really messy. 

I agree with that and agree with your firewalled system of settings. Someday I will catch up (although I have some disagreements on small issues).

That being said, you are modding an engine egregiously doing WORSE. Quakespasm runs quake.rc on every gamedir change, accumulating all kinds of random crapola ... including nasty stuff that wasn't intentional.

It is also piss poor for anything except a completely crippled luddite single player engine, especially in the long term.

Do I want to nuke all keys and reset them to default when connecting to a co-op server running a mod? Most people want to retain their keys, sensitivity, gamma, contrast, etc. and the old message about running quake.rc was superior to than implementing some very ... well ... half-assed.

Plus supporting gamedirs like quake/i_like_my_mods_in_weird_places_I_guess_I_dont_play_hipnotic_or_rogue_ever_apparently/travail

Considering Quakespasm Spiked is NOT crippled (great stuff you've put into it), what would you have the engine do if some goofus with a gamedir like that hosts a game with downloads enabled?

/Anyway, end of random thoughts on the multiplayer design topic. 

Clarity: the above is not a criticism of ericw, who I think is awesome. And his game controller code is organized so well I give it 6 stars out of 5, and made non-SDL controller code mirror that refinement!

Spike, mh and myself have long discussed vulnerabilities of things like quake.rc, oddball user preferences and I have personally watched the destruction of at least 3 engines before my very eyes.

I have strong feelings about detrimental features that take away choice or control from users or thrust chaos on them.

When users request things, they often don't understand the implications/side-effects or even how it blocks the future.

I'm not saying the user is always wrong or anything like that, but careful consideration has to be given to future implications of a change.

In the above post I outline how nice things in Quakespasm Spiked are impeded by some changes in Quakespasm basic. 

FTE reexecs configs only if it notices one of the files that it would normally exec is now in a different path.
It also saves its config to try to match the default.cfg (or config.cfg or so).
So if you switch to TF, then you get your mod-specific settings, and if you then switch to one of those map packs (that is only a gamedir because it has a new start map) then you get your id1 settings.
Note that when FTE execs default.cfg then it resets all cvars to their engine-set values before execing the rest of the config, which is meant to block undesired accumulation.
(unfortunately, custom cvars don't have engine defaults, so these don't get reset and can accumulate, especially if they were setaed. I assume that it would be okay to wipe them.)

Of course, this isn't an ideal world, so there's lots of mods that include pointless autoexec.cfg/config.cfg/quake.rc files that do more harm than good, etc. These anti-social mods will end up getting isolated.

Unfortunately other engines don't subscribe to the same ideal either, so they write config.cfg files all over the place and strip all sorts of settings, etc, even if you're not doing gamedir switching. The only way to handle these sensibly is to ignore the damn things completely, using a completely different file instead. Which of course breaks other things.
This is likely why you believe FTE's behaviour to be worse.
My solution: use FTE exclusively. :D



I'm not sure what you mean regarding downloads.
The client should have code to block downloading models named stuff like 'config.cfg', which prevents various forms of evil.
FTE will just automatically switch to whatever gamedir the server says, reloading configs only if it actually makes sense. FTE also attempts to download packages rather than files, and these have explicit gamedirs attached to them (but gah, remodelling packages!), unfortunately there's still a LOT of legacy servers that have no support for packages at all (nor the versioning that they can provide).
Regarding QSS, I never actually got around to getting it to automatically switch gamedirs (no mod-isolation code meant that I bottled out of trying), so yes downloads may currently end up being written into the wrong gamedir. :(
It does at least warn if the gamedir is wrong, but yeah, noone pays attention to warnings. 

These anti-social mods will end up getting isolated.

That line of thinking requires too many things that are false to be true.

The day of the curious user sailed long ago, today Quake is a commodity.

That doesn't mean there aren't curious users ... there are!

And if you think for a second, I've managed to do a Pokemon and "catch them all" with Mark V while punting the Steam noobsters off through trickery.

It's the Baker "cream of the crop" thiefdom steal.

And quite deliberate. So I get the brilliant ones and talent ones, while SteamNewbster123-where-is-my-Quake-folder is learning with some other engine.

The "haha funny" is that tomorrow never resembles the past. But tomorrow is easy to predict.

Tomorrow is coop.

When tomorrow comes, there won't be room for engines that suck balls at coop.

I've been saying this for years.

Sometimes I got mocked for saying that in the more distant past (I'd snicker a little and say nothing, in Steve Jobs style because I knew why -- "why" is a useful thing ... if everyone knew "why" the world would be boring and I'd never get to make fun of people for being wrong --I'm made out of a human so yeah, everyone has their faults, I'm a prankster by nature) -- but today everyone sees cooperative play knocking hard on that door.

Users often describe "tomorrow" as "today" thinking tomorrow resembles today. But that kind of "me too" thinking is why no one uses Windows phone, why Steam Machines isn't a thing, why BlackBerry was once king and is now dead.

Tomorrow isn't today. It is like "today", but more aggressive form of today.

What does tomorrow want?

/Question of the day. Someone mocked me for saying I was going to make a Quaddicted install (*cough* Spike!) then proceeded to make his own Quaddicted install in FTE. So yeah, like it or not, I suck because I understand what tomorrow is going to bring with some level of consistency but it isn't magic or even me -- it's just connecting obvious dots in an obivilious world. Not my fault!

A great question is why does this matter for a volunteer engine coding for a 22 year old game? But this rhetorical question is just me being a smart-ass again in a lot of ways -- in my head the answer is that if you can't win the small ones, how could you win the larger scale real-life ones? Which is why I find engine coding entertaining, everyone tries their best to do things right because it is somehow reflective of result generation on a larger scale.

Plus it is fun with those you've known the minds of for years!

/End stupid commentary. My next post is probably an engine release which has been compiled for 4 hours, but I have 4 beers left and we can't have that can we? 

We live in an increasingly mobile world. Mobile phones today have 53% of gaming revenue.

Quake's future will be partially on mobile phones. (Duh? Surprise????) Ok, no really).

Software decoders on phones eat 60-70% cpu. We all know CPU is battery.

That's ok. There are hardware decoders that take precious little cpu.

Clue: Hardware decoders ... 100% mpeg everywhere that means MP3.

Ogg? Uh. That's like 0%.

And if you can't hardware decode a music format on mobile, it has no future.

Now if Quake is to have a future (it does) and if part of the future of Quake is mobile (it is), where does ogg fit into that future?

Well ... under the stupid person's plan you could have ogg on the desktop (oh wait! Quakespasm supports mp3) and mp3 on mobile.

OR?

OR?

OR?

You could have MP3 everywhere.

Gee --- I wonder how this ends?

Ok --- no I don't. I've known how this ends quite a long time.

It ends with MP3 everywhere. It always did.

/Understanding tomorrow means you can extrapolate what to do today