Some of us like to refer to documentation. Let me guess... it's built in? Well how and I to know that? 8-P 

Next version will have a worldspawn option to increase sound distance. As an experiment to see if it is useful. Mostly because of issue you mentioned about sound cut-off being undesirable for what you are working on.

re:readme - this thread mostly serves that purpose for now. The "find" command in the engine is also helpful (like type "find sky" in the console ).

This is more of an interactive project with those that want to participate and help test and refine and such. 

@rook - Yeah, I quite like what MH did with the shadows and your "what Quake should have had from day one" is what I think about that awesomeness. ;-)

---
mh - regarding window borders. aguirRe back quite a while ago now, made a "fullscreen windowed mode" and every engine I worked on since emulated that behavior.

If the window size is the desktop size, no borders. So that is one reason why I wanted the engine to say what the borders should be. Also want to preserve resizable borders as an option (the D3D wrapper may end up encasing the software renderer in an optional build that uses a texture as the frame buffer, which I don't feel like implementing resize for the software renderer right now since is moderate hassle) or keep the option of no borders as a possibility even in windowed mode (because some external video capture tools capture window borders).

So that's what is up with that and my comment in the code. If that seems reasonable. 

1) Noticed Requiem engine (by jdhack, I've referred to it as "Spirit's engine", and johhny law as I understand it has put some work into it too) --- uses "force char as unsigned char" option during compilation. Tried that option with Mark V, about 5 fields of code inherited elsewhere had to be changed from char to int.

Any proper C code is going to treat char as both signed and unsigned simultaneously (C specification allows both as valid treatment) but when debugging I don't want to see -40 or -128 or even -1 as a value for a char field. Slows down debugging to have to think ;-)

2) Newlines in Con_Print, etc.

I view newlines and quotes in a printf as a source of fragility and an ease-of-reading nuisance.

And as an example, Google's Android platform debug logging expressly thinks in terms of fully-formed lines and you don't supply the newline.

I used a tool to "robotically" identify and replace Con_Printf to Con_PrintLinef where applicable and then examined what remained.

Most of the Con_Printf without a newline at the end, it was unintentional, as I suspected.

Anyway, in the next version, that behavior has largely been expunged in the entire engine barring obvious circumstances that must persist like QuakeC or messages from the server or the reverse.

Makes code easier to read and more maintainable.

3) Speaking of Con_Printf ...

Con_Printf has always been borderline undesirable, especially with vsync because it causes an immediate rendering of a frame --- but since using vid_vsync will pause engine operations until it is time to render a frame, can be quite undesirable.

In some circumstances you do want immediate feedback. Like "Connecting ..." or a very slow operation like "edicts" or some intermittent feedback for "imagedump" (FitzQuake dump OpenGL textures to folder command).

But most of the time, you simply do not want Con_Printf at all. It the opposite of an optimization. 

isn't there a Con_SafePrintf to solve that problem? 

Yes ;-) 

In unreleased Mark V (grabbed Windows DPI awareness from Quakespasm) tested on GeForce with driver version 373.19

No flickering.

Driver version 373.19 = ok
And didn't see flickering for 372.70 in previous test = looked ok

Will see what results are after next Mark V update. 

Next version will have a worldspawn option to increase sound distance. As an experiment to see if it is useful. Mostly because of issue you mentioned about sound cut-off being undesirable for what you are working on. That's great news. I had the same issue in my Retrojam map as well. A very large chamber and the doors and plats were silent. In reality you'd hear the sounds echoing from a distance.

I think adding dev tools like your inspector are a great help.

A suggestion: Can the console text be resized separately from the in- game text? I usually have in-game text at a legible size but that limits how much you can display in the console. Just an inquiry. 

@dumptruck_ds I'm pretty sure this is possible, in Qrack I have the realtime ability to resize the console text using ctrl+mwheelup/down which doesnt affect the mesagemode text size. 

@dumptruck_ds I'm pretty sure this is possible, in Qrack I have the realtime ability to resize the console text using ctrl+mwheelup/down which doesnt affect the mesagemode text size. 

