k8vavoom: no good thing ever dies!

[Remilia Scarlet]

Sweet!  Time to `git pull` and rebuild.

Spoiler

Like I do once a week anyway :-P

 

[ketmar]

2 minutes ago, Remilia Scarlet said:

Like I do once a week anyway :-P

please, be careful with that: sometimes i'm pushing something that can totally break everything. of course, you're definetely know that, but if other people want to have the "bleeding edge" self-built version... just remember that only "official builds" are more-or-less tested. each build is properly tagged, and you can use "git tag" to list all tags.

 

also note that devbuilds may mess with your config too.

[ketmar]

and a bonus: Zan: Jorney to Another Dimension. show those demons what The Real Demoness can do!

[TheGreenZap]

I replayed Unending by Remilla last night in K8VaVoom and it made a huge difference from playing it in GZDoom. 
The lighting, shadows and detail of the map really came alive.

[ketmar]

7 minutes ago, TheGreenZap said:

I replayed Unending by Remilla last night in K8VaVoom and it made a huge difference from playing it in GZDoom. 
The lighting, shadows and detail of the map really came alive.

thank you! i am really proud that such talented mapper made a map for k8vavoom. tbh, it's hard to ask for something better than this: Remilia's maps are artworks by themselves, and having such artwork made for k8vavoom is something i never really hoped to achieve.

Edited March 4, 2021 by ketmar

[TheGreenZap]

15 minutes ago, ketmar said:

thank you! i am really proud that such talented mapper made a map for k8vavoom. tbh, it's hard to ask for something better than this: Remilia's maps are artworks by themselves, and having such artwork made for k8vavoom is something i never really hoped to achieve.

 

I definitely understand that and I completely agree!

 

[Biodegradable]

Congrats on the release of the new build, Ket. :^)

[ketmar]

14 minutes ago, Biodegradable said:

Congrats on the release of the new build, Ket.

thanks! actually, if not the new map, i'd keep postponing the build more and more. so, the more map we'll have for k8vavoom, the more frequent releases will be. ;-)

[jval]

Nice work, congratulations for the release!

 

10 hours ago, ketmar said:

proper shadows:

  Reveal hidden contents

 

 

Damn, this is amazing! The visual output of source ports of the next decade is available right now!

[ketmar]

thank you, @jval!

 

but i want to add that the foundation work was done by Janis, in Vavoom. he did huge work cleaning up the code, separating modules, writing proper interfaces. Janis also created original lightmapped and stenciled renderers. i did alot of work too, but without Janis it wouldn't be possible. it was a joy to start with Vavoom codebase. let's not forget that original Vavoom was amazing, and it really was the most advanced Doom sourceport back then. it was slightly unstable, and had bugs here and there, but the amount (and quality!) of work Janis did was simply gigantic. and no good thing ever dies! ;-)

Edited March 4, 2021 by ketmar

[GRAU]

Man, could you implement back the softwarerenderer from Vavoom 1.30-1.31?  I loved it a lot. Another thing i would like to see is .kvx Voxel models. What doi you think about that?

[ketmar]

1 minute ago, GRAU said:

could you implement back the softwarerenderer from Vavoom 1.30-1.31?

no. Janis removed it for a reason. to make a long story short, it cannot be implemented as Quake-like span renderer anymore, it requires a full-featured rasterizer with z-buffer, and partial shader support. too much work for too little gain.

 

i may implement palette emulation in the future, tho. but don't hold your breath, this feature is somewhere at the bottom of the list.

 

4 minutes ago, GRAU said:

Another thing i would like to see is .kvx Voxel models

this is planned, but i can't give any estimates yet. while i like the look of voxel models, Ken's file formats are... let's say, they are less than perfect. KVX doesn't even have a signature for proper detection. also, voxel models are not very friendly for GPU rendering.

[GRAU]

No. thanks. I see no reason in palete emulation. i love only true siftwqare renderers, and i loved old vacoom...  But now the best ones are Q/LZDooms and Delphidoom i think. As for voxel rendering on GPU - The man who created voxelstein knew HOW to work with voxels in opengl. Astually SLAB6 siurce contains logics for rendering tonns of voxels on gpu - it uses one of opengl's i think, but i am not a coder, so a just say that THERE ARE gpu-friendly voxel renderers. EDUKE have one too!

[CorianderCastor]

@GRAU No love for cardboard (EE?)

[ketmar]

