Having the client dynamically allocate entities is easy. Having the server dynamically allocate them is hard, because the QC interpreter does a lot of pointer offset trickery to access edict fields. It's even valid for the interpreter to try to access a field in a different edict to the current one. I'm not sure why you'd even want to, but I've tripped up on that assumption in the past.

Static entities and efrags have absolutely no reason to have hard-coded limits and can be just pulled from Hunk memory as required. At a guess I'd say that the hard-coded limits in the original were there because Quake had to run on an 8mb MS-DOS machine (a lot of the weirdness in Quake's memory system comes from that and the fact that DOS had no virtual memory, and it's notable that id threw it all out when they moved away from DOS). There's no reason to preserve that in a modern source port. 

@baker:
better the client disconnects than the server crashes.

fog is different in almost every engine. it would be nice if someone actually documented the formulas engines use in an attempt to create some standard that all engines could then use...
https://xkcd.com/927/

@mh
the _only_ reason for weird fields is weird ens - ie: qccx hacks (there's no other way to easily generate those dodgy fields). imho, nuke them from orbit, but I guess baker doesn't have that luxuary due to his proquake stuff.
fte+dp use regular indexes for ents instead of offsets (screw qccx), and in doing so, they can dynamically allocate more memory. the catch is that you can't free it again mid-map. 

Fog isn't just different on every engine, it's also potentially different on different hardware, drivers and even APIs.

Fixed pipeline fog (i.e the various glFog commands) is allowed to be evaluated per-vertex or per-fragment. AFAIK OpenGL doesn't specify this, but D3D also allows more explicit control of range-based (versus simple depth-based) fog and even table-based fog.

You're completely at the mercy of what your 3D card and driver gives you for this, so it's pointless specifying a standard. The best anyone can do is implement something that looks good enough to pass, but even so it may look completely different (even with the very same code) on somebody else's PC.

Fixed pipeline fog doesn't even work at all under D3D with Shader Model 3 or better hardware. You must write your own fog in a shader.

Fixed pipeline fog quality in OpenGL is controlled by a hint and the documentation for glHint explicitly states that "the interpretation of the hints depends on the implementation". It's perfectly legal for you to request GL_NICEST but for the driver to give you low-quality instead.

Shader-based fog can use any formula at all, and can likewise be calculated per-vertex or per-fragment. The end result can look much higher quality than fixed pipeline fog (you can even experiment with crazy things like moving fog) but the higher quality may be interpreted as different or non-standard by comparison to what a player is otherwise used to.

Quake 3 and Doom 3 avoid all of this mess by doing their own fog as an extra pass over all surfaces, which obviously comes at the cost of extra geometry submission and processing. Depending on the scene, this could cut framerate in half.

It's also possible to implement fog by drawing the depth buffer as a full-screen quad over the scene and deriving a fog formula from the values stored in it, but that of course will fail for anything that's not written to the depth buffer (particles, translucent water, etc won't be fogged). 

Well, putting max_edicts "8192" into autoexec.cfg enabled me to get past "Nehahra's Den" with existing savegames. The problem is that while Nehahra's gibs are flying around, the exit elevator breaks through the ceiling, and with all the glass shards and debris raining down while gibs are still visible, it's just too much with low edicts settings.

I noticed a small detail with episode ending text screens. Looks like the last line(s) of text are cut off. Thought it may be because I use scr_menuscale 3, but reducing the value didn't reveal the missing lines (they were complete when checking it on console, though).

Summary of Nehahra playthrough:
- "Nehahra's Den" crash fix needed
- Possible issue with ending texts (may be general issue or not)
- Adding missing fog would be nice, but optional
- Otherwise, flawless gameplay. Music plays (if set up properly), cutscenes work, all maps completable etc

Keeping the "resurrection crash issue" with ne_ruins in mind, I will continue my Mk V testing queue with:
- Quake mission packs (SoA almost done already)
- Travail
- Honey
- Rubicon Rumble Pack

Possibly more after that, provided my free time allows it. 

@nightfright .. I appreciate the testing. I can't work on this and play a ton of mods at the same time ;-) 

Did you say that earlier you had max_edicts at 512? Because that's lower than dosquake which allowed 600 edicts, which might explain why it caused crashing. There's an argument here that allowing people to reduce the memory footprint below what was considered acceptable 19 years ago is unnecessary today. This argument would continue that engines should prevent people shooting themselves in the foot by enforcing a minimum max_edicts of 600. 

Edict size in ID1 is 876 bytes. This can be variable because mods can add their own edict fields which are tagged on at the end of the struct, accessible normally through QC but only accessible through C code by means of some pointer jiggery-pokery.

Say 1k as a good working size and because it makes subsequent calculations easier.

So if max_edicts is 8192 that's 8mb of memory. If it's 32768 it's 32mb of memory. Neither is a huge figure today, nor would it be considered huge on a PC from 10 years ago.

Most of that memory is going to be unused though, and there's also the fact that a lot of engine developers like to have their engines run on the same (or at least similar) class of machine that the original ran on.

One solution under Windows would be to VirtualAlloc a largeish pool of memory - say 64mb (for headroom) - with MEM_RESERVE. This won't count towards memory used, it just marks pages as reserved for subsequent use. Then as edicts are assigned from that pool, another VirtualAlloc with MEM_COMMIT for each new edict will actually use the memory, and only the memory, required for however many edicts a map might need.

I'm sure Linux and other POSIX systems have APIs that allow a similar scheme, but I'm not familiar with them. Either way, this setup allows the max_edicts cvar to go away.

IMO this is a good thing. I get that max_edicts is well-meant, but a major weakness of it is that it puts the obligation on the player to do the right thing. And the player must be aware that it exists, know that it may be needed, know what the appropriate value to set it to is, and know to set it before loading the map.

That just seems appallingly player-unfriendly to me. OK, I also understand that newer mods come with their own quake.rc that sets it accordingly, but it's still broken under older mods and it's something that with a bit of thought doesn't even need to exist.

In the end I just don't see an acceptable middle-ground for players. Either set a hard max_edicts and design mods around it, or make there be no practical maximum. But putting the burden on the player to do the right thing is eventually just going to blow up in your face. 

512 sounds low, but it was a machine picking the limit because the map probably had like 150 entities.

Dynamic ents will fix.

Dynamic ents doesn't solve any issues except this one. By the time you hit 5000 server edicts you are going to have all kinds of problems with the networking limits for stock Quake.

If it isn't one thing, its another. 

Windows OpenGL | WinQuake

1) PNG screenshots might be fixed. Need NightFright to check since I don't experience issue. Changed download from GL_RGBA to old style GL_RGB before saving to PNG.

2) WinQuake large resolutions should be fine, but scaled (because WinQuake renderer can only do so many vertical lines). I don't have a 1080p monitor, so need verification as well.