haha what's Qrack? I downloaded but there's no readme????? Website is pretty minimal. Well I guess I could just try it. :) 

I do understand where you're coming from, but...

There are architectural and internal differences between GL and D3D, and how they interact with the windowing system. This is compounded by WDDM on Windows Vista or higher.

GL doesn't specify any interaction with the windowing system. You use GDI and native API calls, you have full control over everything, but also full responsibility to do everything yourself.

D3D has tighter integration and interaction with the windowing system is defined as part of the API. For example, you don't use ChangeDisplaySettings and a window resize to set a full screen mode; instead you specify a backbuffer size then Reset the device, and D3D will do this automatically for you.

That's why there are other differences too, such as the changes I've made to AppActivate. I don't make those changes for the jollies, or for some idealistic crusade for cleaner or nicer code. I make them because they're required.

Full screen is different between GL and D3D. D3D has a concept of a cooperative level, which is how (and if) your program cooperates with others. Windowed modes have non-exclusive ownership of the graphics hardware, meaning that other programs that also have non-exclusive ownership can run and use the hardware. Full screen modes have exclusive ownership, only one of those can use the hardware, and no non-exclusive programs can use it. (That's why lost devices happen - something else starts using the hardware that blocks your program's access to it).

GL has absolutely none of this. If a full screen mode has any meaning in GL then the driver is going to have to apply heuristics to detect it, perhaps by sniffing at the window styles or by comparing the window size to the display mode. What you think is a full screen windowed mode might actually be being converted to a proper full screen mode by the driver (another reason why it might seem to work in GL).

That's all background intended to help you understand that you just can't always do a 1:1 mapping between behaviours and that API differences go deeper than just syntax. Differences are architectural, and D3D is a whole driver model as well as just an API.

Regarding borders and full screen windowed modes - I tried it and it didn't work. I actually spent about 2 weeks at it over a year ago, and 2 weeks spent toggling between modes, setting breakpoints, printing out window and backbuffer sizes, then change something and try again, is enough for anyone.

The most common problem was that Windows wouldn't let the program window cover the taskbar. I don't have a direct link for this, but I believe that this is a deliberate change in newer versions.

Coming right up behind it was that the backbuffer was sized differently to the window client rect. This could be really subtle, but it was enough to cause the driver to need to do a stretch blit instead of just a buffer swap, and performance fell off a cliff.

Other problems included window positioning, not actually going full screen windowed at all, and issues around Aero styling when toggling modes.

In other words, when I say "I tried it and it didn't work" I'm quite satisfied that I did make a comprehensive enough attempt, and when I say "don't do this" I do expect you to believe that there are reasons for it. I'm not saying "don't do this" because I'm too lazy or don't want to make the required code changes, I'm saying "don't do this" because you really shouldn't. 

Got it. It's all good ;-)

I know D3D is wired differently and I've read your comments. I was trying to express why I even would even want to do such a thing.

I'm rather good at working within boundaries ;-)

I rather cleverly worked within the limits of the DX8 wrapper and I can do that here too.

No worries! 

Ah, Aero style! That's jogging some memories with the DX8 wrapper. Not fun memories either! 

Aero styles is one of those things that every time I do this it messes up in some way, so I spend a few days "poking it with a stick to see if it moves", until eventually I get there.

I should have probably added - none of this is that way that real cross-platform/cross-API games are written. What we're doing is taking code written around the way GL works/the requirements of GL, then mangling it to work with D3D. A real cross-API game isn't written like that at all. Instead it would have "SetModeGL", "SetModeD3D" and use the correct native code in each.

Much of this is from the perspective of pre-empting queries along the lines of "but game X does it so I don't understand why you can't". 

