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

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".