k8vavoom: no good thing ever dies!

[inkoalawetrust]

I tried turning off decals, but it didn't seem to change anything. Also no I'm pretty sure this computer does have an Intel iGPU since it uses Intel UHD Graphics.

 

Also I still think that there should be some sort of alternative to rendering above and below the sky strips that doesn't look as awkward lol, even if it isn't neccesarily how ZDoom does it.

[ketmar]

also, to get weapons (or other items), you can do:

VScriptCommand give RocketLauncher

for example (it is easy to type with autocompletion).

it can give you anything, tho, even things that are not meant to reside in the inventory, so be careful.

 

also, you can try:

VScriptCommand fire DoomImpBall

to fire imp firebals and kill monsters without alerting others. ;-)

Edited May 31, 2021 by ketmar

[ketmar]

2 minutes ago, inkoalawetrust said:

I tried turning off decals, but it didn't seem to change anything

:-( but thank you!

 

3 minutes ago, inkoalawetrust said:

Intel iGPU

sighs.

 

3 minutes ago, inkoalawetrust said:

Also I still think that there should be some sort of alternative to rendering above and below the sky strips that doesn't look as awkward lol, even if it isn't neccesarily how ZDoom does it.

i may implement some alternate sky modes in the future. it's just not a priority now, and sky code is quite... let's say, it is messy. it is one of OpenGL1.1 era leftovers that should be completely rewritten. with the rewrite, i may implement other types of sky stretching too. what i meant by my answer is that it is not something i'm planning to implement in the nearest future (and that i enjoy its weird look ;-). i have plans to rework the rendering code to decrease amount of data k8vavoom has to transfer to GPU, though, but this is quite big amout of work (not only coding wise, but design-wise too), so i prefer to avoid adding hacks to rendering code for now (at least until it is strictly necessary).

 

so, your suggestion is not rejected per se, it is rather "put on hold" for now. ;-)

[inkoalawetrust]

17 minutes ago, ketmar said:

also, to get weapons (or other items), you can do:

VScriptCommand give RocketLauncher

for example (it is easy to type with autocompletion).

it can give you anything, tho, even things that are not meant to reside in the inventory, so be careful.

 

also, you can try:

VScriptCommand fire DoomImpBall

to fire imp firebals and kill monsters without them retaliating. ;-)

 

It may be a good idea to add a shorthand alias for VavoomC commands like give and fire like VSC give <actor> and VSC fire <actor>. To make typing it in faster.
 

12 minutes ago, ketmar said:

sighs.

I should probably add that I've never had these shorts of graphical glitches with L/GZDoom on any PC, except for that one time that on a PC that has OpenGL 4.6 and can run GZDoom, it couldn't really run LZDoom because of a similar bug, but with pitch black flickering polygons instead.

 

Though in this case the flickering is probably caused because as you said, K8Vavoom renders stuff differently from how games usually do it.

Also my favorite features in K8Vavoom are probably the pre-calculated lightmaps, the (proper !) dynamic shadowmaps, and the 3D polyobjects, especially the last two, since they can significantly improve how maps look, and give far more possibilities for stuff to do and add in them, such as being able to recreate the whole starting sequence of Half-Life.

But unfortunately those 3 are also things that will never be added to GZDoom. The lightmapping is the only thing that even had a chance of being implemented, but ZDRay ended up being scrapped.

[ketmar]

39 minutes ago, inkoalawetrust said:

It may be a good idea to add a shorthand alias for VavoomC commands like give and fire like VSC give <actor> and VSC fire <actor>. To make typing it in faster.

it is quite fast, i believe. just try:

vs<tab>g<tab>ro<tab>l<tab>

autocompletion rocks! ;-)

 

also, you can create aliases with:

alias name "commands"

if you want to, and even bind aliases to keys with "bind". just note that alias is not a macro, so it can't have arguments.

 

39 minutes ago, inkoalawetrust said:

I should probably add that I've never had these shorts of graphical glitches with L/GZDoom on any PC

