k8vavoom: no good thing ever dies!

[Remilia Scarlet]

3 hours ago, Gwarl said:

k8Vavoom is too bright

If bloom is enabled, disable it. I noticed that made things unusually bright (not just where things should be, either).

[Gwarl]

okay, turned off bloom and fixed the aspect ratio and it looks better now. I still think dark sectors are too bright though, referencing my other screenshots.

btw, legacy has fragglescript which is probably as old as vavoomC, but what people mod in is.. DECORATE, which is good for this port.. and Zscript.

 

I think with darker sector lighting shifts this port could be like, the darkplaces of doom, which is a compliment I love darkplaces. Would work better with some maps than others depending on placement of light sources but if it were an option it could please everybody.

[Gwarl]

and here's the same scene with bloom on where I just set all sector light levels to 48 and 16 respectively (bloom on).. it still isn't darker than the 104 lit sectors in the other ports, but it looks so cool..

[ketmar]

let me make some facts slightly more clear: Vavoom (and k8vavoom) is not scripted with VavoomC, it is written in VavoomC. the engine is written in VavoomC, which is augmented by some C++ code, not vice versa. it was like that almost from the start (yet VavoomC language had several iterantions, from "mini-C" to what it is now). so it is not completely correct to compare it with FraggleScript, and even with ZScript. the former is just "another ACS", and the later was added to the existing engine late in development. but Vavoom was ported to VavoomC almost from the beginning, it was the design plan, not some afterthought.

 

i mean, it is more like Unreal, where C++ side does rendering, sound management and some very low-level coldet tasks, but everything else was written in UnrealScript. it is the same with Vavoom -- it is basically "Unreal of Doom". ;-) the whole playsim, including physics, is VavoomC code. Vavoom really was the most advanced Doom sourceport (as its site claims back then), and on many aspects it still is. this was one of the reasons i picked up its development.

 

don't take it as passive-aggressive attack, please (it may be my bad wording, but not my intention). i just wanted to explain why VavoomC is not "yet another scripting language for Doom sourceport", why it is so essential for Vavoom, and why i'm saying that VavoomC was The First (and for a long time The Only) and unique thing in Doom sourceport world.

 

(also, Vavoom is the only freestep idTech1-based engine out there, afaik; so it may be much closer to DarkPlaces than you may think ;-).

 

p.s.: yep, i'll try to implement selectable lighting levels. it is slightly more complicated than simply fixing some tables here and there, tho: it is a complex interaction between "in-engine" lighting values, fog rendering (level darkening is just a black fog internally), and some other lighting caluculations. i never had to touch that code until now, so i am not completely understand what is going on there. so it may take some time.

Edited March 23, 2021 by ketmar

[Gwarl]

Meta discussion of languages aside can you point me to the file in the source which reads sector light levels? I can probably do a quick hack and write my own non-linear sector light translation function before the rest of the engine sees it as a demo - I wouldn't expect you to implement it like that but I'd to do the experiment while you're busy with more groundbreaking stuff like 3d polyobjects

[ketmar]

it is slightly more complicated than that, but if you want to simply change light values you got from the map data, you can do it with VavoomC mod. i attached the example which you can use as a base. load is as any normal pk3, before or after your wad, it doesn't matter.

 

but please, don't include it with your maps: i won't guarantee VavoomC compatibility across k8vavoom versions.

dimlight.zip

 

p.s.: you may need to replace `(lastchild of VLevel)` with `(lastchild of Level)`, tho -- i don't remember if i renamed that class in the public build.

Edited March 23, 2021 by ketmar

[Gwarl]

wow, great! thanks I'll mess with this and try and approximate software-ish darkness, I'll post the results here - should be relevant to any maps with lighting done with software in mind (like the iwads!). Thanks for all your work

[ketmar]

thank you! if you'll come up with something that can "fix" the lighting, i may include it as an option in next builds. you can change alot of things there, btw, feel free to look at the relevant data structures in "GameObject.vc" and experiment. you cannot change number of vertices/lines/sectors/things etc. yet, tho, and be very careful with vertex data (this is in case you'll want to go wild with that). it directly modifies internal engine data structures, so you'd better know what you're doing there.

 

