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.