GZDoom renderer is not even close to k8vavoom, they don't share a single root. so one may work, and another may fail. k8vavoom renderer is quite a beast, that sometimes does weird things due to it's OpenGL1.1 legacy roots. this is one of the reasons i want to redesign and rewrite it.

 

the thing is that most OpenGL drivers are only tested with modern games, and more obscure (and older) codepathes are either not tested at all, or tested very badly. k8vavoom is liberally mixing "new" and "old" modes, and it may hit some obscure part of driver code nobody bothered to properly test. so even something very simple and innocent may cause a glitch. GZDoom renderer is much closer to what modern game engines do.

 

39 minutes ago, inkoalawetrust said:

Also my favorite features in K8Vavoom are probably the pre-calculated lightmaps, the (proper !) dynamic shadowmaps

actually, lightmap tracer does texture checking too. you cannot see it becasuse lightmap resolution is small, with higher resolution lightmaps the image will be much closer to shadowmapped one. but increasing lightmaps resolution causes at least quadratic (and sometimes cubic) decreate of lighting speed. i.e. increasing lightmap resoultion by 2 will make everything slower by 2^2 (actually, closer to 2^2.6).

 

39 minutes ago, inkoalawetrust said:

shadowmaps, and the 3D polyobjects, especially the last two, since they can significantly improve how maps look, and give far more possibilities for stuff to do and add in them, such as being able to recreate the whole starting sequence of Half-Life.

not yet. ;-) i mean, you can, buth it won't be fun, won't be easy, and will be somewhat slow. i have some plans to improve things, tho. but it's too early to talk about those, i'm still in R&D phase. yet 3d polyobjects is the first step in that direction. it is more a proof-of-concept than the real thing. i mean, it works, of course, and works quite good, but it never was my final goal, only a first step to something bigger. ;-)

 

39 minutes ago, inkoalawetrust said:

But unfortunately those 3 are also things that will never be added to GZDoom.

3d pobjs are possible, i believe. i didn't checked GZDoom code that deep, tho, but if it works with the common "opening" concept (most modern ports do that, i believe), 3d pobjs can be implemented without touching most of the other parts. i tried to make 3d pobj specs as clear as i could, so other engines can implement them and be sure that the implementation is compatible.

 

(of course, i'd prefer to not see 3d pobjs in GZDoom, because this is one of the Killer Features of k8vavoom. but joking aside, i'd love to see other engines implementing this feature. i believe that it will be good for the community as a whole. ;-)

 

i think that when people will start making maps with 3d pobjs, GZDoom team will be forced to implement 3d pobj support. it just need somebody to do that first in some other engine (hi! ;-), and then some wads that will use that, and GZDoom users will start asking for the feature. ;-)

 

fun fact: floor decals are actualy much harder to implement in GZDoom than 3d polyobjects. k8vavoom doesn't care on which surface it should draw decals, but GZDoom code is written explicitly around solid walls. that's why you cannot put a decal on a 2-sided wall with a transparent texture in GZDoom (like the grates near the exit of E1M1 -- in k8vavoom the blood can be on those grates, but in GZDoom it can't, as far as i know).

Edited May 31, 2021 by ketmar

[inkoalawetrust]

6 minutes ago, ketmar said:

also, you can create aliases with:

alias name "commands"

if you want to, and even bind aliases to keys with "bind". just note that alias is not a macro, so it can't have arguments.

Oh right, I constantly forget the alias and bind commands even exist in L/GZDoom.
 

12 minutes ago, ketmar said:

not yet. ;-) i mean, you can, buth it won't be fun, won't be easy, and will be somewhat slow. i have some plans to improve things, tho. but it's too early to talk about those, i'm still in R&D phase. yet 3d polyobjects is the first step in that direction. it is more a proof-of-concept than the real thing. i mean, it works, of course, and works quite good, but it never was my final goal, only a first step to something bigger. ;-)