yet modifying cosmetic things like lighting, textures and such should be safe in most cases.

Edited March 23, 2021 by ketmar

[Gwarl]

This is the weirdest thing, that .pk3 you uploaded worked the first time I tried it, I went in to edit and it didn't work.. then the original didn't work, when redownloaded.. taking your advice about VLevel or not. - I even reinstalled k8vavoom and got nothing. Might try a workaround with something like omgifol to convert a map, at least to experiment with different correction algorithms

[Gwarl]

Been messing around a bit and a partial cubic interpolation seems to work okay; I've uploaded what I think the pk3 should be, and e1dark.zip is a darkened version of knee deep in the dead along with the omgifol script I used to make it if anyone wants to try.. I think it looks pretty nice.

 

Bonus is a screenshot of the dynamic lights working wonders against a darker backdrop, using the darkening formula on my own map

dimlight.zip

e1dark.zip

[ketmar]

@Gwarl ahem... i gave you non-working pk3, btw, its contents should not be in a subdirectory. ;-) sorry. that's why you never seen any effect from your changes. i was using it unpacked (k8vavoom can mount disk directories as pk3 with "-file /path/to/dir/").

 

anyway, it is too dark for my taste. dark areas are almost pitch black. and i HAET darkness in Doom: what is the reason to play a map where i cannot see anything? ;-)

 

i may add some options to hack map lighting this way, tho. because why not, if people want to play the game the way they want, and it costs me nothing...

 

still, the core issue is more complex. part of the problem is in darkening formula, which is a normal "distance fog" in k8vavoom, but not so in Vanilla. and second is brightness levels per se, they're not strictly linear in Vanilla too.

 

second translation is controlled by "r_darken" (set it to 0, and you'll see the difference ;-). this is what can be tweaked more to make light levels less linear.

 

but fog formula is hardcoded into shaders, and it is used for all kinds of fog. adding new set of shaders is a massive PITA (as renderer don't have any kind of "materials" internally, each time i need to select a shader, there is a massive `switch`; alot of them in various places), so i don't think that i'll change darkening formula any time soon.

 

yet i may give user more control of internal light level translation table -- this is basically what you're doing anyway. will prolly make several lighting modes, as in other sourceport.

 

 

p.s.: VavoomC is not js/etc. `min()` is simple `min()`, not `math.min()`. not that it matters, tho, as due to me being dumb the VC code was never compiled anyway. ;-)

Edited March 24, 2021 by ketmar

[Gwarl]

2 hours ago, ketmar said:

@Gwarl anyway, it is too dark for my taste. dark areas are almost pitch black. and i HAET darkness in Doom: what is the reason to play a map where i cannot see anything? ;-)

 

Sure! It's a matter of taste (I used to use F11 playing DOOM.EXE in the first place), but I would say it's factual that dark areas in k8vavoom are less dark than the same dark sectors rendered in most other ports - and being new to this port it looks 'wrong'. Dark areas *are* nearly pitch black in software - OpenGL renderers tend to be brighter, but still mostly darker than k8vavoom's.

 

Attatched is the fixed pk3 you gave me - this loads as a zip if anyone wants to try. The light level translation formula still needs work but as I say; IMO, the lighting effects in this port really stand out against darker backdrops - I get doom3/darkplaces vibes.

 

Going to try and finish my level and get it released then I'll see if I can come up with a more systematic approach to sector lighting corrections; I did alter r_darken but I could only seem to make things less dark using the value, not more dark, and the sector darkening seems to be getting results.

dimlight.zip

[Gez]

15 hours ago, Gwarl said:

btw, legacy has fragglescript which is probably as old as vavoomC, but what people mod in is.. DECORATE, which is good for this port.. and Zscript.

They're not comparable.

 

"Scripting language" is a bit too broad a category. We could split it into three separate categories to make things simpler:

1. Content definition language, such as DDF, DECORATE, EDF... This is a scripting language geared towards, well, defining content, such as new monsters and weapons. DEHACKED can borderline be considered one, especially if you include DEHEXTRA. These scripts are read during initialization, while the game is loaded and before you can reach the main menu.
2. Level scripting language, such as ACS or FraggleScript. This is a language geared towards having events happening in a level, like opening a door when a monster is killed or spawning a key when a switch is flicked, this kind of things. These scripts are part of level data, meant to run on the specific level they're part of, and that's it (ACS can reach outside of its own level but it needs a special setup to work).
   Now it can be possible, sometimes, to fake level scripting with DECORATE, or content definition with ACS, but it is difficult to pull off, suffers from harsh limitations, and may involve hacks that will make port developers sob.
3. True scripting languages. This is the category where VavoomC and ZScript are. Basically the port becomes an interpreter for a virtual machine, and the original game code is translated to this scripting language. This gives you the ability to essentially rewrite the entire game. It's basically the Super Saiyan 2 version of a content definition language.
   The price for that power, however, is that the scripting language becomes intimately tied to the engine that runs it. While it's not too hard to implement working DECORATE support in a port (at least the basic syntax, not talking about the gazillions of weird codepointers or the backward compatibility cruft), and it's also not too hard to implement working ACS or FraggleScript support either; implementing support for VavoomC or ZScript is another issue entirely. Since it's something that connects directly "mod code" to engine internals, it means you need to have your engine internals working in the same way as Vavoom or GZDoom...

 

[ketmar]

1 hour ago, Gez said:

implementing support for VavoomC or ZScript is another issue entirely. Since it's something that connects directly "mod code" to engine internals, it means you need to have your engine internals working in the same way as Vavoom or GZDoom...

yeah, exactly. with VavoomC or ZScript mod developer is basically doing "engine programming" now. they may not need to recompile C++ source, but they're still modifying the core engine code.

 

that's why i am against using VavoomC in mods unless it is REALLY necessary. it is completely unportable (and may even stop working with future k8vavoom releases), and it is VERY easy to do something wrong there -- because there are almost no safety nets. eh, VavoomC even have pointers, and while it is harder to trash memory via wrong pointer there, it is still possible. also, without intimate knowledge of the exact way the engine doing things, wrong VavoomC code can trigger various UB effects. they may work, or may break, or may shutdown our Universe. ;-)

 

with ZScript, it is almost the same. and GZDoom also have to support several ZScript versions (and have explicit version stated in some files), or some mods will break. it makes engine upgrades very hard (and sometimes simply impossible).

 

for example, i completely rewrote hitscan tracer recently. it is faster and easier to use now, but all code that is using the old API (it is on VavoomC side, C++ code doesn't need or use that thing) should be rewritten too. and it is impossible to emulate old API, because the whole reason for rewrite was 3d polyobjects -- old code simply cannot cope with them.

[ketmar]

2 hours ago, Gwarl said:

I did alter r_darken but I could only seem to make things less dark using the value, not more dark

yes, this is boolean cvar. i simply wanted to show you that k8vavoom already does some light level translation internally, and without it the lighting is too bright. i'm not sure if i can add more translation tables, tho, and the consequences of changing that table -- it needs more investigation.

[Gwarl]

Cool, so if I turn off r_darken will that leave me with what the engine sees as 'linear' light? And then if I base my own translation tables for this minimod on what I see with that turned off, I guess that'll be easier for you implement as a menu option.

[ketmar]

3 minutes ago, Gwarl said:

Cool, so if I turn off r_darken will that leave me with what the engine sees as 'linear' light?

yeah. the table is built in `R_Init()`, and then the code does `if (r_darken) lightLevel = light_remap[lightLevel];` here and there.

Edited March 24, 2021 by ketmar

[3t0]

On 3/23/2021 at 4:59 AM, ketmar said:

sure. it is even named `SetLineTexture`.

Sorry, I forgot line action specials are NOT equivalent to ACS function names. I was ready to swear I have not seen such token in line specials, until I noticed it's actually ACS.

 

On 3/23/2021 at 4:59 AM, ketmar said:

generally speaking, this is UB.

I am interested in it being reliable in k8vavoom only - would custom 100% transparent 1x1px (or 8x8px or what would be best) PNG FLAT/LUMP do it?

 

On 3/23/2021 at 4:59 AM, ketmar said:

i meant second one, with missing top/bottom textures. it triggers floor floodfill bug in vanilla

I was completely misdirected by the image, thank you for clarification.

 

Now, I noticed you sidetracked ThingModel(?) (ThingMisc(?), MiscModel(?), well basically "UDMF" "directly loadable" 3d model thingy) issue very carefully ;). I guess same limitations would apply like with immutable geometry - would not be worth to support right (non backwards compatible, problematic dissemination, need of consensus for multi-engine support)?