3) Added Ctrl+Left+Arrow, CTRL-A, CTRL-Z (undo), CTRL-SHIFT-Z (redo) to console.

[I was going to do one level of undo. Then I thought, I'm not going to bother with undo. So of course, it has an unlimited undo buffer that compacts to words.]

4) Fixed drawing chat text if the console width was too narrow to display the whole line.

I have another batch of changes, but wanted to hit a check a "checkpoint" because I made heavy revisions to the console for auto-complete, console drawing and for undo. The auto-complete function in previous versions worked fine, but the code was embarassing cobbled together spaghetti caked on layer after layer that happened to work. 

Windows Open GL | WinQuake 

I dunno what you did between this release and the last one but music suddenly works!

Weeeeeeee..... 

I noticed that with developer 1 active the console gets spammed with messages about sound volume -

https://www.dropbox.com/s/33s43kepni4d7cc/mark_v_0000.png?dl=0 

I'm really happy your music works now! 

Cheers. This has replaced all my other engines now. I will still be using dark places too but only to make sure dark places is compatible.

Any reason why gl_texturemode settings don't save? It resets each load unless you set it in an autoexec.cfg 

It isn't a cvar. Fitz 0.85 it was a command.

[Quakespasm made it a cvar and has it save. I don't see that as something someone generally would touch except as curiousity and if they do, they wouldn't know the default value easily to restore it.] 