I mean honestly even in their current form and with their caveats, they are far better than what you can do in GZDoom, the closest thing you can make to a 3D polyobject in GZDoom is a grid of polyobject 3D middle texture lines, and if you even stand on top of it you vibrate and just bounce right off at 80 km/h. And something like a moving, enterable train can only be done by a twosided polyobject with portals on it, and it works really poorly at best, as it totally breaks the AI and sound.

 

53 minutes ago, ketmar said:

3d pobjs are possible, i believe. i didn't checked GZDoom code that deep, tho, but if it works with the common "opening" concept (most modern ports do that, i believe), 3d pobjs can be implemented without touching most of the other parts. i tried to make 3d pobj specs as clear as i can, so other engines can implement them and be sure that the implementation is compatible.

I would hope they are, but when I asked phantombeta yesterday about it. I was told that it can't be easily done due to Doom's wonky actor physics and collision.

 

54 minutes ago, ketmar said:

i think that when people will start making maps with 3d pobjs, GZDoom team will be forced to implement 3d pobj support. it just need somebody to do that first in some other engine (hi! ;-), and then some wads that will use that, and GZDoom users will start asking for the feature. ;-)

 

fun fact: floor decals are actualy much harder to implement in GZDoom than 3d polyobjects. k8vavoom doesn't care on which surface it should draw decals, but GZDoom code is written explicitly around solid walls. that's why you cannot put a decal on a 2-sided wall with a transparent texture in GZDoom (like the grates near the exit of E1M1 -- in k8vavoom the blood can be on those grates, but in GZDoom it can't, as far as i know).

I would REALLY hope that is the case. But honestly I doubt they'd be very willing to try adding such a thing even if a bunch of people requested it and not just me.

Also I'm not too sure if decals on planes would be harder to implement in GZDoom than 3D polyobjects, since I think there's more of a desire and push to add the former on GZDoom from the developers than 3D polyobjects. But that may just be because any focus on mapping features seems to have just fallen by the wayside on GZDoom.

[ketmar]

5 minutes ago, inkoalawetrust said:

I would hope they are, but when I asked phantombeta yesterday about it. I was told that it can't be easily done due to Doom's wonky actor physics and collision.

i thought that too. but i found it much easier than i thought. ;-) it may be harder in GZDoom due to more hacks in the code, but it's still not that hard, i believe. just need somebody with a good knowledge of (GZ)Doom physics code (now THIS is the problem, i believe! ;-).

 

44 minutes ago, inkoalawetrust said:

Also I'm not too sure if decals on planes would be harder to implement in GZDoom than 3D polyobjects

implementing non-solid-wall decals in GZDoom will require some major changes in renderer. currently, GZDoom clips decal polygon to a wall, and renders it on top of the wall with a small Z offset (to avoid z-fighting).

 

and k8vavoom doesn't do any clipping at all. no math involved, literally. k8vavoom is using stencil buffer to mark all surface pixels, and then simply renders the whole decal poly with stencil test. that's why it can draw decals on transparent textures -- transparent pixels simply not marked as belonging to a surface, so nothing is drawn there. this way, i was able to completely skip most complex math calculations (proper polygon clipping by another polygon is not that hard, but it's not very easy too), and properly render decals on any surface, with any orientation, and with any texture. this is slightly slower than what GZDoom does, but the flexibility is... eh, just look at screenshots! ;-)

 

it is possible to implement it like that in GZDoom too, but i'm not sure that stencil buffer is not used for something else there, and even if it isn't, it will still require some changes in renderer code. also, it may interact badly with lighting, SSAO and FXAA. while implementing 3d polyobjects can be isolated in several places where physics is done.

 

that's why "non-wall decals feature requests" were rejected time and time again in GZDoom.

 

tbh, when i wrote decal code, i wanted to do it with minimum efforts, and i absolutely HAET doing math. so i cheated with stencil buffer. it was intended as a proof-of-concept solution that will be replaced by a proper polygon clipping later, but i found that my PoC code is not that bad after all, so i left it as is. and then i realised that i can do decals on transparent textures with it, and basically on any surface with any texture with holes. the only missing part for non-wal decals was some high-level code that will assign decal polys to subsectors and floor/ceiling surfaces. once i wrote that, the renderer did the rest.

[dpJudas]

The stencil buffer in GZDoom is indeed already in use by the portal clipping code. I think the easiest way to implement transparent pixel decals in GZDoom would be to pass in the wall texture as a mask texture to the shader drawing the decal.

 

And that is also why you will probably never see this feature. The design of the renderer backend is at the very limit of what is possible without a major refactor of how it deals with vertices, shaders, uniforms and textures. Not only would such a change require a significant amount of work, it would also have to be compatible with the Build engine now that Raze utilizes the same backend. That means even if you could find the developers willing to commit to do that kind of improvement to the engine, there would be a high chance of the work being rejected by the GZDoom project unless it also is implemented exactly like Graf would like it to be.

[Teo Slayer]

I never used k8vavoom source port :/

[ketmar]

4 minutes ago, Teo Slayer said:

I never used k8vavoom source port :/

it is never too late to try! ;-)