[ketmar]

37 minutes ago, 3t0 said:

I am interested in it being reliable in k8vavoom only - would custom 100% transparent 1x1px (or 8x8px or what would be best) PNG FLAT/LUMP do it?

it is still UB. 1s wall should have a solid, non-transparent and non-translucent texture that fully covers it. anything other is UB. this is what 1s wall is: it MUST NOT have holes in it, because thechnically there is nothing behind it (the "void" is "nothing"). having no (or transparent) texture there means that depth buffer for such walls will not be filled correctly -- which is much worser than overdraw issue.

 

43 minutes ago, 3t0 said:

I guess same limitations would apply like with immutable geometry

yeah. as with any feature that requires something non-standard to be added to editors and such. i.e. i won't implement anything complex that is not supported by other sourceports, and is not already widely used.

 

the main goal of k8vavoom project is to play Doom. if i would want a new engine, i'd do it from the scratch, throwing away everything that is not worth keeping these days. but for Doom engine, i see little reason in introducing features that will need alot of efforts to use, and be used in several demo maps, and then forgotten.

 

like, 3d polyobjects, for example, don't need any modifications to the existing editors (the only modification is adding one new thing id, which doesn't even require code changes). then mapper can simply draw a closed sector with 2-sided walls, drop standard polyobj anchor there, and drop another "spawn 3d polyobject here" thing. that's all. ah, plus several lines of ACS script to control 3d polyobj movement. no need to learn any new tricks, no need to upgrade editors. it just magically works.

 

but adding things like "wall models" is more complex. i don't want to introduce more "thing hacks" for that, so it will require new flags in editors, new file formats to describe such models, and so on. alot of new things to learn, and you've already seen how well such learning works: Boom is available for more than 20 years already, yet people still stuck with abusing vanilla rendering bugs. so no, i won't go that way. i have really huge list of things i want to implement in k8vavoom to be immediately usable, and i just don't have enough resources to spend on things that are essentially gimmicks, and will be used once by 3 or 5 people, just to try it out.

 

(and yeah, wall/flat portals is one of those gimmicks. ;-)

[ENEMY!!!]

6 hours ago, ketmar said:

3d polyobjects, for example, don't need any modifications to the existing editors (the only modification is adding one new thing id, which doesn't even require code changes). then mapper can simply draw a closed sector with 2-sided walls, drop standard polyobj anchor there, and drop another "spawn 3d polyobject here" thing. that's all. ah, plus several lines of ACS script to control 3d polyobj movement. no need to learn any new tricks, no need to upgrade editors. it just magically works.

 

I had been wondering about how well 3D polyobjects would fit in with current editors (especially Ultimate Doom Builder) - this is good to know!

[ketmar]

@ENEMY!!! that was the idea from the very beginning -- people should not need to learn anything radically different. if they know how to do polyobjects, they know how to do 3d polyobjects. otherwise the feature won't be used. ;-)

 

3d polyobject creation looks natural. normal pobj usually is a set of 1-sided walls, without "inner part". it is only logical to assume that drawing pobj using 2-sided walls can create 3d pobj. its "inner sector" is also used to set floor and ceiling textures, which also looks like a logical thing. that sector's height is maximum pobj height. and so on. editors may later add "3d pobj preview mode", but even without special mode it should be easy to look at it, fix midtextures offsets, and so on. (yeah, all the standard texture offset knows should work, and scrolling textures are possible). you can also align your sector to flats where you created it, and it will be "cut" with correct flat offsets.

 

also, i'm glad to tell you all that most major technical problems are solved: collision detection and LOS checking seems to work. i had to rewrite several parts of the engine for this, but interestingly enough, the new code is smaller, cleaner, and sometimes even faster than the old. small bugs are still possible here and there, but i'm more-or-less happy with the implementation.

