Quake2 ports with focus on the software renderer?

[JasonX]

Aside from qfusion, do you guys know any other Q2 ports focused on the Software Renderer?

[leileilol]

Nope.

I was going to enhance ref_soft as a contribution to r1q2 but there wasn't any interest. All I did was get software colored lighting working.



Unfortunately due to how Q2BSPs are made and how the gamecode works, there isn't that much room for porting Engoo features over to Q2. No special bobbing, no autosaving, no enhanced model lighting because light entities are left behind in compiling...


Also this colored lighting attempt isn't identical to Engoo - I had to do some shifting and gammaing to get it 'on level' with a 3dfxgl player since they had high gammas, that and quake2 doesn't have a lot of dark shades in its palette.

[qbism]

FTE rendered Q2 in software way back. IIRC last version was in 2008.

Fake software rendering, simulated with Berserker Q2 set to gl_nearest and low resolution. So this is actually hardware rendered just to be clear.

[qbism]

AROS Q2 has a few ref_soft improvements [url]bszili.morphos.me[/url] including waterwarp aspect correction and dithered texture smoothing. Although not implemented, the code implies there's a stereo3D ref_soft somewhere on the internet, and that a version of Q2max has ref_soft enhancements like (one of my favs) stainmap. Although stainmap and perhaps some others can also be seen in FTEQW software engine.

[qbism]

Engine work in-progress, showing SMD mod.



[edit: fix image links}

[leileilol]

Unfortunately Q2's palette really fringes with overbright colored lighting. Try shifting the lightmap down to the "QUAKE2 TOO DARK!!!" levels.


Also, you might get an inspiration from SIN's software renderer. That had map-only colored lighting, but it also utilized per-level palettes with per-level color lookup tables for it. All the textures (including 2D) get converted to the level's palette on the fly (leading to some infamously long loading times)

[jitspoe]

[qbism]

The fact that gamma was turned way up for the screenshot doesn't improve the appearance. But colors in dim areas always fall back to the same few dark greens and dark reds. It may be a benefit to increase minimum ambient light and/or reduce saturation of colored light at load time (perhaps with a cvar). Or increase sensitivity to color differences when building the table, cubed distortion rather than squared.
Per-map palette loading makes sense but probably, yeah, would avoid remapping every texture.

[Spike]

regarding gamma, would it not be possible to factor the gamma values into your blends? might seem less extreme that way.

[qbism]

[qbism]

...here's a ref_gl (hardware opengl) render for comparison. Texturemode = gl_nearest. This screenshot was brightened to get closer to the (non-adjusted) ref_soft screenshot above.