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. ;) 

A fair number of the Arcane Dimensions maps are BSP2.

Spike added BSP2 in this patch: http://triptohell.info/moodles/junk/markv_bsp2.zip

I'm sure I've posted you a link the above before. BSP2 is way easier than protocol 666.

There is also the Quakespasm acquisition of that BSP2 patch at https://sourceforge.net/p/quakespasm/patches/11/ which has a diff file. 

I do have a working version with bsp2 support but somehow it broke my normal quake skys. Sky boxes work fine. Spike made suggestions yet i havent had any time to fix :S 

O_o really? Would be interesting. 

In 24 hours or less, some fun stuff to play with ...

* A very nice Direct X 9 build, with mirror support.

* Ubuntu Linux Open GL build
* Ubuntu Linux WinQuake build

* GL builds have MH WinQuake-style water warp. Default setting. Setting r_waterwarp 2 will get the FitzQuake look.

* Windows WinQuake through Open GL for KillPixel. I also happened to need to make this for Linux purposes.

* GeForce/Nvidia issues and DPI annoyances should be gone.

This feature is somehow a super-perfect fit with Quake. You don't quite realize it is missing until you have it available, and then not having it feels wrong.

* A rather extensive changelog, but I couldn't say for sure what is in it.

* I do know it has a worldspawn option for dumptruck_ds to set the sound distance.

* WinQuake version now also has resizable window in real-time like the Open GL and Direct X 9 versions.

* Mac mouse acceleration fix (The "SleepWalkr" fix, as I think of it).
* IPv6 tune-up on non-Windows platforms giving it all the nice features available in the Windows version.

Linux versions have about 99.5% of the Windows feature set, with the main omission from my perspective being video capture -- which the Requiem engine has and I haven't had time to get "X Windows"-ish with the code base.

Oddly enough, the Linux build requires SDL 2.0.5 ... at one point I was preparing for an Android build (which isn't coming anytime in the new future, but I always lay foundations in advance) and I need SDL for Android.

Many people think that any engine using SDL needs to have external dlls. It's not true. Just for fun, I'll throw in a Windows SDL build that requires no DLLs. To keep things relevant, I guess I'll make this SDL build a WinQuake Through Open GL SDL build for Windows. 

looking forward to waterwarp especially :) 

 

@fifth/@kp -- Trying to fill my mana bar for final gauntlet.

I actually have a list of 24 separate individual items on a sheet of paper to apply what I hope is the right level of polish to this.

Engine coding is all about the small ball.

Testing 4 or 5 Windows builds (GL, DX9, DX8, WinQuake, WinQuake via GL), 2 Mac builds, 2 Linux builds, making sure the Debug and Release builds are right and then in Windows making sure it works in Visual Studio and CodeBlocks is a hassle.

But if all goes well ... it'll be worth it ;-)

/Sometimes I ask myself "Ok what is the reason to do all of this again?" Usually the answer is "Because it is there." Or something, haha ;-)

No seriously, should be quite worth it. ;-) 

That's nice and all but is there twue rotation w/collision :-P

I heard the time is now... 

He needs to add 4 player splitscreen coop yet ;) 

... grrr, hehe