(of course, i can optimise it even better, and i'll do, but not now)

 

there is small problem with lighting, tho: as i'm not really splitting pobj to subparts, and 3d pobj doesn't have one "host sector" anymore, it is not clear what source sector is. and without splitting, pobj light level can be changed only for the whole pobj. i.e. pobj sector cannot have two light values, and you cannot create effects like "slowly moving from bright to darkness with proper lighting" (at least without using dynamic lights ;-). considering this, i think i will give you ACS API to control pobj light levels, and so be it.

 

option to not carry objects when moving horizontally or rotating are already implemented. you'll be able to use spawn thing arg field to set the flags (and there is already ACS API to query and change those flags on the fly).

 

if you can code, you can watch my progress via git. i'd say that it is quite interesting read sometimes, and you may even find some explanations to some algorithms (like LOS checking, which is just a simple ray-to-convex-solid intersection check you might seen in Quake engines, but with a twist, and with a cheat ;-).

[3t0]

16 hours ago, ketmar said:

it is still UB. 1s wall should have a solid, non-transparent and non-translucent texture that fully covers it. anything other is UB. this is what 1s wall is: it MUST NOT have holes in it, because thechnically there is nothing behind it (the "void" is "nothing"). having no (or transparent) texture there means that depth buffer for such walls will not be filled correctly -- which is much worser than overdraw issue.

Got it. Even as an artifact in GL engine only, it's basically in same class as that boom sector leak thing. Just because it works (and probably will work in foreseeable future) it does not mean it's a feature. Pity :(. On the other hand I am starting to appreciate how abuseable doom is :).

 

16 hours ago, ketmar said:

but adding things like "wall models" is more complex. i don't want to introduce more "thing hacks" for that, so it will require new flags in editors, new file formats to describe such models, and so on. alot of new things to learn, and you've already seen how well such learning works: Boom is available for more than 20 years already, yet people still stuck with abusing vanilla rendering bugs. so no, i won't go that way. i have really huge list of things i want to implement in k8vavoom to be immediately usable, and i just don't have enough resources to spend on things that are essentially gimmicks, and will be used once by 3 or 5 people, just to try it out.

Makes perfect sense. I think I understand now fully, that the very thing that gives doom it's stability (community, tools and techniques wise) is the same thing which makes more experimental (and perhaps dead end) changes hard. This also explains developer "gangs" that tend form around engine ports form. Unless you are short of genius (ehm, ehm), it's really hard to keep the port going just by yourself. So multiple people sharing same ideas band together and they forward the port the direction they want. It seems this is the case with technically heavily extended but "lesser" ports. I never understood these weird forking patterns among doom ports, but this now explains it great. Sad thing with these advanced ports is they are not that popular. Thank you for enlightening me.

[ketmar]

2 hours ago, 3t0 said:

Got it. Even as an artifact in GL engine only, it's basically in same class as that boom sector leak thing. Just because it works (and probably will work in foreseeable future) it does not mean it's a feature.

yeah, exactly. UB is UB. i'd be very happy to simply bomb out on such invalid lines, but sadly, we already have maps with such bugs. they are playable, so i deliberately allowed such UBs -- it is better to have some rare rendering glitches than completely unplayable map. (this is also the cause for many other UBs the engine detects, but cannot reject.)

 

2 hours ago, 3t0 said:

the very thing that gives doom it's stability (community, tools and techniques wise) is the same thing which makes more experimental (and perhaps dead end) changes hard

yeah. this, and compatibility. we still can play maps made 25+ years ago, which is very important to keep community alive. i.e. map makers can be (mostly ;-) sure that their creations will be playable in foreseeable future. alas, this compatibility makes alot of things much harder than they could be.

 

2 hours ago, 3t0 said:

So multiple people sharing same ideas band together and they forward the port the direction they want. It seems this is the case with technically heavily extended but "lesser" ports. I never understood these weird forking patterns among doom ports, but this now explains it great.

yep. ;-) the engine is relatively easy to hack, and there is alot of content for it. so if somebody wants to implement some New Cool Feature (or improve the engine in some direction others didn't explored yet), they fork. and let natural selection do the rest. ;-)

Edited March 25, 2021 by ketmar

[ketmar]

as i said, you can abuse that shit. as i am pretty sure that building crap out of 3d polyobjects will be the first thing any mapper will try, i did it for you in advance.

 

p.s.: no, you'd better don't build complex structures with this. it will be SLOW. not a replacement for proper moving sectors.

Edited March 26, 2021 by ketmar

[ketmar]

while doing rendereing code cleanups, i got an idea how to fix t-junctions (The White Dots ;-) in lightmapped renderer too. i hope that in the next build, all renderers will be "dot-free" (finally!).

 

if you wonder how bad it is in lightmapped renderer, just run Doom1 E1M1, step back to the starting door, look slightly down, and turn the camera left/right. you will see white dots flashing along the invisible floor line. this is unacceptable thing i kept accepting for too long. ;-) now i hope to get rid of it once and for all.

 

