k8vavoom: no good thing ever dies!

[Gibbon]

It probably flags the exe name because it sounds suspicious.  Don't worry, it's a great source port.  Fast, fluid and while certainly different, it has a nice flavour that I like to experience every once in a while.

[boris]

The download link uses HTTP, that's probably what Chrome doesn't like.

[ketmar]

thank you people for helping! ;-)

 

and while i am here: yep, still alive. currently i have one blocking bug that blocks new build. will release as soon as i fix it. (yay, we finally have bugs sorted by types due to Fossil! ;-)

 

p.s.: chrome and/or windows defender doesn't like "catbox.moe" site at all. just tell 'em to STFU, they just don't like file hosting sites without ads. ;-)

Edited September 28, 2021 by ketmar

[Gibbon]

Can't wait to try it.

[ketmar]

8 hours ago, Gibbon said:

Can't wait to try it.

thank you! but if you have GNU/Linux, you don't have to wait. ;-) (windows version on windows itself is still unbuildable, i believe. oops.).

the blocker bug is about 3d polyobjects anyway. i simply don't want to release the binary people could use for experiments with 3dpobjs with broken behaviour.

 

Spoiler

i'm mostly working on my Tcl engine now. doing something completely different from time to time brings new ideas, yeah.

 

but no, there won't be Tcl in k8vavoom… at least i really-really hope so! ;-)

 

Edited September 29, 2021 by ketmar

[Gibbon]

I gave it a spin today, wow it really does feel like Quake.  It caught me a bit off guard, love the blood on ceiling stuff.  Damn gorgeous too.

Edited September 30, 2021 by Gibbon

[Redneckerz]

On 9/29/2021 at 2:53 AM, ketmar said:

thank you! but if you have GNU/Linux, you don't have to wait. ;-) (windows version on windows itself is still unbuildable, i believe. oops.).

the blocker bug is about 3d polyobjects anyway. i simply don't want to release the binary people could use for experiments with 3dpobjs with broken behaviour.

 

  Hide contents

i'm mostly working on my Tcl engine now. doing something completely different from time to time brings new ideas, yeah.

 

but no, there won't be Tcl in k8vavoom… at least i really-really hope so! ;-)

 

I wish i could see what Elle is for, but that site is sooo borked. What is it about, sir Ketmar The Dark? ^^

[ketmar]

6 hours ago, Redneckerz said:

I wish i could see what Elle is for, but that site is sooo borked

no mobile browsers. no macs. no cloudhosting IPs. violators will be terminated. ;-)

 

6 hours ago, Redneckerz said:

What is it about

just another engine for interpreting Tcl language. because the world really needs yet another one. not that there is Jim Tcl, for example...

 

8 hours ago, Gibbon said:

I gave it a spin today, wow it really does feel like Quake.  It caught me a bit off guard, love the blood on ceiling stuff.  Damn gorgeous too.

glad you liked it! yeah, if i remember right, i made player movemed less slipery by default (you can turn off that in game options menu, of course). a simple trick: just multiply player friction by some coeff if no movement keys pressed.

 

p.s.: hey, we have more than 850 cvars to control the engine! … and it's better don't touch them, defaults rox. ;-)

Edited October 1, 2021 by ketmar

[Remilia Scarlet]

4 minutes ago, ketmar said:

if i remember right, i made player movemed less slipery by default

This has been one of my most favorite things about the port since I first tried it: no more ice skates on normal floors. Yet still adjustable for the masochists.

[Gibbon]

Yeah I liked that too.  I increased the friction to feel more like walking rather than ice skating :)

[Redneckerz]

10 hours ago, ketmar said:

no mobile browsers. no macs. no cloudhosting IPs. violators will be terminated. ;-)

But how can i then tell what you are working on? :P

10 hours ago, ketmar said:

just another engine for interpreting Tcl language. because the world really needs yet another one. not that there is Jim Tcl, for example...

But nothing Doom related, no? I saw visions of a TCL infused Doom coming to light...

