I have no time for testing with a house full of visiting mini-ogres. And it looks like there's still work to be done before exhaustive testing really begins. 

Been sick the past few days so I'm a little behind schedule, but all of the items mentioned by Baker above are now fixed. I haven't yet integrated the changes Baker made to the wrapper.

There's some weird interactions I want to shake out between video startup, mode switching and window resizing, but if it takes me too long I'll just do another upload of the current version with window resizing flagged as "potentially unstable". 

Current vsync behaviour is a bug in my code.

What's happening is that the vsync setting is not holding across a device reset. Now, sometimes (e.g. if creating a new context or doing anything else which reverts all state back to defaults) that's the behaviour you want, but other times (mode change, alt tab, etc) it's not.

The quick and dirty fix is to find the line "this->PresentParams.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;" in context_t::SetupPresentParams, remove it from there and put it into context_t::context_t *above* the call to this->SetupPresentParams instead.

That should be enough to get you going and you can remove your workaround. :) 

A bit more about the flickering:

I played through DOPA using mark_v_winquake.exe and didn't notice any flickering.

I switched over to using mark_v.exe for playing ad_mire, and I noticed flickering pretty regularly (played up to the point of turning the first valve). Switched to quakespasm_sdl2.exe and played through the same part of the map, no flickering.

I'm using a GTX 1070 with latest drivers. Let me know if you ever want some additional system info, or for me to try anything out. 

A couple of things about autosaves:

- I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional?

- The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves. It looks like the autosave names are not recognized, at least for autocomplete purposes, until you after do a manual savegame. 

http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2016-12-30.zip

You'll need to do a diff with the original wrapper engine code for this too, because there are some subtle changes required engine-side relating to Alt-Tab handling.

I dropped your "ResizeWindow" and rewrote "ResetMode" to handle switching from Windowed to Windowed without other changes.

There's a changelog included so you can see what's different/fixed/broken/etc since the last release. 

Cool! I'm kind of sporadic during the holidays.

Look forward to checking out the code!

@johhny

I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional?

Yes, at least for now. FrightNight and I didn't like non-user based save games in the menu. Doesn't mean that is a "final answer" or that couldn't change, but unwanted "randomish" save games in the menu seemed wrong.

The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves.

I'm rather certain that is perception only. While I haven't checked, one thing I do know is that any save game forces an autocomplete update.

The first save has a bit of different interval because who really cares about a save game when you've played less than 2 minutes, if you see my point.

An autosave is a "Help! I forgot to save and played for 45 minutes!" feature as a safety net for the player.

The "I died 100 seconds into the map" isn't really what autosave is there for, you know ;-) 

Also, you have hit on a fine-tuning weakness.

I usually start coding something "too conservatively" and then gravitate it towards what the user would expect.

Which is fine and the right way to do things.

You make it work efficiently first, then you relax it to conform to user expectations and figure out how it fits into the user interface correctly.

It is ok for something to be over-efficient at first, but not user-tuned. If something is written over-efficiently, that is the right kind of problem to have as a starting-point. 

Give it a try. :-)

The issue is that Lists_Update_Savelist is only invoked on new game or on manual save (in Host_Savegame_f). 

That being said,

void Host_Savegame_f (lparse_t *line)
{
...
...
Lists_Update_Savelist (); <---
}

It don't think I'm wrong about this, but even if I happen to be right (at a quick glance looks to be the case) don't stop telling me about things you think I overlooked. 

But actually you are right. That is the user-initiated pathway. The auto-save mechanism never hits there.

+1 

I ported Q3A's r_shadows 2 mode to DirectFitz.

http://www.quaketastic.com/files/screen_shots/ShadowsThatSuckSlightlyLess.jpg

I guess not many people are aware of this mode (I'm certainly not aware of any well-known Q1 source ports that use it), but it uses a simplified variant on stencil shadow volumes to resolve many of the major annoyances of classic Quake's r_shadows.

Just to manage expectations a little, it's not real-time lighting, it doesn't give you arbitrary shadows from any number of lights, it doesn't fix dynamic light shine-through; what it does do is fix cases where classic Quake r_shadows 1 breaks down, such as on steps, at edges, on angled surfaces, etc. 

 

I was aware of this mode in Q3A, but I couldn't enable it on my latest system.

Am I seeing self-shadowing on the shot? 

I think I would prefer just a kind of simple blob shadow under the monster ala turok or something like you see in severance 

I implemented Rich's shadow tut years ago in Qrack,(the un-interpolated version) and works fine enough, yet it's BASIC openGL v1.1; no vertex arrays. Combined with applying an alpha value based on how bright the surrounding light brightness can make it look someone real, hard-edge yet conforms to stairs/walls/slopes.
I'll have to look at Q3A's method for a quick and dirty CPU-driven shadows vs the stock shadows in Quake.
The pic you posted above imho is what Quake should have had from day one. It just makes the scene more immersive :)! 

The Q3A shadow code doesn't use vertex arrays, but just to correct a misconception: vertex arrays are also basic GL 1.1. 

lol, you'd think I would know this by now ;) 

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