The WIP Thread

[InsanityBringer]

yeah, I guess I'm a little bad at spec reading. Reading the relevant VU a little closer does imply this is the case. feels like a weird thing to stick in a VU, but as mentioned it makes sense since the system already knows.

Now all I need to do is come up with some strategy for rendering the level that doesn't suck.. I have some ideas.

[Nash]

Forgot to post this here. Made a cover of the first boss music of that new Sonic game last week. :D I played (re-recorded) the instruments on this then sang over it, because no good quality instrumental-only version of the song existed at the time.

[InsanityBringer]

first pass of world rendering is going okay. Many bugs to resolve, features to add, and so on.

I added two lightmodes, one which is clamped and replicates the original GL renderer's lighting very closely, and one that is unclamped, allowing overbrights like software. The effect is striking. Comparison here. The effects of vk_modulate (analogous to gl_modulate) and the optional clamping are all done in the shader, so you can change their values on the fly without a vid_restart. (the intensity and gamma tables aren't done in shader yet, though)

[leileilol]

Quake2 lighting is a super subjective subject. I think gl_modulate (as it was implemented then) is evil and lossy. There was also 'intensity' which washed out textures. and there's a slightly different behavior regarding 3dfx where there's *less* intensity on the textures and there's proper screen gamma correction (1.7 usually). Only software had overbrights and its light values were normalized from RGB iirc. There was also inconsistent behavior with translucencies (software breaks on non-64x64 given they've derived off the old water turbulence span functions). and then you've got the fanbase that wants all the lighting off with extreme modulate settings.

The only time i've dabbled with Quake2's renderers was when:
- ref_gl : implementing nonpowerof2 textures (quake2 had a LOT of them), mono combine op lightmaps for software overbrighting (but not as much on the models as software did clamp model lighting)
- ref_soft: implementing RGB colored lighting out of Engoo but with precalculated gamma application to the rgb table so it has the 3dfxgl.dll visual balance many had. This also looked better for the palette as there's not a lot of range in there.

Yamagi does have software colored lighting these days but it is not my engoo techniques and looks weird and very bandy. Also their GL renderer's translucencies look very off (all the hit and smoke flashes look too bright and solid)

[InsanityBringer]

Honestly, having 3 individual user settings (intensity, vid_gamma, and gl_modulate) contribute to the lighting in a lossy, bit crushing manner is a rabbit hole I wasn't expecting when I started working on this (I didn't actually know what intensity did until I started working on this...). I'd like to move most of it to shaders so I can at least have more bits in the intermediate stages.

My reference was GL renderer, intensity 2 (the default, I think?), and gl_modulate 2 since that's what I always played with. At first I thought this would somewhat replicate software with my unclamped mode, since I assumed the colormap range is ~0x at darkest and 2x at brightest, but the intensity thing makes it too bright. Setting intensity to 1 is too dark, though, so I'll have to determine more closely what software is doing there.

Comparison here.. I just quickly poked the desaturation algorithm the software renderer uses (take the brightest channel) into one of my shaders for testing, but I'd like to support some sort of software lighting emulation as part of this project.

[Nacht]

I've been up to a lot and I mean a lot, I'll show off 2 projects I am working on now and some others later

---

(Sprites courtesy of Nexinita)

Schmetterling:


Cyborg Dog:

---

Vermillion Risen is a Doom 64 map pack with 3 maps and is meant to be a co-op experience it will feature the revenant and archvile, possibly more the enemies come at you hard from the get go but if you have a co-op partner you should be fine

Diabolo Vengeance:


Lost Luminous:

[InsanityBringer]

got transparent surfaces, warping surfaces (emulating the software warp behavior to some degree), and alias models working. Alias models were fun because I was able to get frame lerping work entirely GPU-side, which was fun to set up.
I also had fun learning that lighting of alias models is entirely different between software and GL. Software calculates the dot products for lighting at run time, while GL uses a table of fixed dot products, quantized to 16 different angles. I looked at the table to determine the light vector and range, and instead do the dot product in my shader so light moves smoothly when an object turns. I should probably tone down the overbrighting on objects, though..