Spoiler

for those interested enough: this is caused by surface subdivisions. to keep lightmap cache use ratio good, the engine subdivides big subsectors to even smaller ones. and while doing that, it creates new vertices in some new polygons, but not in others. due to floating point inexactness, some pixels may be not drawn. to fix that, we need to insert new vertices in all polygon edges.

 

shadowmap and shadow volume renderers doesn't do any subdivisions, so fixing The White Dot Problem is much easier there: only walls should be processed, and only walls that have adjacent sectors with dfferent floor/ceiling heights.

 

but for lightmaps, each surface should be checked against each other surface that shares any edge. of course, for most surfaces it will be done once on startup, so it shouldn't hurt performance too much.

 

p.s.: ok, the idea seems to work -- no more "cracks" on the floor. now i only have to implement a similar thing for walls, then throw away most of the code, and write the good one instead. ;-)

 

two images.

before:

Spoiler

after:

Spoiler

 

as you can see, all "stray" points now have proper lines going to them. this means that each shared vertex is correctly shared by all edges, and guaranteed to have exactly the same coordinates for each surface. i.e. no more cracks.

 

the algo is quite slow (simple brute force), but it is better than nothing (and i can optimise it later). wall fixing is not implemented yet, but the idea is the same. i only have to use (x,z) coords instead of (x,y) to stay on surface plane (because walls are always vertical). it should be even slightly easier than floors and ceilings.

Edited April 1, 2021 by ketmar

[3t0]

On 3/26/2021 at 3:50 PM, ketmar said:

as i said, you can abuse that shit. as i am pretty sure that building crap out of 3d polyobjects will be the first thing any mapper will try, i did it for you in advance.

I presume these are otherwise normal polyobjects that can be used as rotating doors, am I correct?

 

23 hours ago, ketmar said:

while doing rendereing code cleanups, i got an idea how to fix t-junctions (The White Dots ;-) in lightmapped renderer too.

This is great news! I was hoping for this such a long time.

[ketmar]

3 hours ago, 3t0 said:

I presume these are otherwise normal polyobjects that can be used as rotating doors, am I correct?

yes. they are absolutely normal polyobjects, only with finite height. original polyobjects always have height of the owning sector, always stay at the floor of that sector, etc. those "free 3d polyobjects" have their own height and z coordinate. but they are normal polyobjects otherwise, processed with mostly the same code as "old" ones (except some additional checks for top/down surface collisions, and cheating "rect-in-poly" checks).

 

that thing was built from several 3d polyobjects (top and bottom platforms, and columns), linked by the special new "link pobj" thing. so if you'll move the first pobj, others will be moved too. and this is done atomically -- i.e. it is like they're all a one huge pobj.

 

3 hours ago, 3t0 said:

This is great news! I was hoping for this such a long time.

i think i finished it. just made a final commit. there are some rare corner cases without fixes, but they are so rare that i don't think somebody'll notice. the code is a fuckin' mess, and is slow as slow shit (by my standards, it is still not noticeable for the end user ;-), but it seems to work. at least i see no white dots in problematic test maps (taken from real wads).

 

of course, there will be some inevitable bugs there, but i hope that most of the time the visuals should be "rock-solid".

 