10 hours ago, ketmar said:

p.s.: hey, we have more than 850 cvars to control the engine! … and it's better don't touch them, defaults rox. ;-)

So K8 comes with a CVAR Guide Book, narrated by Star Trek's Cvar Burton, am i right? ;)

[ketmar]

1 hour ago, Redneckerz said:

But how can i then tell what you are working on? :P

do not trespass. UAC Secret Facility is off limits!

 

1 hour ago, Redneckerz said:

But nothing Doom related, no? I saw visions of a TCL infused Doom coming to light...

it would be a great fit for the built-in console, but alas, it's too late now.

 

1 hour ago, Redneckerz said:

So K8 comes with a CVAR Guide Book, narrated by Star Trek's Cvar Burton, am i right? ;)

sure! each cvar is carefully explained with C++ and VavoomC code, it can't be more detailed than that!

[Redneckerz]

50 minutes ago, ketmar said:

do not trespass. UAC Secret Facility is off limits!

Then you better reply my PM sir!

50 minutes ago, ketmar said:

sure! each cvar is carefully explained with C++ and VavoomC code, it can't be more detailed than that!

What i mean't with that is, with that many CVARS that can be adjusted, surely there is a guide that can detail them?

[ketmar]

13 hours ago, Redneckerz said:

What i mean't with that is, with that many CVARS that can be adjusted, surely there is a guide that can detail them?

it was the answer. ;-) sure, each cvar has a brief one-line explanation, but everything that is meant to be user-adjustable is in options menus, where i tried to explain at least something with built-in help popups (and by the way, i believe that k8vavoom is the only port with such help for each option! ;-).

[The BMFG]

this is an awesome source port @ketmar im genuinely thinking about making this my main source port. i been playing coffee break with this port and i love it! i love the idea of random crits in doom. im guessing you took that idea from tf2? one time i one shot a pinky with a pistol because of those crits! its awesome lol. great job on this port and i hope you continue working on this!

[Redneckerz]

14 hours ago, ketmar said:

it was the answer. ;-) sure, each cvar has a brief one-line explanation, but everything that is meant to be user-adjustable is in options menus, where i tried to explain at least something with built-in help popups (and by the way, i believe that k8vavoom is the only port with such help for each option! ;-).

Ill look up the MAN pages, then.

[ketmar]

On 10/2/2021 at 7:04 AM, The BMFG said:

im genuinely thinking about making this my main source port

thank you!

 

On 10/2/2021 at 7:04 AM, The BMFG said:

i love the idea of random crits in doom. im guessing you took that idea from tf2?

nope, never played that. it's from D&D and Fallout. ;-) also, while it is random, headshots are always more powerful, and do x1.5-x2 damage, it just not shown to not spam the screen. and distance and "closeness" to the horizontal center of a sprite matters too.

 

but be careful. i, for example, so used to this mechanics that i simply cannot play other sourceports anymore. they all feel broken. ;-)

 

On 10/2/2021 at 7:04 AM, The BMFG said:

great job on this port and i hope you continue working on this!

thank you again. and yes, i am still full of ideas. it's slightly cold here, and i sometimes want to take a little rest (by doing other small projects), yet the new build is almost ready. it is, as usual, is faster, better, and with new shiny bugs!

Edited October 4, 2021 by ketmar

[wesleyjohnson]

I run 32-bit Slackware Linux too.  I agree, there is no pressing need now for 64-bit addressing either.

 

As to that other forum:

I am putting this here because I don't bother with those people anymore.   I won't even reply to them anymore, cause it is not worth the effort.   They will get upset if you won't do the same as they are doing, or dedicate your priorities to using the system they favor.   It is all emotional arguing, insults, lies, and opinions passed off as fake data.   They push what they do as "everybody is doing it", and then declare anything else as "dead" to try to take away any other options.  There is nothing to be gained because such people will NEVER admit to anything counter to any opinion they hold.   They are not worth the 7 sentences already invested in this.

 