But ugh, that junk floating in the sky on base100 is making me realize my attempt at clever world meshing hasn't quite worked. I'll have to work on it more.

[xenoxols]

Little mod I'm working on.

[Kinsie]

Little mod I'm working on.

Keep going, I'm listening...

[Dr_Cosmobyte]

I know that HUD from your works very well...
from one of your best works, actually.

[leileilol]

warping surfaces (emulating the software warp behavior to some degree),

My old experimental attempt at this (in GLSL) was something like this

Code: Select all

	vec2 txc_bad = gl_TexCoord[0].xy;
	vec2 txc_badder = sin((gl_TexCoord[0].xy*4) + (round(u_Time * 35)/35)) * 0.14;

	txc_badder = round(txc_badder*128)/128;
	txc_bad.x += txc_badder.y;
	txc_bad.y += txc_badder.x;

	vec2 txc_nearest = round(txc_bad * txsize.xy) / txsize.xy;	

sin with round to get the 64x64 turbulence

[Jay Two]

Forgot to post this here. Made a cover of the first boss music of that new Sonic game last week. I played (re-recorded) the instruments on this then sang over it, because no good quality instrumental-only version of the song existed at the time.

Fantastic job! Especially the vocals! I think it sounds better than the original, personally.

[InsanityBringer]

warping surfaces (emulating the software warp behavior to some degree),

My old experimental attempt at this (in GLSL) was something like this

Code: Select all

	vec2 txc_bad = gl_TexCoord[0].xy;
	vec2 txc_badder = sin((gl_TexCoord[0].xy*4) + (round(u_Time * 35)/35)) * 0.14;

	txc_badder = round(txc_badder*128)/128;
	txc_bad.x += txc_badder.y;
	txc_bad.y += txc_badder.x;

	vec2 txc_nearest = round(txc_bad * txsize.xy) / txsize.xy;	

sin with round to get the 64x64 turbulence

Interesting, my initial approach did similar but was using floors rather than rounds. I eventually decided to it all floating point for the best visual quality, but I saved off my initial iteration of the shader somewhere around here.. The current one looks like this

---

Code: Select all

#version 450

layout(set = 1, binding = 0) uniform sampler2D colorTexture;

layout(push_constant) uniform intensity_blocktype
{
	float inv_intensity;
	float time;
} intensity_block;

layout(location = 0) in vec2 outUV;
layout(location = 1) in float outAlpha;

layout(location = 0) out vec4 color;

void main()
{
	vec2 worldSpaceUV = outUV * 64;
	vec2 newUV = worldSpaceUV + vec2(sin((worldSpaceUV.y + intensity_block.time * 20) * 6.283185307 / 128) * 8, sin((worldSpaceUV.x + intensity_block.time * 20) * 6.283185307 / 128) * 8);
	newUV /= 64;
			
	color = vec4(texture(colorTexture, newUV).rgb * intensity_block.inv_intensity, outAlpha);
}

I need to finally get the intensity calculations working in shaders so I don't need to do the inv_intensity multiply here...

It's currently missing one thing that the software renderer has, where the sin table ranges from 0 to 16 rather than -8 to 8, offsetting the texture some. But the GL renderer doesn't do this, so that's just another decision over a renderer difference I need to make...

I did poke in a "fun" feature a few days ago to see if it would look any good.

Since I recorded that video, I made the effect additive rather than normal blending and added positions for the shotgun and supershotgun, complicated by a sequencing bug in the server dll that makes the first frame of all weapon firing sequences get skipped.

[xenoxols]

Some WIP bits.

[HopeMetal]

An FPS game I have been working on. Its a very early prototype level, hence the lack of actual textures (and crapiness in places where there are).