its at times like this that I apprechiate vulkan's WSI (windowing system integration).
its a bit like gl (in that its simply attached to the client part of a window), except with explicit swapchains like d3d (but cleaner and less annoying. its just much more sane than either.
fte now uses the same gl_vidnt.c file for both gl and vulkan. one renderer creates a wgl context attached to the window, the other a wsi surface. which is much nicer than having d3d doing random poorly-documented things to your window thereby breaking things.

vulkan's backbuffer is actually an image just like any other, which means you can blit true-colour software-rendered images to the backbuffer using only simple buffer copies, no glsl required. unfortunately the queues and stuff are kinda annoying. when everything uses compositors anyway, there's not really any difference between the backbuffer and a texture nowadays - render-to-texture for all!

I assume d3d12 is similar, but I've never really looked at that. 

From what I've seen of D3D12 it's much the same DXGI interfaces as D3D11, so you've got the same swapchains, texture with rendertarget view, and arseways crap of running in one of two modes: "we control everything and nothing works the way you actually want it to" or "we control nothing and you have full responsibility for all of the pain and suffering" - neither of which are the way you'd actually like it to run. 

eww, dxgi 

My idea of doing a chdir to id1, forcing the opengl32.dll to load, then chdir back failed.

Had to revert to Spike's LoadLibrary/GetProcAddress suggestion.

Wasn't a big deal, since Mark V is already setup to rewire rendering functions (OpenGL vs. Direct X 9, etc.)

A call to getenv("COMSPEC") /* should be highly retrocompatible*/ obtains the system directory where the correct opengl32.dll should live.

If it doesn't find the .dll there, or can't load that .dll or any of the functions fail to load, it describes the problem and asks user to rename opengl32.dll

It also prints a few lines of bronzed text complaining.

Why does this matter?

Because GOG.com --- the DRM-free game buying site --- distributes GLQuake complete with a toxic OpenGL32.dll provided. 

qboolean CheckOpengl32(void)
{
FILE *f;
char ogname[1024];

Q_snprintfz (ogname, sizeof(ogname), "%s\\opengl32.dll", com_basedir);
if ((f = fopen(ogname, "rb")))
{
fclose (f);
return true;
}

return false;
}

/*
===================
VID_Init
===================
*/
void VID_Init(unsigned char *palette)
{
int i, existingmode;
int basenummodes, width, height, bpp, refreshrate, findbpp, done;
HDC hdc;
HGLRC baseRC;
DEVMODE devmode;
extern void VID_Menu_CalcConTextSize (float cw, float w);

if (CheckOpengl32() == true)
Sys_Error ("Please delete the opengl32.dll from the Quake folder."); 

I've had one that similar to that in ProQuake for ages.

I wanted one that doesn't require any user action at all and simply ignores it, haha ;-)

Mission Accomplished. 

Qrack is an old engine based on joequake .13dev (circa 2004) I released a final version for Quake's 20th bday, hense the silly webpage; looks like a 90s website. The "whatsnew.txt" is in the zip in the Qrack folder. it's just a changelog (where most of the documentation can be discerned). Newest version will load arcane dimensions and has protocol 666 etc but not bsp2 support. it's basically just my personal project to keep me entertained and doesnt try too hard to do anything else :P 

It requires at a minimum using /DELAYLOAD:opengl32.dll in visual studio

Or I guess simply not linking to the opengl32.dll at all is also an option. 

nice, "**warning Mark V detected an evil troll, killed it with the glowing sword, you may proceed.."

"The Troll Room
This is a small room with passages to the east and south and a forbidding hole leading west. Bloodstains and deep scratches (perhaps made by an axe) mar the walls.
A nasty-looking troll, brandishing a bloody axe, blocks all passages out of the room.

Your sword has begun to glow very brightly.
The troll swings his azxe, but it misses.

>swing sword
Whoosh!
The troll swings, you parry, but the force of his blow knocks your sword away.

>get sword
Taken.

The troll hits you with a glancing blow, and you are momentarily stunned.

>kill troll with sword
The troll is staggered, and drops to his knees.
The troll slowly regains his feet." 

I've always wanted to make a QuakeC console version of some kinda Zork clone hehe to play while wiating for a multiplayer game to start. ;)