I agree, there is no problem with compiling 32-bit packages.

I compile much of the important packages anyway because I can specify the CPU as K10 (Athlon64), instead of having to settle for i586 code, or i686 code.

The binary packages that can be downloaded are so generic that they don't use the CPU capabilities that we have invested money and effort to obtain.

Don't have to do anything special in compiling the packages, other than to specify the CPU properly in slackbuild.  I make a copy of slackbuild and modify it, adding K10 options to the CPU menu.  I could use the "native" setting, but that makes it difficult to properly label the resultant binary.   The slackbuild binaries are marked as to i686, or K10.

How much trust can I put into a native CPU compiled binary a few years from now, when I may not remember which machine it was compiled upon.

So I go through the extra trouble of adding options to the CPU choices in every slackbuild.

 

The compiler will detect situations where it can use the advanced instructions, use them automatically, and do it better than most of SIMD code I have seen.

I worked on some of the Flightgear SIMD code, due to it crashing on 32-bit systems.  Flightgear has explicit SIMD support in their SimGear package (various different kinds of SIMD support).   Trouble is, the SIMD support was ineffective.  When I disabled the SIMD support it ran faster.   The problem was that they did not realize that SIMD instructions require the data to be in the SIMD registers, and that to use a single FAST SIMD instruction to add 3 components of a vector requires the compiler to move those components from from the regular registers to the SIMD registers first, and then move the result back to the regular registers.   The extra overhead totally wiped out any gains.

 

Saving cache space, avoiding fetches to main memory, has been proven to be more important than clock speed.

If your pointers are smaller, your cache usage is more efficient.

Using an estimate that pointers account for approx. 20% of data structures, then using 32-bit gives me about 10% more cache space.

Even a gain of 10% cache space is significant due to avoiding the reloads for two conflicting memory accesses.  Speed gains can exceed 20% due to the reduced size of conflicting addresses that remain.

 

I have been changing some of the DoomLegacy code to take better advantage of the number of instructions that can be executed during a main memory fetch.

Probably can afford to use 5 or 6 simple instructions, if it will save a main memory access.

 

Some of the Doom code has had tables to avoid some calculations.  Fetching those from main memory is no longer cost effective.   Even 1/x can be calculated in one clock.

Large lookup tables are no longer a great speedup, and they use up valuable cache space.  If the same result can be calculated in 5 or 6 instructions, it will probably be faster than using the table lookup.   Will have to put in some timing test to verify exactly what the speed trade-off is before just changing stuff blindly on suspicion.
 

Been squashing some of the data structures too to reduce the cache footprint (thus speeding up everything).   Many structures used an int as a default numerical type.   If there are many copies of that structure in memory, then there can be significant savings in your cache footprint by changing to an int16_t or even an int8_t, where possible.

 

I have found that it is not that difficult to align structure fields manually.  Putting all the pointers in a structure together makes it easier to make then aligned (aids with memory fetches that do not have to cross cache lines).

Have moved some of the structure members around so the pointers are at 4 byte offsets.   Having fields grouped in a structure according to function never did work that well anyway, so grouping them by data size, so the field alignment is maintained naturally, works out fairly effectively, and is perfectly readable too.

 

Most attempts to use the PACKED attributes, to keep holes out of structures, has had a host of problems.  DoomLegacy is supporting compilation on 4 to 7 different compilers.   It would be easier to go GNU GCC only, but for years we already been supporting other compilers.

I already have GCC-4, GCC-10, Clang, MINGW, and WATCOM support, and if I remember all the rules, it won't break.

Have not been able to use any PACKED attributes because tests on MINGW indicates that it totally ignores all the variations that I have tried.

A supporter has submitted some code that includes among other things a system for defining a PACKED macro, that seems to work for a number of compilers.

I have to see what the response is from those who compile on BSD, FreeDOS, and others, before I can recommend it.

 

