k8vavoom: no good thing ever dies!

[ketmar]

54 minutes ago, Graf Zahl said:

GZDoom is a hobby for me

sure, like k8vavoom for me. yet you are still thinking like a "pro" -- it is almost inevitable after working in the industry (programming) for decades. ;-)

 

54 minutes ago, Graf Zahl said:

Of course, love of experimenting with new things played a large role as well.

yeah, this is a great stimulus. yet for me (as i already wrote) working with gfx is "necessary evil".

 

also, k8vavoom project goal is to produce the engine ketmar will like, and the engine ketmar can use to play doom. no more, no less. ;-) making it good for other people is secondary goal (sorry, mates! ;-). i don't like the way GZDoom is going (i am not saying that it is wrong, no! i just don't like it -- tastes differs ;-), and i also like vavoom, and nobody else seems to work on vavoom, so i took it as a foundation.

 

of course, i sometimes like to write "eat this, GZDoom!", but this is just a joke, a nod to a leader, sign of respect. ;-)

[dpJudas]

The main thing that will probably make me prefer Vulkan for future projects is more about which has the least cons. The way I see the cons of the various graphics APIs:

 

OpenGL 1.0 - 2.0:

1) Too many global states that needs to be set. Works totally against trying to make code modular as the state leaks everywhere

2) 90% of the stuff it manages (i.e. light, matrices and texture units) is built around very old light models (70's to mid 90's) and it doesn't map at all to anything newer or different.

3) Shaders and frame buffers are barely supported

 

OpenGL 3.0 - 4.4:

1) Still global state hell

2) None of the vendors ever managed to write a compliant GLSL compiler. It is a mine field where I had to learn carefully to avoid typing things like I would otherwise have done.

3) Intel and Microsoft. First one by their amazingly awful drivers, the second by treating it as abandonware as it competed with their own Direct3D alternative.

 

Direct3D 11:

1) Windows only

2) HLSL is ugly and has weird semantics. On the plus side the compiler is maintained by Microsoft so at least you don't have to worry if 1 vs 1.0 will compile or not as for OpenGL GLSL. But it is still HLSL.

3) Some of the nice-to-have features in OpenGL are not there. You have to code it yourself.

 

Vulkan:

1) Initial setup costs stupid high. (but at least know I know them and don't have to pay this cost again)

2) Very limited sources of documentation. Almost as if the vendors and a short list of engine developers communicate directly and the rest can just wonder what the intent was with something in the standard.

3) Validation layer not very good. Makes debugging frustrating. Describing render passes is no fun either.

 

In short: none of them are remotely ideal, but I prefer Vulkan for now as its cross platform while having left the disadvantages of OpenGL behind. OpenGL 4.5+ would have been a good alternative, except knowing its hardware vendors I can wait until 2075 before Intel users abandon their older hardware required for me to use it.

[Graf Zahl]

26 minutes ago, dpJudas said:

3) Intel and Microsoft. First one by their amazingly awful drivers, the second by treating it as abandonware as it competed with their own Direct3D alternative.

 

You forgot to mention AMD and Apple here.

 

AMD for never releasing a stable and performant driver for the core profile and Apple for actively sabotaging OpenGL by first not supporting it properly and then for deprecating it in a very shitty state on their platform.

 

So, to sum it up, that makes 4 out of the 6 biggest players in this field (GPU and OS providers) that treated it like shit - with 3 out of these four doing active damage. Microsoft doesn't count here because their actions were merely passive.

 

I think the damage done by Apple and AMD vastly eclipses Intel and Microsoft. Intel's fault was mainly to be too late with capable hardware, but at least they are there now. AMD, on the other hand, has never ever managed to release an acceptable OpenGL driver for Windows and this is what really kills all momentum, because it's a given that it will run like shit on AMD. And Apple with their now deprecated GL 4.1 implementation would ensure for all eternity that the code base couldn't get upgraded without abandoning their shitty platform.

 

 

Edited March 27, 2019 by Graf Zahl

[ketmar]

aaand, another public build is here!

 

WARNING! IN CASE OF CRASHES, TRY TO RUN WITH "-nomusic" COMMAND LINE ARGUMENT, AND IF IT STILL CRASHES, TRY "-nosound". THIS IS KNOWN PROBLEM, AND I AM WORKING ON IT. THANK YOU.

 

* fixed bug in prebuilt glnodes loader
* fixes in advlight clipper
* advlight mode is even faster: now i get 70+ FPS at E1M1 start; and it was ~40 before; there are some bugs, tho
  (some lights can skip shadows), but 70+ FPS is worth it!