I can confirm that latest snapshot fixes screenshots with transparent statusbar for me.

Something else on my wishlist for quite a while is a sound resampler - especially useful if you set sndspeed 44100. I picture something like in ZDoom with its snd_resampler variable, letting you choose between "NoInterp", "Linear", "Cubic" and "Spline" modes.
Currently, I try to compensate the most annoying upsampling side-effects with converted sounds, but as we know, that's not a very elegant solution. 

the nice thing about MarkV using DirectX to play back the music is, the sfx and music are mixed together by the OS, not by MarkV. By using the default sndspeed 11025, you'll get very high quality upsampling provided by Windows, better than "Cubic" or "Spline" I'd guess.

In stock id quake, the lightning gun crackle is one of the only 22050Hz sounds, and I think everyone's used to hearing it downsampled to 11025. the need for a good resampler only comes into play if you want mix 11025 and 22050 sounds (in a mod, say), or mix 11025 with 44100 music in-engine (quakespasm does this). 

Good start. Now 2 of 3 known issues that I don't or can't experience are gone.

If someone with a 1080p monitor can see how the WinQuake version reacts to setting a screen resolution like 1920 x 1080.

I have another update with maxedicts gone (client always has 8192 edicts available, server will use 8192 edicts unless protocol is 15 (standard Quake) and in that case will use 600 for backwards compatibility), ericw's allocblock and double precision adjustments for lightmaps (even in the WinQuake version for the lightmap adjustments) and a few other things like fifth being annoying with developer 1 and changing mp3 volume printed.

I have dzip for .dz demos integrated in the current released build, but I don't have it doing anything yet.

I need to tweak the Nehahra handling a little and see if there is anything else I've missed. 

@ericw:
Really good advice with sndspeed 11050, thanks a lot! Didn't know that it actually sounds better with default setting. As you said, some sounds (not only in vanilla Quake, but also addons) have different sampling rates, but I guess this is a fair compromise.

I am about to finish my Travail tests. So far no issues. 

I can select the mode for 1080p, it seems to work in that respect but I can't tell if it's truly setting that as the resolution. I thought taking a screenshot would show the true res but the resolution of the .png file was 960x540 

Yep same here. I'd guess that's intended since Baker was talking about handling the problem thru scaling. It's funny that you get "fewer pixels" at 1080p than at 720p here, but if for whatever reason the renderer can't handle 1080p then pixel-doubling could be better than having to interpolate.

Is this what other SW renderers do at high resolutions? 

I loaded up Half Life and went to options->video and selected the software renderer, but my vertical resolution is 768 and it won't let me try higher.

Don't have Quake 2 installed at the moment to try that either.

[I did try to adjust by a percent initially instead of dividing by an integer, but the status bar was imperfect at some resolutions showing a line (WinQuake doesn't always draw the status bar, so it isn't quite a single surface.). So I went with the integer multiplication method because of that and the results should always be very predictable and I don't have to worry about stretching and such possibly looking bad at some resolutions, so it will look clean cut.] 

r_shared.h, change #define MAXHEIGHT 1024 to 1080.
1920x1080 works fine now, though it's pretty slow 

Touching that definition introduces a chain reaction that filters into the assembly language definitions and numerous things in the software renderer files.

That's way outside the scope of this project for me. 

didn't realize you were doing scaling.
The latest markv winquake build works well here @ 1920x1080.