Been working on some of the DoomLegacy OpenGL code the last few days.  Looks like a bug breeding ground.  Trouble is, every time I try to fix one of the more ingrained imaginative data structures, it often breeds a entirely novel new bug.    Made the OpenGL renderer use the new extended skies (changable in the menu).   Looks nice.  Only problem is that after 4 or 5 sky changes, strange things happen, random texture changes, like the player weapon changing to a floor texture.    Changing a texture after it is loaded into OpenGL has not been provided for in this implementation.   Attempting to do so leads to corruption of a texture list maintained by the OpenGL driver in DoomLegacy.  It seemed like a simple fix when I started working on it, and now I have to extend the OpenGL support too.

Edited October 6, 2021 by wesleyjohnson

[ketmar]

20 hours ago, wesleyjohnson said:

The binary packages that can be downloaded are so generic that they don't use the CPU capabilities that we have invested money and effort to obtain.

i'm ok with this. ;-) but i'm still rebuilding things, because default builds often either contan something i don't need (and it may depend on some other package i don't need), or don't contain something i need. long time ago a wrote the simple package builder, and i'm using it since. what's good with it is that you basically can say "./configure --help >mypkg.xopt", and then it requires very little manual editing. of course, i was planning to write SBuildV2 for years, but… ;-) yet it already has "build profiles" to easily switch the target arch.

 

recently switched defaults from "native" to "nehalem", though, because Valgrind still cannot emulate AVX in 32-bit mode. yet it seems to understand SSE3 and higher now.

(it matters because GCC loves to generate AVX instructions for small memset/memcpy calls, if it is allowed to.)

 

20 hours ago, wesleyjohnson said:

The problem was that they did not realize that SIMD instructions require the data to be in the SIMD registers, and that to use a single FAST SIMD instruction to add 3 components of a vector requires the compiler to move those components from from the regular registers to the SIMD registers first, and then move the result back to the regular registers.   The extra overhead totally wiped out any gains.

yeah, to take full advantage of SIMD, data structures should be designed in SIMD-friendly way too. otherwise FPU code can be as good as compiler-generated SIMD (at least on my CPU this is the case).

 

still, hand-written SIMD may be faster, because you can simply read 4 fp values with 4th being the garbage, and then write them back. if your vector (for example) is 16-byte aligned, and always has 4 bytes reserved for garbage, SIMD may win. i didn't checked, but i think that newer compilers are able to generate such "cheating" code too.

 

20 hours ago, wesleyjohnson said:

If there are many copies of that structure in memory, then there can be significant savings in your cache footprint by changing to an int16_t or even an int8_t, where possible.

still, it's not always the case: having your struct fields properly aligned may give a speed boost big enough to justify bigger sizes. as you (and Graf) said, it all should be carefully profiled. what makes it harder, tho, is that profiling can show quite different results on different CPUs. gone are the days when we could simply count ticks-per-instruction and memory access cycles, and be sure that it has any sense. ;-)

 

20 hours ago, wesleyjohnson said:

It seemed like a simple fix when I started working on it, and now I have to extend the OpenGL support too.

yeah, things often starting quite innocent, and suddenly you found yourself rewriting the whole engine subsystem. ;-)

Edited October 7, 2021 by ketmar

[printz]

On 7/14/2019 at 10:22 PM, ketmar said:

sadly, no. they're scattered across the source code, and i never bothered to write any documentation. sorry.

 

this perfectly fits to a wiki, but alas: k8vavoom has no dedicated site, and no wiki. maybe one day some volunteer will setup one, but until than k8vavoom will prolly stay a hidden and obscure gem. ;-)

No documentation yet? Instead of a wiki, why not just have a markdown file inside the git repo, with a dry list of all the user-exposed editing options? You know your work the best. And it's easier to maintain than a spam attack prone wiki.

Edited October 12, 2021 by printz

[inkoalawetrust]

1 hour ago, printz said:

No documentation yet? Instead of a wiki, why not just have a markdown file inside the git repo, with a dry list of all the user-exposed editing options? You know your work the best. And it's easier to maintain than a spam attack prone wiki.

A wiki isn't neccesarily prone to spam attacks if you do what the ZDoom wiki does, where you have to actually contact the admins to request a new account to be able to edit it.

[OliveTree]

Maybe im dense but i've been trying to find where the download link is for a good ten minutes ':D

[Remilia Scarlet]

18 minutes ago, OliveTree said:

Maybe im dense but i've been trying to find where the download link is for a good ten minutes ':D

It's near the bottom of the OP.  Look for the text "donwload from catbox.moe"

[Redneckerz]

18 minutes ago, OliveTree said:

Maybe im dense but i've been trying to find where the download link is for a good ten minutes ':D

Here (Download from catbox.moe in OP)

[OliveTree]

ty both!! i did eventually find it and should have said something haha

[ketmar]

On 10/12/2021 at 7:48 AM, printz said:

No documentation yet?

tbh, there's a little reason to do so. everything user-configurable is in option menus, even with help tooltips. and things that are not there aren't something ordinary user will want to touch, even with the documentation.

 

On 10/12/2021 at 7:48 AM, printz said:

why not just have a markdown file inside the git repo, with a dry list of all the user-exposed editing options?

because Fossil has built-in wiki, which is kept in the project repository — along with tickets, and built-in forum. and it is immediately browseable with `fossil ui` (after you cloned the repository).

 

On 10/12/2021 at 7:48 AM, printz said:

And it's easier to maintain than a spam attack prone wiki.

it's very-very hard to spam something when you don't have any rights to write there. ;-) and no, with Fossil wiki is way easier to maintain than separate files. i will eventually convert all currently available documentation to wiki format too.

 

On 10/12/2021 at 1:35 PM, OliveTree said:

Maybe im dense but i've been trying to find where the download link is for a good ten minutes ':D

that's because i am widely known for my outstanding skills in user-friendly design!

Edited October 14, 2021 by ketmar

[Gunrock]

Not trying to rush you Ketmar...but any hints on a new build soon? ;)

[ketmar]

4 hours ago, Gunrock said:

Not trying to rush you Ketmar...but any hints on a new build soon? ;)

yep, i just opened the page to write that Remilia helped me to fix the blocker, and i'm working through the usual pre-release testing routine now. final production tests usually takes several days, so let's say "on this week". ;-)

Edited October 19, 2021 by ketmar

[Mr.Rocket]

Hey I was wondering if you'd like for me to create a small command line readme based on all the commands that I've put in the launcher for k8vavoom?

It could be a stepping stone for any future additional info. 

 

Can't wait for the next release! ;)

Edited October 24, 2021 by Mr.Rocket

[ketmar]

sorry, don't have enough… energy to write something witty here. so just announcing a new public build for you all. enjoy.

 

highlights:
* switched to "DarkDoom" lighting mode by default
* added optional Contrast Adaptive Sharpening posteffect shader
* non-lightmapped renderers now support overbright
* you will hear the sound of the exit switch now! ;-)
* added some accessibility options (mostly visual for now): you can control light flickering and such, and recolor HUD numbers
* added built-in option to relace vanilla hitscan attacks with fast projectile attacks (see gameplay options menu)
 

Spoiler