* fixed almost decade-old bug with entities stucking in ledges on game loading
* slightly better ACS timing; added GZDoom ACS HUD workaround (so some ACS-based HUDS will flicker less)
* added optional built-in monster healthbar
* fixed bug in `A_RemoveChildren` (tnx, id0!)
* added some UI options for stencil shadows (options -> video -> advanced)
* fixed bugs in checkpoint loading
* and even more advlight improvements -- 80/140 FPS at E1M1, and much less FPS drops when there are many light sources visible
* many lighting improvements, both in lightmapped and in stenciled renderers (especially, two-sided walls are better lit now)
* shader code was badly messed, which caused some heisenbugs (and could even glitch/hang some GPUs)

* anisotropic filtering can work in "nearest" texture filtering mode, so turning on aniso filter won't force texture filtering mode anymore

WARNING! clipper is partially broken, so expect hiccups and slowdowns on big/detailed maps! (and there can be gliches with polyobjects/3d floors).
 

please, do not use official vavoom 3d model packs if you want to play with model shadows turned on! it will work, but... i will release updated packs later, splitted to sets, with instructions how to use only subset(s) you like.

 

 

p.s.: also, two screenshots. people loves screenshots (and me too)!

advanced lighting with shadows from 3d models

blood on two-sided walls with masked midtexture

Edited March 29, 2019 by ketmar

[ReaperAA]

Bad news. The new build is very crash prone in my case. It always crashes right at the start of E1M1 for me. Sometimes it even crashes when trying to access the menu.

 

My specs: (in case if they are helpful)

- Dell Inspiron 5570

- OS: Windows 10 64-bit (Build 17134)

- CPU: Intel i5 8250U

- iGPU: Intel HD 620

- Dedicated GPU: AMD Radeon 530

[ketmar]

can i see your config (config.cfg), and conlog.log? it may help.

 

(of course, i found a "theoretically crash bug" immediately after i uploaded the build; but it shouldn't crash right away ;-).

 

p.s.: thank you for your report. from some PoV, immediate crash is good news, as we can easily check if it is fixed.

[ReaperAA]

Here u go

files.zip

[ketmar]

@ReaperAA thank you. is it still crashing in windowed mode? also, will it crash if you'll add:

r_level_renderer "2"

to config.cfg?

 

also, can you install windows version of GDB (you will prolly need to install MinGW to get it), please? if you want to dive into this, i'll give you a binary with debug symbols, so i can get backtrace to see where exactly it crashes. of course, it is not required, but if you have some time to make your hands dirty, it will help alot. i don't have windows installed, and with Wine it works, so the only way we can find it fast enough is to debug on your box. sorry.

[ReaperAA]

34 minutes ago, ketmar said:

@ReaperAA thank you. is it still crashing in windowed mode? also, will it crash if you'll add:

r_level_renderer "2"

to config.cfg?

 

It still crashes. Also u will have to wait for some hours before I get to have my "hands dirty" as I have to leave home for some important personal stuff

[ketmar]

5 minutes ago, ReaperAA said:

Also u will have to wait for some hours before I get to have my "hands dirty" as I have to leave home for some important personal stuff

sure, no problems, it is not urgent.

 

also, can you try to run it with "-nosound", please? my friend reported problems with timidity (and it may be true, it is glitchy af). if it will work with "-nosound", we may skip gdb step. ;-)

[ReaperAA]

1 hour ago, ketmar said:

also, can you try to run it with "-nosound", please?

 

It worked. Its no longer crashing with -nosound parameter.

[ketmar]

10 minutes ago, ReaperAA said:

It worked. Its no longer crashing with -nosound parameter.

great! i mean, it is bad, but i know who's to blame. ;-) for now, you can play with "-nomusic" -- this will turn off timidity, but you'll still get normal sounds. not a real solution, but at least something. thank you for you report!

 

it looks like the best way will be to steal GZDoom music code. i don't like it (it is too intrusive), but i don't want to roll my own too. too bad that there are no other easy-to-use SF2 midi renderers besides timidity and fluidsynth. timidity rox, but old, and glitchy. and fluidsynth is too complex: my quick try to use it failed.

[ReaperAA]

Another bug discovered. See screenshot.

 

 

In E1M1, after getting to the balcony secret area and looking at the nukage area, this is what I see. However after dropping down, area becomes visible again.

[ketmar]