voxelstein is not using OpenGL. it is based on voxlap engine, which is pure software renderer. also, there is a huge difference between fully-voxel world (with occasional polygon models), and fully-polygon world with occasional voxel models. those are two completely different engine types, with completely different internal designs and rendering pipelines.

 

also, i didn't said that i don't know how to do it. i said that voxels are not GPU-friendly: even the simpliest voxel model has TONS of polys when converted (and such conversion is the only realistic way to render voxel models in hw-accelerated polygon engine).

 

this, again, is a question of time/efforts required vs benefits gained.

 

10 minutes ago, GRAU said:

i love only true siftwqare renderers

i can insert some empty loops into renderer, so it will be as slow as software one.

[Mr.Rocket]

/ hands everybody a cold beer..

Edited March 6, 2021 by Mr.Rocket

[seed]

21 hours ago, ketmar said:

i may implement palette emulation in the future, tho. but don't hold your breath, this feature is somewhere at the bottom of the list.

 

Ah, this fluff may be interested in such a feature 🦊.

 

But, do you think you can make it in the style of Build, enabling the use of the COLORMAP too? It's the sole reason I still switch to Software sometimes in Hexetic, because these games really benefit from it.

[ketmar]

2 hours ago, seed said:

But, do you think you can make it in the style of Build, enabling the use of the COLORMAP too?

that's why it isn't implemented yet. "paletize" the image in postprocess pass is quite easy, but i don't want such fake. ;-)

[seed]

Ah shit, seems I'll keep dreaming then 🦊.

[ketmar]

37 minutes ago, seed said:

seems I'll keep dreaming then

;-)

 

the main obstacle is that k8vavoom renderer still has its roots in GL1 days. it should be rewritten to use materials and "compound" shaders attached to textures, otherwise adding advanced rendering features will turn everything into uncomprehensible mess.

 

changing colormap, for example (like invuln does, or applying custom texture tinting) currently done by manually recoloring all the required textures on the CPU, and uploading them to GPU -- instead of simply using a custom recolor shader. "swirling" textures reuploaded each time too. and so on.

 

this should be rewritten to allow me to "construct" multistage material shaders, to allow freely combining things like "recolor this texture", "use swirl on it", "perform palette lookup", and so on. but this is a huge work (basically, i'll have to ditch the current texture manager and alot of rendering code, and rewrite it from scratch), so i postponed it. but i will eventually do that.

Edited March 6, 2021 by ketmar

[wallabra]

3 hours ago, ketmar said:

but this is a huge work (basically, i'll have to ditch the current texture manager and alot of rendering code, and rewrite it from scratch), so i postponed it. but i will eventually do that.

 

You could just toggle each one with a bit field.

 

if (render_flags & RFLAG_COLORMAP) do_sh_colomap();
if (render_flags & RFLAG_SWIRL) do_sh_swirl();
// ...

 

Now, sadly I don't know about operating textures in software while still benefiting from the hardware renderer's texture mapping. The only way I can think of to do that, is either caching a transformed texture and its mipmaps (boy oh boy, poor VRAM), or using shaders. Come to think of it, hardware pipelines are way too inflexible, and even in GL3+ using shaders can really be a performance hit AND an instant big bump on the minimum needed hardware.

[ketmar]

@Gustavo6046 current renderer does all that on CPU. but i need a way to do it on GPU, and to dynamically build texture combining code. and this will require rewriting shader manager code, texture manager code, and most of low-level rendering code.

 

k8vavoom already using shaders, and alot of them (the engine tries to use most effective shader for each case: i.e. for solid textures there is no need to check for transparent texture texels -- one less comparison; and so on). it is already barely manageable, and now imagine that each such shader (several dozens of them) will need to be written with each possible texture transformation case. of course, this won't work. i need a way to split shaders to "building blocks", and freely combine 'em. that's why i need to rewrite the whole thing.

 

the whole shader code is a mess now. at least i don't have to manually create shader interfaces, small GLSL processor will do that for me. before vshadpp it was almost impossible to touch shader code without introducing alot of errors to renderer.

[Firebrand]

Yesterday I player that map made specially for k8Vavoom, it was a pretty cool map! :D

 

But I want to ask about a strange thing I saw with the current shadowmap options, if I turn off shadowmaps completely, dynamic and static lights screw up, like if they get cut down strangely by map geometry, is that intended or is that a bug with the CVARS somewhere?

 

I also saw that decoration barrels in Heretic can be pushed around by the player and monster corpses, I don't think that's right, some debug thing left around? :P

 

I might come back with more bug reports when I finish setting up things myself. Nice work with improvements to the clipper, thought ;).

[ketmar]

3 minutes ago, Firebrand said:

if I turn off shadowmaps completely, dynamic and static lights screw up, like if they get cut down strangely by map geometry, is that intended

yes. the engine won't bother lighting subsectors that are invisible from the light source position. this way it is much faster to render shadows, and lights won't "leak" through closed doors and secrets. but the side effect of this is that without proper shadows lights will be "cutted" by subsector boundaries. as playing without shadows is not something i expect people to do often, i didn't tried to workaround that.

 

7 minutes ago, Firebrand said:

I also saw that decoration barrels in Heretic can be pushed around by the player and monster corpses, I don't think that's right, some debug thing left around?

Doom barrels can be pushed too. this is controlled by "gameplay options -> pusheable barrels". it is "on" by default because i like it this way. ;-)

 