[Teo Slayer]

Just now, ketmar said:

it is never too late to try! ;-)

Ok, is it like GZDoom?

 

[ketmar]

3 minutes ago, Teo Slayer said:

Ok, is it like GZDoom?

of course, it is better! why else would i develop it instead of simply using GZDoom? ;-)

[Teo Slayer]

4 minutes ago, ketmar said:

of course, it is better! why else would i develop it instead of simply using GZDoom? ;-)

Does it lag?

[ketmar]

7 minutes ago, Teo Slayer said:

Does it lag?

of course! its lags are bigger and better than in GZDoom! ;-)

 

joking aside, GZDoom renderer is faster, and GZDoom does slaughtermaps better. so maps with alot of details are slower in k8vavoom, maps with alot of active monsters are slower too. and advanced lighting doesn't come for free. but the only way to know if it is good for you is to try, i think. it is free after all. ;-)

[ENEMY!!!]

I've been working some more on BDLite for k8vavoom and have found something with the bouncing code - am I right in thinking that it doesn't calculate angles and acts as if walls are all at 180 degrees to the impact?  I noticed this with DavidN's flak cannon, which in GZDoom has flak shards that ricochet off walls and, with some skill, can be used to kill monsters from around corners, but in k8vavoom the flak shards just head straight back at the player regardless of the angle of impact with walls and so it isn't possible to kill monsters from around corners.

 

If this isn't circumventable I could replace the flak cannon with something else with similar niche appeal for the k8vavoom version, but wasn't sure if this is a bug or a fundamental difference in the engine.

Edited June 1, 2021 by ENEMY!!!

[ketmar]

5 hours ago, ENEMY!!! said:

and have found something with the bouncing code

td;dr: it is something i want to fix, but i don't know when (or even how ;-).

 

tbh, the bouncing code is a broken mess. it should calculate proper angles and such, but currently nobody knows what it does. bouncing and ripping code are two most messy parts of the engine, i mostly didn't touched them (except some obvious (crash)fixes).

 

i'm somewhat afraid to touch that code, because each time i tried, something went wrong.

 

if you will create a very minimalistic decorate, and step-by-step instructions to test it, i may fix it faster. ;-) BDLite code is quite good, but the smaller test code is, and the clearer instructions are -- the easier for me keep track of it. i am often choosing bug to fix on "do i have a way to reproduce it without running a whole mod, and oh... what was the bug? ah, here's what to do to see it!" basis. it can be a one projectile actor (i can use "VScriptCommand fire actorname" to fire it), and something like: "stand here, look there, shoot, it should do that, but does this instead". thank you!

 

p.s.: i am asking for this also because it may be not a bouncing code at all. it may be a wrong firing angle or something, for exampel, or some other subtle difference, and "hand-lanuched" projectile may work. etc. so preparing a minimised sample helps to be sure that the bug is really where we think it is.

