Mark V - Build 1050 - Ultimate Mouse Driven Menu Edition
Direct X 9 - Mark V 1050 - Windows
* Fully mouse-driven menu yet it is the classic menu.
* Tool_inspector works again. (Pritchard)
* Load game + death bug fixed. (Pritchard)
* Numerous other small enhancements/tweaks.
Special thanks to Pritchard in particular for bug reports and so it took this long for some of them. And probably Gunter when he isn't annoying or ticking off MH. Thanks to all other providing feedback, bug reports, suggestions, criticisms. And perpetual thanks of course to MH, Spike, ericw and metlslime.
I had hoped to get this out a day or 2 ago, but I wanted to get the mouse-driven menu tuned to exacting specifications.
Also mouse-driven was very, very, very hard to do. The Quake menu code is some of the ugliest in existence.
@killpixel, c0burn - I expended all my energy getting this across the finish line. It was harder to wrap up than I expected. @ Tribal - yes, and maybe Gunter will make himself useful and tell you how (type "find qmb" in the console and it tells you different cvars to turn stuff off) -- because I'm a bit sapped.
(mh note: scr_sbaralpha doesn't work with DX9 -- tried some tweaks/hacks but still failed -- and is the sole deficiency to what otherwise should be a rock-solid release. If some time in the future you had some time to check it out at a time of your convenience, that would be cool. No rush ;-) And thanks for your contributions!).
@1830 unnamed guy - "I think sv_aim belongs in the preferences"
Well, it is in preferences!! Haha.
You're awesome =D
"And probably Gunter when he isn't annoying or ticking off MH."
I don't think that ever doesn't happen.
It looks like the previous issue has been fixed where you could see "the sky" through entities. It doesn't seem to happen any more. (#1665)
You can still see shadows though entities but only if you have set r_shadows 3 (I know those are experimental shadows though).
I have a transparent fake player guy inserted by the ent file, and he is only transparent if I set gl_fullbrights 0. If I set it to 1, he's solid. I'm sure I've mentioned this before. Ah yeah, looks like it has to do with fullbright textures (#1082, #977). That probably wouldn't be the same issue with the scr_sbaralpha.
gl_overbright_models 1 can also allow weapon models to be properly transparent when you have the ring, but not the transparent entity guy.
Yeah, as Baker said, you can use "FIND QMB" to see all the QMB effects. If you really wanted only the lighting effect, you'd have to have "QMB_ACTIVE 1" and "QMB_LIGHTINING 1" but have all the others manually set to 0!
I would suggest doing "FIND QMB" then type "COPY" to copy all those variables to the clipboard, then paste them into a text file and edit the file to remove unnecessary text and change the values of everything to 0 except the things you want. Save it as a cfg file then you can just exec it.
Gunter +1. He might know the engine better than myself, haha.
Let's man up. Besides I am feeling the code rage ...
March 9th. New feature.
I shock your world. SUBMIT!
Marking The Calendar
It works like a charm =D
Tho only thing weird is when I set the command "qmb_blood" to 0 it doesn't change the blood to particles, it mixes red particles with blood sprites o_O
Hey, you're right. "QMB_BLOOD 0" doesn't deactivate the QMB blood.
You found a bug for Baker to fix!
You're an honorary Junior Grade Gunter now!
Find about 500 more bugs and you can almost reach my level ;D
scr_sbaralpha doesn't work with DX9 -- tried some tweaks/hacks but still failed
Had a quick look over the code; you don't seem to be setting glTexEnv (GL_MODULATE) when drawing alpha pics in the status bar (compare with the setup for Draw_ConsoleBackground). In theory that shouldn't work in GL either, so I guess you just got lucky that drivers accept it, but you really should fix it for both.
That fixes it.
Interestingly, it's also a bug inherited from the original FitzQuake code, so it's been around for a while.
Hello and thanks for the this great engine!
I was making some tests running custom code for a mod and using "eprint" to debug some entities. However, this is making Mark V run unplayable with very low fps. I think it might be a bug, because other engines doesn't have that problem.
Also, loving the mouse features.
Congrats On The Release Baker
Mouse Driven Menu
feels really good, thanks!
Finally fired this up today. It's great. The mouse menus are very nicely engineered. The engine is snappier too I think. GG
@mh - oops! Thanks! I'll see if I can fix. I'm glad you are always in "rendering godmode" because I shift and fade focus. Haha!
@ericw - Thanks, obv! If you weren't around, I think I might feel alone because mh and Spike seem to know everything and it feels like only you and I have to scale up and grow, haha!
@dumptruck - Yeah, time and energy expended to make it perfect. Meticulous.
@hipnotic rogue re: joystick - I care about joystick. Right now, I'm not zoned into that but have "THE QUAD" running in some other departments and I need to kill the monsters my QUAD can nuke quickly as I don't have unlimited time.
@fifth - Thanks! I haven't forgotten about about joystick/four player. I need to level up to that point, killing some zombies immediately in my sight that I can kill. I want to see if I can reward Spirit emotionally. Spirit has made big sacrifices to build something awesome/nigh impossible and in my heart I want his ideals to come true. Plus when I see people stressing Spirit out every once in a while or accusing him of not doing enough, I just don't think that should be the reward for building something.
@epiolon - '"eprint" to debug some entities' Ah, I'm not Mr. QuakeC so I figure that is QuakeC printing of some sort .. perhaps a more QuakeC dev can translate to what causes your issue.
I think we need to blame Gunter that you found a QMB cvar bug. I am really disappointed that Gunter let that slip by his bug testing.
I expected more from him, haha!
Standard Con_Printf will do a full screen update.
This is really useful if you're printing some text and you want to see it on the console right now.
It's painful if you're doing lots of small Con_Printfs to print, say, an entity, because each entity printed could trigger tens of screen updates.
If you have console logging to file always on it's also going to be constantly hitting the disk - again, tens of disk writes per entity.
Changing ED_PrintEdict to use Con_SafePrintf can help with the first. For the second you really need to do what the doctor said when you told him it hurts everytime you do this.
I look into that, I get your drift. It isn't priority #1 on my list, but yeah message received.
Addendum: Despite 12 beers to end a wonderfully chaotic weekend, sounds like an easy fix.
March 9th surprise is going to be a total blast!
Con_Printf's screen refresh kinda sucks.
1) its slow!
2) ANY prints inside the drawing code results in recursion, and then more recursion, and then eventually CRASH! catching out many newbies.
3) if your drivers are tripplebuffering then its going to show the wrong print last, which makes it really misleading.
4) a number of frameworks don't allow you to swap buffers yourself making it a complete waste of time.
If you trust the engine then its redundant anyway - win32 engine devs are probably better off using OutputDebugString, while unix users will have working stdout. Its really only dos that 'needs' prints to be displayed onscreen NOW.
imho just redraw the screen only when developer is set (and when not recursing), then users can won't be sitting around waiting for the loading screen.
The one exception is with the connect command, but imho that should be made to be non-blocking anyway.
in the mean time, disable vsync.
I will avoid using the function for now.
But seems like there's no vsync option on Mark V (and i usually disabled it because of input lag)
if you do "find vsync" don't you find vid_vsync?
Maybe it should be a menu option!!
*hears Baker frothing at the mouth*
Hey, I gotta leave a few bugs unreported so everyone else can experience the thrill of ... reporting bugs!
Hm, it looks like I did mention in #653 about blood and fullbright, which you looked into but couldn't exactly fix. mh mentioned there's a 1 and 2 setting for QMB blood. I had suggested adding some standard particles into the QMB effect to allow some fullbright to still happen.
Tribal mentioned: "when I set the command qmb_blood to 0 it doesn't change the blood to particles, it mixes red particles with blood sprites"
I am not at my Quake computer at the moment -- I'm wondering if maybe you did mix in some regular particles for the 0 setting, instead of disabling the QMB effect.... If not, you should have a setting that does do that! I guess qmb_blood 3, if both 1 and 2 are already used. What is the difference in them?
MarkV seems to have console debug logging enabled by default, so it does hit the disk for every Con_Printf, meaning that debug printing of entities will be incredibly slow.
Glad to hear you're still working on the split-screen.
No idea if borrowing the controller code from QS is possible but I'd say it works best there by default.
I'd say that having multi-controller support/setup would be best placed in the multiplayer setup menu.
Would be awesome if going into the multiplayer setup menu also dropped straight into split-screen and each player could adjust their own character colour, name and bindings.
I suspect it'd be a huge undertaking in code but would be super awesome for couch gaming, something that would probably go down really well for those who launch through steam etc.
So Where's This 9th March Surprise ;)
That's The Surprise
He vanished. Not exactly what we all thought or needed, but definitely a surprise! :P
I Predict STILL Hungover.
It seems that QMB_BLOOD 0 causes all kinds of particles (not just blood) to be a mix of QMB + Standard particles -- my blue water splashes and grey chat smoke, for example (I use lots of particles in FvF).
Also, OGG support, please!
Update! Part 1 ...
No I didn't vanish. Despite my stupid drunk posts, which when I get the time I intend to apologize to snug for ... I had some "coder frustration overload" + way too much beer.
Which is a nice reminder of why to patient, humble and kind. Coding is like a deathmatch against unmovable objects. You lose. A lot. Sometimes hard.
It is not fun to lose, nor lose hard. And I did not take it well that particular day.
Update Part 2
I missed the target date of March 9th.
I expected rolling over the coding problems and instead got socked with several deep and severe issues. The issues kept building and building.
Eventually, I toughened up and geared up for a brutal fight. One which I won 3 hours ago.
24 hours: Version 1.70. Part 1 of 2.
Both Part 1 and Part 2 are going to change things quite a bit.
And I'm not going to ruin the surprise, but a couple of developers likely suspect what's up.
Add: Many people may think Quake is dead.
It isn't. Quake isn't dead. It is asleep.
In the next 24 hours, we will not be waking up Quake.
But it will be great eye opener of precise the manner of which it can be done!
He goes from "drunken poster" to "vague mystical guru posts."
Either way he's working on Mark V, so it's good.
I also need to get drunk. Otherwise I am not able to understand these mysterious announcements... xD
In the next 24 hours, we will not be waking up Quake.
Quake will be waking us up. Showing us that what we thought was reality, was in fact a dream all along.
Looking Forward To It
Really enjoying 1050. Although I am getting a water warp message in developer 1 even when there are no liquids in the map.
Will It Run
... all maps of the latest "Arcane Dimensions", that's what we are all wondering about! :P
But seriously, right now I wouldn't know how you could significantly improve Mark V beyond its already impressive feature list. Baker implemented pretty much anything I asked him. Sure, OGG music support would be nice, but Baker's teaser indicates it's gonna be a lot bigger than that.
I Dunno, Ogg Would Be Huge
OGG support, please!
Hey, how does everyone else pronounce this engine's name?
I was on Discord talking with a guy who is doing some Quake streaming on Twitch (twitch.tv/dirtgod) and he was saying "Mark 5" but I always say "Mark Vee" ... :?
V Is The Roman Numeral For 5
I was born in MCMLXVIII
Yeah, V is the Roman Numeral for 5, but with Mortal Kombat X, for example, X means 10, but the official pronunciation is "Ex" (says Eb Boon: https://twitter.com/noobde/status/473572797684256768?ref_src=twsrc%5Etfw
X is 10 because V is 5 and X is an upside-down V with another V above it. 5+5=10.
This is a case of video game marketing and communities ignoring an ancient numbering system from one of the most powerful empires in history.
Who wins this one?
Mark V Build 1080 + Touch Screen Support (iPad/iPhone)
Download: Windows | Direct X | Linux | WinQuake
(Plus a WinQuake GL for KillPixel and a couple of others)
Source code: here
iPad/iPhone source code is in there.
* Full multi-touch iPad/iPhone source code for an experience rivaling Minecraft for the iPad in user-interface.
** Drag look just like Minecraft
** Adjust sliders in the Quake menu by touch
** Optional support for bluetooth keyboards like the $7 ones
at Walmart that support iPhone and Android.
** Tap fire. Double tap on the Ogre to fire at him if you like.
** 5 taps to host a "New Game" (cooperative).
** At the moment, it is the WinQuake build, can't muster up the stamina for the Open GL at the moment.
** Thanks to Mark V LAN discovery borrowed from Spike's fine work, "Join Game" for a LAN game is a breeze, just like Minecraft.
** Any map that works in Mark V, works on the iPad. But the iPad gets lower frame rates than a desktop, so standard Quake maps are plenty fast but it is likely that a 400 monster map with open spaces would run unacceptably slow.
* Mouse-driven menu on Linux and in WinQuake
* Touch Screen mode that I hope works on, say, Fifth's Surface Pro. All builds have a touch screen option in video options. Unfortunately, I do not have Surface Pro so there is not multitouch support, I would not be able to test it.
* Direct3D sbar alpha works thanks to MH's tip.
I may or may not take a quick stab at an Android port. If I were to do such a thing, it would likely be basically done in a 48 hour period. My main concern is that I think for Android I was use SDL2 and if I recall, SDL2 had a sound lag issue for me on Android -- and if it sound lag, I would be irritated.
This is Part 1. Part 2 comes in a few days, has nothing to do with mobile devices.
@Tribal - I took a quick look at the qmb_blood option, isn't quite the quick fix I had hoped. Thanks for the bug report.
The LAN discovery feature is good news! As for iPad support I am... bemused but entertained? :-) I am inclined to steal my wife's iPad mini to check it out, altho looks like I'll need to figure out how to build it?
I've Got A Surface Pro 2...can Test Later
But I can't think of a use for multi-touch unless the Win10 build also has the touch controls for movement.
And I was concerned with your health... Coding and drinking doesn't go well for me, so I never drink.
"Unless the Win10 build also has the touch controls for movement."
Video Options -> Touch Screen
Without multitouch, you can only touch one thing at a time, which sucks compared to the iPad version where you can press 3 things on the screen at the same time.
@johhny - To build for an Apple device, you have to have a Mac. My source code is friendly, you literally click "Build". But the sticking point is having a Mac. Plus, iOS has some new red tapes that iOS 9,8,7 didn't and the project probably doesn't meet those red tapes so you might have small chores like making a 98x82 icon and a 196x163 icon and 10 other pesky nuisances like that.
That being said, playing on the iPad version is un-fucking believable. When I got the multitouch interface working right and then loaded it up, I was not prepared for the level of awesome.
Thanks! Nah, my health is 2x awesome.
I encountered Level 92 frustration developing this version, it was so frustrating at one point.
I had to get real tough and prepare for a dog fight in the mud. Obviously, I rose to the occasion. Besides, can't have mh or Spike thinking I'm not hardnosed like they are, haha!
multitouch is surprisingly useful for touchscreens even if not explicitly needed by the app's UI, just for example having it not ignore a second tap because your finger from the first tap hasn't fully lifted off the screen yet, or, not completely ignoring everything you do because your hand holding the edge of the tablet is slightly touching the screen edge.
Techical Note @ Qmaster
On an iPad, you can touch 16 things at the same time.
If mh reads this, he may recall I implemented his "single point of checking mouse state per frame" mouse input paradigm long, long ago in Mark V. This version of Mark V extends that philosophy to the touch controls activation/deactivation and it was at first a major nightmare, but then it collapsed in simplicity and beauty after a dozen revisions.
I have the multitouch tracking everything.
The user interface only acknowledges one press per button where the whole screen is a separate button.
To access the menu, you press a transparent triangle hint in the top left corner.
A funny thing, I was thinking of you off and on while writing this. To the best of my knowledge, you and Sleepwalker are the only other 2 that I know for sure is familiar with the ins and outs of the Apple interfaces and while well conceived, they required quite a bit of learning to use properly.
But There Will Be
... a new OpenGL build, right? That's the one I am religiously using!
Is there something that the DirectX 9 doesn't do or some specific reason it doesn't meet your needs?
The DirectX 9 version is, in my view, absolutely superior in every way.
1) Does everything that the Open GL does (99.9% on that).
2) Vastly higher frame rates that blow away any other Quake engine except DirectQ and only eeks out a small win against FTE Open GL (FTE Direct3D likely beats Mark V Direct 3D because FTE has better rendering code). MH's extreme craftsmanship of the Direct3D 9 wrapper allows Mark V Direct 3D super-speed despite the fact I should rewrite the underlying rendering to probably get another 75% to 100% speed gain.
3) Bad Open GL drivers? NVidia doing a wacky update -- Direct 3D is immune! Can't happen. So stability + reliability +++. I get a bit tired of NVIDIA doing some update and it breaks something in Open GL, but the Direct X cannot be updated by NVIDIA (this is my understanding at least, and I think I am right).
Those are my thoughts.
What does your Linux version use? I'm clueless on this stuff but hope to have a Linux machine up sometime soon. Also any clue as to why I am getting a waterwarp size is 1024 message in developer 1? No liquids?
Hmm. Lots of duplicate symbol errors when linking the iOS build, conflicts between input_surface.o and various other .o files.
My first guess was that it might have to do with eval_flags/eval_frags being declared as int rather than extern int in progs.h, but changing that didn't help anything that I could see.
Will give it another whack later.
Waterwarp Size Is 1024
I think that message comes from code I wrote. I'll review it hopefully tomorrow and see what the cause might be.
I use Ubuntu but the Linux binaries works on a fair number of other Linux distributions, or so different Linux users have said.
@ johhny - if I recall, there are 288 source files but if sometimes seeming randomly -- like maybe if it targeted the simulator or a generic device? -- XCode would try to compile 568 files. I plugged in an iPad and targeted that and it works fine. I am using XCode 8.2, I think the current version is 9.2 and since it seems like every XCode upgrade introduces some quirks/inconveniences to tackle, I put off upgrading a bit. Short version: Couldn't quite say,
OK. I'm targetting simulator at the moment. Will wait until later when I can plug in the iPad.
@johnny ... be sure create a folder called id1 in Documents on the iPad and throw pak0.pak (and pak1.pak) in there.
I can't remember the method to put files on an iPad offhand.
Note to self: Use Mark V http download offer to download pak0.pak or something on startup if it doesn't exist in the next revision.
Direct X V1.80 Build
I have taken a quick look at the Direct X build and it seems to look and behave just like the OpenGL one, so I stand corrected with my prejudices. I cannot say much about speed differences, but it feels smooth alright.
Still missing my favorite gl_nearest_mipmap_linear option, but besides that, it's all fine.
Is this build capable of running all the new maps of Arcane Dimensions now, btw?
I need to add Sepulcher support. It is on the "todo" list.
My first priority is getting new unreleased capabilities off my hard drive and into reality.
Then I'll be adding things like Sepulcher support, etc.
Go to Video Options -> Pixelization.
I'm 99.9% what you want is in the DirectX 9 build.
Let me know.
waterwarp size is 1024
This is just a notification that should only happen at startup and when/if the video mode changes. If it's happening more often (every frame) it's a bug. It's nothing to do with water surfaces but is rather used for the underwater warp effect.
It happens even if the current map has no water because the next one (or the previous one) might.
The alternative is to destroy and recreate the texture each map, which could lead to extreme video RAM fragmentation, or to create it on-demand which (in addition to fragementation) could cause runtime hitches and stalls. So I decided instead to burn a little extra memory in exchange for performance.
This should be fully supported; I've reviewed both my original wrapper code and the MarkV implementation and can confirm that.
I actually checked explicitly for that. The only options for the pixelated look are gl_nearest and gl_nearest_mipmap_nearest. Just like in the previous (OpenGL) builds.
Smooth mipmaps transition ftw! ^^
It should be settable from the console though. If something's missing from a menu option it's nothing to do with the API used.
Egads. I version 1.36, I had gl_nearest_mipmap_nearest. Then I knew it needed to be the "other one".
So I switched it to gl_nearest_mipmap_linear. Then I forgot I did it.
Then I worked the todo list and switched it to the "other one" again and since it was gl_nearest_mipmap_linear in the source, I changed it to gl_nearest_mipmap_nearest.
Then basically you switched it twice so it was effectively as if you had never changed it?
Well, now please just change it ONCE again and I can die happily. ;)
I'm trying to cause this developer 1 + r_waterwarp message, but not having any luck.
Line 812 of gl_texmgr.c is where it happens.
Mark V - Buiid 1081
Direct X | WinQuake
- Windows rebuilds
(killpixel's winquake gl in there too)
Got rid of dumptruck's warp message printing in developer 1 and another message that was spamming some, gl_nearest_mipmap_linear replaces gl_nearest_mipmap_nearest and fixed noticed the menu being drawn during QuakeC or demo playback or disconnect go to console.
That was a really fast fix. Thanks a lot, Baker! Another proof that Mark V should be anyone's favorite vanilla-style port since it's handled so well! :)
thanks for the update!
Mk V DirectX 1081 crashes to desktop without error message (just the usual Windows notification that the program "stopped working") when trying to use the remade ogre model by Chillo:
Download (1.0 MB):
Tested in E1L2, crashed right away. The model is quite big, but I dunno if that's what's causing the crash.
What engines is it known to work in? It looks like DarkPlaces and DirectQ.
Mark V supports 3984 verts, the maximum possible in WinQuake according to a note by aguirRe.
If it works in Quakespasm, for instance, let me know.
It also works in my original FitzQuake implementation that I built the D3D wrapper on.
Model loads without issues in latest Quakespasm 0.93 x64 build. According to QuarK, it has 1290 triangles.
Number of triangles in a .MDL file can be very differrent to number of triangles in an engine. Most engines will unpack them to strips and fans for drawing whih can change the counts quite dramatically.
Basically, it's completely unsafe to limit the verts in a GL engine to the same limit as is used in software.
@Baker: running a debug build should tell you exactly where this crashes.
Another Model Issue
Another of Chillo's models, the Shalrath, gives an error message when trying to load the model:
"Skin taller than 480"
Package with model (shalrath.mdl):
Ignore my last report. Just took a look at the Shalrath skin file, it's obviously a placeholder. It's just still about that ogre model, then.
E4M6 crashes with the Authentic model improvements pack. This used to work with previous (OpenGL) builds of Mark V.
Download model pack:
I could not identify which of the models is causing the problem.
Map Crashes (summary)
There are more maps that crash. I checked all maps of the original campaign and the model improvement pack does not work in these levels:
E4M6 (as reported above)
These maps likewise work fine in my original codebase.
It's obviously a model that's common to them all overflowing an internal buffer that's differently-sized in MarkV.
I found the model that causes the problem. If you remove the Fiend model from the improvement pack (demon.mdl), the maps stop crashing.
This leaves two models to be investigated, demon.mdl from the existing improvement pack and ogre.mdl from Chillo's release.
The only thing I can find as a possibility is mipmap generation for non-power-of-two textures.
In my original code I let D3D take over mipmap generation, whereas MarkV retains it's own mipmap generation.
These models have unusual texture sizes: odd numbers, not multiples of 4, etc. So when you go down a miplevel you need to be aware of whether you are going down exactly to half size, or if rounding down is involved, and depending on how the engine handles memory allocations for this, it may trigger a crash.
Well, curiously the models won't work with Mark V 1.36, either. I just tried. However, they should since I remember playing through the entire game at least with the demon model since it is already in the improvements pack.
If It Helps...
I just tested various DX9 builds from previous Mark V releases. The last one that works with BOTH models without crashing is 1.27 rev. B:
Starting at 1.28, the crashes start:
Hopefully that narrows it down for Baker to find what's causing this.
Time To Dust Off The Surface...
That is a high quality investigation, thanks for the detail that should make tracking this down easier.
I guess I'll do an OpenGL in the next one *only* for the purpose of trying to nail down what is going on with this.
I *do* want to know what the differences are and unwind this small mystery, but also I want to get some more new stuff out. I want to get new concepts off my hard drive and into reality.
Speaking of which. I expect a new version with something quite new in 24 hours. Maybe 36 to 48 hours because I had to kind of fork the codebase and need to "unfork" it to get the source code tidy.
This isn't the "big one". The "big one" is still a few days out.
@fifth - Really?
I thought you used your Surface Pro all the time.
Map Hard Crashes 1.81
I am testing maps for dm4 Jam on Mark V 1.81 One of the maps uses a trigger_once to trigger a map hack using an info_null using W_FireLightning
The engine freezes and I have to Ctrl+Alt+Del to kill it. Here's the map and source.
It's the large trigger once immediately after the info player start.
Map plays on most recent versions of DarkPlaces, FTE and Quakespasm
In Order To Avoid Misunderstandings
These crashes with high-poly models occur in both DX and OpenGL builds starting at 1.28, doesn't matter which one you use.
This also explains why I remember the new Fiend model working - last time I launched Mark V was well before summer 2017.
I rarely use it tbh, I may use it more since I get extra long lunches now and could map in them.
It has some issues with keeping charge and the keyboard isn’t great so this is why, plus I have a decent PC anyway
I remember finding out that the skin loading code for either SPR sprites or MDL models in vanilla WinQuake has a bad pointer arithmetic. I really don't remember exactly where it is though, but its badly offset by a very small value, something like 4 bytes. I remember being surprised that it didn't cause any crashes.
Dear Spike, gamers, programmers and Quake fans. Could any of you lend any knowledge about multiplayer capabilities for FitzQuake Mark V? Does one need to setup static ip, forward ports and establish DMZ for good old coop with a friend over the internet (local server)?
I found Mark V enging is very good and i love it. But Quake without coop is not complete.
As far as I know you simply have one player start the game as a host and the other type in the IP address of the host in the join menu, same as usual. 192.168.whatever.whatever.
On Windows you can do Winkey, type run, hit enter, type ipconfig, hit enter then look for ipv4 address.
You're assuming a LAN game tho. Cadaver747 sounds like probably he's talking about co-oping over the internet?
Baker would of course be the best guy to ask about Mark V's port usage. I'm pretty sure I recall that he's included some of the fixes done in a few modern NetQuake engines so that it only requires its single listen port (26000?) to be forwarded.
for engines using a single server port, just reconfigure your router to forward that sepecific port (26000 for nq servers, 27500 for qw servers) to your machine, then eg google for 'ip' and give that to your friend to connect to (don't depend upon windows - it'll show you addresses that are only valid on your lan, which is not what you want).
for other engines, you'll need to set up dmz stuff crippling your router's nat+firewall stuff, as get your friend to do the same.
all quakeworld servers+fte+dp+qss+markv use a single port for connections. the rest all suck big hairy donkey balls (including quakespasm) at least for internet coop.
this is not the only reason that most people favour quakeworld for online play, prediction is another significant factor...
sidenote: with the exception of non-fte quakeworld, the above engines all also support ipv6. assuming your isp isn't dragging their heals and generally being lame then ipv6 makes things cleaner by removing the need for NATs. You'll still be firewalled by any good router though.
lazy people: if your router follows certain ICE-friendly rules (eg most home routers but few business ones), you may find that just setting sv_public 1 on your server is enough (the heartbeats should automatically open your firewall/nat).
the other person can then use their client's menus to find your server according to its hostname cvar - if they can spot it. This should be true of FTE+DP+QSS, but I don't think markv supports any real master server protocol so good luck with that.
probably the server listed by the master will appear to use a different ip+port, that's just the nature of NATs, but means they can't use a direct connect command.
But again, this depends on the server's router, so it might not work. Setting up explicit port forwarding on your router should fix it for any other routers.
do not use 192.168.x.x over the internet. it will not work. 169.254.x.x won't leave your lan. 10.x.x.x is another unroutable one, 127.x.x.x is also not going to work, 172.16.x.x/12 isn't going to go far either , and 100.64.x.x/10 means you're fucked and need to get a new ISP (carrier-grade NAT - this would only be between you and your isp, so you're likely to be screwed without otherwise noticing it) - ipv6 is your only real choice when it comes to CGNAT, or just get the other person to host.
Mark V Multiplayer Works!
Thank you Spike! I tested Mark V 1.36 and 1.60 (beta) for coop with my friend over the internet today. It works like a charm, just a simple port forwarding from my external ip 77.50.xx.xxx to internal 192.168.x.xxx (for port 26000) and that's it!
You wouldn't believe what i tried to do to play Quakespasm online. Mark V rules!
Too bad not all maps from Arcane Dimensions currently supported by it. But i'm sure that'll be fixed in time.
Cadaver747, you and your friend could also try connecting to FvF, which is almost always in co-op mode. Then you don't have to mess with running your own server (though it sounds like Mark V made that easy for you anyway). Other people might connect to FvF and join you as well. It's... different than standard Quake, with lots of cool options and enhancements.
Arcane Dimensions (only 1 Map To Go)
Correction, only 1 map doesn't work, it's ad_sepulcher (The Forgotten Sepulcher).
Host_Error: ModLoadLeafs: 74168 leafs exceeds limit of 65535
Thank you Gunter, but unfortunately your server is not meant to connect from my country (Russia), ping is almost 150. The idea of implementing RPG elements in Quake is quite interesting though.
ad_sepulcher needs a bit more than just the standard "big map" support.
It's also the case that there are a handful of big static arrays scattered about the engine for which, by the time you move to supporting ad_sepulcher sized maps, you really need to move to dynamic allocation.
Finally, ad_sepulcher is going to run like shit in the GL version of MarkV because it still uses glBegin/glEnd code. It will run fine, but still far more poorly than it should, in the D3D9 version because it's transferring a lot of vertexes that don't even change to the GPU each frame. The particle system may however kill it with draw call counts; IIRC there's some very sub-optimal state change stuff hanging over from the original GLQuake still in the sprite code, and that's going to prevent the D3D wrapper from being able to batch things up.
Man, I would have killed for a 150 ping 15 years ago when I was still using dialup and playing lots of Quake, and still kicking butt in deathmatch :D
But these days people think a 150 ping is unplayable, even in coop! ;)
ad_sepulcher doesn't run reliably in QS either. It crashed from time to time while I played, which forced me to quicksave often.
Making an engine that runs it reliably seems to be one of the ultimate challenges in Quake engine coding.
That's interesting; I would have thought that QS was the target engine when the map was being built, and would have received the most testing through all iterations of the build.
I Thought QSS Was
Well, my laptop has an Intel HD Graphics 3000 GPU and 6 GB of RAM, running Windows 7 64-bit. And the crashes happens after exploring the map for a while. First the engine starts stuttering and the hard drive starts making noise like crazy, and then the engine crashes.
...the hard drive starts making noise like crazy...
Sounds like something else wrong with your machine that's only manifesting when it's under a particular load. There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.
OGG/MP3 Using Fmod
Baker I'm 99% done adding ogg/mp3 to Qrack using fmod.
It's *way* simplier than you might think. Only thing i have to do is add a cvar to init/uninit the fmod instead of using a command-line parm.
I can shoot you a copy of my fmod.c file. There are other entry points where it plays cd tracks but they all points to functions contained in that one fmod.c file.
It's so simple i was kicking myself for not adding it sooner; not until i read here people yelling "OGG SUPPORT!" did i even pursue it. Know you use fmod, i thought i'd pass it along.
I'm not sure if there is anything special about ad_sepulcher that makes it difficult to run - it has careful visblocking and with the fixes to func_detail in qbsp I made, the PVS is good quality. I'd expect it to have similar fps to other large maps in AD (and it does in my experience).
(The exception is if the engine supports the fancy particle extensions, i.e. QSS. Particle effects for all torches in the map render every frame without regards to the pvs. Also, various particle effects cause tracelines to run. This applies to all of AD, though it probably has the biggest hit on sepulcher due to probably having the most torches.)
Sorry to hear it crashed for you mankrip. The only thing I know that could cause disk thrashing is Quakespasm uses the original Cache_* code, which, if the cache is too small, will cause it to read MDL's off disk every frame. This is something I want to fix and I know of mh's tutorial on insideqc about it. Do you remember if you used an explicit size with the -cache command-line argument?
There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.
Windows automatically stores RAM contents in the swap file, you know. And it also happened without anything else running, right after I had to reboot because the whole OS got unresponsive.
I might run it again later and take a look at the RAM/CPU/etc usage in the task manager.
Do you remember if you used an explicit size with the -cache command-line argument?
IIRC I've only used the parameters recommended in the readme file. I may look into it after going back home.
There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.
If the quake cache is too small, quake will keep unloading models to make room for new models. A bigger heapsize solves this I think. (in engines with standard quake caching/memory logic.)
Yeah, the caching system is really the only thing, other than some kind of hardware failure, that could cause this.
It's worth observing that if one is using a replacement/"improved" MDL pack, they're going to consume more cache space and therefore have a higher likelihood of triggering this kind of behaviour.
This seems to have gotten lost in the noise.
From the description it seems that MarkV doesn't have the robust SV_TouchLinks fix. Some discussion: http://forums.insideqc.com/viewtopic.php?f=3&t=1431
Just had a look at the MarkV SV_TouchLinks fix. It's, umm... unusual...
My recollection is that QSS has a sensible fix that's absolutely trivial to lift over to any engine, so that should be the way to go.
An interesting observation about MDL caching.
It's possible for 2 or more MDL files to only differ in terms of the skins they use; otherwise they have identical geometry (vertices, frames, triangles, stverts).
You'd think this would be a theoretical possibility at best, but it actually happens in ID1: progs/spike.mdl and progs/s_spike.mdl are identical aside from skins.
Load up ad_sepulcher and there are about 30 MDLs where this happens.
So to save memory with MDL caching, and also potentially save memory with VBOs if you use them, this is something you could check for, without being too disruptive to the rest of your code.
I don't know if the SV_TouchLinks thing is similar to the old engine-crashing teleporters without proper destinations bug, but a QuakeC fix is mentioned here: https://www.quake-info-pool.net/q1/qcwa.htm#trigger_teleport
I don't think that is related to SV_TouchLinks.
Here is Quakespasm's SV_TouchLinks fix which I adapted from Spike's in QSS:
Screen Res For Mods
Is there a particular reason why Mark V (1081) wouldn't copy over screen resolution settings from id1 folder when running mods from custom dirs?
Because You Forgot To Copy And Paste Your .cfg From Id1
That's Weird Then
I am used to Mark V taking all settings from config.cfg located in the id1 folder...
Here's my QuakeSpasm parameters for AD. They're from the readme:
-game ad_v1_50final -heapsize 256000 -zone 4096
The ad_sepulcher readme says to use these:
-game ad +map ad_chapters
I'm not sure if something else could be causing system overload. Maybe the Intel HD Graphics 3000 drivers emulating stuff in software?
I've implemented a SV_TouchLinks "fix" in my code, and it broke the end-of-level teleporter in the map Citadel of Doom
. That map is good for testing.
Spike's more robust SV_TouchLinks fix works fine in that map.
The Intel HD 3000 should not be emulating anything in software; it's right at the start of the "Intel graphics are no longer crap" era and IIRC will even run Doom 3.
Isn't "heapsize XXXXXX" Deprectaed In Current Engines?
I thought this was no longer needed...
mh: Yeah, I've played Doom 3, Quake 4 and the 2013 Shadow Warrior in it.
So many posts to read.
I had super-Android obsessive tunnel-vision "I will beat this platform into the ground and make it do my bidding" madness.
I figured there were be 5 new posts here, instead there are maybe 35-45 haha!
I will read them. But a bit too much too digest right now -- I see something about a TouchLinks thing, I have some sort of TouchLinks fix in Mark V from some other respected source but apparently not good enough for the issue in question.
Do QuakeDroid bugs belong here or in the QuakeDroid thread. Enjoying QuakeDroid a lot btw.
@qmaster - Yeah, QuakeDroid Thread
Yeah, QuakeDroid is a different kind of animal.
So all QuakeDroid talk should be in the QuakeDroid thread.
I'm glad you are enjoying QuakeDroid.
@Spike - thanks for helping Cadaver with his multiplayer.
@cadaver - Glad you got it working. Mark V uses Spike's single port server so just port 26000.
Touchlinks - I can't recall where/how I got the touchlinks fix. And if I recall, when I was acquiring Spike's QSS single port server/IPv6/server browser capabilities, his was slightly different. Mark V has "co-op players can walk through each other on respawn and the ability to save multiplayer games AND reload them with the wrong number of players.
So if the code their looks usual, lots of action going on.
@nightfright - here in a couple of days, I'll see if I dig into the Chillo model pack thing.
@nightfright2 - I am used to Mark V taking all settings from config.cfg located in the id1 folder...
Mark V loads AND saves the settings to the Quake startup gamedir. If you start up Mark V in id1, it will use id1. If you start up in "-game rapture" it will use rapture.
So it sounds like you played, say, rapture and then changed the video mode, which causes the video mode to write to, say, rapture --- then you started id1, the video mode from id1 was the old one.
@mankrip - Ok, you are talking about a Quakespasm issue. I assume.
Wondering if you could add support for light entities in the entity inspector mode? Just curious. Not a huge priority.
Sure, I can put that on the medium-term wish list. I think (?).
I haven't thought about lights in a long time.
I'm not immediately sure if they stick around or just ones that can be toggled/flicker like the E1M1 nail gun up the lift that is dark until you trigger it.
Do you have something that prompted this thought that perhaps you were trying to do while mapping?
Working On My Tutorials
I was recording a basic lighting tutorial and wanted to show viewers what the diff light values and whatever other info was displayed. However no lights for me at all. I was using 1.50 and I do need to upgrade my video capture directory to the latest version.
Honestly, I'd hate for you to add it just for me but I think the functionality is very cool overall and was curious about why lights weren't included. I didn;t try to examine switchable lights. Will try that.
You've done a great job with those video tutorials, I've read that they have help a lot of people.
My focus with the tool_inspector was mostly QuakeC/entities as an assist to mappers to be able to
1) To get the entity # for an entity!
2) examine why something does/doesn't work in their own map
3) check out the mechanics of a different map
So lights never even occurred to me.
So lights never crossed my mind.
Not really a request. I'd rather you work on Gunter's wishlist. ;)
I'm not immediately sure if they stick around or just ones that can be toggled/flicker like the E1M1 nail gun up the lift that is dark until you trigger it.
Yep this is right, light ents are removed from the world on map load unless they have targetnames, or a sound/model attached to them (e.g. light_fluoro/globe etc). Simple enough QC alteration to disable this (misc.qc #45) but not sure how advisable that is.
Makes perfect sense. No not worth the effort IMO.
Choppy Refresh Rate
Maybe it's just me, but Mark V D3D9 starts to visually stutter on the default host_maxfps "72" when I'm moving and "mouselooking" at the same time. I normally play on 144, which is double the default, despite it causing physics bugs, so that's why I didn't notice it right away. Is there a special CVAR I could tweak or something I need to configure in the NVIDIA Control Panel? Or is it a bug? Doesnt't happen with Quakespasm btw, but that uses OpenGL.
RAM: 16GB DDR3 800MHz Dual Channel (1600 MHz)
Main-/Motherboard: GigaByte B85M-HD3 R4
Thx in advance :)
Sorry for the double post, but I don't know how to edit my posts. Do I need to register? Please forgive my ignorance.
Anyway, in Scourge of Armagon, the SG & SSG leave one bullet hole decal every shot, these are rendered through walls in Mark V.
@DabbingSquidward - Windows 10 Stutter DX9
Only mentioning it because Windows 10 is known to install miscellaneous apps/features without user consent.
I wouldn't normally post wild guesses.
1- Search "Xbox" in windows taskbar's search bar (Bottom left of your screen where Cortana is)
2- Click on the Xbox application icon to open it
3- Find the settings icon (a small gear) on the taskbar to the left side of the Xbox application's window and click on it to open the settings menu
4- Find the Tab labeled " Game DVR" and select it
5- Slide the switch to off to turn off the Game DVR feature.
"List of things to try
Turn off game dvr
Turn off Windows game mode
Windows advertising stuff.
Turn off in windows update allow downloads from other pcs "
@DabbingSquidward - Decals
I loaded up Hipnotic and in the first level shot both sides of a thinner wall and didn't see a decal on each side.
c:\quake\mark_v.exe -game hipnotic -hipnotic +start
I believe you, but can't replicate it. Do you have a save game you could provide? Like look at the decal and type "save decal". After saving a game it would be in the hipnotic folder, in Mark V you can just type "folder" it will take you there and be called "decal.sav".
Forgot to mention it, I'm on Windows 7 Home Premium x64.
This is probably common knowledge, but where do I upload saves and screenshots? Sorry for the inconvenience, please bear with me.
I haven't used a free upload service in a while, if I recall this one is okish:
I'm on Windows 7, but I don't have a 144 Hz monitor nor a GTX970
@Baker fantastic job, but would it be possible in the next release to rise The step left / right icons at the same level of the fwd icon. In my opinion this would lead to an increased playability. What do you think?
-->sorry Wrong Topic, The Post Was Meant For QuakeDroid
Go to Screenshots and Beta post and at the top you will find login information for Quaketastic which is an ftp site you can use to upload forum related files. It has a web interface and you can scroll to the bottom of the page to login and upload. Welcome to func.
Sorry for taking so long, but I just uploaded a screenshot, a save and a video, all titled decal to Quaketastic.
@Baker I only have a 60Hz monitor but still play with 144 FPS, because I belong to the (supposedly small) demographic of people who think that having more frames per second than your refresh rate looks smoother. I also disable V-Sync in all my games and limit my FPS (via NVIDIA Inspector, Bandicam or ingame) instead to get around the input lag and still fix possible physics, etc. issues.
@dumptruck_ds Thanks for the introduction, I love watching your Trenchbroom tutorials on YouTube and as you can see, I'm fairly new around here. I usually hang around the ZDoom Forums and lurk (have no account yet) on Doomworld :)
(@mh) Dabblingsquidward - Direct3D9 Specific Issue
mh - Dabblingsquidward found that the decals in the Direct3D9 renderer through walls and this doesn't happen in Direct3D8 renderer 1036 build
or the Open GL.
I'm think of trying to get out a comprehensive update of Mark V within the next 10 days after I can review NightFright's deal, get full Sepulcher in there.
If you have the the time and the opportunity to take a look at that in the next 10 days that would be awesome, but if not that's fine too.
- I really need to change Mark V to use RawInput, it may resolve the mouse issue you experience. Main problem is only so much time.
I'm not going to be able to look at anything for the next approx 5 days (touring central Europe and drinking lots of nice beer can have that effect) but I am very interested in investigating any kind of state-related glitch such as this, so I'll be jumping on it first chance.
touring central Europe and drinking lots of nice beer can have that effect
Enjoy yourself and have one for me!
Go To Frankonia!
We have one of the highest densitys of brewerys in Germany!
@NightFright - Cannot Reproduce Your Issue
I have used several versions of the "Authentic Model Pack".
I can't get any version of Mark V from 1036 forward whether Direct3D/OpenGL/WinQuake to crash.
I load map E1M2 using pakz.pak after renaming it to pak2.pak.
My success rate has been 100% with no issues in any version.
I'd sure like to fix the issue you are experiencing --- but without being able to replicate it, I don't have any method of taking any kind of action :(
Reminds me that I never looked at the decals issue...
I have analyzed my file structure and found something that is probably the ultimate cause for the issue.
I am using an autoexec.cfg in my id1 dir with the following entries:
What causes the problem is apparently the r_shadows entry. If I comment it out or even only change it to "2", the crashes will stop.
Please create a file as described above and test the issue again. I am sure you will experience my problem this way.
It's R_shadows 3 For Sure
The r_waterquality 32 has nothing to do with it.
The crash appears to be related to:
// 3984 is WinQuake asm maximum verts possible
#define MAX_LERPED_VERTS_3984 MAXALIASVERTS_3984
#define MAX_LERPED_INDEXES_12000 12000
If I increase the 12000 to 24000, it doesn't crash.
I am guessing that 12000 should instead be 3984 * 6 (23904), only because FitzQuake normally supported 2000 verts and 12000 must have been 2000 * 6.
This is my speculation, how mh's r_shadows 3 works is something I understand in a broad sense, but not in a detailed sense.
/End speculation, but the above seems to be fix the issue.
I should have tried to run everything in a "clean" environment without any config files or other mods right away, my sincere apologies for that. :/
At least it seems certain now that it's not the new models alone that cause the crash, but using them in combination with this shadow option.
I guess it's still something that should be addressed since r_shadow 3 works just fine under normal circumstances.
I suspected that it was going to be something like this, but when I did a scoot through a debug build about a month or so back I didn't see any evidence of the index list overflowing.
Strictly speaking the maximum number of indexes should be max triangles * 3, not derived from max verts, because any individual vert may be potentially reused an arbitrary number of times.
Even more strictly speaking GLQuake's MDL meshing function which converts a highly compacted triangle soup to strips and fans will mean that the generated mesh will potentially bear little relationship to the original in terms of counts. What I'm saying is that using the software Quake maximums as a limit on anything that comes out of the meshing function is asking for trouble.
Anyway, in Scourge of Armagon, the SG & SSG leave one bullet hole decal every shot, these are rendered through walls in Mark V.
This is a problem with how polygon offset is implemented in GL and D3D9. (Don't believe 20+ year-old articles claiming that D3D doesn't have polygon offset; it does, it's just called something different.)
In D3D8 polygon offset is completely different, and probably doesn't actually work at all (at least in the context of MarkV), so hence that the problem doesn't seem to happen.
In D3D9 what GL calls "polygon offset" is called "slope-scale depth bias" and if you compare the GL spec with the D3D9 documentation you'll see that they're controlled by the same formulae. GL has the addition of an implementation-defined constant value which for D3D9 I assumed to be 0 (IIRC, I had good grounds for that assumption). Gotta love implementation-defined GL behaviour; what's the point of a standard if individual implementations can just do what they want anyway?
Another possibility is that I may be missing some state. In order to enable proper draw call batching in D3D9 I implemented lazy state changes where state doesn't actually change until a draw call is made; state change requests are tracked and only if a state change was actually required is a draw call batch finished, flushed, and a new one begun. It's possible, for example, that there may be interactions between polygon offset and depth testing that I hadn't considered.
That's something to work with. I'll update further as I find out more.
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 ...)
I Vote Update Sooner...
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
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.
MultiPlayer Saves/Loads Coming To The Menu
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?
3 Beers Remaining - The Assured Death Of OGG + Why
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.
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
Ogg made sense when MP3 was still patented and an unencumbered format was required/desired. Where the Free Software world often falls down is in not realising that it's not 1998 anymore; the assumption is that rules and situations that applied in 1998 would continue in perpetuity, but the MP3 patents were always going to expire and Ogg's reason to exist would be reduced.
A technically inferior solution that has high market penetration or better ease of use will always win. The moral of the story is that end users don't give a flying one for technical superiority. They just want something that works and gets out of their way while doing so.
Baker, you sound like you may be on a few beers too many, but I'm still going to reply with my own rant at your ranting, because you're touching on some of the issues I've had with Mark V:
What does QuakeDroid have to do with Mark V supporting OGG? If QuakeDrioid doesn't support OGG, then it doesn't support OGG (I will probably never bother copying the Quake soundtrack to my android anyway). I play Mark V on my WinXP netbook, not on my android device, and Mark V already can play OGG files (assuming the correct decoder is present on the computer) -- Mark V just doesn't bother to look for OGG files. So I have to rename OGGs to MP3, or hex edit and hack Mark V to look for OGG instead of MP3.
And as I mentioned in #1767, OGG files fix an unsolvable issue my Netbook has with running MP3 files in Mark V -- that being a long delay (sometimes ridiculously long) in loading the file in Quake. We did a massive amount of troubleshooting of my issue in the old topic, where I tried so many different things like installing various decoders, but NOTHING worked... until I tried using OGG files and the problem magically went away.
I've been holding out hoping you would do the utterly simple step of simply ALLOWING Mark V to see the OGGs that it is already capable of playing.... The other option I have thought of is either: offering a pack of OGGs files renamed as MP3 for download for people who want to use the soundtrack in Mark V, or hex editing Mark V and offering my hacked version for download on my site for other users like me who would prefer an OGG soundtrack (without confusing renamed MP3-OGG files).
This is not the future -- this is the now, and people are playing an ancient game using old computers, and those people are asking for OGG support.
You're simply wrong about this one Baker. Stop being so stubborn and LISTEN to the people who are actually using your engine. I think we know what we want... rather than what you're telling us we SHOULD want.
I also agree with Spike that switching gamedir should absolutely exec the configs in that gamedir. Otherwise you are not running the mod correctly. "game fvf" is supposed to replace the need for a command line switch "-game fvf" yet it does not, because it does not exec config files that are set up for that mod.
Yeah, we've been over this before ( #55 #68 #87 #89 ), and you always go with "but what if there are bad settings in those config files?" Then that's how the mod should run, because that is the expected default behavior of Quake when running a mod!
Basically I still need to use a command line "-game fvf" since "game fvf" does not work like "running a mod" is supposed to, and would require at least one extra step.
Hey, Johnny Law. It looks like you are a real power user with running custom maps.
I'd like to get your opinion on a feature in Mark V (since we're revisiting some of these old issues): If you are running from a gamedir or mod with custom maps, and you use the menu to start a New Single Player game, Mark V guesses at what map to run instead of putting you in the default start.bsp (standard Quake behavior -- though actual mods can alter this to start you wherever they want).
Is this a feature that you actually make use of, or do you run custom maps a different way?
I really like the "Levels" menu that lets me specify any specific custom map I do want to run. (Though I remember there was an issue with the Levels menu being disabled when custom menu graphics are present, though me and someone else suggested it shouldn't be.. up around #1227 ).
But I greatly dislike the "guessing" behavior, and it has given me problems by guessing wrong from what I actually want, and I can't even disable this feature. It takes away user control, doesn't apply or function in some situations, and causes unwanted behavior other times (also discussed in-depth around the same location upthread).
I have to point out that it seems to me to go against Baker's credo, which he just stated:
"I have strong feelings about detrimental features that take away choice or control from users or thrust chaos on them."
Honestly I'd forgotten that Mark V does that... hmm.
For almost any episode-ish thing that has a start or hub map, they use start.bsp for that purpose. On the other hand if it's just an unconnected collection of maps then I always just select the map I want explicitly through the levels menu or a launcher or whatever.
It's true that there are some older id1/vanilla maps that have a startmap+othermap combo for selecting skill, and since they expect you to place it in id1 they call their startmap something other than start.bsp. Like Adamantine Cruelty having an acstart.bsp map. If you put that in its own mod folder then it could be useful to have Start New Game infer that it is a start map, but since I'd forgotten about that behavior I always just explicitly pick the map in those cases too.
Sorry, no real opinions. I'm not sure in what situations the "guessing" behavior would be worse than not-guessing, since the worst case either way is that you end up launching the wrong map.
I suppose one way in which it could be worse is if it guesses wrong but you don't realize for a while that you are in the wrong map. (Because you haven't played those maps before.)
Out of curiosity, do you remember an example of it guessing wrong?
I believe that the guessing feature doesn't activate when everything is running from id1 (so it becomes useless when maps are installed in id1, as I assume a lot of custom maps packs are).
Issues I have run into include (more detailed info was upthread):
( #1251 )
Having a modified DM6 map included in my mod, and since that is the only map, Mark V assumes it should be run when I go to start a single player game. This is completely wrong....
Or, if I want to install extra maps in my mod folder (FvF can be used with custom maps, as can some other mods), then one of them will get guessed and selected when I want to start a new single player game, and it will always be the same map, either going alphabetically or looking for cues in the map name (like with your "acSTART.bsp" -- that would be selected). But that's almost never going to be what I want when I have many maps installed and I go through the menu to start a default single player game.
Baker's intent is to make it easy to launch single-player map/mod releases by using the menu; see #1253 (and you could read 2 posts later where I examined the map packs that had been mentioned to see how useful it would be in practice -- maybe 50% useful).
But I think the Levels menu is already the ideal solution for that. And it could still show the maps near the top of the list that it guesses are most likely the intended starting maps....
So to me it just seems that a feature which sometimes works, sometimes doesn't, and sometimes causes problem -- that's a feature that should not be activated by default with no way to disable it.
And it sounds like people may not even be using it anyway.... I'd assume that most people, like me (and you, it seems), would just assume that default of starting a new single player game in the menu will behave as Quake always did, and start the default game, and if we want to start a custom map we'll use that wonderful Levels menu.
LOL at the whole "mobile gaming is the future and I'm the next Steve Jobs" nonsense. Sober up, Baker.
Well, we can allow him a few rambling rants when he's on a few beers, as long as he becomes reasonable and rational at some point afterwards ;)
This Is Madness
As long as Baker doesn't turn Mark V into a mobile exclusive port, he may rant as much as he wants.
Mark V - Version 1.98 (Stable?)
Larger update than the norm for Mark V. 46 modifications plus some major revisions.
Download: Windows - Direct X | WinQuake
(Direct X is fast!!)
1. WinQuake GL
2. SDL "zero dlls" build with mp3 sound track + all controllers support
In this version:
1) Xbox Controller Support.
PS4 + Steam Controller will happen later. (based on ericw help in the implementation in Quakespasm)
2) Perfect "install" unpacking for non-traditional zips (johnnylaw)
3) r_shadows 3 issue with higher vert models fixed (NightFright)
4) Big Sepulcher Support
(pulsar, killpixel, qmaster reminders/nudges)
5) Multiplayer save game menu integration (qmaster)
6) Possible fix for input lag (killpixel, dabblingsquidward). Verification needed.
7) Alternate "joy_" prefixed game controller names (conversation amongst Spike, gunter, ericw)
8) DirectX 9 hipnotic decal workaround per mh (dabblingsquidward)
9) Dynamic scaling for scr_showfps 1 and friends (gunter)
10) And 36 other small or moderate enhancements including things like 64-bit killer buttons fix via ericw, small Linux enhancements and implementing tweaks from comments from many different users.
Next Version: Split-screen support!! (video
Now ... here's the catch ... will it be 2 weeks or next winter?
I'm a winter coder and we had a frigid April in Ohio/USA. I tend to vanish for months in warm weather. And I'm a bit burnt out.
But if there is enough user feedback, I also kind of feel like doing this sooner rather than later. I need a bit of convincing there are actually people who are actually going to use the split-screen with 2 people or more playing on the same screen sitting on the same couch.
@iriyap - It's supposed to be funny as self-deprecating comedy through going the opposite direction. / Anyways the start of Cinco de Mayo is serious business. No time for beer rants! Peace out!
Can you shed a bit more light on the functional difference between mark_v.exe and the SDL build?
Also a heads-up... I tried "install mapjam6" as a test just now, and it went a little haywire. It put bsp files and lits directly into id1, and also discarded various other things from the .zip.
"install qump" went a bit better, but it still put the maps into id1\maps (rather than qump\maps) even though a start.bsp is among them.
Haven't tested other installs yet.
Mark_V.exe has mh DirectX 9 uber-speed.
The SDL build serves 3 purposes:
1) Any game controller support instead of just Microsoft Xbox compatible. I don't have a PS4 controller to available to do the kind of coding/test for pure native Windows API at the moment. (I made phone calls and it was Xbox, Xbox, Xbox, Xbox. "Ok what about your friends? Xbox? Really?" What kind of luck is that? Especially since PS4 selling extremely well ...)
(Short version: Mark_V.exe all the way)
2) To see if gunter's foobared Windows XP machine can play mp3s with that because I use an entirely different direct Windows API method. I still hope he spills coffee on it, but it has been great for testing -- especially the extreme compatibility mh has offered with the Direct X 9 version (mh is simply incredible).
3) Poke Quakespasm a bit to go "no dlls". The same way Spike sometimes pokes at me about X, Y or Z (or how sometimes I poke at Spike a bit) or the same way mh occasionally pokes at me about X, Y, Z. Friendly developer "Aw come on dude!" peer pressure and all that.
Let me know how it goes with the install capabilities. I felt like I couldn't do a release without getting it right so I rewrote half of it to be very precise.
@johnny - After Typing That Reply I See ...
Well .. I'll test those examples tomorrow and do a version 1.98b.
I took a diverse pool of zips with many different configurations, but apparently a different have a diverse enough set in the pool.
Perfect is the goal. So ... perfect it shall be. And perfect is what I demand it must be be ...
Hah, perfect isn't required. :-) I will just be doing a test run through the examples I listed earlier.
Actually, when the next build is up, I'll go through all of the 50+ installs that the SP starter pack currently supports. Not sure it will happen this weekend because of family stuff, but as soon as possible.
Alright ... qump (what an incredible start map!) and mapjam6 now unpack ok.
Only that binary has been updated while I kick tires on a couple things that don't affect the windows operating system.
Hm, the mouse speed seems dramatically lower in the new build. I've always used a "sensitivity 10" setting, but now I need to set it to 20 to have the same feel (and the slider only goes to 11).
The SDL version seems... weird.... Text and other colors are off, and the sound it tinny. But it has the same freeze-up delay of around 5 seconds when I enable the music, as it loads track04.mp3 (and this was after encoding it in various ways to get that delay down from the original 14 seconds). but if I use an ogg renamed as an MP3, the delay is less than 1 second....
I don't remember all the testing we did in the past (it's all on the oldpage), but I think FTE and Quakespasm had no delay at all for loading MP3s for me....
Question: would the split-screen players be able to connect to an online server?
1) Mouse now uses DirectInput so sensitivity is a bit different.
According to the research I've done, Windows updates in recent years introduced some behaviors that could cause "frame lagging" with the "ancient way" that Quake did mouse input (which involved recentering the mouse cursor every frame), hence the change to DirectInput which I believe will eliminate the frame lag some users say they experience when using, for instance, a high refresh rate.
Aside from having to tweak the sensitivity.
2) The SDL build uses 44100 as a forced sound frequency because of some sort of SDL2 oddness. Hence the much more crispier sound. I prefer the way that Quake traditional sounds myself but Mark V has a sndspeed cvar that can be set to 11025, 22050 or 44100 and is read on launch. (Has no affect in that SDL2 build, 44100 must be forced).
3) Too bad the mp3 has a delay on your old Win XP computer even for the build that uses a completely different Windows mechanism. I had hoped that on your machine that it would resolve the issue. I tried. I know reformatting that Win XP isn't an option.
4) Split-screen connecting to an online server ...
Well ... I wasn't planning on that.
If I did have it do that, would you be able to test it?
But here is a big question: I am planning to target exclusively the Direct X 9 for that feature. I have to really abuse Windows API to do split screen and SDL2 serves as middleware and isn't going to let me use the abusive Windows API evil that I do for split-screen.
Ah yes, I remember back in the day I would use the -dinput switch, and that would have a similar effect of requiring me to ramp up my sensitivity. I think this does make my trackpad movement look very slightly smoother too. But you might consider allowing the Sensitivity slider to go up to 22 or so, since this will likely have a similar effect on other people.
Yeah, the XP MP3 issue is weird. On my other (even older) XP laptop, I recall I did't have the issue. But I also remember seeing a post on Quakeone where Dutch said Mark V has "a difficult time playing external MP3" on his WinXP computer.... I don't think he ever gave additional details about that, but I'd very likely assume it was the same issue.
Oh, I would certainly give it a test if split-screen could connect to an online server. Hm. But there are all kinds of issues around that, like if someone wanted to chat on the keyboard, which player's guy would speak? I'm guessing there would only be one "master" player which was attached to the keyboard, and others would be limited to a certain gamepad?
Adjust slider range to reflect? Excellent idea, gunter!
Gunter, Re:Split Screen
I'm guessing there would only be one "master" player which was attached to the keyboard.
That is correct. Only one player can keyboard.
I once considered that I think Spike said RawInput can provide access to 2 keyboards. And perhaps someday I'll consider that route. But I don't feel like coding for such a situation right now.
Multiple keyboard support is probably very low priority.
Add: Iriyap List + Parubaru
Revisiting found the comprehensive list that iriyap wrote up that had some ideas/suggestions for improvement (self note it is post #1805 -- I keep losing track of it)
In particular, I have my eye on the few seconds of lag issue on video restart that affects some machines.
I know how this was introduced. I was actually trying to stop a sound jutter, and while fixing it on some machines indirectly caused this to happen on others.
Install testing is looking pretty good -- I got about halfway through, might be able to finish it off tomorrow or Monday.
A minor feature request for your consideration: an optional argument to the install command to indicate "please put this in its own mod directory" (regardless of whether it could work in id1). Like, if I'm installing terra and I want to make sure it ends up in its own "terra" folder.
Small interesting thing when installing func_mapjam5: there's a zerstörer.wad inside the zipfile, but it gets extracted as zerstÃ¶rer.wad (let's see if that ends up showing correctly in the post here).
That's just in the "source" directory though so it doesn't matter functionally. Something to keep an eye out for though I guess.
I can add an argument to allow you to do that. Maybe even one to force a folder (like a Quoth set).
Cool. FYI the install tests all look good now. :thumbsupemoji:
@Baker Arrow Key Bug
I've experienced this both in Quakedroid and now in 1098. I don't think it's my hardware in this case. Here's an unlisted tube showing the issue.
Meant To Add
That a reboot fixed this issue but it's still bizarre.
I'll certainly look into it.
And if you have anything that I have missed, please let me know.
I've had such a large list of touch-up or in some cases rewrites (like what johnny + I are discussing) that keeping a handle on every single thing has been tough.
I think you need to unplug your PS4 controller.
PS4 doesn't using the same analog axis mapping as Xbox, it successfully detects your controller and then thinks you are holding a stick up.
I do plan to extend Mark V controller support beyond the currently supporting Xbox mappings, Mark V uses native Windows API so I have code this myself (which isn't a problem) but I haven't code such yet (and haven't obtained a PS4 controller yet).
I can confirm it's working again in the latest build with improved models. Thanks a lot, Baker! ^^
haha That's (almost) exactly what it was. I had forgotten I plugged in a PS3 controller to charge via PC the night before. When I read your post I looked down near my PC and there it was still plugged in. Fixed. Thanks!
@NightFright - ;-)
@dumptruck_ds - Until I get my hands on a non-Xbox controller like a PS4 one, I'm going to force non-Xbox controllers to be ignored (if I can, and I believe I can). In theory, I could code the axis/button remapping without having a controller, but I know from practice that "on the blind" coding usually is a quagmire.
Eventually, I'll get my hands on a PS4 controller ... but I'd like to ask you this.
Is getting a PS4 controller to work with Windows as easy as plugging a USB cord in (it is that simple with the Xbox One Controller S, as an example).
@iriyap - Your List
I looked through your list.
First 2 items resolved. #1 already fixed. #2 - sound stutter on vid_restart that occurs on some machines (I've witnessed it first hand on a couple) should be fixed.
I looked at the sky in GLQuake vs. Mark V vs. Quakespasm with gamma 1 and contrast 1 which shouldn't be setting neutral.
The sky does indeed not look quite the same as GLQuake! But ironically appears to look about the same as WinQuake.
So now, I'm not quite sure what to think. WinQuake is kind of the baseline that GLQuake was supposed to look like. Still, maybe an option will happen.
Other things: tga fonts + alpha masking for replacement fonts. Older replacement fonts supported FuhQuake/JoeQuake which has less flexible rules. The newer ones tend to be oriented towards DarkPlaces which has different rules regarding the alpha masking (more proper rules, I would say).
The main issue that has caused me to do nothing is that the replacement fonts for DarkPlaces don't tend to be a 1:1 drop-in replacement but rather really need larger resolutions or they look terrible in resolutions like 640x480.
I had once drafted up a solution been eyeing a solution which is to determine the minimum scaling when loading the replacement font. But the fact I didn't do it bothers me --- I may have run into an issue like HUD replacements and font replacements might require the same base scale under certain circumstances.
WinQuake: A 16-bit renderer would be a massive undertaking. Mankrip lives and breathes the software renderer. My level of interest in the software renderer is very close approproximation to the original WinQuake feature set + modern maps. I would eventually like to get alpha masked textures working (I've made several runs at it). As for HUD scaling, FitzQuake has a ton of canvases and scales all over the place. Mark V's software renderer isn't actually based on WinQuake, especially not the placement and canvasing. A dedicated WinQuake-only engine like Engoo or super8 need not worry about canvasing consistency with a Direct3D/OpenGL version, but one of the main features of Mark V being able to switch between the WinQuake/hardware versions on a whim and get nearly the same experience. Re-writing all that canvasing would take far too much time, especially when the less capable but fairly accurate approximation "stretch mode" is available in video options.
Also looked at bloom. Then realized that at the moment I cannot bloom to work in the Direct3D build but I believe it is fault of something on my end (as opposed to the wrapper). I'll probably look at in the future.
Likewise, multisample isn't supported in the Direct3D version at all and to some extent I'm not 100% that multisample is relevant these days because simply using a higher resolution with a larger scaling factor typically gets approxiamately basically the same results. Multisample with modern very high resolution monitors on 3D renderering is going to be mighty tough to notice, but on older hardware like 640x480 crt modes yeah you can easily tell.
The Direct3D 9 wrapper's level of performance (rendering speed) and stability (AFAIK not even a botched NVIDIA update can mess with it, so it may be totally immune to those kinds of problems).
Direct 3D supports multisampling but the details are interesting.
The OpenGL philosophy is "the programmer can go nuts and the driver will do it's best to sort out something that works".
The Direct 3D philosophy is "the programmer absolutely positively cannot go nuts, and that sorting out something that works business is on your shoulders, matey".
In a native D3D application this is actually easy. You just enumerate the supported formats and follow the rules.
In an emulation layer that has to translate from the GL spec (and oh lordie if it's pre-3.0 stuff) to the D3D rules the path of least resistance is to just not advertise the extension.
Sure it can be done. But time, patience and sanity are finite resources round my way.
I have yet to actually game with a PS4 controller on a PC. Or a PS3 for that matter. When I plugged in the PS3 controller via USB drivers were installed but I don't think they were with the PS4. I do know Steam supports PS4 and you can use them with Sony's streaming setup. I have zero experience with Bluetooth on my PC so that may be the ticket. No idea and doubtful.
So using those controllers is NOT plug and play. That makes sense to me as Xbox controllers are native for the most part in Windows and Sony interfacing with PCs has been historically clunky - usually their software is pretty wonky there.
The following will be available for the installer. Needs run through your series of tests, I'm rather confident it will pass them all.
1. Forced to specific gamedir:
install elek_neh_episode4 nehahra // a Nehahra expansion
install thehand quoth // A Quoth map
install qt_pre02 travail // A Travail expansion
2. Special "self" keyword
install bnt self // Maps only release forced to its own gamedir quake/bnt
@dumptruck - Thanks for info, trying to plan out how long I need the controller and what could go wrong.
Is there a functional difference between "install bnt self" and "install bnt bnt"?
Like, would the latter fail because the "bnt" directory doesn't currently exist, or stuff like that? I don't have a particular desired behavior here, just making sure I understand any specialness about "self".
There isn't no functional difference, "self" is just automatic naming "bnt.zip" ---> "bnt".
The 2nd question: if it is a maps only install, using the override will overwrite files.
If it has more than maps (i.e. pak or progs), it should refuse to double install.
Going to have to kick the can on the "ignore non-Xbox controller" until the next version, I want to test it on multiple machines first and don't fell comfortable putting in a beta without doing that. (i.e. I worry if the code works wrong, it will ignore a real Xbox controller).
Got it, thanks.
Sounds good, this will make me delete a lot of code out those batch files. Which is a plus. :-)
Mark V - Version 1.99 (Stable?)
Download: Windows - Direct X | WinQuake
(Direct X = fast!)
1) Xbox One Controller support tweaked
2) Should eliminate sound stutter on some machines (iriyap, parubaru)
3) In-engine installer tweaks (johhnylaw)
4) Linux versions refinements (todo: make available)
5) Other touch-ups based on input
This is in addition to Big Sepulcher support (@pulsar, @qmaster) and the NightFright r_shadows 3 w/higher verts replacements models fix and Direct X decal workaround (DabblingSquidward) plus other items outlined in post #2037.
1. WinQuake GL
2. SDL "zero dlls" build with mp3 sound track + all controllers support
Looks like all bugs and standard usability feedback issues have been addressed, clearing the queue.
Needs verification of resolution of issues.
Thanks to all the feedback to get this very polished! Always consider feedback even if it is not possible to immediately act on it (@iriyap).
Spot checks on the install stuff look good. I'll see if I can run through them all tonight.
A non-install-related thing:
If I launch Mark V using the -game option, my base video settings from id1 don't get carried over.
(Other settings do seem to get carried over properly from id1.)
If there is a config.cfg in the gamedir (say quake/travail), it will supercede what is in id1.
And with -game is how it should work.
For instance, I run quake/travail and then set a video mode and exit and then restart travail ... it saved the config.cfg to quake/travail and that is the one it should read the settings from.
I have thoughts on how to enhance that to accomodate what I think you are describing (and do it in a traditional way, not doing something crazy).
/If I am understanding you right ...
There's no config.cfg in the gamedir. It's a fresh mod install. I launch Mark V using the -game parameter, and I don't get my normal video settings... it's back into 640x480 windowed and I have to set all the video stuff again.
Other things like mouse invert and key bindings are handled OK though. Whatever I have set in id1 for such things is carried over, as usual/correctly.
Maybe it was that way with the 2017 stable release too? Feel free to ignore me if I've lost it.
Nope, you found something. What it doesn't do is fall back to id1 when there is no config on the early read if a gamedir is specified.
It just tries to early read from Travail, and if it finds no file it just stops.
This only affects things thing vid_width and vid_fullscreen that are read early, hardly anything is.
Hm. #203 #215
(heh, sorry, just had to point that out because my mental file pings me when I hear an issue that I may have heard before....)
I'm a bit confused about the three different download links. Which build should I use? I play Quake (and map) on an old Windows Vista Laptop and stayed away from Mark V because it performed sub 60 FPS even in id1 maps, so I just stayed with QS for now.
Sorry for my ignorance but does this build (1.99) address the non-XBox controller conflict? I have 2 controllers attached to my Win 10 machine. The first is a Hori controller set to PS4 and the second is an Xbone controller. I still have the spinning on the spot issue. I have to unplug the dinput controller before I can use the xinput...
Sorry if this issue is still to be addressed and I'm just repeating what you already know. :)
I'll do an update later today with the missing gamedir config issue and also put in something that should ignore your Hori controller but let you use the Xbox controller.
That'd be great. Thank you. :)
Yeah, I'll need your feedback and from dumptruck_ds since I don't have a non-Xbox controller available. ;-)
I don't have a PS4 controller, but the guides I've seen online about using them on a PC all talk about using a driver called ds4windows, which presents the controller to games as an Xinput device (emulating an Xbox controller). With that driver installed, I'd expect it should work with no extra configuration through MarkV's Xinput support.
My understanding of DirectInput is, it should probably be disabled by default unless you have a match from a mappings database like https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt
because the axis mappings are going to be random otherwise, so you'll have spinning on the spot problems etc. Winquake had it disabled by default for the same reason.
I can loan you a PS4 controller to test. I have two and we rarely play split screen. Since we're in the US. Shipping would be no big deal if using ground. LMK.
Ericw I'd offer but IIRC customs is a drag on your end right - or has that changed?
Thanks for the thought, yeah, shipping + customs would probably be cost prohibitive; I was thinking of getting one since they seem like a nice controller.
I could send you a 3rd party controller if you like. It's a GameSir. Switches between dinput, xinput and iOS. Wireless with a dongle... Lemme know. I'm in sunny Scotland. :)
Which model do you own? I personally have the G3s, as it's really good for the price imo.
Yeah, that's the one. I use it on my PS3 which I only have around for Xevious Resurrection!
For the money, it really is pretty good. Nice and sturdy. :)
@dumptruck_ds - I should be able to get my hands on one.
@ericw - Yeah, more or less at some point I'm going to do pretty much what SDL2 does ... if not downright take that chunk of the code eventually. Ironically that controllerdb is more or less in the SDL2 source code.
Mark V - Version 1.99 - Revision 2 (Stable?)
Download: Windows - Direct X | WinQuake
1) Eliminating a config reading issue (johnnylaw)
2) Must add -joystick to command line to enable Xbox controller support
The adding -joystick to avoid false axis interaction with non-Xbox controllers. Some time in the future, I'll extend the implementation of controller support to an SDL2 level where it detects and remaps a quantity of known controllers.
Alternate extra builds which are provided for experimentation purposes or have been specifically requested: Extra builds
Video config stuff looks good. Will do install tests later.
Mark V Page Updated To Latest Version
Updated the downloads/installer on:
Empty queue of existing issues, I think this build classifies as "rock solid".
(Always more features to do ...)
Congratulations! I've just been playing Quoth on a laptop at 4k. A bit choppy here and there but it's an Intel HD 5500 so I don't think it's 1099. Glad you updated the website. I was going to nudge you a bit on that!
Now I can do that video!
How is the default contrast value of 2 looking for people? It seemed ok running in a Windows VM on my Macbook, but on my desktop I had to crank it down to a value of 1.
My mistake, it was also 1 in the VM too. Not sure how that happened since 2 is the default; maybe the previous build had a different default?
The contrast default wasn't supposed to be changed. I may have been comparing different values between the hardware and software renderers.
AD 1.71 Compatibility
So is this build now fully capable of running latest version of Arcane Dimensions or some limits still need to be raised?
I was able to play Sepulcher on the first build of 1099. I have not attempted Ter Sheboleth yet. That would be the real ball buster, even compared to Sepulcher.
@NightFright/dumptruck_ds ... Loads Sepulcher and every dm4jam map.
Didn't feel like posting a technical post ... but ...
Eventually I will implement a big coordinates protocol (for maps like Ter Shobelth) like FTE-999, which takes the weaknesses of protocol 999 and fixes them.
I wouldn't be able to implement the very flawed and incomplete protocol 999, which cannot do co-operative play at all, because it would gross me out too much and I'd feel like vomiting.
Co-operative play is important. Any "big coordinates" protocol must be one that do co-operative play. And 999 sure cannot, but FTE999 sure can.
A large maps protocol like FTE-999 is on the to-do list. A 2019 item. But I also want prediction, framerate independence and something else I want which is boring and technical.
/End snooze fest technical post
Rephrase About 999
If you do a co-operative game, do you want to ...
1) Be killed by invisible monsters?
2) Be killed by vore balls you can't see?
That is what broken protocol 999 will offer you in co-operative play.
It also has "scale", which doesn't work on 2/3 of entity types (.bsp, sprites) and also doesn't work right on the other 1/3 of entities (.mdl) and would result in Ogre feet in the floor and bad collision.
So it is just loaded to brim with the brokesters upon more brokesters.
Wanting large-coordinates is a valid thing!
And those needs will be met in the future, but more in a FTE-999 manner that doesn't offer invisible monsters and being killed by vore-balls you cannot see.
I'll go through and retest everything I've reported in the past....
First thing I checked: Looks like unpacked pak files now work.
Hey, Proquake 4.93 seems to have nicely-populated server browser (finds 36 servers).... Mark V only shows like 5 servers. How about reading Proquake's protocol to help populate your server list?
lenovo e480 win10-64
intel uhd 620 latest drivers
dxdiag seems good, still no dx seems to be present, all versions of dx-mark5 prompt an error, even older ones from 2016.
Good news is the last gcc version does run fine, nno errors seen while playing +5hrs.
Older versions/Win7 does work all of time by now.
Tested 1.99 on various hardware btw, all fine.
all versions of dx-mark5 prompt an error
You know, I really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, HATE it when people do this.
At least you could say what the error message was.
Those things don't exist for bamboozlement or amusement, you know. They exist to provide useful information on how the error might be fixed. Saying what the error message was can enable people to say things like "ah, you got that error message, that's caused by situations A, B, C, and to fix it all you need to do is X, Y, Z"
Thx, that download helped, works now.
I won't really be testing the SDL version... (it likes to freeze up or crash on me), but I will point out that it appears to be printing bronze text where it should be printing white text (like for player names and the FPS digits).
I don't want to be the bearer of bad news... but the "QMB_BLOOD 0" bug is still there :P
if you set "QMB_ACTIVE 1" and then "QMB_BLOOD 0" to deactivate the QMB blood, it doesn't work, the command only mix qmb_blood with red particles :/
I'm using a clean install and testing lots of old things. I find that a lot of my suggestions have indeed been implemented. Excellent.
Here are some initial issues:
- Using Shader Gamma (the default), switching to any full screen mode that is not at my netbook's native resolution of 1024x600 causes Hardware Gamma to be used. It still says Shader Gamma in the settings, but it's definitely Hardware Gamma - everything gets darker and my desktop gamma is altered. Switching back and forth to full screen 1024x600 from a windowed mode does not cause the issue, and Shader Gamma stays in effect.
- I'm seeing something new: CDAudio: drive ready test - get status failed
Oh, I guess that's because the "External Music" is ON by default.
Ah, the error message does not appear if I disable external music, or if I actually have the music tracks in place... AS OGGs RENAMED TO MP3!!! because you won't allow OGG to be detected by Mark V.... PLEEEEEEEASE do this! I and others prefer to use OGG, and for me it addresses the issue with MP3 freezing up my game for unreasonable amounts of time as the MP3 song loads.... I'm sorry an OGG file killed your dog and burned down your house when you were a kid, but it's time to let it go, man!
- The mouse sensitivity slider now goes to 21, though that's right at the value I feel is good, around 20, so that doesn't leave much range for increasing it any more. The slider should probably go higher to account for users who might like it a bit more sensitive. I'd suggest at least 30 or so.
- Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.... Should that happen? I mean, I know it should fire my gun, but not when the console is down. ALT also has this behavior (I tried binding ALT to +jump to test it). Be sure you're in a multiplayer game when you test this, as the console fully pauses a Single Player game.
- Old issue that really needs addressed: the Multiplayer Setup menu, when you are changing your name, the name should not be committed until you are fully done changing it. It's like, for every letter you delete or add, it's doing a complete "name" command (which, among other problems it gives me, spams the console with name change messages).
- Speaking of old issues, r_noshadow_list contains bolt1.mdl which does not exists in Quake.... It's just... not... right!
- Known rendering issues: water surface is drawn on top of shadows, teleporter surfaces are drawn on top of water when viewed through transparent water (see #142 #147). And r_shadows 3 are visible through entities. Fullbright textures can't be transparent, and are made ugly by Contrast adjustment. (I know: all known issues -- I'm just noting that they still exist).
- chase_mode - I know it's an experimental feature, but it should really behave like other console variables. It's confusing because just inputting "chase_mode" causes it to cycle to the next mode instead of reporting the current mode. "inc chase_mode" should be the correct way to do that (though it wouldn't wrap back to 0 after... whatever the max value is).
(I've got a much larger list of preferences/defaults/suggestions I'm working on)
"MWHEELDOWN" In Customize Controls
I was running 1099 and found out in the "customize controls" menu, that "mwheeldown" binding doesn't display in the menu.
I have "mouse wheel down" bound for "next weapon" and it does allow me to bind it just fine, but the menu still displays it as ???, as if nothing wasn't bound (or if I have an additional alternate binding, it only displays it. Both bindings still work).
Anyone else have this problem?
Well, thanks gunter/mfx/tribal/esrael/jl for the polishing tweaks I need to do! Much appreciated!
I guess going into hibernation mode will have to wait a bit!
But also why I did the (Stable?), thanks for the quality testing guys!!
@Tribal: yeah, I lost the stamina to do it. I hear you and it is important. Can't promise I'll do it immediately, I'm tapped out a bit. But I do appreciate your testing.
"r_noshadow_list contains bolt1.mdl doesn't exist in Quake"
maybe it exists in hipnotic, rogue, zerstorer or something like that. metlslime put in FitzQuake 0.85 for a reason, but I don't claim to know what single player it is intended for.
I don't know. It's your computer. I assure you if says "shader gamma", it's using shader gamma.
I'm still rooting for you to spill coffee on your computer, haha. I suggest creating an incident at Starbucks!
ProQuake server list
Dunno. I'll think about it for a Christmas-time release. I want to tune up anything small and take a break. I'm running on empty.
Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.. (must be connected to a multiplayer game)
Wow, that's interesting. It sure does! I was going to post "cannot reproduce" and then re-read about connecting to a multiplayer game so I connected to shmack and tried, and yes.
That's a hell of an awesome catch!
I'd like to think I spot stuff like that.
Baker fail +1.
Now ... what I did was this ... I added ericw controller support. But I didn't want all kinds of joystick buttons showing for people without a joystick, so I made the display dependent on whether or not a joystick was connected.
But I was "too clever by half" ... and a tad not careful enough ...
Mark V - Version 1.99 - Revision 3 (I Blame Esrael!)
Download: Windows - DirectX | WinQuake
1) mwheeldown wasn't showing due to a <= vs < typo (esrael)
2) Link to DirectX 9 drivers on homepage (mfx)
Experimental/requested extra builds: Alternate Builds
Question of the day:
Is DirectX Mark V faster than VxQuake (Vulkan)?
I have reason to suspect DirectX Mark V is faster than VxQuake.
(start.bsp beginning has a mirror there that Mark V uses so that is not a good test spot).
Triple Speed Screenshot
Screenshot: DirectX Mark V sometimes 3x speed of FitzQuake 0.85
And from what I have seen, VxQuake using Vulkan is only about 15% faster than its source base.
But the mh DirectX wrapper is offering a frames per second jump that is vastly greater than 15%.
There's no point benchmarking an engine in small tight corners with very few polygons visible. This is the same syndrome as "50,000 fps in dm3 - woooo!!!!" - it's a meaningless statistic.
Benchmark it under heavy load, then do a comparison. You'll likely find that D3D9 MarkV is substantially slower than either QS or VkQuake (but substantially faster than Fitz) because it still hand-feeds all vertices to the GPU every frame, whereas QS or Vk store them in on-GPU buffers. But that all depends on where the bottleneck in your system actually is.
For the record, I make absolutely no claim whatsoever that my cobbled-together wrapper is faster than properly written native code, and I would always recommend properly written native code over a wrapper.
Addition To The Above
It's OK for Engine A to run at 200 fps in dm3 whereas Engine B might run at 5000 fps.
What matters is how they run in a map like sepulcher. If the same Engine A runs at 150 fps in sepulcher whereas the same Engine B runs at 30 fps, then Engine A is clearly the better performer.
Waiiiit, Fitzquake had a noshadow list? Hmm, must have been inaccessible to the user, and only existed in the engine code? Ok, in that case, if you grabbed your list from Fitzquake, then it was Fitzquake that had an error in its list. Way back on the old page, I first reported that bolt.mdl was missing from the list, then I clarified that "bolt1.mdl needs to be renamed to bolt.mdl" See, that was just a typo in the original list: it did not contain the actual bolt.mdl but it did contain the non-existent bolt1.mdl (simply, the "1" should never have been there). So that's the reason Fitzquake had it there: a typo, not some intentional inclusion. Of course, even if it was an intentional inclusion to account for some specific mod, I would be against that too (it's not the engine's job to account for every custom model that a mod might use -- the correct option would be for the mod to include an altered noshadow list).... But it sure looks like it was just a typo. You did add the bolt.mdl that I pointed out was missing, but you didn't remove (or more correctly, rename) the bolt1.mdl which was there in its place, so now both bolt.mdl and bolt1.mdl are there... which is just building upon the original mistake instead of fully correcting it.
It looks like Quakespasm copied your early noshadow list (as stated here: http://quakespasm.sourceforge.net/Quakespasm.html#ss6.5
) and never fixed the error (they don't have their own Gunter to point these things out to them!), as you can see in its code (i.e., bolt1.mdl instead of bolt.mdl): https://sourceforge.net/p/quakespasm/code/HEAD/tree/trunk/quakespasm/Quake/gl_rmain.c
Hardware Gamma: Ok, then it is still using Shader Gama when it says Shader Gamma. The problem is that switching to any non 1024x600 fullscreen resolution resets my desktop hardware gamma setting just as if I were using the Hardware Gamma setting in Quake. i.e., normally my desktop gamma setting is adjusted up a bit, and that applies to Quake as well, so I don't have to adjust Gamma in Quake up by a lot. Using Shader Gamma in Quake in a window or fullscreen at 1024x600 doesn't alter my desktop gamma at all. Using the the Hardware Gamma setting in Quake, either in a window or in fullscreen, resets my desktop gamma, meaning I have to ramp up the gamma in Quake to make it brighter, then I have to reset my desktop gamma when I quit Quake.... The same gamma reset happens when using Shader Gamma, but only for full-screen resolutions other than 1024x600 (native).
And just a note: you don't have to connect to an online server to test the CTRL/ALT buttons in console; just do New Multiplayer Game locally.
Hey, would it at all be possible to allow mouse selection of text in the console for CTRL+C (copy text)?
Oh, and there's little chance of me spilling coffee on my netbook... I don't drink coffee ;)
Who would want to deal with a caffeinated Gunter??
And on the Second Day, Gunter posted his long list of feedback over here: http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3811
FitzQuake's no-shadow list was indeed hard-coded into the engine.
Compare it with the tempent parsing code and it seems evident that progs/bolt1.mdl was a typo/bug; the tempent code (correctly) has progs/bolt.mdl but does not have progs/bolt1.mdl; meantime the no-shadow list doesn't have progs/bolt.mdl; I don't think we need to debate this one.
Fork Of MarkV
first of all I'd like to say a big thank you for this excellent source port. I love playing the WinQuake version.
A few months ago I made the following changes to the old 1036:
* Fixed a bug in single player where a saved game wasn't properly reloaded after death (you fixed this too in 1050)
* Changed all the defaults to make WinQuake look and feel exactly like the original
* Hid all the customization menus but without removing the variables, so if a mod needs them, it will work
* Limited the maximum resolution to 1280x1024
Ever since I made this, I've been following your changes and keeping my little fork updated, but I haven't uploaded it anywhere yet.
Since Mark V isn't on github or a similar site, I didn't want to just upload it and make it look like I'm the author so I wanted to ask if you're planning on uploading Mark V on github or a similar site, so I can fork the project and give you the credit that you deserve.
Heyyy, I like the idea of having a fork that "Changed all the defaults to make [Quake] look and feel exactly like the original"... to a certain extent; I mean, I see no need to remove menus that allow for easy customization, and if a user wants a higher resolution, there's no need to prevent them from selecting it.
I have no problem with making all kinds of changes (I enjoy tweaking and playing with settings... which is why I break so many things in bugtesting!), but the default Quake look and feel should always be the starting point (which was the vast content of the post I just made on my forum -- all the actual reasons why I would like many settings to be reverted to the Quake Default, as they produce unwanted behaviors for me).
In any case, no disrespect to Baker, who is the true mastermind behind Mark V, but I (and others) would absolutely prefer use a fork which addressed all the issue I have with altering Quake defaults. AND maybe dosse91 would remove the intentional blocking of OGG support! :D
Don't worry, I'd still bugtest here ;)
Though I might run into issues with dosse91's fork trying to make everything like WinQuake whereas I prefer hardware-rendered Quake....
MAKE YOUR OWN github repo call it sporkV or something then not its a test fork of markV with a link to Baker's website. or make your github private and only show it off to baker? or no just compare notes.
Ah, I don't care about credit -- I don't even have "Baker" on the Mark V page nor in a text file with the executables (or on most other things like the QuakeDroid page) because I don't care.
Everyone's work is a fork of Carmack's anyway, isn't it? /end joke
My only interest is conveniently being able to play any Quake mod in the context that was meant in a resolution independent and preferences independent way and be able to use as close to anywhere as possible (all major desktop platforms, all major mobile platforms) -- with the start demos working nice and properly which no other engine has ever taken the effort to do it because it is tedious and unrewarding (stuff like bizarre behavior of the start demos if the menu is opened when the start demo switches, etc. etc. It's like 25 things. Hence almost all engines hide the start demos because the problems are so hard to address.)
Settings is no win. Some people think Quake is GLQuake or ProQuake (like gunter) and some people think Quake is WinQuake/DOS and others prefer say the FitzQuake feel or (insert another engine).
There is no winning with settings, only trying to make the major ones available -- even with things like mouselook, always run, animation smoothing, stair smoothing.
I tried to make it easy to compile so someone wanting to compile themselves would be able to do that.
<--- That Pitfall Guy Is Me Successfully Escaping ...
Warm weather now. I'll check the thread sporadically in read-only mode, unless someone finds an Earth-shattering mistake or such.
Main difference from last year, is I think I get to vanish with no annoying bugs like last year tool_inspector being broke.
I Think I Heard A Whoosh
And There He Goes
See you again for v2.0, mate! You deserve a break after this update marathon, I guess. We can all play AD in the meantime. With Mark V, ofc. :P
Well, dosse91, Baker's outta here for now, so it looks like you need to make your fork available for download and create your own thread here on Func so we bugtesters can take a crack at (breaking) your version and provide feedback :D
Two points on Baker's last thoughts as he ran out the door:
"My only interest is conveniently being able to play any Quake mod ... and be able to use as close to anywhere as possible."
Would it not be so much more convenient and compatible to allow OGG support then, for people who have OGG Quake soundtracks (it seems to be a common format for Quake users), and for people who have computers that don't handle MP3 well though Mark V for some reason (like me!)....? Just saying! OGG support would serve both the stated goals there: more convenient, and more compatible.
"Settings is no win. Some people think Quake is ..."
Indeed, which is a good argument for leaving all settings at the Default. Then you are sure to please at least one (rather large) group of people: people who expect Quake to act/look/feel the way it always has (whether that's Win or HW version).... Other people who want to change that can do so, to their own tastes. But having the engine set SOME settings to different defaults (some old, some new, some Fitzquake) has no chance of getting it just right for anyone... except people who don't care.
... hey... how do you people make your quoted text appear grey?? Is it a secret function for registered users?? bbcode obviously doesn't work here....
Huh, ya know, come to think of it, there are already those options at the bottom of the Preferences page:
Set to Mark V
Set to Fitzquake
Why is there no "Set to Quake Default??" That should revert everything I complain about to the standard Quake Default settings ;)
And that should be the Default settings, heh, and then people could easily apply your Mark V recommended settings if they wanted.
Quoting from #1763 for your benefit.
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).
Adding this support is not as easy and clean as you think it is.
Replacing the existing MP3 support with a different format - easy and clean.
Adding support for two or more co-existing formats - messy, troublesome, hard decisions to be made.
You say "just saying". Well you've said it; over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and Sweet Baby Jesus Make It Stop.
You want people to listen to you? Return the favour and do some listening back yourself; I don't think that's too much to ask for.
Been Super Busy
I haven't been keeping up with Quake recently, good to see so much work still going into MarkV. Can't wait to play some split screen when it happens ;)
Linux Binary PLEASE
Any chance for a Linux version of the 1.99 release? And actually have working external music support? Quakespasm Linux has working music I don't see why the Linux binary of MarkV can't have it.
Also what the hell does "Cache_RLU: NULL link" or whatever even mean? I've never had that happen in Quakespasm.
Now, mh, YOU KNOW that the paragraph you quoted from yourself in the past is utter nonsense (why are you trying to make it sound overly-complicated by talking about sorting lists and comparing bitrates and acting as though it's a crazy impossible situation if there are multiple formats in the same folder?).
Do you know how I know that you know it's nonsense? Because I just fired up DirectQ, YOUR QUAKE ENGINE, and guess what? It can play both MP3 and OGG files, and if I have BOTH an MP3 and an OGG file of track04 in the same folder, it simply plays the MP3 instead of getting confused by this "crazy-assed situation" and causing the earth to explode. FTE, on the other hand, supports both formats and gives preference to the OGG in the same situation.
So, YOU'VE done this. It was simple, because apparently you did it without even knowing you did it. It just works automatically, easily, and effortlessly for the user. But now you act like it's some impossible insurmountable obstacle to programming....
Are you retarded or something?
See, I don't listen to tards, because they say retarded things that just aren't true.
Just saying! ;)
Now the continuing report of the weird centerview behavior....
Me and another player on the FvF server experience it working and not working at the same times. I checked the clock and it seemed to be right about 15:30 when it stopped working. On the next map (it starts working again after map change), I watched again to see if it would repeat, and it seemed to stop working again right about 15:30. Then it started working again around 18:00, stopped again sometimes after 20, then stopped again after 21... and stayed that way. At each point I told the other guy and he agreed that it would start/stop working during the same periods it did for me.
I was using Quakedroid with keyboard only, and he's in Linux Mark V using mouse + keyboard.
I tried playing around some more to see if those times would aproduce the bug in single player or local multiplayer, and by restarting a map on the online server and messing with the host_framerate, but I can't really get it to repeat.....
But it's rather odd that centerview (not force_centerview) should be affected by anything the server is doing... at certain times... for multiple connected players... isn't it? We were just standing around in the game not doing anything weird. Pretty sure I don't do anything in FvF that should alter a player's view like that. And as I reported before, after tapping the centerview key, the view will center itself after like 10-30 seconds when the issue occurs.
Weird one. *shrug*
@gunter ... get me a demo and the time within the demo the problem crops up. Use cl_autodemo 1 or have your friend use cl_autodemo 1.
There are dozens of items used in the Quake view drift calculations, some come from the server or the mod (QuakeC).
It could be so many different things like the server/QuakeC specifying "wishangles" or movetype fly/noclip or an onground flag that without live catching it, there is not a reasonable chance of isolating what is occurring.
Since a demo is the capture of all communication from a server, the information within a demo should be enough for examination to see what variable is the source of what you have experienced.
Other: I'll build the Linux in the next 24-72 hours. The "link active" thing should go away. Although I spent some time examining ffmpeg, too many irons were in the fire and I never got around to adding soundtrack support for Linux nor QuakeDroid because there was too much going on. So that'll happen next time (maybe Christmas).
@fifth - Yeah, split screen is going to happen! Haha! Almost happened this time. Next time is a lock.
It's ironic that this may happen when I am playing the least amount of Quake for about 10 years.
Asking Baker for help
since he has experience with both the software renderer and with things like his tool_texturepointer.
Did I say adding ogg support was impossible? Don't seem to recall saying that. Yes, I've written it myself in the past, did I deny that? You'd think the fact that I've written it would put me in a position where I could be assumed to know what I'm talking about, but apparently not.
Yes, I know what code that supports multiple formats looks like. I know the kind of things it needs to do. I've written such code, so please don't assume that I'm BSing when I say that the MP3 code in MarkV is nothing like it. This isn't a simple modification, this is an extensive gut-and-rewrite.
Asking for the same thing over and over again when it's already been both patiently and impatiently explained that you're asking for a lot more than you realise is wearing pretty damn thin.
MP3 Vs OGG
I don't quite understand what's the big fuss about having to use MP3 versions of the Quake soundtrack. They are not that hard to obtain. "Other ports support OGG" is not a valid reason to insist on this IMHO.
Sure, it's maybe nice if you can use the soundtrack files in different ports if they are in OGG format, but honestly I am only using Mark V by now. As far as I am concerned, I got used to using MP3 files.
@gunter - Your Rare Heisenbug Demo
I reviewed your demo and peeked at some internals. Things affecting lookspring ...
1) internal game clocks (seems fine)
2) onground is non-issue
3) Although the problem went away on level change, it could be just a coincidence.
4) The server wasn't stuffcmding anything that interfered.
Can you link me up a copy of your config.cfg and autoexec.cfg so that I can review some other potential things since cvar settings combinations could be involved or divide strangely with floating point.
I almost replied your post @ inside3d yesterday about your engine and polygon points.
But I suspect you might not like my opinion of an answer, but here goes ...
Mark V has *ALL* of mh's matrix calculation and manipulation functions. This stuff primarily is not needed for WinQuake since it doesn't use OpenGL, yet even Mark V WinQuake uses these.
I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.
What stopped me from posting is that since you do the software renderer, you likely don't use OpenGL matrix transformations -- and I felt my answer would be unhelpful (*).
You'd also probably have to add some GLQuake extra fields to some structs to make life easier. So I figured you would hate my answer and didn't post it.
(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)
There is Carmack matrix manipulation stuff in WinQuake, but where it differs from the look and feel of OpenGL matrix manipulation it looks Greek to me, mostly because if I didn't need to understand it for a feature, why investigate. I think one of the few times I used Carmack's matrix stuff was for "fov doesn't affect gun" option.
More Concise version: If I were in your shoes, I would add all the glpoly_t to the WinQuake renderer and modify the surface structure and use those to access coordinates. Then use mh matrix functions against those points and things like Mark V project/unproject (which is basically similar to gluProject) But I don't think you'll like that idea.
Plus my thoughts are shaped by my lesser knowledge of the internal workings of the software renderer than yourself, so I don't even know if "what I would do" is optimal.
(* because it took me a couple of years of get good at 3D matrix math and if you aren't using it regularly, I doubt you wanted the "hey start learning it and in 6 months .." kind of answer.)
Yes, that's more or less the point. I don't want to get deep into this kind of 3D math before finishing the stuff I'm working on right now. Plus, what puzzles me the most is not the math, but the fact that it seems that the on-screen vertex data is unreliable.
I you looked at Mark V texture pointer code, you can see it drawing the polygon and doing that calculations you are seeking would be straightforward.
For now I'm going to do it the brute force way and extract the coordinates from the chained spans data, iterating through the whole chain to get the max and min x & y values. I suspect there'll be a lot to rewrite in the engine to get this kind of data in a straightforward way. But I'll take a look at what you suggested, thanks.
By the way, Makaqu has support for .scale on SPR sprites, so you can copy it from there. IIRC it's pretty simple. It also has .scalev, which can be used to scale each axis individually. The only model format I didn't try figuring out how to scale is BSP.
extract the coordinates from the chained spans data
The glpoly_t has those and generates them on map load.
BuildSurfaceDisplayList <--- in Mark V and I think the same name in FitzQuake 0.85, which might be the same code as GLQuake (never looked, but seems very likely).
Also see: DrawGLPoly where it shows code drawing iterating through a polygon.
Generates all that glpoly_t stuff. Just on map load.
For any glpoly_t named "p" ... the verts are p->verts (X), verts (Y), verts (Z)
Anyway, the reason I recommend this is that the code for getting the verts is already written in GLQuake.
(Then create a projection matrix and a model view matrix based on current player origin/angles and fov and combined with the viewport width/height you can get convert between real world points and screen points including z near depth 0 and z far depth 1 as much as you like <--- part of answer you will hate obviously, but the nice part is that it works.).
Here's a thought for you ... QuakeDroid has tap-fire and the very first QuakeDroid was (WinQuake) before a switched GL to be the main QuakeDroid.
1) Load up Mark V WinQuake.
2) Type vid_touchscreen 1 in the console.
3) Double click on a torch and watch what happens. It is QuakeDroid "tap fire".
Now double click on a wall.
Now think about the fact that in order for that to work, the "tap fire" has to know the targeting distance to get the angle of fire correct!
("Tap fire" has about all the calculations you want, and it does them in WinQuake! No GLQuake at all. It shows you how to do most of the things you need.)
@Baker Help/support For My 100b Jam Map.
Hey, I've got a map incoming for the 100bjam. It is currently using many new mdls, some with alpha textures recently supported with the newest Quakespasm release. Notable, these trees here as seen in Quakespam 0.93, Quakespasm currently displays all my models correctly:
When in MarkV dx9 the transparency doesnot work on 1 skin, also the model itself appears to be transparent with the background bleeding through
In Mark V the skin is fixed but bleeding from behind the model is visible, as well as a transparent layer that seems to cover the entire model:
Also, geometry is bleeding through all my models in Mark V even when they don't have transparent skins:
Currently only QS will run this map correctly. Anything that can be done Baker?
OMG! It's beautiful! I knew you were a talented guy but I've never seen anything like that in Quake. I'm not sure I would have ever thought it possible.
1. Do you have r_shadows off?
If r_shadows is off ...
There is an Open GL Mark V 1.99 in the following zip http://quakeone.com/markv/builds/1099_mark_v_windows_extras_revision_3.zip (It's the SDL GL .exe)
I would recommend you check and see if looks ok in OpenGL.
Let me know ...
Running on the newest openGL MarkV fixed all the issues with the models and the display perfectly now.
But there's a new problem. My map uses a func_illusionary for the bottom skybox face, with a minlight func_group beneath it. This is in order to properly light the models. Other methods failed because there is a problem with the current version of ericWs tools. This sky works fine in QS, but the bottom is not showing in this MarkV release now.
I guess I didn't notice that the bottom skyface wasn't showing on older MarkV version as well. I mean I could try casting sky on a func_wall (although this makes sky 'shootable') instead as this also worked in QS, but will either of these methods methods display properly in MarkV?
So there is a func_illusionary skybrush at the bottom of the map?
Do you have a sample .bsp that illustrates the issue? Need something to look at.
Sample map with func_illusionary as bottom sky face, beneath that func group with minlight, beneath that a regular brush. 3 layer Sandwich. Run this in Quakespam and MarkV and you will see MarkV has no support for func_illusionary sky.
Source is included
Cool! Sky brush entities are rare (so rare I can't name with a map that uses one, and I have lists of maps with uncommon features) I probably forgot to implement it for lack of a test subject.
Yeah, otherwise it seems to run fine in the newest version which is good news. I guess this means v1.999 is on the way?:)
Trouble With Rubicon Rumble Pack
Rubicon Rumble Pack, version 1.03. In map telefragged, when you approach the area with the 4 labs (the one with the platforms going up and down in a pool of slime), Mark V closes to desktop with no error.
This is on Windows 10 1803 x64, with all versions of Mark V.
For the area you are talking about, could you type viewpos and give me the numbers.
It looks like this:
Camera: (544 288 50) 0 90 0
Viewpos: (544 288 28) 0 90 0
Rubicon Rumble is a really big map.
Sky entities addition done. Just need to build.
(I would like to look the issue that gvakarian says occurs with Rubicon Rumble before doing another build, I've looked around some of the maps but I don't know/can't find the area he is referring to ... the maps are gigantic).
Great stuff Baker. I'm hoping that players who are MarkV users will be able to enjoy my map. Not sure how your gonna find that Rubicon glitch, needle in a haystack. Goodluck
The approach to the 4 labs is in telefragged.bsp at "1134 -319 -8" facing angle "0 0 0". the labs are through the doors at the end of the hall.
Haha! Thank you!
If someone says they have an issue and I can't investigate it, it is annoying as hell!
@redfield - Any chance to get something to test the outstanding issue of screenshot you first posted that had black where transparency would be in the DirectX Mark V. I've done some fence model texture skin tests in DirectX Mark V and it renders just fine.
I'm glad to see alpha masked models get some live use in actual Quake.
It's a tricky one. Baker mentioning floating point divisions put me on the right track of what to look for.
Ok, in FvF, the Cleric and Monk can create health and armor. In Quest (coop) mode, they get XP (frags) for giving that health and armor to their teammates.
A regular health box given to a teammate earns you 0.25 frags... so after you've given 4 health boxes you've earned 1 frag/point/XP.
Quake doesn't have a problem with this for math and display purposes, as it only shows the rounded number in scoreboards and such, and when the map changes, the fraction is dropped completely from the frags value.
BUT! This seems to be the cause of the bug. When ANY player's frag value contains a fractional value, it prevents EVERYONE on the server from using centerview! Well, I mean, it usually works on a delay of like 20 seconds.... But what's up with that? Why should someone else with a fractional frag value prevent everyone's centerview from working correctly? Why would frags even be involved in centerview?
Upon tossing that 4th health box to a wounded teammate (so my frag value no longer contains a decimal value), my view will then auto-center right away (having previously pressed the centerview key).
Reproduced in Mark V, QuakeDroid, ProQuake, and Qrack... so... if you fix this bug, you'll be breaking new ground ;)
@gunter - Great!
Awesome gunter! Glad to see you solved the mystery.
I turned over every rock and was striking out.
For me the big deal is that Mark V has a really hard time loading MP3 files on my WinXP netbook. I've heard another person say something similar.
When loading a decent-quality MP3 track inside Mark V, the entire game literally freezes up for over 20 seconds while a glitched menu sound (if I just activated external music in the menu) replays over and over until it unfreezes, and then the music starts playing.... I manged to find some re-encoding settings that reduced the quality of the MP3 a lot and got that freeze delay down to 5 seconds....
However, when I use OGG files (by renaming things or hacking Mark V with a hex editor to replace "MP3" with "OGG") then the song loads almost instantly, with only a 1 second delay or less.
So yeah, it's a real issue for me, and not just some weird irrational preference for certain formats! ;)
Add: I'm not sure, but since you can reliably identified and recreated the circumstances in multiple engines, it gives me something to think about.
Gunter, I just want to point out that it is impossible to play ogg on Android or an iPhone (without unacceptably chewing up metric shit tons of CPU -- hence the frames per second would be absolute trash --- because it is an obscure format and hence does not have hardware decoding in the processor) while because mp3 uses hardly any cpu at all because it has hardware decoding built into every phone/PC/device on the planet.
Plus the Mac version of Mark V plays mp3 via Apple API via hardware decoding using nearly 0% cpu. ogg being an obscure format that no companies ever use, there is no Apple API for that.
I care that your Quake works right, but you already found a solution that works for your computer issue
with mp3 by cheating around with something that happens to work on Windows.
So your personal issue is solved.
My issue is I want things to work the same on all 5 platforms that Mark V supports.
Why the hell would I want to support an obscure music format that can never work on the 2 mobile platforms that I like with Mark V.
Why would I also want to recode the Mac version to support a shittier music format that uses more CPU? Oh -- and since I couldn't use Apple API I would have to rewrite the music code.
And the Quake .mp3 sound tracks are available everywhere, like on the Steam page. Case in point, this guy is links to it. Also Travail's soundtrack is mp3.
Also why the hell support more than 1 music format?
Shall we figure out new graphics formats like .bmp or hey let's do .gif!
The only engine that can't play mp3 is DarkPlaces, and to be blunt --- DarkPlaces is an extremely shitty engine for playing Quake because it made itself so damn incompatible with a lot of Quake mods.
I'm just communicating my point of view.
I don't care if people discuss it or what not, discussion is always a great thing -- environments where you don't find discussion or arguing are sterile and mindless. You might consider listening to my point of view, though --- I have one too! Haha
mh, yeah, I was being overly-dramatic because you were doing the same. But you've remained clam and respectful in your recent post, so I will do the same (funny how that works).
Sure, I would normally take your word for it, in areas of engine programming, but not when you are making statements that are clearly exaggerated and misleading.
Of course, in your original post on the matter ( #1757 ) you pointed out that Mark V already supports OGG through DirectShow, which you knew because you were the original author of that code, but Mark V is hard-coded to only look for MP3, and supporting OGG should just be a matter of adding support for other extensions, but, you said, "I can't say what kind of work would be involved in this change."
After that tip, irlyap and I found we could hack Mark V to allow OGG files, and PRITCHARD made the amusing comment: "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!' "
irlyap made the comment that it would be like "adding 3 characters" which is when you pointed out it would not be THAT simple, which I'm sure is true, but the paragraph of reasons you gave (which you recently re-quoted) is the problem.
I'll just take one part of it as the crux (though I believe the entire quote is trying to make it sound more complicated than it actually is):
"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?)"
So, since you have coded multiple-file-format support before in DirectQ, did you actually DO that comparing of bitrates?
I already know the answer: No, of course you didn't. Comparing bitrates of various file formats would be a completely ridiculous thing to do. There are several Quake engines that support multiple formats, and I bet not a single one of them would dream of doing something like that. The only decision you have to make as to what takes priority is, "do I want MP3 or OGG to have priority?" and the answer to that is already quite obvious for Baker! Heck, I'm thinking that decision would happen automatically if the coder didn't want to specify a specific order -- the engine would just play the first format it came across according to it's internal list of formats to look for....
In #1764 irlyap pointed out that OGG was already " listed in Mark V's file extension look up table" and he guessed that there must be some code that explicitly ignores of forbids it. Then just a couple posts after that, both he and I pointed out that you don't need to do any of that overly-complicated stuff -- just add support for OGG with preference for MP3, and that's it. Sure, that's likely more than adding 3 characters, but I know it's nowhere near as complicated as the quote you brought back up, after we had previously "patiently explained" that none of that was necessary....
Now, maybe your original intent wasn't to make it sound overly-complicated and you were just considering options.... You did also say in that same old post, "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. ... 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."
The expected behavior is just as I said (and maybe irlyap explained a bit more thoroughly in #1768 though he spoke of 3 example formats when all you need are 2). Allow support for MP3 and OGG in that order of preference. Or, stated more simply: just allow the engine to look for OGG files if it doesn't find MP3 files! How hard could that be?
Baker's objection to OGG has never been that it would be difficult -- he just wants Mark V to be The Engine of the Future, and OGG doesn't exist in his Perfect Future! (or something like that!).
Now, before there are any slippery-slope arguments like "Where do you stop? If you add one format, you have to add hundreds more..." -- Nope, all anyone is seriously asking for is a second format, OGG. So you have a mere two formats, and that's all you need. Nobody uses any other formats for Quake music (not that I've heard of -- someone said something about Opus and QS? Is that really a thing? What the hell's an Opus?? Isn't that the penguin from a comic strip??).
I explained my point of view. I want the engine to work the same on all 5 platforms.
Tomorrow, you might get a new computer and you will no longer care about any of this.
Ok, I'll address your points.
I accept that Android won't play OGG. No problems with that. But I don't see that as a good reason to say, "Since mobile platforms don't support OGG then I also want to prevent the desktop versions from using OGG when they otherwise could."
You say you want things to work the same on all 5 platforms, but that's never going to be quite true. For example, my WinXP netbook does not have a touch screen, and my Android device doesn't have a mouse.... Yet there are touchscreen and mouse things coded into the engine.... So what happens if I enable touchscreen or mouse on a device which doesn't support touchscreen or mouse? Nothing. Nothing happens. And that's fine. That's how it should be.
So if you allow Mark V to simply look for OGG files if it doesn't find MP3 files (simplest way of stating it), what would happen on an Android device, even if I had OGG files installed? Nothing? Would just nothing happen because Android won't play OGG files? So it would be no different whatsoever from now? That's what should happen: Nothing.
So there would be no harm done if a WinXP computer, which can easily play OGG through DirectShow, were allowed to do so, but a Mac or Android would simply do Nothing because it can't play OGG. For the user's benefit it would just be as simple as stating, "Mark V supports MP3 as the primary format, with OGG as an alternate format if you have a Windows computer with DirectShow which is capable of playing OGG" (and face it, Windows users are likely the majority, so it's not a trivial number of users we're talking about).
"Why support two formats?" For convenience of the users. I'm not the only person who has asked for OGG support in the past -- I only started asking when I found OGG magically fixed my freezing problem with MP3s (and I suspect Dutch had the same problem). Yeah, I can hack a workaround, but then I have to offer my hacks to other users who may prefer OGG for various reasons, and I find that "solution" to be ... ugly.
Nobody is asking for more graphic formats, and nobody is asking for a multitude of music formats. But yeah, apparently OGG was a fairly common format for the Quake soundtrack... otherwise there wouldn't have been multiple people asking for it.
And what would be the harm if just *Nothing* happened on platforms that don't support OGG? While at the same time allowing OGG to be used on supported platforms by simply allowing Mark V to check for an OGG file IF it doesn't find an MP3?
The benefit is that it helps users who either have MP3 problems in Mark V (like me), or users who already have the soundtrack in OGG format installed....
Pros: Benefits/is more convenient for some users.
Is that accurate?
I mean, this isn't a case where you have to specifically tell android to NOT play OGG because it will be slow and crappy, is it?
Isn't it the case where Android (or Mac, or whatever) will simply do Nothing if an OGG is present? Because that's exactly what Mark V does now when an OGG is present!
"Tomorrow, you might get a new computer and you will no longer care about any of this."
You keeeeep wishing that, don't you? XD
(And I still don't know how to make quoted text appear grey.... How do people do that?)
And then I found THE FAQ thread.... Which told me the codes, which are very similar to BBCode but not exactly the same....
Baker, download this model and drop it into a map using Quoth custom_mapobject or AD misc_model and set the skins to 0 and 1.
I tested with an isolated clean install of Quake and MarkV Dx9 and your newest build. Only the new build displays these models correctly.
Thing was a bitch to make, so its nice that newest builds of all the engines (DP untested as yet) can display it properly.
@redfield - Masked Models Will Be Ok In DX9
I think everything is going to work ok for DX9 with the masked models.
screenshot: red tree masked model now renders leafy style in DX9
I'm not actually modify the DX9 rendering, but in this case was able to determine what the DX9 hated and do it a bit differently to get it pretty close to what it should look like.
Just curious, what was different between the two mdl's that caused one to work and the other not?
This is great Baker, thnx.
Yeah would be interesting to know. Its the same model only skin difference.
The Red Tree Skin
The red skin has fullbright pixels in it.
If you do "imagedump" and look at the fullbright skin generated ...
You can see dark red that would technically show up in pitch black with no lightning.
(Really the texture probably shouldn't -- like it might have glow in the dark pixels to the extent that dark red is , but it happens in map textures all the time too, haha.).
So it was using a combination of OpenGL capabilities at the same time that doesn't normally happen in Quake with alias models (.mdl), so the Direct3D wrapper wasn't prepared for that situation or at least never tested in that situation.
/Short version: Was a DirectX wrapper thing
I gotta fix this POS tree asap. I'm gonna kill this fu*king thing!
I had the palette set to no brights, goddmanit!
This should be a meme or something
I'm drafting court papers against mtPaint right now. No brights was loaded in the palette. FRAUD.
Everyone Take A Deep Breath...
Ok, the tree has been DEALT with. The evil brights are gone and the tree now displays in Dx9 Mark V as intended:
Directx9 Alice Quake Map
There is also a womans shoe model in an bubble with alpha applied and it seems to display as well. There is still a visible transparent layer across the models that does appear in the 1.99 release however.
Thank you @Baker and everyone.
I'm going to celebrate now with the mixing of chocolate and milk...
^Does NOT appear in 1.99 I should say^
Just say "there is small rendering glitch in Mark V DX9 in one area and I'm told that it will be looked into and fixed in the engine if it can be".
If I can fix it, it'll get addressed. I wouldn't stop the show because of that.
Mark V - Version 1.99 - Revision 4 (Final)
Download: Windows - DirectX | WinQuake
Download: Linux GL | Linux WinQuake
* Sky entity support (redfield)
* Alpha masked models w/fullbrights fixed in DX9 (redfield)
* Ctrl/Shift bind firing/console if on server (gunter)
* Linux "Cache LRU link_active" fix (Dr. Dumb*uck)
Also available are a couple of alternative/requested builds: extra builds
Just related a note, (as I've reported before) my func_illusionary guy with his fullbright pixels still isn't transparent unless I set gl_fullbrights 0. The same goes for weapon models except the axe when I have a ring (unless custom weapon textures are used, which contain no fullbright pixels).
Now, a fun story!
Oh my gosh.... I just went on a very frustrating adventure to try and make one point... and ended up with several points to make.
So to do this, I decided to try out Mark V's "install" command for map pack from Quaddicted. I've never messed with this feature before.
I tried "install qump" then I went to Single Player, New Game (because Mark V's "map guessing" feature is supposed to make that work)... but... it didn't start Qump.
So I looked at how it was installed, and I see that everything was put directly into the id1 folder....
So I checked the Qump readme, which explained that everything should be installed to a Qump folder.... But I scanned down and saw that the first map was titled "Beginning" (by PRITCHARD!), so I tried "changelevel beginning" -- map not found.
So I looked in the id1/maps folder and saw all the maps were actually named qump_[something], but there was no qump_beginning.... but I saw a "start.bsp" which had been installed.... Ok, that must be it, BUT because of unpacked files not taking preference, doing "changelevel start" will not go to that map!
Ok, so let's start over. I do "uninstall qump" ... NOPE! Mark V tells me the qump folder does not exist.... But.. you just INSTALLED it that way! argh!!!
Ok, I MANUALLY delete all the files that Mark V installed, using the list it told me in console. Handy.
And I notice that it overwrote my id1 start.lit file with qump's start.lit file.... *grumble* So I'll have to replace that with the correct lit file later.
Now, I remember people saying something about specifying a gamedir to install things to with the "install" command, but the HELP info for "install" doesn't tell me how to do that....
Soo.... I just guessed it would be something like "install qump qump".... buuuut that doesn't work, and produces an error message that I find unhelpful:
Need the game to install or the entire URL with
the http:// in it
Example: install travail or install [http://URL]
The version of libcurl used does not support
https:// at this time
So I give up on that and come to the conclusion that I dislike the install feature and will just install everything manually from now on!
I noticed when removing files that the qump.zip file has been downloaded to a id1\_library folder, so I just unzip that and it already contains the Qump folder, making it very simple to install correctly.
Next I switch to the qump game dir and start a New Single Player game, and I'm in the qump start map (because it's correctly named start.bsp, making map guessing completely unnecessary).
So am I happy now? Nope! I finally got to the (only) issue which I started out wanting to illustrate: Mark V does not play the background music for this single-player release from Quaddicted because it's in OGG format!! XD
So I started up DirectQ (mh's engine!) since I knew it supports both MP3 and OGG (with preference for MP3) and did "game qump," and to my surprise it automatically tried to exec an autoexec.cfg file in the qump gamedir!! Which is now the third issue I have previously argued for in Mark V, which mh has strongly argued against, which I have later found to already be incorporated into his own quake engine!
So let me just go through this checklist:
[continued in next post, because I write more than 5000 characters!]
So let me just go through this checklist:
1. Failed at correctly installing with the "install" command (and overwrote one of my lit files), and I couldn't find in-game help info to tell me how to do it correctly. So I had to install manually by just extracting the zip file, as usual.
2. The "map guessing" feature failed to help whatsoever, because in the first situation the start.bsp was installed to the id1 folder, and Mark V gives preference to the pak files (yeah, that's the Quake default, but it shouldn't be, because if someone has copied new files, like this new start.bsp, that should obviously take priority -- I guess that's issue 2.5). Then, once I installed qump correctly, the "map guessing" feature was pointless because the map pack correctly has its own start.bsp... and even if it didnt, I could have used the Levels menu to select a map.
3. Mark V does not play the background track because it's in OGG format, even though (on my system) Mark V can easily play OGG -- it's just hard-coded to only see MP3 files.
4. If I had set up my own cfg files in the Qump directory with any special configurations I want for Qump, Mark V would not run those for me when I switch to the Qump game folder....
Compare this to DirectQ, which is old and no longer being developed:
1. No difference in the first step -- I have to install the qump folder mahually. But since I know I have to do this, I wouldn't have to go through that annoying experience I had trying to use Mark V's install command!
2.5 Even if I had installed incorrectly into the id1 folder, DirectQ would have handled it correctly because it gives preference to unpacked files!
3. DirectQ automatically plays the background music because it hasn't been hard-coded to ignore OGG files.
4. DirectQ automatically runs the autoexec.cfg file in the qump folder when I switch to that gamedir (just the autoexec, not quake.rc), so any settings I want to use for qump will be automatically applied, as they should be.
Now, I'm not actually considering switching to DirectQ, but damn, it did EVERYTHING better in this example!! And each of these issues are things I have strongly argued for in Mark V. And ironically, every one of these things are things that mh has argued with me about, taking the opposite position! Well, not specifically on the "map guessing" feature -- I don't think he's said anything about that, but DirectQ also has a map selecting menu like Mark V does (which is the most correct option for starting custom maps).
mh may suggest that he made mistakes by including those features in DirectQ (he's done that before: #1640 ), but I'm serious here: mh, don't sell yourself short -- these features I've just encountered were great additions to DirectQ, because they "just work" and make things easier for the user without getting in the way or causing problems.
Now, back to the only point I was trying to make when I began this ordeal: some single-player map packs at Quadiccted contain the soundtracks in OGG format (as that was a pretty commonly-used soundtrack format for Quake engines), and Mark V, even though it could easily play them (though not on every platform, I understand), will not do so because you basically won't allow it to look for OGG files.... So... Mark V is (intentionally, in this case) not compatible with maps packs like the following, which contain OGG soundtracks, ranging from 1, 4, up to 11 songs:
These are just the ones I found when specifically looking.... Are there more? I would expect so.
You've said compatibility with single-player releases from Quaddicted if one of the main goals of Mark V, so why deny compatibility to the platforms (like Windows) which are easily capable of playing OGG if you would simply allow it to do so?
And oh yeah, all those other issues which I have argued for in the past, which just happened to come up when I was testing this example:
- No "map guessing" -- it causes me problems in addition to not working or not being needed.
- Unpacked file preference -- if a user installs unpacked files, those are obviously what he wants to use rather than the defaults stored in a pak.
- Exec autoexec.cfg when changing game dir -- if a user has an autoexec in a game dir, he obviously wants it to auto... exec it for that game.
Well, that was fun! XD
Are you sure you are using the most recent version of Mark V?
There's no way current Mark V would install/unpack qump to anything except its own folder.
Johnny Law and I used qump as one of the test subjects for getting the install unpack perfected.
Ah, you're right about that; I have a separate test folder and didn't copy the today's newest Mark V there before testing. I was using 1.98.
I'm testing again with 1.99 annnd... it installed correctly to a qump folder.
Johnny, since you are familliar with a lot of the map packs, do you know of any others besides the 4 I mentioned that come with OGG soundtracks?
Quick comment -- I wanted to look at qump's skyboxes on the original start map. Of course, qump includes its own start.bsp, meaning it overrides the usual start.bsp (as it should).
Then I went to the Levels menu and scrolled down past Qump's "Start - Between Worlds" map, all the way to the bottom section for "Original Quake Levels," hoping Mark V would know to use the start.bsp located in the pack file if I selected it from the "Original Levels" list... but... it doesn't, and qump's start.bsp still runs.
How about forcing it to use the original levels from the pak file if they are specifically selected from that section of the Levels menu? Is that possible?
Thinks: I wonder if this same topic "over and over and over and over spam" reaches the point where moderator assistance becomes necessary? I sure hope not.
I wonder if moderators will start taking action on all the passive-aggressive posts on this site? I sure hope not, even though a lot of people around here are [edited by moderator]
What you want is possible as long as the unpacked maps are in a different gamedir (qump/maps) while the original Quake packs remains in id1.
Start the pack with -game qump, and type map ../../id1/maps/start in the console.
When running mods, it would be wise for the maps menu to add this relative path to the original maps' names.
[edited By Moderator] No Offence
i don't get that fancy shit, like automatically extraction to that given folder, the peeps are too lazy nowadays
just download the hotdamned archive, and extract it according the readme file
About the "OGG drains too much battery" issue, that can be perfectly worked around by making the engine transcode the OGG files to MP3 and saving the resulting MP3 files to the storage flash/disk drive during engine bootup. This way, when the game wants to play music the MP3 files will be there.
Optionally, the OGG files could be automatically deleted after the MP3 files are saved, to conserve storage space. I'd leave such an option turned off by default, though.
It's true. Few people will use the install command.
It's a stepping stone to full blown built-in "Quake Injector".
At this point is only needs a nice user interface inside the engine.
I want it to be very sophisticated like the Quake Injector, but I also want it to look nice and Quakey in the engine.
Maybe next "development season" I'll talk with Johnny Law and get his thoughts.
I would also kind like of like to enhance the frogbot support to offer some way of setting up the frogbots nice and easy in the engine. (Maybe "development season".)
/Next time things
<--- There He Goes!
Ended up doing a final revision for redfield especially because the map uses alpha masked models (I like alpha masked models and want them to be used in Quake).
I'll be back sometime before Christmas and do split screen for sure and I'll probably check the thread every few weeks in read-only mode.
/Back around Christmas, I imagine.
I would also kind like of like to enhance the frogbot support to offer some way of setting up the frogbots nice and easy in the engine. (Maybe "development season".)
Wow, sounds nice!
There He Goes
Or so he said last time. We'll see....
@mankrip, nice, that would be a really clever way to "support" OGGs on systems such as Android that can't play OGG natively. Though I'm not sure how much of a delay might occur the first time the transcoding occurred. And it wouldn't help in my situation, as I would be right back where I started, with MP3. But still, that would be a clever workaround to allow maximum compatibility for soundtracks on all platforms.
I've got a pretty thick skin so I can handle being called a "dumbf*ck." But I have never run Quake on Linux and have not tested Mark V on anything but Win7.
As far as the install command. I plan on covering that in the upcoming Mark V video. I love that feature and anything that will make it easier for people to play my maps is welcome. It's not laziness IMO. There are too many alternatives for people's attention.
Mistaken identity. There's actually an FvF player called Dr.DUMBFUCK who I told to come here and report his Linux issue, heh. #2137
But I guess you could be Dr. Dumptruck!
it wouldn't help in my situation, as I would be right back where I started, with MP3.
Then I don't see what's the problem. I don't pay attention to most posts.
Shortest version: on my WinXP netbook, loading an MP3 causes Mark V to completely freeze up for up to 20 seconds, but an OGG file of the same track loads in 1 second or less.
Then the MP3 playback needs fixing.
I've been following the thread and didn't notice that name. LOL
Mark V And Xinput
Baker, here's a note for your next session. :-)
Sometimes I play Quake through Steam in-home streaming. My controller in that case is a Steam controller that presents as an Xinput joystick + buttons. This works with Quakespasm, but not with the latest Mark V (even with the -joystick option specified).
The console says:
joystick not found — invalid joystick capabilities (6)
Reading back through some previous posts I can’t quite tell if I should have expected this to work or not. So, FYI.
Thanks for putting out that new release Baker. You are da boss. My map should be out with the release of the upcoming mapjam.
Yeah, I still have issues too. I still have to physically unplug my other controller (whether set to dinput or xinput) just to get Mark V to recognise my XBone controller. I, too, was unclear if these issues were addressed or deferred... I'm not the brightest bulb on the Christmas tree so it's nice to see I'm not the only one a little confused here. :)
[edited By Moderator] Not Sure If This A Bug, But
Let's say i'm running a background streaming video in my browser
i run MV, and in that case, the fps are locking at 60
i terminate the streaming video, the fps are upping to their max
i'm still cannot figure this shite
Why Is Everyone Saying Android Doesn't Natively Support Vorbis?
I'm fairly certain that Android has supported Vorbis since 2008, so why is everyone saying that Android doesn't support it natively? What's the big issue with Vorbis support anyways?
I also find it strange that people say that Vorbis is not used in the game industry at all and that it's 'obscure,' yet I can name 5 games off the top of my head that use Vorbis?
I don't recall the claim being that Android doesn't supports oggs. The point is that hardware decoding of mp3 is ubiquitous, oggs must be software-decoded and that make a very appreciable difference to both performance and battery life. "Everything is software" is cutesy in the desktop space but it cuts no ice in mobile.
Use Ctrl + F and search for OGG and you'll eventually find claims that Android doesn't support Vorbis.
And what exactly does Mark V have to do with mobile though? I still see no reason to purposely disable Vorbis support for the desktop if Mark V is used on mobile devices, especially when some people have issues with Mark V loading MP3s.
About that: I still would like get an answer on mp3 playback in the Quakedroid channel. Just look at my most recent post over there.
When I was mentioning that Android wouldn't play OGG, I was only mistakenly repeating what Baker seemed to say in #2169 where he used the word "impossible." But then I found that Android CAN natively play OGG, and I posted about it over in the QuakeDroid thread.
I read something online saying that ringtones in MP3 format do not loop in Android, but ringtones in OGG format do loop (if a certain flag is set in the file), so I assume that's why Google uses OGG format ringtones for apps like Hangouts (and other built-in alarms and ringtones you will find in Android).
brassbite, I don't think music support has been added to QuakeDroid yet. Like you, I could not get an MP3 to play in the game.
Well Thats A Bummer
Why are we even discussing adding ogg support when the fucking game can't even play any music at this point?
QuakeDroid played the OST just fine for me...
So... i'm trying to compile the last version of markV
(this one http://quakeone.com/markv/builds/mark_v_1099_revision_4_source.rar
and i'm getting the following error:
fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
what am i doing wrong? :/
QuakeDroid played the OST just fine for me...
Well, then I don't know what the deal is. I (and brassbite) can't seem to get the MP3s to play in QuakeDroid. We need word from Baker about this.
(And I think we're getting some cross-posting confusion between QuakeDroid and Mark V.)
JFC Baker Has Repeatedly Said Ogg Wont Be Supported
Stop banging on about it for gods sake.
Gunter's mp3 problem will be solved in the Christmas update (this isn't new, I eventually gave up trying to communicate this to gunter).
Spike maybe a year ago told me about something neat he uses in FTE that will work even on Gunter's old WinXP computer just fine.
I'll add a cvar mp3_decode_fte and have it be a third click option in "cd/mp3 music on|off".
Gunter will end up being very happy and pleased.
@brassbite - I answered your question in the QuakeDroid thread (so anyone else looking for the answer can find it more easily).
@dumptruck - You wouldn't let me get the Trinity or the other 2 artifacts. And made me wait 10 seconds for the hammer. ;-)
@johnny - Yeah, just XBox controllers support. Microsoft controllers are actually backwards compatible to Windows 98 (!!) If you are super intent on using a Steam controller, find the release post and use the "alternate" SDL2 build! Your Steam controller *should* work with that. DirectX Mark V is not SDL2, so doesn't have the rich and deep controller support that they put into SDL2 (unless I steal it and graft it in, which eventually I will probably do in the future ... SDL2 is a very nice and freedom granting license .. a good reason to support SDL2)
@hipnotic - Yeah, it uses the first controller it finds. But in the Christmas version I'll add a way to set it to use "controller #2".
@tribal - I compile with Visual Studio C++ Express 2008 get it plus Service Pack 1. With that version, you open Mark V .vcproj and click "Build" --> BANG! It compiles.
So Tribal, I hope you can get it to compile. With the same Visual Studio, should be easy enough. There is no such thing as "current Visual Studio" because now they don't really do "versions" so I imagine they break things every 6 months or so because Microsoft is really good at that now.
/Resuming sustained months long inactivity ...
@dumptruck - You wouldn't let me get the Trinity or the other 2 artifacts. And made me wait 10 seconds for the hammer. ;-)
I'm guessing you were probably messing around in the menus before starting the map. The sound files seemed to get out of sync with the triggers when I did that. Disconnect, set your settings and then reload. I tested the map in Mark V extensively and prefer it to QS. :) Should be a solid experience.
I Wood've Bear With Baker
a lotsa bears
Thank you for the links, but i couldn't install VS C++ 2008 :P
I download other versions of the same program and none of them install... i searched on google and it seems there's something worng with my framework NET 3.5 or something like that... i'll try to fix it on the weekend :/
Thanks again =D
And i agree with dumptrunk, i prefer MarkV to Quakespasm... i like the HUD that doesn't cover the weapon, the sound and music are better, the colors have more saturation, it seems to me that the explosions have more particles, i don't know, but the classic explosions looks more powerfull in MarkV) and the special effects like the shambler's lightning, tarbaby's explosion and the fact that you let me decide which special effect i want turn on or off is awesome =D
Thank you one more time XD
Hi, it' me again =D
I think i found a bug :P
The tarbaby/spawn explosions doesn't change when you set to 0 or 1... it's the old/same explosion :(
i miss that pretty purple circular explosion from QMB
Is WAV Playback Supported For Music?
Wav Is Supported In Quakespasm
...but can't confirm if it works in Mark V here at work. I wouldn't be surprised because uncompressed formats are generally easier to support and it's not OGG. (LOL)
Spike has stated that .wav soundtracks is a bad idea.
Take an 4MB mp3 file and convert it to wav and watch it become 75 MB to 95 MB to 120 MB (it's kind of shocking -- you should try it and see for yourself.)
Spike said that the load times, the storage space, disk access time, memory usage make .wav "taxing" and undesirable for music play.
Anyway, that's what Spike said once upon a time when such a topic came up.
That last post re: OGG was not a dig. I was LOLing at someone else.
Gunter is very helpful and often able to make interesting observations that most people wouldn't notice. He plays co-operative all the time, knows QuakeC in a way comparable to Preach. Gunter isn't a bad guy, just passionate.
I think everyone occasionally gets passionate about something. Sleepwalker once had a guy named Dequer in the TrenchBroom thread who was "very passionate" about certain topics.
I think it is cool there are people still passionate about Quake.
Fun fact: Gunter once wrote a QuakeC rollercoaster ride. I kid you not!
Just like this thread!!!!
That's a amazing. I do think Gunter's passion for Mark V has made it better. There's no one who is as vocal or who tests it more than he! GG Gunter.
WAV memory usage is smaller than most compressed formats if it's streamed from the drive instead of being fully loaded. But the other negative aspects still apply.
Gunter made a whole playground entirely in QuakeC where you collected "Quaders" to use the games and rides, which included said rollercoaster, a trampoline, and something else. The arcade games were tetris and pac man all done using Quake's special characters font. Along with little things you can interact with like sticking your hand down an ogres pants for a quader. All this was used as a hub for connecting to other popular servers at the time.
Sorry I know it isn't related to the topic, but it had to be mentioned.
Also A Zombie Wall Climb
Yes, The Hub mod. I remember long ago Baker had mentioned an idea about a Quake server that would act as a hub for connecting to other servers and maps, so I went nuts with QuakeC to see what I could come up with. Ok, well, all my QuakeC is kind of nuts. I probably don't actually know QuakeC as well as a lot of other coders, but I can hack code like a crazy mofo.
Using lots of stuffcmds I had all the various exits around the Start map linking to all the various active servers at the time. Just touching an exit would test the server and give you a report about what map and players were connected there, and if you sat in the exit for 5 seconds you would connect to the other server.
Of course I made the whole map like an amusement park (making new floors and walls just using QuakeC to copy entities), with lots of things to do....
Here was n old thread on Quakeone: http://quakeone.com/forum/quake-talk/quake-central/1100-the-hub-two-thumbs-up
It runs as its own server, so I can't really get it up and running since I don't host servers. And it's more of a curiosity now anyway, since there are so few active servers these days, so it kind of lost it's initial purpose.
Though I have considered hacking the hub stuff into FvF Start map... but that would require me to be a lot less lazy than I am.
Oh, and I have to note the arcade games in The Hub were taken (and modified) from code made by FrikkaC and MauveBib.
And yeah, I'm passionate about stuff when I'm right
about stuff ;)
And yeah, I will be very happy and pleased if MP3 starts working well for my WinXP netbook, but it would still be right
to support OGG, for maximum compatibility and ease of use (remember, some single player map packs contain OGG soundtracks...).
Mark V is going to have a built-in Quake Injector with full blown graphical user interface + search, taking the existing "install" command and taking it to the logical final step.
The same way QuakeDroid downloads shareware or how the "install" command downloads from Quaddicted, Mark V can easily download an mp3 for the very few Quake mods (three? four?) with some non-mp3 sound track.
Besides, Nehahra has the soundtrack in the crazy .xm format which I plan to convert to mp3 to eliminate the crazy fmod.dll dependency in Nehahra.
I've had a blueprint in mind for ages.
These small things are easily handled and not even interesting conversation to me.
I also plan ahead: Mark V had Android/iPhone code in the source for 2 years before QuakeDroid or releasing compilable source for the iPhone version which predated QuakeDroid by a month, for instance.
Likewise, today's Mark V source code has jpeg support so the built-in Quake Injector will be able to download map screenshots from Quaddicted and use them immediately on-screen.
I always hated the fmod.dll dependency of Nehahra. Getting rid of that is another step in perfecting the support of this mod. Not sure if a conversion from XM to MP3 resulted in a loss of quality, though.
There are a number of items in the pipeline, often undiscussed.
Like changing the Effects menu item from [Classic | JoeQuake] to [Classic | JoeQuake | NPRQuake]. The current source code is reorganized to make this straightforward to implement (last year's source code was not).
Also: Making mh's work on "r_shadows 3" really kick some major ass by having the option to have shadows acknowledge brush model collision as a surface (i.e. e1m1 slime bridge) would be great. The framework for the feature is already written.
WAV memory usage is smaller than most compressed formats if it's streamed from the drive instead of being fully loaded.
In a world where 8gb is standard that's not really a big deal.
Besides, disk access is still slower than memory access anyway, so streaming from a HD in order to save memory, in a case where saving memory would not even be a requirement, seems to be the wrong side of a tradeoff.
disk is slower but you can cache ahead as much as you need. The most intense disk i/o is at map load time so streaming during gameplay would reduce that.
(note: I am not advocating giant wav files to replace mp3s)
Btw I am curious if Baker manages to make a flawless XM to MP3 conversion of the Nehahra music once it's necessary. I tried today and some of the tracks have crackling noise after conversion, even after normalization.
How does this one sound to you? My initial attempt to convert had crackly sounds for this track.
I then meditated on it a little and the result was this ... which seems to be perfect.
Nehahra - neh5.mp3
Let me know.
Mark V HD High Resolution Pack - June 16 2018
Screenshots: Screenshot 1
| Screenshot 2
| Screenshot 3
Download: HD Pack - 128 MB
and extract to c:/quake/hd
* High resolution textures (via qrp.quakeone.com)
* Modified JoeQuake menu to match Mark V.
* Conback and character set (via gfx.quakeworld.nu)
* .lits and transparent water .vis for Quake maps.
You may wish to set the following for best results ...
viewsize 110 // Hud to more Quakeworld appearance
scr_scaleauto 2 // "Auto Large"
qmb_active 1 // QMB effects instead of classic
Read more ...
I'm not a fan of the look but I will check these out for educational purposes and I am a fan of Mark V.
That type of look is popular in Quakeworld, DarkPlaces replacement textures users (Google up "Quake Epsilon" or "Quake HD" ... you might be surprised). and those who may have in the past really liked JoeQuake or Qrack (*).
There are also users who like high resolution textures because that have a large monitor and Quake textures don't look magnified on a large display because they lack the detail.
(Qrack: R00k doesn't seem like he is updating Qrack much these days. Qrack was popular for especially among those who liked playing original Threewave CTF online, and the last couple of years NetQuake multiplayer has declined quite a bit.)
I may in the future add some more options to support more fully the appearance of an ezQuake-looking HUD.
its slowly evolving with some tweaks and feature
just not as many players any more so ive
ive been focusing on singleplayer functionality
but not dead but nothing to write home about
Trouble Since Windows 10 April Update
My Windows 10 did the large April update, and since then Mark V has been super slow to start up, taking several seconds, whereas Quakespasm, for example, still loads almost instantly. Also, I'm not sure if it's related to the problem, but I tried playing dm4jam_ww, and without exception the game freezes when the Shambler's supposed to spawn at the beginning.
Has anyone else done the April update and had the above problems with Mark V afterwards?
For your information, if the engine freezes for you and you're unable to get the task manager window or the mouse pointer visible, I was able to do it with the following steps:
1. Press the WIN + TAB keys
2. Navigate to Mark V with the arrow keys
3. Press SHIFT + F10
4. Move the game to another desktop
5. Your primary desktop should become visible and controllable, where you can open up the task manager and shutdown Mark V.
What I've observed is that the latest Mark V and latest Quakespasm both take a few seconds to start up now -- longer than I remember from before -- and that Mark V Winquake is still fast.
I don't have issues starting up the engine but I get pretty poor performance. I've had slowdowns in id maps. Meanwhile my FPS doesn't dip like this in other source ports. Mark V WinQuake is all right but my PC has a hard time getting good performance out of regular Mark V.
More Windows 10 updates weirding things up ...
Anyone else using Windows 10 have issues with the engine?
/Looks like an investigation is in order, but little surprised this didn't arise as an issue back in, say, April or May.
Chiming in. Audio issues but I don't have access to that particular machine ATM. I thought it was my crappy hardware but then trying 1099 on an older Win7 laptop confirms there's likely an issue with Win10.
I will have access to another Win10 machine in a couple of days. Will report back ASAP.
Not Sure Where To Ask This
Is there a way to autoconcatenate demos? I never can do demos because I spam quicksave/quickload so often.
Am I admitting I play horribly...not really, but I love to save, do something stupidly crazy, probably die or fall to my doom, then quick load. I like to take huge risks, blast into a room, run around and get 50 baddies to follow me, trail vore balls through the lot, etc.
Is there a way to restart recording on the same demo file on quickload?
Demo To Avi/mpeg
Is there an engine with support to record demos direct to video format?
Mark V has a way to record a demo to avi. Search for capturedemo above.
Also cl_autodemo for automatic demo recording. But I have not played with it. cl_autodemo 1 for host_maxfps 72 and cl_autodemo 2 for framerates above that.
I know there were some very good demo tools designed for protocol 15 that have wonderful features. I need to go and research them tho. I killed those brain cells with beer long ago! They are all old and may still work. Keygrip was the craziest one. Had an editing UI and everything. I tried getting it to work last year without any luck.
There was one great tool that made a highlight reel from deathmatches. It would eliminate everything but the kills and you could adjust the time before and after.
I am SURE there was one that joined demos. Just have to find it. But probably no way would it work with newer protocols. :(
I have the same issue. I Quicksave a lot and when I am reviewing someone's work I have to go back and reload and start a new demo.
also if you just want a video and don't need an actual demo file, you could use outside software like Fraps or the Windows "Game Bar"
There is a command line tool called convdemo for protocol 15 at http://web.comhem.se/bjp/
that can concatenate demos (which may not be a lot of help since everyone uses protocol 666), but you could type "sv_protocol 15" in the console before playing and many maps probably still play with that on.
Mark V you can type "capturedemo demo1" in the console, the Mark V page has a codec that works fast and easy listed.
You can also do a .bat that looks like this and Mark V will exit after the capturedemo is completed.
c:/quake/mark_v.exe +capturedemo demo1
c:/quake/mark_v.exe +capturedemo demo2
c:/quake/mark_v.exe +capturedemo demo3
Mark V doesn't have a demo concat built into it.
Like dumptruck said, the "find" command finds about anything.
Along the lines of what metlslime said, there are video tools that concat videos.
Probably easier to do that ...
Drat...screen capture sucks though. Slows everything down.
Quite a number of quake engines support video encoding one way or another. If you're intent on avoiding demos then my advice to you would be to avoid xvid. ffdshow should have an h264 encoder accessed via the x264 fourcc setting, but as that's patented I have no idea what americans should use instead for streamed video.
If you're okay with a demo, then try fte's capturedemo command. Its an offline offscreen demo capture process, so it'll run as fast as your hardware allows (iirc, dp also has some sort of offline capture, but it doesn't support 666 so w/e).
Which reminds me that I really ought to update fte's ffmpeg plugin in order to make use of nvenc etc properly, which should greatly reduce the overheads - if you've got an nvidia gpu (which should also be a way around patent issues).
The supplied XVID codec on the Mark V has a few advantages that I have not been able to find in another free download:
1. It is rather fast. (WebM is way slower)
2. It doesn't come with adware.
3. It doesn't come with some other junkware.
4. It is easy to install.
5. It is known to work with the Windows video capture library that AVI capture Quake engines use.
6. Doesn't need a registered copy to encode.
7. It is known to work with the engine.
8. H.264 codecs seem to get overwritten by video apps installing their own special H.264 codec.
9. Doesn't do watermarks for unregistered versions.
For instance, I've found H.264 library and I did get it to work nice, but I had to do a lot of cmd.exe commands and might have had to run it as administrator --- too much to explain.
So I have a downloadable codec that is click, click, click to install.
/Anyway, the H.264 ones I found always seemed to have undesirable characteristics or junkware or put watermarks on the videos. And if it did work, the next video app might overwrite it with its own H.264 codec. Or so I recall. I myself would prefer a hassle-free H.264 codec without spyware or unwanted junk.
I would just want to make normal demos under protocol 666 or 999 without changing my playstyle. :/
add "+cl_autodemo 1" to the command line or type it in the console before the map. It should do a demo every time you re-load from a save.
Then use something like Virtual Dub Mod (free) or some other video app to concatenate the videos together.
Another option is something like Bandicam and record the screen while you play.
That's cool! Because I often refrain of recording demos because of Saving/Loading.
Lately I've been having an issue with mouse clicks occasionally not registering. I doubt that it's a problem with my mouse because I've tested extensively in a few other source ports and I never had issues there.
OBS Local Recording?
It's worked pretty flawless from my experience? And I even have an old PC(circa 2010 AMD.
You have plenty of options etc, why is this not mentioned?
I Have Obs, Quality Is Horrid
Thanks baker, I'll give it a whirl.
I play some Quake 3-4 times a week. Never experience mouse issues. And haven't seen any issues like posted in the thread.
I'll keep an open mind, though.
It could be a Windows 10 thing. One of the updates within the past several months broke mouse look in the SDL 1 version of Quakespasm. I've used Mark V quite a bit but I only started noticing this mouse problem within the past week or so. Or maybe my mouse is failing but coincidentally only when using Mark V.
I have a machine that I think now has all the updates for Windows 10.
Probably next week I'm going to see if I can experience any Windows 10 issues and see if I can locate a list of behavior changes for the "Spring Update".
Windows 10 updates are like a jar of random monkeys. Microsoft used to be good at compatibility and consistency.
Well, Win7 has done me good for like 7 years so.
Can you confirm the proper settings to play Mark V with a 144Mhz monitor?
My current config:
QS runs smooth as silk. It's clearly not working in Mark V 1099 and seems a bit stutter-y.
And yes I know 144 breaks physics. I just prefer playing this way. One thing to note: I use the same directory for QS and Mark V and switch between them often. Could it be a cvar I am missing?
I don't have 144 hz monitor, so beyond:
* vid_vsync 0 + host_maxfps 288 (yes 288, not 144 for 144Hz) ... might get better results ..
Back when I did have a display with a higher refresh rate available, I don't recall it behaving any differently.
Does this alternate version of Mark V do 144 hz smoothly? SDL alt build. There may be something SDL is doing to smooth things, but this falls into the "hard to code for scenario one cannot test".
/Note to self: See if can locate a 144hz display.
Also might need to manually set the refresh rate in Nvidia Control Panel to 144 when running Mark V or play with some settings there.
Mark V doesn't request a refresh rate.
(Because when Mark V first came out, it looked like 60 Hz was going to all displays, there weren't 144 Hz monitors and the only thing that supported changing refresh rates were CRTs and those were already dinosaurs.)
Don't forget to add Spike's QSS fix for high fps.
The SDL version had no change.
Typo above I meant vid_vsync 0
Setting "Highest Available" in the nvidia control panel was the ticket. That was the only option available to me in the CP. Thank you.
I am going to try and get 1099r4 tested on my Windows 10 machine tomorrow to check some of the issues mentioned above since the Spring update.
Setting "Highest Available" in the nvidia control panel was the ticket.
That fixed the issue?
If so, when I do new version around Christmas I could have Mark V have a refresh rate cvar or command line param and just specify the refresh rate on startup.
Thanks for the feedback, very helpful.
Good idea. A way to implement it would be:
- If recording a demo, store its filename into the savegame;
- When loading a save, reload its corresponding demo;
- Search in the demo for the frame that corresponds to the current frame stored into the savegame;
- Delete all frames stored afterwards, and resume recording. This new recording could use a different filename to indicate that it's a new branch (like "mydemo.dem", "mydemo(1).dem", "mydemo(2).dem", "mydemo(1)(1).dem", etc.).
Yep that fixed it. Silky smooth now.
Full Colors Maps
Full color maps were briefly brought up in another thread.
Short Video: Full Color Maps
Map Download: halflife.bsp - 239 kb
for anyone to try themselves in Mark V.
Will also work in FTE, DarkPlaces, several other engines.
Full color what, exactly? Colored lighting + 16/32-bit textures?
Textures Unbound From The Palette
hlbsp has licensing issues from its toolchain, and the hull size issues makes it generally unusable for quake anyway.
besides, lit files and (same-size) replacements provide all the same advantages and with well-defined compat fallbacks, and without shamblers ending up half-inside walls, and retains overbrights, just with more files (unfortunately).
if really needed then the -bspxlit arg can be used to embed the lit files, and -notex can be used to force external/replacement textures using the same mechanism hlbsp uses for external textures (so should work in the same engines) including support for q1 or hl miptex from a texture wad.
How To Make A Video In 45 Seconds Expending No Effort
How To Make A Video In 45 Seconds Expending No Effort ...
0. Do once: Install XVID codec 11 MB. This isn't about the codec, this is about something that works quickly and doesn't come with ads/spyware.
1. Go to a map.
2. Type record thisdemo
3. Walk around for 30 seconds.
4. Type stop to end demo recording.
5. Type capturedemo thisdemo
Your are done. Where is thisdemo.avi? Type folder and it will be highlighted in Windows Explorer.
6. Optional: Drag and drop it on your YouTube page and upload it.
If you are in 640 x 480 windowed mode when typing capturedemo it will be faster than say fullscreen resolution @ 1400 x 900 because 640 x 480 has far less pixels to encode than 1400 x 900.
"Anyone else using Windows 10 have issues with the engine? "
Not so much in MarkV; but QArack, and JoeQuake specifically take 10 to 15 seconds to initialize in win 10 for me. Where as both engines take under 5 seconds on my XP and win7 machines. Dunno. opengl 1.x emulation?
I can confirm that startup on Windows 10 is extremely slow on my new tower. I have an Intel 7820 and 32Gbs of RAM. HD is a pretty decent raid from 10,000 RPM drives. Videocard is a Nivida GTX 780.
In Windows 7 - a much older machine startup is near instantaneous.
No audio issues as I have seen on my laptop thankfully.
Is there any way I can help observe/record the startup issue for you?
1. Is it just the Direct X version?
2. Or is it also true for the WinQuake version also?
3. What about the SDL alternate build? download
It might help me triangulate in on something.
I'll test this evening and post results. I probably should have done a proper test.
Also a question about Dx9 files you have linked? How do I determine if I need those?
Sorry yes I was setting up TB2 and only played around with the DirectX version as well as QS and QSS. I'll copy over the SDL alternate and WinQuake versions this evening.
> How do I determine if I need those?
Mfx said he had the issue and said installing those files solved it, but I'm not seeing a description of the message other than "it didn't start up".
Posts 2106, 2109, 2110 -- "mfx - Thx, that download helped, works now."
Yeah Mark V needs the DirectX 9 runtime support. I don't remember the error message but IIRC it's fairly obvious if that's why it's failing to start.
If you play other games on your computer there's a good chance you already have this installed. If not, it's harmless to install it.
In the future, I may try to roll DX9 detection/installation into the installer form of the engine distribution.
There will of course always be the plain zips of the engine .exes.
Report on Mark V Windows 10 delayed launch (and exit)
Mark V 1099r4 delay of 3-6 seconds launching and exit.
mark_v_sdl_gl_gcc - no delay
mark_v_winquake - no dleay
mark_v_winquake_gl - no delay
quakespasm .93.1 win64 - short delay launching and exiting (1-2 seconds)
quakespasm-spiked-win64 - short delay launching and exiting (1-2 seconds)
Mark V 1099r4 has the longest pause of all exes.
So DirectX Mark V is 3-6 seconds slower starting/exiting. Quakespasm is 1-2 seconds slower starting/exiting.
But Mark V WinQuake, SDL and OpenGL are unaffected.
Trying to unravel that ...
It is possible that specifying a refresh rate on startup slows things down. Quakespasm does this. DirectX Mark V specifies a refresh rate that is the desktop default when requesting fullscreen mode. The Mark V WinQuake/SDL/OpenGL doesn't touch refresh rate.
If I am right ...
Does the following have a difference in start up times ...
a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX
If it relates to the refresh rate, according to the code it looks like in windowed mode that Mark V DirectX does not set a refresh rate, but for fullscreen mode it does.
/A guess. If this thought turns out not to lead anywhere and it may not, I have a couple of other thoughts but this best matches your test results ...
Let me know ...
If a 6 second delay is a problem, my engine is fucked.
But yeah, it's always nice to eliminate unnecessary delays.
A delay at startup does sound like it's changing the display mode for sure; that would certainly do it.
Some info on command-line params used and resolutions of the PCs being compared would help a little more here.
@baker I need to try this in windowed mode too. But I'll try what you posted above. Typically I stick to fullscreen.
One other thing that might help. Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV. The tools compile quickly as expected, then there's the delay in launching MV. Then I review the compiled map. Now for whatever reason after I quit MV the cmd windows (which has been running in the bg as usual) stays up for about 3-4 seconds before closing.
I am 99% sure the delay in launching MV happens if I click a shortcut on the desktop without running any compilation so maybe unrelated?
Just remember this is Windows 10 now. My older machine is Win7 and had zero issues on start up and shut down with the same monitor and a very similar video card and same MV version. Also the same command line etc.
1920x1080 144Hz refresh forced by nvidia cp and that's my desktop res and refresh as well so I don't think it's mode switching.
I need to confirm but I'm pretty sure the delay happened before I set the refresh in nvidia to 144Hz
parms are +developer 1 and +gl_clear 1 +load map <map I am editing> (those were the same on other systems)
It does seem to take a while to load for me too. QS is pretty instant
Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV.
Windows programs inherits the CPU affinity and the process priority of the process that launches them. If the launcher is e.g. a single-threaded 32-bit program running at low priority, maybe Mark V needs some extra time to adjust its process' properties. Just a guess.
Home and testing this now. We're getting somewhere.
Does the following have a difference in start up times ...
a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX
No delay on the windowed setting above! Fires right up. Also I have QS and QSS in the same forectory of MarkV so they share config.cfg. I'm noticing if I switch between those two the delay in launching and closing them goes away. If I launch MV then QS or QSS afterward the delay on those two is back. Albiet shorter as I said above.
Can you confirm there is never a delay for windowed mode?
If so, that would be convincing enough evidence to make a test "fix" for DX9 fullscreen mode.
/Probably throwing in a pq_moveup bug-fix that PoorChop spotted.
Possible DX9 "No Delay" On Fullscreen Startup Fix?
@dumptruck, fifth + anyone else who experiences a delay on DX9 Mark V startup:
Download: DX9 Mark V - July 11 potential slow startup fix
@dumptruck -- let me know!
So this July 11 version no change.
Made 2 shortcuts on my desktop to this new exe.
Windowed mode launched 5 times in a row with almost no delay.
Using fullscreen (-current) re-introduced the delay.
I launched this 5 times as well - all the same. The I switched between the two shortcuts twice. Same results.
I tried this new exe on my older Win7 machine and it doesn't have the issue. Launches full screen with only a tiny delay.
As I said, that is almost certainly a display mode change. Probably 2, switching away from your desktop mode then switching to whatever your selected mode is.
Check your console output log and you should see evidence of it. A bunch of vid_describemodes and vid_describecurrentmode commands can also help.
Yes. I'm aware of the fact that it happens on 10 vs 7, but the fact that it doesn't happen in windowed modes is additional evidence.
Great! You might also check and see if the fix eliminates the need to set the refresh Hz in the Nvidia control panel for your 144hz display.
It may resolve that, then again it may not.
/I think dumptruck has easily earned the June and July "Gunter Award For High Quality Beta Testing".
Nothing is less fun with engine coding than issues that require setups not easily available.
Thanks for the high quality beta testing that identified the source of this issue!
Thanks I am no Gunter tho.
Did you misunderstand though? This did new release not fix the issue. :(
When You State...
"Full external texture support, DP naming convention."
Does Mark V use special effect textures as well? Gloss, normals etc? And what about shaders?
I see you have a HD pack using qrp textures, I can derive the answer from that. Apologies
@dumptruck -- my bad. I quickly scanned the post and only saw the "no delay" and "with only a tiny delay". Missed the part saying the problem still exists for fullscreen. Sorry ... guilty as charged!
I know I vastly prefer the DX9. Maybe mh will come up with some thoughts at some point. The inner workings of DX9 isn't in my knowledge set.
Odd that the OpenGL variants like the WinQuake-GL (WinQuake rendered through Open GL) and the SDL (which is also OpenGL) have no delay.
@damage - Just vanilla replacement texture support like ezQuake, JoeQuake, Qrack.
Mark V supports texture replacement from HUD to Quake models to conback and menu graphics.
ps. sometimes i get the fps locking at 60
If sounds like you have an app running in the background that is forcing video sync.
All you can do is close the other app.
I've seen it happen before, but I can't remember what it was for me (Netflix?).
As I've now said twice, it's a display mode change. Probably two. Seen it once, seen it a million times. I don't understand why dumptruck is being resistant to helping diagnose this further, though.
Traditionally Quake engines only track width, height and bpp when matching display modes. Some engines add refresh rate. A real display mode contains other values, however, and it's possible for two or more modes to exist which are the same so far as these traditional values are concerned but which are actually otherwise different.
Don't be surprised if Windows 10 adds additional modes that aren't in 7. It's a higher version of the driver model with extra capabilities.
What's happening is that dumptruck is running with -current but the engine is not starting in the current mode. It's starting in some other mode, which involves a display mode change, then switching to the current mode which involves another.
There's no delay when shutting down because it's already in the current mode and so doesn't need to switch back.
The other engines have a shorter delay at both startup and shutdown because they're doing a single mode change at each.
There's no delay running -windowed because it doesn't do a mode change at all.
In an ideal world that first mode would be a windowed one and all of this would go away - instant startups would be back. But when I tried to do this years ago I got HUGE pushback from the community. Yayy community.
Anyway, I asked dumptruck to check his console debug log which would tell us which mode it was starting in first, which could have been useful information. But once more he's being resistant to helping us to help him, so I guess that's where it's gonna end, unless he comes round.
@dumptruck - just to be clear.
I am NOT saying "you silly person, ha ha ha",
I AM saying "it's an engine bug. Help us to help you. Please"
Come On Now Mh
I'm not sure why you're bagging on the one guy who is downloading extra builds and running all sorts of tests on request. If he's overlooked something you asked him to do then you could make that clear.
I've previously told him twice that it was a display mode change. He responded the first time to insist it wasn't, he ignored the second. I've previously asked for his console log and the output of some vid_describe commands. He ignored that too. So obviously I'm the bad guy here. Yayy Community. Again.
If sounds like you have an app running in the background that is forcing video sync.
yep, It frequently happens when i run the online widz etc
sometimes it happens just for no reason , switching to desktop and back to the game's solving the issue
Looks like I need to experience the problem firsthand and see if I can get the problem.
It is possible something non-obvious is going on.
mh brings up bits per pixels and some other factors.
Mark V always tries to use what it thinks are the desktop "current" parameters with -current (ignoring all config settings), but maybe Windows 10 adds some additional parameters I didn't consider.
@mh - Eventually I'll get to the bottom of what is going on. The main issue to trying to find technical info on what Windows 10 updates changes/impacts has been difficult.
THE FIRST DISPLAY MODE CHANGE
This is happening inside VID_Local_Vsync_Init where a call is made to sysplat.wglSwapIntervalEXT(0) - under OpenGL this is not a display mode change; under Direct3D it is.
Suggested solution: suppress this test if running under the D3D9 wrapper; you can safely assume that vsync control is always available in D3D9. This will shave 3 seconds off the startup time.
Got it. I'll give that a try.
THE SECOND AND THIRD DISPLAY MODE CHANGES
In classic Fitz, at the end of VID_Init there is this block of code:
if (COM_CheckParm("-width") || COM_CheckParm("-height") ||
COM_CheckParm("-bpp") || COM_CheckParm("-window"))
vid_locked = true;
This needs to have "-current" added to the list of params checked, otherwise the engine will run the configs during startup and trigger two display mode changes (assuming a clean config, could be more). The first of these changes is slow, the second is fast (in my test the first went from fullscreen to windowed, the second just changed the size of a windowed mode).
In MarkV I think the equivalent is the video_override_commandline_params array, which is missing "bpp" from classic Fitz's list.
Fixing this up shaves a further 3 seconds off the startup time, and startup times are now instantaneous with no display mode changes happening.
I'll examine that as well.
Yeah, bpp is gone (that's a relic from the 1990s when 65536 color mode was a thing).
As a troubleshooting tip...
In context_t::PreReset I added the following at the start:
Con_Printf ("context_t::PreReset: %f\n", Sys_FloatTime ());
In context_t::PostReset I added the following at the end:
Con_Printf ("context_t::PostReset: %f\n", Sys_FloatTime ());
I was then able to track when display mode changes occurred and cross-reference that with whatever else was going on in the console during startup, as well as time how long each change took. Makes it very quick for hunting down this kind of thing.
I don't understand why dumptruck is being resistant to helping diagnose this further, though.
I need to read the rest of the thread above but I promise you I am not ignoring this situation. I can only test after work and family stuff kept me busy last night until pretty late.
Honesty, I didn't notice anything in the console and I was definitely paying attention the other night when I DID test.
So my desktop is set to 144. The game is set to 144 there's still a mode change in FS? I don't get that.
What I will ask is that someone let me know what I can look at in Windows to help troubleshoot. I am not stellar with troubleshooting the OS.
There's no delay when shutting down because it's already in the current mode and so doesn't need to switch back.
There IS a delay when shutting down but not 7 seconds. The game will close but the Mark V icon is still in the Quicklaunch bar and the system is unresponsive until it closes.
I will post console logs with the info mh is targeting as soon as I can.
You don't need to do anything.
mh solved it. It's all on me now.
I want to wrap up the SnapTile editor (yeah, going with the name mankrip chose -- I can't do better) before doing a Mark V fix.
So give me a few days.
When I get close to completing something, I develop a one-track mind where I want to finish it.
Thanks. And please no pressure on a timeline. Do your thing, happy to wait for your fine work. :) Excited to see this SnapTile project in action.
Mark_v Takes 7 Full Seconds To Load
Seems like a lot. Just tested it with latest build.
Windowed mode is instant.
Tried changing my refresh rates and this doesn't change the delay (I have a 144hz monitor).
Closing Mark_V takes 4 full seconds fullscreen and closes instantly when in windowed mode.
Yeah, we tracked it down.
I owe you an apology for being a dickhead about this. On the other hand, MarkV will get better as a result.
No worries! Poor Baker though. Coding during the summer. ;)
I'm only the idiot who wrote the code, Baker's the idiot who has to maintain it!
Video: High Definition Pack With More Realistic Shadows
High Definition Pack Video With More Realistic Shadows:
1) r_shadows 3
2) r_waterripple 3
3) QMB on, obviously
4) With HD Pack
and Transparent Water .Vis/.Lits Pack
For illustration purposes.
dumptruck_ds: Thanks I am no Gunter tho.
Hey, you're doing extensive testing and detailed reports to help squash obscure bugs AND getting mh miffed, so you're well on your way!
Cool shadows. Any chance for lit liquids in the future?
I can't remember if mh wrote a full fledged prototype or not and if the one or two small but important barriers were solved (i.e. detecting lit water and maybe something else).
I think if he did, it would eventually happen.
I've solved the detection and posted the solution in some thread here or at InsideQC a long time ago.
The other problem was to compile the maps properly, but EricW solved that.
Wasn't there an issue with the surface warping making it look really bad?
Not in my engine.
And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders.
And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders.
This doesn't need shaders; hardware-accelerated Quake already uses two separate sets of texture coords for difuse and lightmap, so just warp the diffuse coords only but don't warp the lightmap coords.
The issue is that whatever way you slice it, it looks bad.
I do understand where the desire to do this comes from. You've built a map, you have a large water surface in it, the surrounding geometry is nicely lit and shadowed, and the fullbright water looks bad. And you're right, the fullbright water does look bad, but lit water actually looks worse.
The two big problems are (1) when the lighting on the water is sufficiently dark you can't see the warp effect at all i it just looks like a big dark spot, and (2) with translucent water enabled the water just disappears.
This is an example of taking a special case and wanting a general case solution for it, but not properly considering how that general case solution may or may not work outside of the original special case.
"Can I have lit water?" seems a reasonable request, but you also need to be thinking about lit laval, lit slime, lit teleports, how it interacts with translucent water, etc.
I've already considered all of that years ago and Retroquad has individual cvars for each texture type. I usually keep r_portal_lit and r_lava_lit disabled in Retroquad, because the textures I'm using for them doesn't have glowmaps. But the slime texture I'm using does.
Your mistake is to think that you're the only one who thought about all that. No, you're not, you haven't even thought about liquid textures with glowmaps (QRP has them!), and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience.
Lit water does look fucking good. The Unreal engine already has lit water since 1998, and nobody ever complained about it because its maps were created with lit water in mind. Lit liquids in Quake is for NEW MAPS ONLY because the maps need a full recompile from the .map sources for this to work and the mapper must deliberately opt-in to enable it in the compiler.
Your issue is that you don't want mappers to have a chance. You don't want them to experiment and learn how to tweak the lighting in their maps to make lit liquids look good. You don't want them to have artistic freedom.
The "it looks bad" argument is not a technical argument, it's merely an uninformed opinion.
You are not a mapper.
...and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience
I am actually also speaking from experience because I have also written this code and have also seen what lit water looks like.
Here's the Quaktastic folder where I uploaded a bunch of screenshots: http://www.quaketastic.com/?dir=files/screen_shots/LITWater
Check the date on them - over a year and a half ago.
Check some examples of exactly what I mean:
Your entire premise is based on the assumption that I don't know what I'm talking about, whereas I actually do. When I say "lit water actually looks worse" you had two options and you instantly reached for the negative one - yayy community.
I am actually also speaking from experience because I have also written this code
No, you are speaking from MAPPING experience.
I've never made a full map but I often practice mapping to test and learn how new features like this could be used.
* not speaking
Not only you used screenshots from other people's maps that were NOT designed for lit water, your E1M2 screenshot shows that you probably didn't recompile them using the latest versions of EricW's compilers, which properly lits the liquids from both sides. The lighting at the edges of the water should be similar to the lighting of the walls that crosses them.
All your screenshots looks like they didn't use EricW's compilers. Completely missing backside lighting.
I'm on mobile and not at home now, but asap I'll post some screenshots of those maps properly recompiled.
To me all three of those screenshots you chose mh look quite promising and easy to work around to get pretty lit water with some effort from the mapper (and yeah some compiler magic would obviously help).
Would be curious to see with some high alpha values, as you seem to say it looks ugly, but plenty of other games have lightmaped transparents that look fine.
OK, I am going to put my money where my mouth is.
This package contains:
(1) A version of GLQuake modified to support lightmapped water.
(2) Source code for it.
(3) A version of e2m5 compiled, using EricW's tools, for lightmapped water.
So now everyone can see it.
Finally. We should let the mappers decide. Thanks for listening.
And to finish settling this, here are the comparison screenshots:
Retroquad E1M2 (opaque)
Retroquad E1M2 (translucid)
Retroquad E1M5 (opaque)
Retroquad E1M5 (translucid)
Retroquad E2M5 (opaque)
Retroquad E2M5 (translucid)
My recompiled E1M5 and E2M5 maps used an older version of EricW's compilers that added improper dirtmapping to liquids, IIRC (which is why their water is a little darker on the edges). But my recompiled E1M2 map used a later version that fixed all issues. Anyway, see how different all of them are from yours.
Since mh wrote a prototype for it (using GLQuake makes it essentially a tutorial for any engine developer), it rather likely that some future date it will added to Mark V.
Especially since ericw (and Spike too?) invested the time to make lit water in the ericw compile tools.
I don't have an opinion of lit water. It is the time investment by other developers which would be the reason to have interest in adding it from my point of view.
Here's a screenshot of my recompiled E1M2 running in mh's GLQuake with opaque lit water support
I noticed that Poorchop mentioned mouseclicks not registering. I'm seeing that myself at the moment with a fresh Mark V install on latest Windows 10... sometimes it's the +mouse1 that doesn't register (and so it doesn't fire), sometimes the -mouse1 (and so it doesn't stop firing).
Happens with both mark_v and mark_v_winquake. Doesn't happen with latest quakespasm.
Anyway, just some corroboration. Let me know if I should test/try something.
1. Does the SDL alternate build do this as well? SDL build
This would tell me if it were something about the pure Windows code or the all operating systems code.
2. Also: What do you have mouse1 bound to? Attack? Jump?
1. Not nearly as often. I was hoping I could say "never", but I do think it missed a couple of mousedowns during a map playthrough. (While in comparison, it would not be unusual for mark_v.exe to miss a mouse event in the course of even an individual fight.)
One probably-irrelevant difference I noticed: the mark_v.exe FPS display is pegged at 72 (my host_maxfps), while the FPS display in the SDL build wandered between 67 and 70 on the same map.
Yeah, the probably irrelevant difference is just that. The DX9 is better at hitting exactly the 72 because it is faster.
re: mouse - Looks like more to do with Windows 10. I'm glad you are able to replicate the issue PoorChop experienced, increases odds of conclusively solving it.
I'm glad too, good to know that I'm not the only one experiencing this.
For the people who want to test it, here are some of the ID1 maps I've recompiled with lit liquids:
I've tried to figure out how to implement lightmapped translucent liquids in mh's GLQuake code, but hardware rendering isn't my thing and I've got no time to learn it.
If I get time I'll do a 2.0 build. It's not overly difficult, like you indicate, just a matter of knowing what to do.
When You Wish Upon A Star...
So these lit water and things are looking cool. I am also wondering about the possibility to implement sv_protocol 999 support in Mark V.
The map I'm working on needs it, and I get a hard crash with hunc_alloc error similar to TerShib when I try to force it.
Is there a chance to see this happen? I would love to be able to see how the map handles in Mark V.
Initially I thought "well, I can just combine the texture & lighting like the translucent mirrors does before blending", but then I found out that GLQuake's mirrors doesn't use lightmaps either. No way for clueless me to hack it in.
I have to be quite tiresome about this and confess that I'm still not a fan of the look. To me, the water no longer looks like water - it looks solid instead.
I'd also be of the opinion that light should go through translucent water.
But then, Quake's rendering was never really about being 100% realistic anyway.
Well, it still looks better in Retroquad, mainly because of soft depth. But I'm confident that mappers will figure out good ways to use it.
And it should certainly be optional.
Feature Request For The Future
cl_autodemo is really invaluable. If you could append the map filename to the file they generate that would be super helpful. Or at least part of the name. Ppl ask me to play their maps often and I use autodemo for this. Would be great to know what map a given demo is for outside of the exe. I am constantly renaming files.
Redfield -- A large coordinates protocol would be a next year most likely. It wouldn't be sv_protocol 999, which sports lots of brokeness (I should make a video sometime).
Dumptruck - Mark V autodemo was adapted loosely from Qrack autodemo which does exactly that. If I am able to determine the cause of the Poorchop/Johnny Law mouse issue, I would probably throw in a "cl_autodemo 2" that like, Qrack, does exactly what you want.
Ooh Ooh, An Idea!
To play all of mydemo0, mydemo1, 2, 3, 4 etc. automatically in a row.
And if someone leaves out, mydemo3 for instance, it would just skip to mydemo4.
Protocol 999 opt in cvar pretty please please. With sugar and a cherry on top. I've got a few Orl-size maps I'm working on that have a 99.9% chance of needing 999.
Yes, would you make that video demonstrating 999's brokenness? Or at least briefly talk about it? Cause I'm curious to know.
Yes, in time I will make a video.
mh has an expression "once you see something, you can't unsee it".
I think seeing in this case is going to be necessary.
I'm the original designer.
The core idea is actually quite solid. It's based on 666, but with the addition of a bunch of opt-in features. The client and server negotiate which features to use, and the whole thing can gracefully degrade if a feature is unsupported.
It was always more about higher precision angles and more TE_ effects than big coords, or at least that's how it seems to me thinking back, but big coords was just one of the things it could also support. The important thing though is that it's extensible nature means that you could plug in your own big coords system if you wanted.
Being built on 666 means that it inherits all of an NQ protocol's weaknesses. That's not an attack on 666, it's an observation on NQ protocols in general. There are much better ways of doing all of this stuff; supporting big coords, more precision, more effects AND being more efficient in the data stream. NQ is a bit brute force, which is fine in simpler setups but hits scalability ceilings much faster.
mh: it was always more about higher precision angles ...
Translated: nice smooth rotating doors and draw bridges.
(like Remake Quake could do -- as opposed to clunky hipnotic doors)
Fitz 666 didn't have enough angle precision resulting in walking on a drawbridge coming down to not feel jerky and the same for getting pushed by an opening door. Also the higher precision angles were used for some rotating effects in QuakeC.
999 should be used on any map with bsp rotation such as drawbridges, pushable gates (ne_ruins), rotating path changers (like Dismal Oubliette but rotaty), etc.
OR maps as big as Orl's.
Still not sure what the problem with it is.
It should probably just be renamed to "ORL Protocol."
Nope. 999 does nothing for hipnotic rotation at all.
If you want to see real rotation, you'll have to play Remake Quake and trigger the draw bridge or find a rotating door.
Must use the Remake Quake engine -- Quakespasm doesn't support true rotation (nor does Mark V, it did briefly once upon a time but it led to the discovery of some oddness with existing Quake maps -- even a couple of stock Quake ones -- and was removed).
Sadly, true rotation sadly interferes some with existing maps where entities or even maps have the angles key set (and they shouldn't be). I think dis_sp3 is an example.
a lot of games come with two *.exe's
one for windows 32 bits and one for windows 64 bits...quakespasm have quakespasm.exe and quakespasm-sdl2.exe... even quake has two exe's (normal and opengl)
maybe would be cool to have two markv.exe's, one for old maps and one for new maps with true rotation :)
just my two cents :)
There's something strange I've spotted on your GLQuake code, in R_BuildLightMap.
This is your source:
for (j=0 ; j<smax ; j++)
t = *bl++;
t >>= 8;
if (t > 255)
t = 255;
dest[j] = t;
But this is the original source:
for (j=0 ; j<smax ; j++)
t = *bl++;
t >>= 7;
if (t > 255)
t = 255;
dest[j] = 255-t;
What's the reasoning behind that?
(255 - (t >> 7)) == (t >> 8) ?
Oh, wait, I've found it
"shift the lightmap by 8 (jnstead of by 7) in R_BuildLightmap
However, by doing that you lose precision, resulting in more abrupt discrepancies in light values across different surfaces, which is likely another reason why the lightmapped water in your GLQuake engine looks worse than in Retroquad.
Compare these shots:
(with soft depth disabled)
Yeah, that's overbrights. Yeah, it loses 1 bit of precision, but it still has 256 gradations of light - software Quake only had 64.
Rotation: higher precision can't fix Hipnotic rotation, that was born broke (fun fact: the hackiest mod is Nehahra, the second-most hackiest is Hipnotic). I can't recall the exact use case but it would have been something like a drawbridge that had the herky-jerkies with standard 8-bit angles.
Retroquad uses the full 8 bits of precision, and it also compensates for the loss of precision. It has nothing in common with WinQuake when it comes to shading & texturing.
The fact is that the same light can be raycast to slightly different levels across the edges shared between different surfaces. The less precision is used, the bigger this difference can become.
The full range of light scales per the BSP format can't be represented by standard 2x overbrights. "z" is double-bright, so with 4 lightsyles combined I make that 11 bits per channel, and that's not including dynamics.
I guess that the point is, you're always going to be losing precision.
maybe would be cool to have two markv.exe's, one for old maps and one for new maps with true rotation :)
32-bit vs. 64 bit doesn't have anything to do with rotation. Remake Quake engine with true rotation is a 32-bit.
Half-Life has had true rotation since 1998 and it evident in all aspects of the game.
There really aren't any advantages for 64-bit on Windows that I can name, except 64-bit uses a bit more memory because pointers are twice the size.
The Linux build of Mark V, for instance, has always been 64 bit.
I guess it wasn't clear that I'm implying that the loss of precision can be compensated for by doing t = (t + (1 << 7)) >> 8. It's exactly the same principle of adding 0.5 to the velocity to fix the gravity issues in low framerates. It's obvious.
Anyway, it may be not enough. Besides this compensation, Retroquad performs color correction, gamma correction, brightness correction and multiple kinds of error diffusion.
Maybe the results will be better when your code gets ported to Mark V or other advanced engines.
The win32/win64 bits was used just as an example of games that come with two exe's. I didn't want to imply that it has something to do with true rotation :)
Well, forget my lame example... My point is, why not compile two markV.exe's? One to play old maps and one (with true rotation) to play new maps that can use this feature? =D
Yeah, Sure Not Quite Mark V But Whatever
A induces B.
That's just rounding to nearest rather than rounding down.
Believe me, I've rewritten the lightmapping code to use L16, RGB16, RGB32F, RGB10A2 and other formats over the years. I've written GPU lightmap implementations where the 4 styles are combined on the GPU with zero precision loss. I've stored exponential factors in the alpha channel and unpacked them in a shader. I've even done 4x overbrights with standard RGB8 lightmaps, losing 2 bits of precision.
This is not a big deal. For lightmaps the extended range is more important.
I guess a version 3 using L16 lightmaps might be in order to prove this.
And just in case this needs to be explicitly stated.
The lightmapped water path uses exactly the same code as regular lightmapped surfaces. In GLQuake that's just multiplying 2 numbers, and nobody can claim that one way of multiplying 2 numbers gives a better or different result than another.
Frankly, I'm sick of hearing "Retroquad is better because..." - where can I download Retroquad, run it, study it's code and learn from it? Nowhere. You may as well be talking about touched-up screenshots for all the practical use that is. I've heard the mouth, show me the trousers.
Arcane Sprites And Particles
I was talking with some others about the way that Arcane's particle effects are rendered in different engines. I was wondering if you had any plans to bring Quakespasm's level of detail to the engine. QS doesn't really do a whole lot but there are some extra sprites for models like the flame. Their absence is pretty striking in Mark V. Here's what I mean:
I didn't even think that QS was doing anything in particular regarding Arcane's extra particle effects. I do know that QSS takes it a step further with smoke but I'm not expecting that level of detail in Mark V. I also know it's a pain when users make requests like this but don't get me wrong, I'm not asking for this to be turned into an existing engine. I just like the extra sprites and I was wondering if there were any plans for something like this.
Their Absence Is Pretty Striking In Mark V
not sure what you mean, i believe the particles not showing up on mark V - it's on your side
i have no probs here
I have a feeling that you're not using a default setup. The flame itself in your photo looks like a sprite or even just a bunch of particles lumped together. In a clean install of Mark V and a fresh install of Arcane 1.7.1 with default settings, flames don't look like that.
Version 3, with GL_LUMINANCE16 lightmaps; thse are 16-bit lightmaps with 7 more bits of precision than GLQuake without overbrights and 8 more bits than GLQuake with overbrights. I'd encourage anyone who thinks that bits of precision in lightmaps are super-impotrant to run this and see if they actually are. I'd even encourage double-blind tests.
yeah, the patricles depend on temp1 in AD cfg settings
Ah The Flames
it's QMB enabled in my case, you can turn them off
GPU Lightmaps Implmentation
Quake 2 engine, D3D9, with GPU-animated lightstyles and GPU dynamic lights; renders the lightmaps at the full original precision of the BSP light data lump; unlimited dynamic range for added dynamic lights.
It's a long time since I worked on this so I don't know how robust it is, but it should be fine for playing through the original SP missions.
Quake 1, Partial Real-time Lighting Implementation
This was another one that went part of the way but I didn't continue with; no real idea why. It uses real-time lighting derived from the same light equations as are used in the original light.exe, but I never got round to adding shadows. Needs heavy optimization work.
Its fun to run around the original maps and look at how different the lighting quality is, but I wouldn't play Quake with this. Also, any map compiled with any more modern tool will probably look hellish weird because I don't have support for all of the other options added since light.exe was originally released.
As You've Stated
I was talking with some others about the way that Arcane's particle effects are rendered in different engines.
this pretty much matches the qs screenshot
it seems it's a great alternative to KMQ
That's just rounding to nearest rather than rounding down.
Yes, but in color calculations, every small inaccuracy amplifies the others. And as mentioned, gamma correction also plays a part
and there may be issues with gamma correction
Anyway, while I was open to explore how to improve the image in GLQuake and trying to figure out what's causing the differences in lighting, you're getting angrier. Better forget this conversation and leave it behind, it's not good to let things become unhealthy.
Go underwater ;)
In Mark V change Temp1 to 1024 and restart the map for particles. Its at 0 by default. Mark V is capable of displaying the same AD particle effects as QS.
the waterwarping is a pretty great
but i'm not a fan of distortions
Thanks spy and Redfield, that worked and it looks great now.
If you let Mark V generate a new config file from scratch and check the gamma, it says that it's set a 0.75 even though 1 is listed as the default. I thought that this was a bit strange and I'm looking for some insight on it.
I also have a slight suspicion that this has an impact on mappers. I've played some maps recently that were incredibly dark at gamma 1 and contrast 1, but they were much more playable at Mark V's default gamma of 0.75. It makes me wonder if people are mostly just testing in Mark V causing their maps to be extremely dark in other source ports that default to 1/1 gamma/contrast.
GLQuake defaulted it's gamma to 0.7 on non-3DFX hardware. Not sure why MarkV is doing similar but it seems too much of a coincidence.
Mark V doesn't default gamma 0.75 (gamma 1 is default), but a certain revision did (revision 2? revision 3?) where I was merging with QuakeDroid. Johhny Law noticed different defaults in the Windows version and I corrected.
QuakeDroid defaults gamma 0.75 because gamma 1 is just too dark.
Windows 10/Poorchop/Johnny Law
On my Windows 10 machine, I didn't experience any Poorchop/Johnny Law mouse oddities.
Makes me wonder if maybe I could cause the issue somehow by installing maybe new Direct X drivers? I don't know.
If I can't experience an issue, makes it tough to guess. The mouse was fine for me.
If Mark V 1036 download link
doesn't experience the mouse issue on Johnny Law/PoorChop's machine, I would suspect the issue relates to DirectInput which 1.99 switched to.
If that is the case, I could make DirectInput turn on and off and maybe default off.
make DirectInput turn on and off and maybe default off.
I'm thinking that's probably the best option.
After playing Mark V and setting my sensitivity to an appropriate value to account for dinput, if I then use some other engine or a different version of Mark V, my sensitivity is way too high!
Here's another thought: If dinput is being used, automatically double the sensitivity value (rather, treat the value as doubled). That would probably get rid of the need for the Sensitivity slider to go up much higher to account for dinput being much less sensitive.
And if people wanna be more precise (even with the doubling happening behind the scenes), they can use decimal values, like sensitivity 10.5
But doubling the Sensitivity value for dinput would probably feel very close to the standard Sensitivity value when dinput is not being used.
Bummer that you couldn't reproduce. I gave Mark V another few tries within the past few weeks and I had the same exact issues that Johnny Law spoke of - sometimes -mouse1 didn't register so I was firing indefinitely. Previously I just thought it was neither +mouse1 nor -mouse1 registering.
I'll spend some time playing around in 1036 to see if it works fine for me.
I'm about to go camping, but I'll remember to get back to this later.
Guys take your time, it's the summer. But yeah, if either of you can find out if 1036 does or doesn't have the issue, it can really shed some light on the nature of the issue.
V1036 Works Just Fine
I've tested long enough by now that I would've noticed if I was still having issues but I haven't had any problems with 1036. I spent a while bunny hopping and playing through maps, and all of my mouse clicks registered just fine.
On a side note, I am getting some pretty terrible performance outside of id1 maps but that's another issue.
Thanks for info. Helps confirm thoughts on issue.
May I trouble you to test one more build ...
The 1080 build. download
And tell me if you have the mouse issue with 1080.
The results from 1080 should allow me to conclusively and quickly do a patch fixing exactly the "right" thing. (The alternative is some guesswork and if I am wrong it could take 3 attempts.)
I'd like to resolve the "Poorchop/Johnny Law Windows 10 mouse issue" right the first time.
I played through some id1 and bunny hopped around for a long time, but I didn't notice any issues with mouse clicks registering. v1080 seems to be working fine here as well.
FWIW I just played through Amphitheater Of Abaddon using build 1080 and didn't notice any problems.
Defaults to gamma .75 I can confirm this as I've installed it into new directories 3x this week. I usually reset my config by hand BTW so it's defaulting for sure.
Heads up that uwjam is performing pretty badly with this mod. Seems the sprites are causing significant framerate issues. I will test some more this evening but wanted to check with anyone else and see if they were experiencing issues.
I just played in QSS and did not experience the showdown.
I haven't tested uwjam with Mark V but I've played a few other maps that have some frame rate issues despite running perfectly fine in other ports. Not really sure how to troubleshoot something like this though.
The MarkV D3D9 sprite drawing code is particularly sensitive to high numbers of sprites and will suffer performance problems in those situations.
Basically it looks something like this:
for (int i = 0; i < numsprites; i++)
In order to deal with D3D9's well-known draw call overhead problems, the D3D9 wrapper code attempts to concatenate multiple draw calls with the same state into a single draw call, so that the whole thing can run with fewer draw calls.
The MarkV code (inherited from FitzQuake, in turn inherited from GLQuake) prevents it from being able to do that, because making any state change will break a batch.
Changing it to something like this will help a lot:
for (int i = 0; i < numsprites; i++)
By SetState and UnSetState I specifically mean the alpha test state here; the polygon offset state only happens with Hipnotic bullet-hole decals and should be rare enough, whereas texture changes are something that has to happen so that's a state change that you'll just swallow. But this change on it's own should go a long way towards fixing things up.
Added to the list.
Recursion is hated in lowest-level coding -- when you look at what is going on at the stack level.
Recursion causes tons of unnecessary stack push/pop slowing down what would be faster loop mechanics inside a single function.
Elegance hates "goto". Yet "goto" dominates the world and well-written low-level code is code that the compiler can reduce to "goto" form avoiding the use of recursion.
/The D3D9 sprite handling is making me think about how to best optimize sprites next round to fit how D3D9 wants the data fed.
This is just similar to the technique for making dynamic lights go fast - if you have a bunch of work to do, dividing it into fewer large batches will always outperform many smaller batches. Beyond that it's just a matter of understanding what patterns can prevent fewer large batches, and in any 3D API (including native OpenGL) that's going to be things like unnecessary state changes. Typically brought on by things that seem "right", such as unbinding textures/buffers, or putting state back the way it was after drawing an object.
The Quake code is riddled with small inefficiencies and it's death by 1000 cuts. None of this mattered in 1996 when GLQuake only ran on high end workstations, and everybody else had a 3DFX which routed it's drawing through a layer which tried to make something sensible out of it.
Ever bought a new GPU and found that Quake ran no faster on it?
Recursion is going to be down in the noise in any Q1 performance graph. Any decent compiler will automatically generate the right optimized tail-recursion code for you, without you needing to resort to tricksy or cutesy obfuscation. Don't waste time on the small beans.
In an ideal world that D3D9 code would not be needed; you could rip it out tomorrow and start investing time in making your OpenGL go fast, which IMO would be preferable to trying to make the 2 APIs coexist peacefully. The big secret is that Intel graphics are no longer crap, and haven't been for a long time. It's not Intel graphics, it's Quake's use of OpenGL that's crap.
As a general rule, bad OpenGL code will go faster than bad D3D code. But good D3D code will go faster than good OpenGL code. But in order to get good D3D code you need to go native and start writing code that's tailored to D3D's strengths; trying to translate bad GL code into something that tries to do the right thing in D3D can only get so far and will always throw up unexpected glitches and bottlenecks - like the sprites case.
I was thinking of qmb and to some extent Nehahra extra effects that are in the engine (above and beyond stock Quake sprites). qmb is highly recursed.
Ah, I'm not familiar with the QMB code although I've been aware of the effects since almost the very beginning. That's something I must rectify.
I took a look at the real-time lighting prototype you made a few hours ago.
Looking at the source, I thought the dates were funny because you wrote it at the same time as the DX9 wrapper.
How do I enable vsync and set color depth in Mark V? And for a Quakespasmer just coming around to Mark V, what are some of the notable differences between Mark V and QS, ie. what's the reason behind developing two separate engines that do a lot of the same things?
Mark V Vs. QS
vid_vsync 1 (I think away from PC)
Mark V in DirectX 9, has mouse driven menus (if you get used to it and go to QS - you'll miss it), levels menu item, demos menu item, you can fast forward demos, some developer tools and a "find" function in the console - which is handy.
Quakespasm has excellent performance and compatibility with mods etc is very good. But I prefer Mark V overall for the reasons above.
Mark V does nehahra, whereas QS doesn't, correct me if I'm wrong
Many of the MarkV features you speak of are not solely markV, but a culmination of other open source software.
Use what you like. But when you get down to brass tacks, gameplay, it's pretty much just Quake.
MarkV Direct3D 9 doesn't allow changing of colour depth; it's hard-coded to the colour depth of your desktop.
Thanks. Mark V looks nicer on my machine (better colour depth, smoother gradients than QS) but as dumptruck_ds alluded to I have issues with performance. As a total package QS is tough to beat.
how could the color depth be better than QS? Is it HDR?
It should be identical unless the driver is doing some performance/quality tradeoffs behind the scenes.
Black is a deeper black and fog gradates better in a map like honey for example. I thought it was my shitty monitor until I ran Mark V for the first time to play Nehahra. Performance was slower than QS (laggy mouselook) but it looked great. Too bad I can't show the difference. Could very well be my system which is getting up there in age but the two certainly don't look identical.
Fog being different would make some sense, because the two different APIs can potentially have different fog calculations, with OpenGL's hint mechanism in particular being quite weakly specified: it's perfectly legal for GL_NICEST fog to give you per-vertex fog, for example.
In general however I would attribute this to your driver just giving a different image, as I said, likely via a performance/quality tradeoff. There's certainly no magic voodoo going on here.
Ah yes, that pesky driver update that failed on three different occasions is fucking me in the ass, thanks for the insight...
Hm. Baker... I found something you did and I don't like it :D
I was re-assigning some buttons so now I can use ALT to +attack (I was using the button on my trackpad with my thumb to +attack, but I've found it's less of a stretch -- physically -- to just hit the ALT key with my thumb instead).
So then I hit ALT + M to do a certain key combo that I occasionally use, and the console starts spitting this out at me:
Mute: ON --- ALT-M to Toggle
Mute: OFF --- ALT-M to Toggle
Sure enough, ALT + M puts Quake on Mute....
But I don't want that!
If you want a Mute feature, just make it a console command: "mute" and we can assign it to whatever key we choose.
As it is now, it's interfering with a key combo that I want to do something else....
Ya know, while I'm talking about ALT key combos, I remember suggesting in the past to allow key combos to be bound, so if I actually wanted ALT + M to do MUTE (if MUTE were a console command) I could do it like:
Bind @m mute
(if you made @ designate the ALT key combination)
Ah, on the Old Page #1352 I was thinking about "shift" keys for gamepad binding, but it could also work for keyboards. I suggested allowing any key to be designated at the "shifting" key for combinations....
Do any other Quake engines allow fancy binding of key combos?
Anyway, key combo binding is a "possible wishlist" kind of thing.
Whereas ALT+M = MUTE is a "NOOOOOOOOOOOO!!!" kind of thing :D
And probably a "Only Gunter would discover that undocumented feature and take issue with it" kind of thing ;)
Do any other Quake engines allow fancy binding of key combos?
FTE allows you to bind alt+m "echo ALT+M was pressed"
(ctrl+alt+shift modifiers and variations thereof are supported. Note that if you use a key as a modifier then you should probably not bind it to something else at the same time - it'll work, you'll just get unwanted binds.)
A workaround for DP would be to write some csqc that looks for modifier keys and then reconfigures DP's bindmaps, which isn't user friendly for multiple reasons.
Yes, confirmed that MarkV has Alt-M hard-coded to toggling mute on/off.
Other hard-coded key combos:
Alt-Enter: switch between fullscreen and windows.
Alt-Tab: switch between different applications on the OS.
That FTE functionality wold be something really (really) good to import.
I hadn't thought about those other hard-coded combos, since they are standardized Windows behaviors.... so they behave as most people would already expect.
I suppose you don't need to have CTRL+C and CTRL+V function when the console isn't down though. Those would be the only other combos I would think that might potentially interfere with something someone might bind. Few people are going to mess with the TAB or ENTER key, since they already have commonly-used functions in Quake (scoreboard and entering messages or menu navigation).
On the subject of Mute, if I use my media keys on my keyboard to change system volume or mute, it causes a little display window to pop up on screen notifying me of whatever I changed, and that causes Quake to minimize. I wonder if there's a way for Quake to ... not be forced to minimize in this situation....
Huh, well, I'm testing it again today and my media keys aren't forcing Quake to minimize.... Well, not consistently. The first time I tried it, Quake minimized but then it restored itself. After that (even after closing and restarting Quake) it doesn't minimize at all, and the overlay flickers in front or Quake for a moment.
So I don't know. It's inconsistent. Probably a Windows thing.
On the subject of Copy/Paste, I guess even if the console isn't down, you'd want CTRL+V to function if someone was entering a chat message too.
I have often wanted to Copy test from the console, but you can only select text from the line you are currently typing on (by using shift + left/right), but that's never what I want to do. There should be some way to select text that has already been printed in the console, either with mouse select or by pressing shift+up to select previous console lines.
I end up having to use the "copy" command, which copies the entire console contents.
How To Build On Linux Myself?
Source code only contains project files for building on Windows. No makefile, cmake, etc.
There's a project file for codeblocks.
In Futute Versions
Would there be a way to have more that just three cycling autodemos? I test a lot of maps for newbs and like to use Mark V's cl_autodemo. But much of the time I die a lot! Which obv overwrites the dems.
I know I asked for the map name to be added before, I figured heck why not ask for this too.
Weapon Animation Interpolation
Animations of Weapons and Super nailgun in particular still look choppy when firing, though these cvars are enabled :
How to make 'em smooth like in DirectQ, for instance?
Animations of Weapons and Super nailgun in particular still look choppy when firing ... How to make 'em smooth like in DirectQ, for instance?
This is a content issue.
FitzQuake (which both Quakespasm and MArkV are derived from) works around it in one way, DirectQ works around it in a different way, and both ways have their pros, cons and trade-offs.
First of all, the issue.
The Quake weapon models have polygons for the muzzle flash animation embedded in them, and when the gun fires the flash polygons are moved into the correct position.
When interpolation is switched on, what this causes is for these polygons to move with interpolation, which causes them to swim into view, and dance back-and-forth across the space between the nailgun barrels.
FitzQuake and derivatives work around this by temporarily switching off interpolation if the gun is in a muzzle flash state.
DirectQ works around it by measuring the delta between vertices in the two frames to be interpolated, and if the delta is sufficiently large (above some arbitrary value that was tweaked until it gave the correct result) assume a muzzle flash motion and don't lerp, on a per-vertex basis.
DirectQ used vertex shaders for everything so it could do this quickly and easily, and it really wasn't much more than an extension of the same kind of thinking as the "assume a teleport and don't lerp" check elsewhere in the engine. It should be obvious that this approach is vulnerable to both false positives and false negatives, however.
The correct way to fix this is new content. A set of weapon models that don't include the flash polygons, a separate generic muzzle-flash model, and the QC code to stitch them together.
Meanwhile, FitzQuake allowed disabling it's behaviour by setting r_lerpmodels to 2 - not sure if MarkV and QS do likewise.
Big thanks for an explanation MH !
"r_lerpmodels 2" works just as intended in Mark V either :)
I've actually wanted to ask you a DirectQ related question since 2013 but was unable to contact you.
You've probably been informed about "sinking into ground" bug that occurs after about an hour of playing in DirectQ. Most of the corpses around the map blow up and the player starts sinking into ground. The only way to solve an issue (temporarily) was to save a game, restart the engine and load it again. I've wondered since then, has there ever been a solution found for eleminating this nasty issue or not? As it is the only major problem I found while playing DirectQ. That source port satisfied me in every aspect of gameplay and gave a really nice old-fashioned feeling of quake experience.
I was running v1.9.0
You've probably been informed about "sinking into ground" bug that occurs after about an hour of playing in DirectQ...
I fucked-up the physics code somewhere, but never was able to determine where.
Yeah... it's a pity.
Apart from that terrible bug, DirectQ is still great
startdemos demo1 demo2 demo3 demo3 etc up to 32 demos
or edit your autoexec.cfg and add :
demos demo1 demo2 demo3 demo4 demo5 demo6 demo7 etc..
Oops! That's Not Right
startdemos assigns the order demos is the console command to skip to the next one in sequence.
so just use startdemos either in the .cfg or console
I wasn't too clear in my request.
Currently Mark V records 3 autodemos per session: autodemo_0, 1 & 2. If I die a 4th time (happens too often!) autodemo_0 will start from that point in the game, erasing my prior demos. What I'd like is to just keep recording demos 3, 4, 5 and so on.
And would love to have the demo be named the same as the mapname. So e1m3_0, e1m3_1 and so on.
Anti-funky Weapon Interpolation Models
I have a set of view models that someone fixed to work better with interpolation, by hiding the muzzle flash under the gun between the frames where it should appear, so it don't look as weird when fully interpolated. This doesn't make it look perfect (there is still some small movements visible), but it is a definite improvement (most notably for the standard nailgun).
I have no idea where I got these.... I've had them for many years.
Uhh, to use those in Mark V, you'll have to make a mod folder and put them in a "progs" folder in there, and run that game folder (but then they'll only work when you run using that game folder), or go to the hassle of sticking them in an extra pak file to drop in your id1 folder so they will always be used... which I'm sure is what you want.
This is a overly-difficult because Baker doesn't have Mark V (like the other advanced Quake engines) give preference to user-inserted drop-in content outside of pak files. But it really should do that, for reasons such as this! ;)
Qrack has cl_autodemo which names demos automatically.
using mapname_date_time as the filename.
cl_autodemo 1 starts recording at mapload and stops at intermission.
Qrack also has bsp2 support with protocol 666 so it will load any map that markv can load.
if that helps for the time being
Downloaded - will play with it for sure. Looks like you are still updating this regularly. I wasn't aware.
let me know if there are any config issues i can
help you set it up.
Dwere Did Some Really Nice Weapon Models
Thank you, mate :)
I will surely give it a try.
MH wrote a nifty ‘hack’ to remove muzzle flash polygons
from the original models.
look for gl_clip_muzzleflash here in gl_mesh
This hack, IIRC, is pretty much what I described above. It's a good few years ago so I don't remember details, but I'm pretty certain it uses the same logic.
Quake Giblets: Mark V
Enjoy! Feedback welcome. I can always do a sequel with more features.
NE_Ruins (Custom Map)
A terrible freeze occurs if I use "LAST WEAPON" command bound to MWHEELUP, especially when I picked up the Quad Super Shotgun (Looks like super shotgun from Quake 2). Once I use "bind "MWHEELUP" impulse 12" it freakin' freezes. Only task manager helps to shut the game.
Also Mark V shut down once I entered the bridge with Death Knights.
NE_Ruins (Custom Map) 2
It's impossible complete this one with Mark V.
I've solved an issue with a freeze glitch discribed above by setting the following cvar :
"sv_gameplayfix_no_impulse12_override" to "0"
but the enemy which uses yellow shield (some sort of a witch) around itself causes the engine to crash. Once it starts to use that kind of attack the engine instantly crashes.
An emergence of this bug was also tested with a default cfg to eliminate a suspicion that something is wrong with setup.
Mark V Mouse Input Issues
Hi guys! New to Mark V, but really enjoying it. The only problem is the mouse input issues that others have touched upon recently, and I have a few things to add:
1. My mouse1 button does tend to get stuck not firing or stuck continuously firingas mentioned before, however it doesn't just extend to mouse1:
-mouse2 also tends to have the problem sometimes in the rare circumstance I use it to scope in. It's difficult to recreate by accident but I can do it sometimes if I purposefully mash it.
-mouse4 and mouse5 also seem to be affected. I use them for next and previous weapon, and they often just don't respond at all.
2. These problems only happen in Mark V, like others have experienced. It cannot ever be recreated in any other game, application, or circumstance. It doesn't seem to matter which mouse I use, either.
3. The most interesting thing is the fact that this doesn't seem to affect other types of keys. I never experienced the issue once after remapping my left click to Ctrl in my mouse software. Furthermore, I had previously mapped the side buttons to 1 and 2 instead of mouse4 and mouse5 in my mouse software and until I changed it back to normal I had never had a problem with those buttons in Mark V.
4.It doesn't seem to be a Windows 10 only issue, as I'm running Windows 7.
Hopefully this can get fixed, because I am really enjoying this engine a lot otherwise. It's difficult to discuss issues like this online without others immediately blaming your mouse despite all the evidence to the contrary or just telling you to switch to another engine like Quakespasm :P
Re: Post 2476
Errr... that crash bug with the witch resurrecting fallen enemies in NE_Ruins was fixed years ago. I had reported the issue and delivered hints to fix the problem back then. Are you sure you are using a recent build for Mark V? If it's crashing with a new version, then the issue was accidentally reintroduced and requires fixing again.
I'm using v1.99 (Revision 4)
From the section "Download Windows .Zip"
"DirectX / GL / WinQuake''
It seems that this bug bug emerges on the newest version...
Re: Post 2476
Yay, that means that Baker must have reverted these fixes in one of his last updates. Try using a previous snapshot and see if it works with those. We need to find the build that broke it.
Ne_Ruins was fixed back then in beta 14 of pre-v1.0:
As you can see, that was back in 2015. The problem back then was "incorrect handling of entities with alpha=0" according to Baker. If he did anything in the meantime that undid this, it's clear why the crashes occur (again).
I am not sure if I had reported the impulse12 issue as well, but when I played Ne_Ruins with that beta build back then, I know I had zero crashes.
Re Post 2481
"Mark V - Version 1.99 - Revision 2 (Stable?)
#2092 posted by Baker on 2018/05/08 23:25:05"
Have just tried "Revision 2" from post #2092
Same issue, same occasion.
You will probably need to go back further. It's possible it broke last year or even earlier again... I never checked it a second time after the fix since I assumed it would not break twice. Makes me wonder which of my reported issues are still solved. Gulp.
Ne_Ruins Crash Reproduction
So I have tried builds dating back to 1001 (Nov 21, 2016) and it still crashes. This needs investigation.
Please download this savegame for testing purposes (zipped, 66 KB)
and copy it into your ne_ruins directory, then load it with F9 ingame.
How to reproduce the issue:
- Go around the corner
- Kill ONLY the Death Knights
- Let the succubus with wings alive and let it resurrect the Death Knights
- Stay in FOV of the succubus, crash will occur eventually
Sad that this problem returns to the stable builds. However, couldn't reproduce the impulse12 crash. I can go back and forth through my weapon inventory without issues.
RE Ne_Ruins Crash Reproduction
I have just checked it out following your instructions.
The crash occured immediatly right after the succubus started resurrecting those guys. Yeah, that's pretty inconvenient to have this stuff emerging in stable builds.
Concerning "impulse12" related crash. You gotta have super shotgun and quad super shotgun in your possession.
Try to scroll previous/last/next weapon with any button you assigned to execute that action. The game freezes then.
Couple Of Things To Mention
1) When I press "load game" then load the savegame and then press ESC button it shows me "load game" menu instead of Main Menu of Quake. That's a bit inconvinient because I usually accidentally press "Enter" button and load a save game while forgetting to save the game after updating my game progress thus it results in loading an old savegame :D
Is there an option to disable this kind of a "Remember last menu" feature ?
2) If you run across a nailgun ammo box while firing the nailgun - it stops firing for a half a second. Really strange. Same applies for Supernailgun.
I think the impulse12 in Ne_ruins would need to be fixed within the mod. It wasn't made with impulse12 support and since that quad shotgun is an extra weapon, it causes problems. I believe s.o. actually made a patch for that, but I could be wrong. The succubus resurrection crash is definitely to blame on Mark V, though.
I also cannot run Ne_Ruins without assigning more memory to it via -heapsize 512000. Otherwise I get a crash right after leaving the intro map (Hunk_Alloc).
One More Thing To Mention (#2486)
At the introdution map of Quake, if you don't move your mouse and you go forward (move forward command) the player starts to look down at ladder a bit and if you go back (move back command) to the top the player centers his view back. If you move your mouse at the beginning - this behavior disappears.
Strange stuff, I think there must be a console command to disable such a behavior, but I can't find one.
When I go to multiplayer section of Dissolution Of Eternity (or any other mission pack) I don't see any maps of this expansion available for deathmatch or cooperative gameplay. There are only original Quake SP and DM maps displayed. Same for Scourge Of Armagon. Is there any way to make the maps displayed in multiplayer? Because it's impossible to play mission packs in coop or dm modes.
Is there any specific command line to enable creation of directories called "Save" and "Screenshots" inside a corresponding mod folder or main ID1 directory? It would be nice to have Mark V storing savegames and screenshots inside these particular folders.
A Note To Baker
You shouldn't remove this command since it is actually used. For example I change my refresh rate between my laptop and stationary PC. On laptop I'm running 60 hz and 100 hz on PC. So I use this - "vid_refreshrate" to set it up.
It would be nice if Mark V had more than 20 save slots for savegames. 50-100 would be great.
Should be implemented :)
Is It Sorta Trolling
i dont think i have ever saved a game. then again quake is kinda easy by today's standards why do you need more points of continue from point another to during any one map?
One simple way to gain more save points is to simply use console command "save".
For example, you can easily type "save 111" in the console and save your progress up to that point in the save file named 111.sav.
Likewise, if you need more save points, simply type another name for the new save file.
Though I must admit that remembering all those save file names can be a hassle. I don't remember if MarkV still allows for "dir" command in console for listing the file names.
So I'm stuck with Windows 10, and I guess you are already aware of the audio problems. Having several second lag on all sounds, so havn't been able to work much with MarkV lately.
My most recent map uses a lot of new mdls some with alpha masking. MarkV can handle all except for one. There is a seahorse with masking on the wings and fullbrights intentionally painted on the stomach for glowing effect.
QS and QSS can render it properly:
But MarkV will display the fullbrights as solid black:
Its a shame, as its the only one it won't handle.
Here's hoping that a fix comes along one day.
Windows 10 Audio Latency
Seems like MarkV is probably detecting palette index 255 as fullbright rather than as alpha.
Who Cares If
everybody's running qs
shitbler and its minions
detecting or not detecting
DirectQ/ QuakeSpasm Style Coloured Lighting
Hi devs, i have 2 questions/requests:-
1) Is it possible to have a tweak(config) for the intensity of coloured lighting in Mark V to match that of DirectQ/ QS. The colour lighting in Mark V is not as intense and vibrant as it is other two ports. I am using lit and vis file from here:
2) Is it possible to tweak settings to get DirectQ style coloured dynamic light effects without QMB effects. Maybe u can add another effect preset that matches DirectQ effects.
Although QMB effects are cool but they do feel out of place of 90's. But the coloured dynamic lights alone feel perfect.
Is it possible to have a tweak(config) for the intensity of coloured lighting in Mark V to match that of DirectQ/ QS. The colour lighting in Mark V is not as intense and vibrant as it is other two ports.
The lighting in MarkV and QS should be identical; they both effectively use the same 2x modulate blend which is capped-off (and saturates to white) at double intensity.
There are areas in even stock ID1 maps where this is a significant factor.
DirectQ used a custom HDR texture format which required unpacking in pixel shader code, and which had neither capping nor saturation. The idea was to store some extra data in the (otherwise unused) alpha channel of lightmap textures to fill in the extra dynamic range. Typically you'd see examples storing an exponential or multiplicative factor in there; I put a division in because I tried everything else and that was what looked best (in the context of Quake lightmaps, that is).
In a fixed pipeline engine it would be possible to trade an extra bit of precision and do a 4x modulate, capping at quadruple intensity. That's actually OK because 4x in 8 bits still beats software Quake's 2x in 6 bits. However it would rule out support for single TMU cards (you could gracefully drop back to 2x via glBlendFunc (GL_ONE, GL_ONE) however, but the very first generation of consumer cards may not support that blend mode). Other texture formats such as RGB10A2 would also work well, assuming you were happy to set OpenGL 1.4 as a minimum requirement.
Personally I think these would be all reasonable tradeoffs - there comes a point at which continued support for dead hardware contributes a net negative - but I'm not the developer of Mark V.
I'm more a fan of e5bgr9, as it can also be used by a fixed-function pipeline (although requires a gl3ish gpu) without extra scalers, doesn't require any manual interpolation, still allows for up to 4000-fold overbright (ish), has higher precision than rgbx8, and uses the same ammount of gpu memory as rgbx8 (half as much as half-floats would). etc. If you're lazy you can just hardcode the exponent and get 4x overbright with the same precision as rgbx8 would get with 2x overbright. And if you're not lazy then you can get more precise dark areas alongside insanely bright areas.
does anyone still use a gpu older than gl3?..
I personally consider D3D11 to be entry level these days, it's a ~10-year old API. GL versions do lag for some vendors, however. GL3.2 is probably a reasonable minimum.
I find it better to do lightstyle animations on the GPU, and dynamics with extra additive blending passes. I've coded it up in GL1.5 assembly shaders, GL 2..4 GLSL, D3D9 HLSL and D3D11 HLSL for Q1, Q2 and H2 so I'm quite satisfied that the approach is solid.
The difference in lit rendering between MarkV and QuakeSpasm, DirectQ could be the LightNormalize function which does:
lit = lit * (greyscale / max(lit.r, lit.g, lit.b));
so max(lit.r, lit.g, lit.b) needs to be equal to the greyscale value, or the final rendering will be different from engines that don't do this. If the lit files from https://quakewiki.org/wiki/External_Lit_And_Vis_Files
don't have that property, this will be causing the difference you're seeing.