8 minutes ago, Firebrand said:

Nice work with improvements to the clipper, thought ;).

not only that. ;-) most rendering code was heavily reworked and refactored (althrough i'm not finished with it yet). there are still clipping bugs, tho, and alot of room for improvement (more aggressive GPU-side geometry caching, for example). i'm not even half-way done. ;-)

[Firebrand]

7 minutes ago, ketmar said:

yes. the engine won't bother lighting subsectors that are invisible from the light source position. this way it is much faster to render shadows, and lights won't "leak" through closed doors and secrets. but the side effect of this is that without proper shadows lights will be "cutted" by subsector boundaries. as playing without shadows is not something i expect people to do often, i didn't tried to workaround that.

I see, so the right way to play is with the feature enabled and sprites set to "none" if I don't want to have sprite shadows? My main grip with the sprite shadows is that missile sprites do shadows and in my personal opinion it sucks! :P Could an option to "exclude" missiles from doing shadows be added to the shadowmaps?

7 minutes ago, ketmar said:

Doom barrels can be pushed too. this is controlled by "gameplay options -> pusheable barrels". it is "on" by default because i like it this way. ;-)

Ah, good to know, thanks!

7 minutes ago, ketmar said:

not only that. ;-) most rendering code was heavily reworked and refactored (althrough i'm not finished with it yet). there are still clipping bugs, tho, and alot of room for improvement (more aggressive GPU-side geometry caching, for example). i'm not even half-way done. ;-)

Interesting, let's see how things go with that :), keep up the awesome work!

[ketmar]

38 minutes ago, Firebrand said:

I see, so the right way to play is with the feature enabled and sprites set to "none" if I don't want to have sprite shadows?

yeah.

 

38 minutes ago, Firebrand said:

Could an option to "exclude" missiles from doing shadows be added to the shadowmaps?

yes, sure. i simply forgot to add the same set of options i did for "fake" shadows (a-la Duke3D). thank you, will add them for the next build.

 

38 minutes ago, Firebrand said:

keep up the awesome work!

thank you! with Remilia's maps we can get some more "visibility", and prolly even more mappers. isn't this what each sourceport developer wants? Vavoom *will* climb at the top of the sourceports hill again! ;-)

 

p.s.: implemented and pushed into git, why not. ;-)

Edited March 7, 2021 by ketmar

[Remilia Scarlet]

Some k8vavoom goodness ^_^  Some more shots in the "What are you working on?" thread.

[wallabra]

Wow, that is absolutely stunning-looking! I'm not sure which features exactly you've used (I am yet unfamiliar with k8vavoom and whatever sets it apart from other source ports), but what you did there really looks very nice! And,I can tell from how it looks it will probably play very nicely as well :)

[ketmar]

30 minutes ago, Gustavo6046 said:

I'm not sure which features exactly you've used

as far as i can see, this is brightmaps + strategically put lighting.

 

@Remilia Scarlet you really want people to switch to k8vavoom from other sourceports, don't you? this looks mind-blowing even on static screenshots! ;-)

[Remilia Scarlet]

37 minutes ago, Gustavo6046 said:

Wow, that is absolutely stunning-looking! I'm not sure which features exactly you've used (I am yet unfamiliar with k8vavoom and whatever sets it apart from other source ports), but what you did there really looks very nice! And,I can tell from how it looks it will probably play very nicely as well :)

Just a few well-placed point lights ^_^  The textures have some brightmaps, too.