[ketmar]

i completely reworked the specs for bootprints.

 

now you don't need to manually create new decal for each new bootprint type: you only need to create a default bootprint template, and the engine will use it with the shade/translucency/animator set in bootprint definition.

 

i.e. you only need to draw a base bootprint decal, and any mod with bootprint support can define it's own bootprint shades for its flat types, then it will Just Work.

 

also, bootprint template decal now specified in PlayerPawn actor. it means that your mod can have several actor classes, each with unique bootprints. i will prolly add some DECORATE API later to change/enable/disable bootprints, so you'll be able to implement different boot types. ;-)

 

or you can redefine default "BaseBootPrintDecal" in decaldef to change the default decal for DoomGuy, if everything you need is a simple graphic change.

[ENEMY!!!]

Here's a version of what I have that I've trimmed down just to the flak cannon, and I've tested it to make sure that it works as intended in GZDoom but not in k8vavoom:

flakcannon.zip

To get the flak cannon just use the all weapons cheat and go to slot 7.

[ketmar]

On 6/2/2021 at 12:22 AM, ENEMY!!! said:

Here's a version of what I have that I've trimmed down just to the flak cannon

thank you! still too much code, so it'll have to wait a little. i'm not blaming you, i know that it is hard to extract the required code even from the good-written mods, and you already made my work much easier. yet i will still have to strip it even more, so it may take some time. don't get me wrong, please, you prolly wouldn't do it better without knowing the engine internals, you already helped me alot!

 

p.s.: again, this is a huge "thank you" for helping. i tried to explain what i have to do with all this, and it may look like i'm  telling you that you didn't do enough work for me. of course, it's not what i meant. ;-)

Edited June 5, 2021 by ketmar

[ketmar]

On 5/9/2021 at 1:15 AM, Gunrock said:

Perfect time to use it on my upcoming Project Slipgate: Remastered.

the next build will also have built-in footstep sounds and bootprints. i'm sure you'll find some creative ways to use those. ;-)

 

yeah, i'm thinking about allowing to put those in a separate lump, so other ports will simply skip them.

[Mr.Rocket]

Hey, I'm thinking about going ahead and releasing that k8vavoom Launcher I've been working on when I had time.

But I'm wanting to figure out the best way of going about it. I mean I could put it in this topic since it's a launcher specifically for k8vavoom, but I don't want to bloat up the threads with random feed back about the launcher here. So I'm thinking of just setting up a small web page about it, maybe a blog type, not sure, but at least feed back, if any, could end up there instead. 

 

What do you think?

 

Thanks

[ketmar]

@Mr.Rocket i think that you can simply create a new topic here on DW, and ping me. i will then put it to the OP and here, and will tell people that they should use your topic for feedback/bugreports/etc.

[Mr.Rocket]

Ok sounds good.. I'll pm you when I've posted up about it if you haven't already seen it already.

 

Thanks!

[ketmar]

note: i'm off for a week. i don't think that i'll read the forum, or would be answer any questions on IRC. sorry. but i'll be back. ;-)

[Remilia Scarlet]

Enjoy your break!  You definitely deserve it :D

[Teo Slayer]

Have a nice break bro

[terminator]

enjoy your break, ketmar :)

[Zylinderkatze]

Enjoy break time, ketmar!

[ketmar]

thank you all!

 

and while i'm still here (not for long ;-), here is the k8vavoom launcher by @Mr.Rocket. it is written especially for k8vavoom, knows k8vavoom specific options, and Officially Blessed. give it a try, you may like it! and feel free to write your opinions/bugreports/requests in that thread!

 

thank you, @Mr.Rocket!

[Mr.Rocket]

Hey np, and thank you for the Official Blessing :P

Maybe at some point I can update it and add an option to load iwads from any location. And maybe a long way off there could be a small server scanner.

Either way, you're welcome, and I hope it will be a useful tool for everyone!

 

See ya when you get back! ;)