thank you! yeah, the clipper is totally fucked: it fails almost at random. you can play with clipper options in options -> clipper debug (warning! they are not permanent!) to make it go (at the expense of some speed on bigger maps; but it is broken anyway).

 

i know about rendering glitches, but i felt that i should give people something new to play with, even if it is glitchy. besides, having glitchy public build can better motivate me to solve those bugs. ;-)

 

i really have to rewrite/fix this code, and frustum code. now i almost done with stenciled lighting (at least there are nothing more i can do to make its performance much better -- no more 38->130 FPS jumps ;-), i will prolly start ironing out clipper bugs.

 

sorry for broken builds. i am doing my best to avoid that, but sometimes it is hard.

Edited March 29, 2019 by ketmar

[therektafire]

2 hours ago, ketmar said:

great! i mean, it is bad, but i know who's to blame. ;-) for now, you can play with "-nomusic" -- this will turn off timidity, but you'll still get normal sounds. not a real solution, but at least something. thank you for you report!

 

it looks like the best way will be to steal GZDoom music code. i don't like it (it is too intrusive), but i don't want to roll my own too. too bad that there are no other easy-to-use SF2 midi renderers besides timidity and fluidsynth. timidity rox, but old, and glitchy. and fluidsynth is too complex: my quick try to use it failed.

Can you not use something like Bassmidi or Coolsoft Virtual Midi Synth (and the midi mapper addon if you're using windows 8+)? I've been using CVMS as my default midi device for a couple of months now and i really like it. And Droidsound E uses Bassmidi for midi playback and it works great as well.

[ketmar]

the problem is that everything should go through k8vavoom sound system. that is, no external midi players allowed; the only option is some synthesizer library that is producing PCM samples i can feed to k8vavoom sound system. that is The Rule i won't violate. but there are only two such FOSS synthesizers out there, alas. one is old and glitchy, and one is so complicated to use it the way i want, that i still cannot implement it. ;-)

 

anyway, non-FOSS solutions are out of question. that is, i may include patches for them if someone will write that code, but i won't write it myself, and will throw those patches away the moment they will start creating problems. sorry.

 

also, i don't have windows at all. tbh, one of the first things i finished is complete removal of windows supporting code from vavoom codebase. ;-) now it works on windows only due to SDL2/OpenGL/OpenAL/sockets are cross-platform solutions. i.e. it "just works". i cannot debug windows-specific code, so i won't include it. if i'll get windows-based developer into k8vavoom team, it may change, but until that happens -- alas.

 

don't take it as "war declaration" against windows, though: i just don't have enough resources (and motivation, tbh), to invest my time in something i can neither use, nor debug. let's hope that someday some windows developer will join to solve windows-related problems, and write better windows supporting code. ;-)

[Gunrock]

Thanks ketmar!!! Great work!!!

[ketmar]

more news. first, i found and fixed stupid bug in clipper i introduced earlier, so clipper is working again.

second, two screenshots for you to compare:

first,

and second.

if you think that this is brightmap support in the upcoming build... well, you're right! ;-)

[ketmar]

i also implemented MD3 model loading. no, "modeldef" is not implemented. i am not sure if i'll implement it at all -- i don't like the way it's done, and it does things upside-down (regarding to how vavoom does model definitions). maybe i'll release a standalone converter to vavoom model defs later, though.

[Gunrock]

3 hours ago, ketmar said:

i also implemented MD3 model loading. no, "modeldef" is not implemented. i am not sure if i'll implement it at all -- i don't like the way it's done, and it does things upside-down (regarding to how vavoom does model definitions). maybe i'll release a standalone converter to vavoom model defs later, though.

Does this mean that "Qstuff Ultra" pack will work with Vavoom?

[ketmar]

7 hours ago, Gunrock said:

Does this mean that "Qstuff Ultra" pack will work with Vavoom?

if you  rewrite gzdoom modeldefs to vavoom xml definitions. it is not hard, but still require manual work: gzdoom defines class replacement, and inside that replacement it defines models, but vavoom defines models, and inside model definitions it sets class replacement. if you will simply use gzdoom modeldef as is, vavoom will load new model for each replaced frame (even if it already loaded that model). i like vavoom way, of course. ;-)

 

i'll try to write a simple tutorial on how to do that later (and how to define vavoom models -- there are alot of things you can do, vavoom is very flexible, but you will hardly find it out without reading c++ code. and yes, k8vavoom has some extensions to vanilla vavoom model defs -- like you can replace sprite frames by name now, and you don't have to specify full path to model file, k8vavoom knows about path to current xml, and will use it ;-).

 

 