sadly, i changed the rendering code so much that i cannot port this code back to the original Vavoom, and KRPG/Scattered Evil is freakin' hard to port to k8vavoom. T_T

Edited April 1, 2021 by ketmar

[ENEMY!!!]

I noticed that -bdw resembles a stripped down version of BDLite.  I decided to test BDLite with k8vavoom and it turns out that it mostly works well if I comment out the three lines of code which use the "gameplay" DECORATE command (relating to deathmatch, so it shouldn't affect singleplayer).  There is a glitch (which also arises in -bdw after switching to and from the fists) with weapon sprites being incorrectly aligned after switching to/from certain weapons - perhaps this stems from another DECORATE incompatibility that I haven't yet located.  Apart from that, it seems to work as well as it does in GZDoom.  Another good thing I noticed is that BDLite (unlike Brutal Doom) doesn't include its own headshots system and the k8vavoom headshots system still works with BDLite, as does the blood/gore mod.  I'm tempted to have a tinker around with this over the Easter weekend and see if I can address that weapon sprite placement issue and get it working 100%.

 

I also tested Tango's Supercharge 2.8 last weekend but that would require somewhat more work to get working - again with a couple of tweaks to the code it will run, but many of the sprite and sound effects are a bit off.  But I was pleasantly surprised by how well BDLite works.

Edited April 1, 2021 by ENEMY!!!

[ketmar]

1 hour ago, ENEMY!!! said:

There is a glitch (which also arises in -bdw after switching to and from the fists) with weapon sprites being incorrectly aligned after switching to/from certain weapons

this is a bug in sprite cropping code, which should be fixed in the next build. you can turn off "options -> video -> sprite -> crop psprites" off to get rid of it for now (quit the game and restart the .exe after doing it).

 

1 hour ago, ENEMY!!! said:

I noticed that -bdw resembles a stripped down version of BDLite.

yeah, it is a weird thing built from very old BD code, some BDLite code, and my own code, just because i liked those two weapons. actually, this was the thing that forced me to start improving DECORATE support in Vavoom.

 

1 hour ago, ENEMY!!! said:

Tango's Supercharge

dunno, sorry. i cannot download anything from "bit.ly", and the author specifically said that it won't work in anything not-GZDoom based. i can go the extra mile to make some old and abandoned mods working, but for relatively new and still supported mods i expect their authors to consider k8vavoom compatibility if they're interested. sorry, but i can't and won't chase GZDoom, and won't do a bug-to-bug compatibility (and i consider anything not explicitly written in ZDoom wiki as "you can do it as you want to, it doesn't matter", so if some mod expects a [G]ZDoom-specific behavior that is not in a wiki, chances are i won't "fix" it -- because there is nothing to fix). i am really sorry, but chasing GZDoom without even having the proper specs is a massive PITA.

 

again, i am really sorry, but the amout of work i have to do for k8vavoom specific things leaves almost no time to decipher and port GZDoom code. i'm still doing that from time to time, but only when i have a minified example with a bug/weird behavior, and some free hours to spend. the mod should also work on GZDoom 3.3, because this is the last version i can properly experiment with (i can't port my testing framework to later versions, it is too much work).

 

sorry for being uncooperative on that (and maybe somewhat rude), but i only have so much time and resources to work on k8vavoom, and i am planning to implement alot of interesting features no other sourceports have. if i'll spend all my time trying to replicate GZDoom, those features will never materialize. don't take it personal, please, i just wanted to explain why i may reject fixing/extending the engine to support some mods. it's not because i hate GZDoom, or mods, or some authors, its all about the physical limits one ketmar have. ;-)

Edited April 1, 2021 by ketmar

[ENEMY!!!]

Reading your post it looks as if you thought I wanted you to make k8vavoom compatible with Supercharge 2.8.  Apologies if it came across that way, as that really wasn't the intention (and I've seen your caveats about mods on the first page).  I had rather briefly contemplated the idea of creating my own build/fork of Supercharge that would be k8vavoom compatible, and decided that it would be far too much work.  But my main point is that the same idea with BDLite looks very feasible.

Edited April 1, 2021 by ENEMY!!!