* use texture atlases for some internal fonts (console, menu, etc.)
* it is now possible to recolor fonts to any RGB color (use "\c[#rrggbb]" or "\c[!colorname]")
* oops! reverted destructive VStr "optimisations"; it's a miracle that it worked before (thanks, id0!)
* it is now possible to change default font for menus and help text ("ui_font_xxx" cvars); you can try "consolefont", for example. default is "smallfont"
* don't try to choose best sky portal by screen coords (some skies may disappear in this case)
* added optional underwater distortion shader (a-la Quake)
* added optional Contrast Adaptive Sharpening posteffect shader
* proper clearing weapon psprite offsets on weapon change (fixes rare bug with invalid weapon psprite placement)
* reset texture animations on map restart/reload
* fixed `A_SeekerMissile()` -- it wasn't working at all
* fixed possible infinite loop in texture releasing code
* fixed bug in pcx and paletted tga loaders: color 0 should not be transparent
* new experimental DoomDark lighting mode, it should be closer to Vanilla lighting (thanks, GZDoom!)
* added intermission for Ultimate Doom Episode 4 (from https://forum.zdoom.org/viewtopic.php?f=4&t=28110)
* switched to "DarkDoom" lighting mode by default
* switched default colormaps for invuln to gold, and for lightamp to green
* added support for DECORATE things like `A_Jump(256, user_variable)` (i.e. decorate uservars can be used to specify state offsets)
* fixed (i hope) recoloring fonts in RGB format (thanks, id0!)
* added several fuzz modes (thanks, GZDoom!); vanilla-like fuzz is default now
* changed masked texture reject alpha, to make bilinear modes look better (thanks, ENEMY!!!)
* added hack to keep last switch sound playing on map exit (thanks, forgettablepyromaniac!)
* non-lightmapped renderers now support overbright
* sounds will move with their respective sources (this fixes sounds of moving 3d pobjs, for example) (thanks, ENEMY!!!)
* better sound origin calculation for sectors and switches
* moved some accessibility-friendly options to separate menu; added options to control/turn off colormap and palette effects
* added accessibility option to control flickering/pulse sector lighting
* added accessibility options to control other light types
* added menu to recolor HUD numbers
* completely rewritten 3d pobj coldet/unstuck code; should be more reliable
* added new thing (9367) to easily create sequences of linked 3d polyobjects
* jumping from the moving 3d pobj will try to retain its velocity (i.e. jumping inside a cabin should work as expected most of the time)
* it is now possible to declare frame range in model definition xml with "end_frame" or "count" (thanks, Lobo!)
* model xml definitions are checked for unknown nodes and attributes
* cvar access from VavoomC code is as fast as accessing other vars now if cvar name is known at compile time
* added some VavoomC code optimisations for vector swizzling
* pinned threads to different CPUs, and switched to intergral timers to get more stable framerate
* fixed small bug in VavoomC parser (it could parse `arr[n]*varname` as array declaration)
* new floating point parser, much faster, and with round-trip guarantee (based on Ryu code)
* show save directory name (hash) in save/load dialogs
* fixed invalid present weapon number highlighting in statusbar (thanks, SilverMiner!)
* fixed invalid local sound position (slight distortion of shooting sounds when quickly moving/rotating)
* added option to select sound resamplter (you can trade sound quality for CPU time, or vice versa)
* more EDGE fixes (thanks, Lobo)
* default screenshot format is jpg now; you can change back to png with "screenshot_type png"; and you can control jpeg compression with "jpeg_quality n", where n is [1..100]
* added `Species` DECORATE property (r/o)
* added `A_CheckForResurrection()` and `A_CheckBlock()` DECORATE actions (`A_CheckBlock()` is prolly very buggy, tho)
* added `+NoInfightSpecies` DECORATE actor flag
* added "Legion Of Bones v1.05" detector (it should work without any additional efforts now)
* properly implemented "+DoHarmSpecies" and "+HarmFriends" DECORATE actor flags
* added built-in option to replace vanilla hitscan attacks with fast projectile attacks (see gameplay options menu)
* less strict number type checking in DECORATE (some int-only math operations will silently convert floats to integers)
* fixed recently introduced segfault with "-nosound", and added "-nosfx" CLI arg (thanks, Remilia Scarlet!)
* fixed wrong internal Z coords for 3D pobjs (thanks, Remilia Scarlet)
* changing floor/ceiling textures on 3D pobjs is working properly now (thanks, Remilia Scarlet)
* added handling of `MonsterHealth` and `HealthFactor` MAPINFO skill defines (done by Remilia Scarlet, thank you!)