also, i must apologize to Janis: almost everything i wrote about model code was wrong. that code is actually well done, and it was used MD2 data directly only in one function, which looks like a leftover from early implementation. i only implemented binary data parsing, and voila -- MD3 is working.

 

 

p.s.: also, i implemented old gzdoom "glow" effect. tbh, it is not really fun without control knobs, but why not? maybe i'll add knobs later.

Edited April 3, 2019 by ketmar

[ketmar]

teaser screenshot: ambient light off (yes, k8vavoom has this feature built-in, no need to write any mods! ;-), brightmaps on, experimental flashlight on.

 

Spoiler

 

[ketmar]

...and in action, both in lightmapped, and in stenciled modes: let's disco!

[Khorus]

Looks great! The brightmaps really pop with the lighting. Will we just have to bind the flashlight to a new key in the menu?

[ketmar]

45 minutes ago, Khorus said:

Will we just have to bind the flashlight to a new key in the menu?

yeah. i thought, "'cmon, why not? we are already so far from vanilla mode, it won't hurt". ;-) i mean, i need a simple way to test spotlights, so i put that into main codebase, and there is no reason to make everyone's life harder by requiring Yet Another Mod.

 

of course, one can custimise flashlight with cvars. but i still don't have good color selection widget, so there are some small problems with making it custimisable from UI yet.

[ketmar]

also, i implemented experimental monster movement interpolation. while the engine itself is lock-free, and physics-driven movement is interpolated "for free", monster movement is a different thing: they are moving by discrete steps, in state machine (decorate) actions. this cannot be changed without breaking game logic in various ways, so i implemented movement interpolation instead. there may be some overlooked subtle bugs, but it mostly works, and the visual difference is striking. of course, you can switch it off in video options menu, if you prefer old "jumpy" movement.

 

and while i was at it, i implemented smooth weapon bobbing and raising/lowering. this is the same thing as with monsters: in the original code, psprite movement done only in decorate actions, so i cannot enjoy "free interpolation" from lock-free mechanics. now it looks better, and also should fix Strife mauler jerkiness.

[furyweb]

Will you every get PBR or at least specular/normal textures working with this. Ive just tried it out and the lightmapping is genious and looks great although, I would love a higher resolution on the lightmap.

 

Thanks.

[ketmar]

1 hour ago, furyweb said:

Will you every get PBR or at least specular/normal textures working with this

nope. this feature is left for GZDoom. sorry.

 

1 hour ago, furyweb said:

lightmapping is genious and looks great although, I would love a higher resolution on the lightmap.

there are technical reasons for low lightmap resolution. mostly due to real-time lightmap tracing (all dynamic lights does this to get proper shadows). it is already slow sometimes, and with bigger lightmaps it will be dog slow. alas. and making lightmap resolution configurable is somewhat hard, because it is hardwired in many places. sorry again.

 

but thank you for trying k8vavoom. maybe you would be able to like it even with small lightmaps and without PBR. ;-)

[ketmar]

in a dream, he came along and told to me "your time has come, your users want it all!" it's a time of the build!

 

* fixed many clipping bugs (and cleaned up clipper code)
* added brightmap support (experimental)
* added glowing flats support (experimental)
* MD3 model support (no GZDoom modeldef parsing yet, though)
* implemented gzdoom "filter/" pk3 feature
* fixed some alias model rendering bugs (out-of-bounds skin indicies with animated skins, etc.)
* exact pathes to alias models in model definitions are not necessary anymore
* faster alias model substitution (use hash tables instead of loops)
* fixed bug with light bleeding through 3d floors in advrender
* moving static light emitters (like lamps and torches) will move their respective static lights
* implemented ACS_NamedXXX ACSF functions
* fixed bug with BSP bounding box updates, which previously caused some clipping bugs with 3d floors
* do not render polyobjects several times anymore
* allow using multipatch textures as patches for other multipatch textures
* multipatch sprites now properly works
* smoother weapon bobbing, and lowering/rising
* added thing/monster movement interpolation (physics was automatically interpolated, but state actions weren't)
* implemented `A_Warp()`, missing args to `A_FaceTarget()`, and other decorate improvements
* partially implemented `Display:` decorate state for weapon psprites (sometimes it is used for overlays, and for some strange weapon logic)

[Gunrock]

Ketmar you are amazing!!!!

 

However with this new build I noticed scrolling floors no longer work. Here is an example wad.

test.zip