Sorry, Pulsar. I should have done a better just communicating the change.

Wanted to make the autosave names more clear and obvious to a newcomer. 

Are you guys making a DirectX engine that can play Arcane Dimensions, right? My low-end netbook can barely play it on Quakespasm sometimes but with the DX9 engine it stays mostly on 60 fps on the few maps that can support it, most still crash.

That would be a miracle. 

I suspect over the course of the week that the answer is mostly likely a "Yes!" 

Direct X 9 Version | Source Code

Requires -nostencil in the command line. Stencil buffer is not yet operational. Does not yet have WinQuake-like r_waterwarp integrated.

c:/quake/DirectMark5.exe -nostencil

Does have fully resizable window capability.

vid_hardwaregamma

Set to 0 = shader gamma (looks nicer in windowed mode)
Set to 1 = hardware gamma [default] (in high resolutions, can be very much faster than shader gamma)

@mh - Some issues exhibited in DirectFitz 9 prototype do not seem to happen in DirectMark5.exe Build 1022. Will do some more testing, but Mark V handles video mode changes differently than FitzQuake and I rewrote small parts of the wrapper. I think the issue list may have gotten smaller, but more testing will tell.

/Source code link will probably work in 10-15 minutes. 

vid_vsync 1 works in windowed mode, but apparently not right away. If I press ALT-ENTER a couple of times, windowed mode doesn't take it.

As a work around for now, I feed it into the command buffer as such ...

Added into end of setmode for now ...

// Vid_SetMode
// Window already created or recreated ...

Vid_Vsync (); // Fullscreen fine, windowed mode no effect though ...

#ifdef DIRECT3D9_WRAPPER
// ensure swap settings right
if (vid.screen.type == MODE_WINDOWED && vid_vsync.value)
... Cbuf_AddText ("vid_vsync 0; wait; vid_vsync 1"); // Works!

#endif // DIRECT3D9_WRAPPER 

Wanted to make the autosave names more clear and obvious to a newcomer.
Any particular reason you inserted an extra underscore in auto_save, then? autosave_0, autosave_1 etc seem more obvious to me since I've always read it as a single word and not two words separated by a space. Or even autosave0, autosave1...: the underscore is more of a programmer thing that isn't intuitively used by n00bz. Plus, the less characters to type the better IMHO. 

There are some single player releases with autosaves built into them. So I don't want to use a name like "autosave", for instance.

In Mark V, someone who used it any length of time would just type "load a" and press TAB.

1) So no one would be typing more stuff ;-)
2) You just need to remember the "a", you don't need to know the name.

Mark V auto-completes even ..
1) skybox names (!!!)
2) key names
3) demo names
4) save names
5) map names
6) game folders
7) Several other things.

Mark V can auto-complete in the middle of line! If you have a long line, you can backspace in the middle of it and press TAB or ALT-SPACE and it won't mess anything up.

In fact, Mark V even has undo and re-do! You can press CTRL-Z or CTRL-SHIFT-Z (redo) in the console.

That's in addition to being able to hold down shift and select text in the console and copy it or paste it.

And in addition to being able to press CTRL+PGDN and CTRL+PGUP to resize the console.

Mark V is user-convenience engine ;-) 

Direct X 9 Version | Source Code

Requires -nostencil in command line, as stencil buffer isn't ironed out.

1) r_waterwarp 2 is WinQuake style waterwarp
2) Resizable window at any time
3) Shader based gamma available (vid_hardwaregamma 0), look nicer in windowed mode. Hardware gamma is faster, especially in high resolutions.
4) The renderer is faster. Startup and Alt-Enter are astonishingly fast. Haven't been able to get a complete handle on the speed increase, but certain highly complex maps seem to render at least twice as fast.

@mh - I've taken it about as far I can go ;-) Aside from some outstanding testing situations I've thought of and some polishing up ideas I've charted out.

Stuff:
1) stencil
2) non-power of 2 texture sizes
3) Technically, vid_vsync 1 + windowed mode doesn't immediately work at video mode change time, but I did a workaround putting some commands in the command buffer.
4) Without thinking too hard, I do not believe there are any other outstanding issues. I don't have any known mode switching issues ever nor the off by 1 pixel shader gamma issue either.

I have the engine use the provided Direct 3D screenshot method when the buffer already has gamma/contrast applied to it (if shader gamma is on, for instance), since it seems to be at least 3 times faster when writing PNG (PNG is a notoriously slow format to write). 

So there is a valid reason, then. OK thanks. 

 

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