The WIP Thread

If it's not ZDoom, it goes here.
User avatar
InsanityBringer
Posts: 3367
Joined: Thu Jul 05, 2007 4:53 pm
Location: opening the forbidden box

Re: The WIP Thread

Post by 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.
User avatar
Nash
 
 
Posts: 17326
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: The WIP Thread

Post by 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.
User avatar
InsanityBringer
Posts: 3367
Joined: Thu Jul 05, 2007 4:53 pm
Location: opening the forbidden box

Re: The WIP Thread

Post by InsanityBringer »

Image
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)
User avatar
leileilol
Posts: 4435
Joined: Sun May 30, 2004 10:16 am
Preferred Pronouns: She/Her
Location: GNU/Hell

Re: The WIP Thread

Post by 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)
User avatar
InsanityBringer
Posts: 3367
Joined: Thu Jul 05, 2007 4:53 pm
Location: opening the forbidden box

Re: The WIP Thread

Post by 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.
User avatar
Nacht
Posts: 2
Joined: Wed Nov 09, 2022 3:17 pm

Re: The WIP Thread

Post by 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
Spoiler: Wolf 3D Chalice of Glory
Spoiler: Doom 64: Vermillion Risen
User avatar
InsanityBringer
Posts: 3367
Joined: Thu Jul 05, 2007 4:53 pm
Location: opening the forbidden box

Re: The WIP Thread

Post by InsanityBringer »

Image
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.

Return to “Off-Topic”