That's basically what the original code in cl_tent.c already does - spawn an entity at the view model origin and update it's position each frame. What you're proposing just seems a more complex way of reproducing the same behaviour as is already there.

Part of the problem is that the view origin for the view entity is actually not the same as the view origin that's used for drawing. I haven't actually traced through this part of the engine code in sufficent detail to say more though. 

Sure, I did say it was messy. But it's qc only as opposed to needing engine changes. 

qbism has released a super8 with the ability to toggle the beams behavior ...

https://qbism.com/download/file.php?id=30

Presumbly the cvar is cl_truelighting 0/1, the same as JoeQuake/ezQuake/Qrack/etc. where a setting of 0 is Quake normal behavior. 

I tried qbism and I really like the look of the engine but ... fullscreen seems broken? My Windows task bar never goes away which is annoying. Am I alone on that? 

Cvar name is cl_beams_quakepositionhack 

What are the cvars that can be tweaked to make DarkPlaces look like software Quake? 

type in this -

gl_texturemode gl_nearest 

r_useanotherengine 1 

Doesn't make any engine look like software Quake. Software Quake had mipmaps but gl_texturemode gl_nearest will disable mipmapping. 

software quake didn't have mipmapping. This will remove all texture filtering and make it look oldschool.

Are you trolling? 

Of course software Quake had mipmapping. That was one of the cool features. 

Oh, I see, you're confusing mipmapping with filtering ... no, it didn't have texture filtering. But it DID have mipping. 

If you view a texture in TexMex, it will let you see the 4 mipmap textures it creates.

Any Quake texture wad has 4 levels of detail built into the texture.

WinQuake uses them. GLQuake did not use them and instead generates it's own mipmaps from the texture. 

gl_nearest_mipmap_nearest 

TexMex ---> open a wad --> select a texture and click View ->View Detailed.

The smaller images below the main image are the mipmap level textures. 

I guess I was confusing filtering and mipmapping as the same thing.

Basically I was helping the dude get the pixelly goodness. 

The workings of the software renderer aren't as well known to most as the GL engines.

Mostly because for maybe a decade, the WinQuake style engines were basically abandoned and forgotten.

Mankrip was probably the main person working on them (other than Spike) but MH did 2 big tutorials that really made them better (one was animation frame lerping). 

You guys seem to over-emphasize smaller differences in rendering from GL to Software. I mean, what most people really want, and notice, are the pixeled textures. And that's it. 

Without simulated 8-bit rendering (i.e. every pixel you see on screen is in the quake palette) I'd be reluctant to say it looks anything like software quake. 

The quake palette is not up to the task of rendering most modern maps which have been designed with coloured lighting. They look like garbage in anything but mark_v and quakespasm. 

 

I mean, what most people really want, and notice, are the pixeled textures. And that's it.

overbright lighting is hugely important. glquake doesn't support it, which is why everyone complained about it being "dark", and the idgamma fix which just wrecked the palette instead was ugly and didn't address the real problem.

metlslime began supporting it in fitzquake 0.70 or so. 

There's also R_DrawSurfaceBlock8_mip0, R_DrawSurfaceBlock8_mip1, R_DrawSurfaceBlock8_mip2 and R_DrawSurfaceBlock8_mip3.

nearest_mipmap_nearest looks fine, but nearest_mipmap_linear can look better; it retains the pixel crunchiness but gives a smoother transition between mip levels. Of course that's moving away from how software Quake looked again, but that's no bad thing IMO in cases where software Quake actually did look worse (is anybody really and seriously going to argue that particles that get smaller nearer the viewpoint look better, for another example).

Of course, some people confuse aliasing with detail, which is why some may actually prefer gl_nearest on it's own.

All that aside, the pixel crunchiness of software Quake has other advantages too, aside from just pixel-crunchiness for the sake of pixel-crunchiness. One of them is that the texture art is actually quite finely detailed down to a per-texel level to begin with, with a lot of those details being as small as a single texel. Look at the health pickup box textures, for example. When you blur those with linear filtering all of that fine texture art just turns into a mushy mess. 

The quake palette is not up to the task of rendering most modern maps which have been designed with coloured lighting. They look like garbage in anything but mark_v and quakespasm.

I'm sorry, but Quakespasm doesn't do anything special with either the Quake palette or with textures. It's just an absolutely standard 2x modulate blend using built-in GL functionality.