I see that some silence has returned to this thread. :P

Well, just dropped in to say that I am finished with my basic Mk V testing sessions.

I checked these:
- Quake + mission packs
- Nehahra
- Travail
- Shrak
- Malice
- Abyss of Pandemonium
- Beyond Belief
- Honey
- Rubicon Rumble Pack
- ne_ruins
- Rapture
- Soul of Evil
- Soul of Evil: Indian Summer
- In the Shadows
- Retro Jam 1-3
- Func Map Jam 1+2

Good news: No problems with any of these actually - besides the remaining issues with Shrak (white skin textures) and Malice (fov crash in map d15).

I will check some Quoth and Drake missions, but I am confident Mk V will do fine here, too. :) 

I'm glad to hear it!

Haven't had much to talk about because I've been working away on the to-do list and items in this thread.

But I'm only about 70% done, so late next week is likely when the next version will be out. 

How do I load from the autosave? I press F9 and it loads from the manual quicksave. 

Type load and the press a and then TAB.

You'll see a0.sav, a1.sav and a2.sav

(I need to give them better names but initially I didn't call them auto_save because some single player releases with autosave tend to use a name like auto_save.) 

a0 = newest, a1 a few minutes older, 2 a few minutes older than that. 

should probably load the latest autosave... Or the last autosave should show up in the load menu. Either/or will do. 

The last Quakespasm update at Quaddicted says Baker ported a MarkV feature into Quakespasm. I know he's involved in both projects. So, what are the differences between them? 

I am sure Baker can tell you all the differences instantly. For me, the most important difference is actually that Mk V can run Nehahra. And that's amazing.

Hoping that Baker eventually gets back to working on the new version. Still waiting for the Shrak/Malice fixes. ^^ 

Yah , Nehara is good.

MarkV is a windows project, with more experimental/fancy features. QS is multiplatform and, perhaps, more solid. 

Is the fog problem in Neh2m5 fixed? 

Is there any way to limit the game fps to 72 without syncing to the monitor refresh rate? My monitor only does 60 Hz. Also, with vsync on, there's some weird lag going on.

DirectQ has this feature, but unfortunately, it also has an annoying issue where the player will start sinking into the floor after some time of playing. 

Host_maxfps should do it 

Thanks, that's it! Still unplayable with it set to 72 though; quite jerky. I guess I won't be playing e3m2 with this engine. Everything else seems fine though! 

The software stuff is really exciting because it's the only software port besides super8 that can load big maps and it's much more faithful than super8. Do you plan on adding the interface scaling from regular Mark V/QuakeSpasm? The HUD is unreadable at 1920x1080.

Come to think of it, if you could implement colored lighting, interface scaling, and fog into the WinQuake Mark V executable, it would instantly make super8 obsolete and it would make me very happy indeed. 

Any news about a new build, btw? I am still waiting for those Shrak/Malice fixes (see #826 and #855). :P 

How does the engine define the intensity and color for weapon model to apply? It seems to me that is checks the light value only without checking delay or wait values of the light entity. So if I have a light source with high light value but with delay and wait adjusted so that it's bright only near the source my weapon shines although the walls are dark.

https://dl.dropboxusercontent.com/u/32711504/mark_v_0008.jpg
This screenshot shows the problem: there's a orange light source with 800 light value underneath (the floor is func_door, so it doesn't block the lighting) but delay and wait (and other) values make it barely noticeable at this distance. While my weapon model thinks that there's a light with plain light 800 that affects it.

Is it possible to fix this? 

I think that's the just Quake's simplistic lighting for mdl's. AFAIK, the engine traces a line downward from the entity until it hits a floor surface in the world model, then it samples the lightmap on that surface. So the engine doesn't ever look at the light entities or their light/delay/wait values, just what's baked into the lightmap. 

from what I see light value affects mdl lighting. Here's the screenshot of the same place but with 300 light value: https://dl.dropboxusercontent.com/u/32711504/mark_v_0010.jpg
weapon doesn't shine that bright.

That's why I think it might be possible to fix.

btw that's surface light. 

quake uses the light on the (worldmodel) floor straight downwards from the model to determine lighting -- even if that floor is quite far below the model. if the floor below you is bright red, that explains it. 

that makes sense. any brush entity floor breaks it =( 

That screenshot makes me want to add a lightgrid to .lit2, and to revive .lit2... 

Ironically, I had a "fix" for that that was in very early Mark V versions, which I removed.

But that would be a lighting change and I'm sure random obscure map X, Y or Z might have a spot where the lighting would be different than expected. 

I wonder if it is possible to make it switchable via console command. So the default value is classic light behaviour but a mapper can add a note in readme that recommended settings for his map are the following (including this new command). Or he can place it in quake.rc 

Your problem is caused by what metlslime says.

You have the opposite of the "black scrags against a bright sky" error, where people place scrags out at a distance but do not light the floor below them because it isn't visible to the player.

The scrags appear solid black even though the sky is full bright and the area up where they are may be well lit. This is because the floor far below is in darkness.

Any floor which is an entity, such as func_wall or door/plat, is not used for lighting models. The engine keeps going down until it finds solid geometry. 

adding lightgrid (or something like it) to lit2 seems like a good idea, because any fix that uses the normal bsp or lit lighting will break expected behavior of old maps. But no old maps use lit2, so it's a fresh start.