k8vavoom: no good thing ever dies!

6 hours ago, ketmar said:

absolute zero. sorry. even if somebody will do it, i won't accept any clang/macos specific patches into the mainline. the decision is final, and not negotiable.

Guess I should really get on that one day.  iVavoom 😄

9 hours ago, Gibbon said:

Guess I should really get on that one day.  iVavoom

you're more than welcome! i will happily put a link to your repository here and on k8vavoom site, if you'll do it. i don't want that in the main repo, but that's mostly it. i'm ready to answer any questions (if i know the answers, of course ;-), and to promote any porting efforts. so it could be "the official unofficial MacOS X port". ;-)

Edited January 25, 2022 by ketmar

Hey, it's been a while :p
It's really awesome to see the shadowmapping, and in particular that it works with sprites! One thing I always wanted was sprites to cast dynamic shadows, but of course that wasn't reasonable with the old methods. Very neat to see this, which creates a lot of pretty eye candy even in vanilla Doom maps.

Besides that, I've noticed some small problems with DECORATE, ACS and MODELDEF.

 

[DECORATE]

1. Gotos jumping to non-existing states are a fatal error. This is reasonable, because it makes no sense to do that. However, some mods do it even if they have a virtual jump before it, which is the "right way" to do it, so perhaps those cases should be replaced with a Stop or Goto Null and let go with a warning?

 

2. A_ZoomFactor requires two arguments, but the function in ZDoom actually doesn't require any. A call with no parameters resets the FOV back to 1.0.

 

3. Weapon.SlotNumber has priority over Player.WeaponSlot, but in ZDoom this is the other way around. This might break a few mods having all the weapon slots jumbled around.

 

4. Projectiles, when bouncing on the floor (at least those of BounceType Hexen), won't count towards the counter that would put them into the death state, so at one point they'll just slide along the floor until they hit walls enough times to explode.

 

5. "Spanish Inquisition says: in decorate, thou shalt use `|` to combine constants." has some false positives. As in, not even that it's called in places where flags are used properly or something, I mean stuff that uses ||, logical OR! :p

Like this example from D4T:

"MARM A 0 HealThing(!(velx || vely || velz))"

[ACS]

6. The layer flags in HUDMessage aren't supported. Not a big deal or very high priority, it's a seldom used feature but just in case you're not aware.

7. SetMusic only supports 8-character long names, not full paths.

[MODELDEF]

8. INHERITACTORPITCH is broken. Like, very broken. The models using it display upside down and facing backwards, and don't respond to any changes in pitch at all.

 

Oh yeah, and MENUDEF. Why not ignore unknown option values? In ZDoom they're left as "unknown", but you could very well just gray them out or remove the entry completely. Surprisingly often, mods include shortcuts to various ZDoom options, but anything K8Vavoom doesn't have will cause an error.

 

1 and 2 in particular would be nice to have solved. They're the only things stopping QC:DE and D4T from booting up in K8Vavoom (and in fact at least D4T does play pretty nicely in K8V once that's resolved).
Also, since you can check if an actor exists using SpawnForced in ACS, could one K8V-exclusive actor that is always guaranteed to be there, be added to help detect K8Vavoom reliably? I'm currently using K8Gore_Blood for that purpose, but given that's been changing from a "mod" to a built-in feature, I'm kinda afraid it'll change in the future, again.

7 hours ago, TDRR said:

Hey, it's been a while

yah! great to see you again! ;-)

 

7 hours ago, TDRR said:

It's really awesome to see the shadowmapping, and in particular that it works with sprites!

that was one of the reasons i wanted it. i also hope to make it even faster in the future (i still have some ideas from Tesseract to explore).

 

7 hours ago, TDRR said:

Besides that, I've noticed some small problems with DECORATE, ACS and MODELDEF.

thank you! i'll put them in bugtracker.

 

7 hours ago, TDRR said:

1. Gotos jumping to non-existing states are a fatal error. … so perhaps those cases should be replaced with a Stop or Goto Null and let go with a warning?

the parser is quite messy, and currently the only reliable way to do it is to crash. alas. also, no mod author ever reads any warnings. ;-)

 

7 hours ago, TDRR said:

2. A_ZoomFactor requires two arguments, but the function in ZDoom actually doesn't require any.

fixed, thank you!

 

7 hours ago, TDRR said:

3. Weapon.SlotNumber has priority over Player.WeaponSlot, but in ZDoom this is the other way around.

i don't even understand how that code works anymore. yes, i wrote it, but… ;-)

 

actually, i deliberately did it that way, so weapon mods could override default settings. maybe i should try to prioritize the value from the latest loaded mod instead, dunno. have to think about that.

 

7 hours ago, TDRR said:

4. Projectiles, when bouncing on the floor (at least those of BounceType Hexen), won't count towards the counter that would put them into the death state

thnk you! bouncing code is fragile, and broken at places, so REALLY thank you for this bug.

 

7 hours ago, TDRR said:

5. "Spanish Inquisition says: in decorate, thou shalt use `|` to combine constants." has some false positives. As in, not even that it's called in places where flags are used properly or something, I mean stuff that uses ||, logical OR!

yes, Spanish Inquisition easily confused. that's why i made it into a warning instead of fatal error. it's there more for mod authors to double-check that they're doing it right. here, it is hard to say what the author really meant. usually, you can hush The Inquistion by adding extra parens, like: `((velx) || (vely) || (velz))`. looks stupid, but should work. ;-)

 

7 hours ago, TDRR said:

6. The layer flags in HUDMessage aren't supported.

yeah, ACS HUD is quite simplistic. it is WAY overcomplicated in ZDoom, and some things aren't even possible in k8vavoom without full HUD rewrite. i will do it someday, when i'll get to rewriting statusbar code (it is a HUD part too, in a very alien sense ;-).

 

7 hours ago, TDRR said:

7. SetMusic only supports 8-character long names, not full paths

as most other music changes, i believe, including MAPINFO. will think about it, thank you.

 

7 hours ago, TDRR said:

8. INHERITACTORPITCH is broken. Like, very broken.

and a lot of ther modeldef things, including matrix stacking. because nobody properly documented them. modeldef support rewrite is pending.

 

7 hours ago, TDRR said:

Oh yeah, and MENUDEF. Why not ignore unknown option values?

because the whole MENUDEF parsing is a gross hack. it supports only a subset that was easy to implement, and everything else is solved with "-nomenudef" ;-) and some menudef things simply cannot be implemented at all with k8vavoom UI.

 

7 hours ago, TDRR said:

could one K8V-exclusive actor that is always guaranteed to be there, be added to help detect K8Vavoom reliably? I'm currently using K8Gore_Blood for that purpose, but given that's been changing from a "mod" to a built-in feature, I'm kinda afraid it'll change in the future, again.

actually, it is more reliable now, because that actor will always be there, even in "-nogore" mode. i simply moved Gore Mod code into the main basepak, and the engine now knows about gore blood actors, and has some special code to process them. so they will stay there.

 

also, you can use `int CalcPlayerLight (int flags)` ACS extra function (index 861), it should never ever return 0 for k8vavoom.

On lundi 24 janvier 2022 at 6:08 PM, Gibbon said:

iVavoom 😄

ik8vavoom

Hmm...

ikvavoom?

ickvavoom!

https://i.imgur.com/a40Ez3E.png

8 hours ago, ketmar said:

yah! great to see you again! ;-)

Same! Very glad to see you never stopped improving this more and more, either.
 

7 hours ago, ketmar said:

the parser is quite messy, and currently the only reliable way to do it is to crash. alas. also, no mod author ever reads any warnings. ;-)

That is very true :p
I guess that's fine enough, I've already patched D4T v1.0.1.1 to work better with current K8V, so maybe I'll do the same, albeit with current QC:DE, given it's not likely to get updates anymore. Would be cool to play those awesome mods with a matching awesome port!
 

7 hours ago, ketmar said:

yes, Spanish Inquisition easily confused. that's why i made it into a warning instead of fatal error. it's there more for mod authors to double-check that they're doing it right. here, it is hard to say what the author really meant. usually, you can hush The Inquistion by adding extra parens, like: `((velx) || (vely) || (velz))`. looks stupid, but should work. ;-)

Good thing it's just a warning then, lol

I'll try to keep that in mind for my own stuff, thought there wasn't any workaround for a bit.

 

8 hours ago, ketmar said:

because the whole MENUDEF parsing is a gross hack. it supports only a subset that was easy to implement, and everything else is solved with "-nomenudef" ;-) and some menudef things simply cannot be implemented at all with k8vavoom UI.

Oh, that's actually fine then. I was mostly reporting that after thinking there probably was no parameter to do that (tried with -ignore-menudef because I recalled there's a -ignore-zscript which did work, so :p), but now it's not a big issue, thank you.

 

8 hours ago, ketmar said:

actually, it is more reliable now, because that actor will always be there, even in "-nogore" mode. i simply moved Gore Mod code into the main basepak, and the engine now knows about gore blood actors, and has some special code to process them. so they will stay there.

That's reassuring, good to know it'll stay then.

 

8 hours ago, ketmar said:

also, you can use `int CalcPlayerLight (int flags)` ACS extra function (index 861), it should never ever return 0 for k8vavoom.

Ah, that's very useful! Is the one parameter necessary or optional?

 

I'll try to continue testing and report any other inaccuracies and such. One I forgot, ACS Warp seems to not return a value, but in ZDoom it returns whether the warping failed or not.

29 minutes ago, TDRR said:

I was mostly reporting that after thinking there probably was no parameter to do that

try to do:

k8vavoom.exe --help 2>help.txt

;-)

 

29 minutes ago, TDRR said:

Ah, that's very useful! Is the one parameter necessary or optional?

it is necessary to not blow up k8vavoom. it is safe to call unknown ACSF with any number of args, tho: ACS VM knows the number of arguments, and should pop them from the stack even if it cannot execute the ACSF itself. ACSFs are a kind of a special opcode that explicitly records argument count in the compiled ACS code.

 

you can simply pass 0 as flags there.

 

29 minutes ago, TDRR said:

One I forgot, ACS Warp seems to not return a value, but in ZDoom it returns whether the warping failed or not.

thank you, i'll take a look!

 

29 minutes ago, TDRR said:

I'll try to continue testing and report any other inaccuracies and such.

and thank you again! ;-)

49 minutes ago, ketmar said:

try to do:

k8vavoom.exe --help 2>help.txt

;-)

K8Vavoom even has a help parameter? That one's very rare in Doom ports :p

 

49 minutes ago, ketmar said:

it is necessary to not blow up k8vavoom. it is safe to call unknown ACSF with any number of args, tho: ACS VM knows the number of arguments, and should pop them from the stack even if it cannot execute the ACSF itself. ACSFs are a kind of a special opcode that explicitly records argument count in the compiled ACS code.

Ah, great to know then. The idea is to help with K8Vavoom support, not kill it, so I'll definitely keep that in mind, heh.

 

And, this isn't an issue or bug per se, but it'd be nice to have. You know how there's two multiplier CVARs for light size and brightness in GZDoom? Could K8Vavoom get that too? It might sound a bit niche, but given Heretic and Hexen have almost no custom maps it's hard to fully appreciate all of K8Vavoom's lighting enhancements in them, and that'd help a lot, even more so with Hexen which has many light-casting objects around but their light is often too dim or small to be really noticeable.

 

EDIT: Oh, seems like Hexen MAP04 crashes on enter, with the following error:

Quote

Host Error: invalid pobj #2 configuration -- bad line #450 (invalid sectors)

 

Edited January 28, 2022 by TDRR

1 hour ago, ketmar said:

k8vavoom.exe --help 2>help.txt

If there's one thing I wish more ports had, it's a --help parameter.  Such a thing is IMMENSELY helpful when you're someone like me and live on a command line (and can't remember shit) ^_^

Actual pseudo-GNU-style-ish parameters would be nice, too (-- for long, - for short, I don't care about combining shorts or using = in longs though).

 

I had started this with that CrDoom port I started.  When I finally get back to it, I'll have to complete the CLI part.  I'm not afraid of breaking compatibility with my port.

7 hours ago, TDRR said:

K8Vavoom even has a help parameter? That one's very rare in Doom ports :p

6 hours ago, Remilia Scarlet said:

Such a thing is IMMENSELY helpful when you're someone like me and live on a command line (and can't remember shit) ^_^

this. there are so many of them, that i myself cannot remember what i have in k8vavoom, and how it is spelled. ;-) the list is built automatically from all registered CLI args, so it is always up-to-date.

 

(tbh, there are even more args there, some are hidden. ;-)

 

7 hours ago, TDRR said:

You know how there's two multiplier CVARs for light size and brightness in GZDoom? Could K8Vavoom get that too?

for now, there are only two debug vars to force fixed radius for all lights:

dbg_adv_force_dynamic_lights_radius

dbg_adv_force_static_lights_radius

;-)

i'll think about adding more control over it. the thing is that light size and brightness is not really linear (there are several different formulas for different types of light), and simple multiplying may look weird; it doesn't matter if you will multiply the original size/brightness from light definitions, or "real" calculated one, both are… strange. but i may add another set of "dbg_" cvars for it nevertheless.

 

7 hours ago, TDRR said:

EDIT: Oh, seems like Hexen MAP04 crashes on enter, with the following error

oh. i added a lot of strictness checks to polyobject code (to ensure that new 3d polyobjects are correct), and it broke some old and buggy maps. and as we all know, the official maps for all idTech1 games are hell-ridden with bugs. ;-) thank you! i will add a workaround.

 

i put all the things you reported to k8vavoom issue tracker, so don't worry, they won't be lost. ;-)

and some small status progress in case anybody's interested: since last year, nothing happened in k8vavoom. at all. ;-)

i am busy writing myself The Brand New Code Editor. already wrote 700+ kb of code, still cannot properly edit text files, lol. i need at least one more month to polish SXED (yes, you pronounced it right ;-), and maybe more (you know what it means when a programmers says "i need only one more month").

it doesn't mean that i am ran out of ideas for k8vavoom. i just ran out of patience, and want a better editor. and too lazy to learn any existing Big One (it is easier to write your own).

don't worry, k8vavoom is still The Main Project.

no tears, please. we have such sights to show you!

On 1/25/2022 at 3:57 AM, ketmar said:

you're more than welcome! i will happily put a link to your repository here and on k8vavoom site, if you'll do it. i don't want that in the main repo, but that's mostly it. i'm ready to answer any questions (if i know the answers, of course ;-), and to promote any porting efforts. so it could be "the official unofficial MacOS X port". ;-)

 

:) it will take at least quite some time.  20 minutes spent porting it got to me the dreaded part....  vavoomc.

 

Oh boy..  this will be interesting, because it is all coded to GCC'isms.  Even the goto statements are totally wrong for Clang :D

2 hours ago, Gibbon said:

Oh boy..  this will be interesting, because it is all coded to GCC'isms.

yeah. that's one of my reasons to reject patches: i am absolutely happy with gcc-specific code, and have no intentions to trade gcc extensions for "portability" (whatever it means ;-). and that's why i said earlier that maintaining the port will be a massive PITA, because i won't stop even for a millisecond before introducing Yet Another GCC'ism into the code.

 

and if you will manage to overcome that, you will face more subtle issue: unaligned memory access by casting pointer types left and right. the whole code is absolutely sure that any pointer can be casted into any other pointer, and minimum required align for any data is 1 byte.

 

also, "-fwrapv" is a must. the code simply won't work otherwise. and math should not be "fast" (i.e. inf/nan should not be equal to zero — this is one of the quirks of "fastmath" mode; there are more).

 

at least i am honest about all that. ;-)

1 minute ago, ketmar said:

yeah. that's one of my reasons to reject patches: i am absolutely happy with gcc-specific code, and have no intentions to trade gcc extensions for "portability" (whatever it means ;-). and that's why i said earlier that maintaining the port will be a massive PITA, because i won't stop even for a millisecond before introducing Yet Another GCC'ism into the code.

 

and if you will manage to overcome that, you will face more subtle issue: unaligned memory access by casting pointer types left and right. the whole code is absolutely sure that any pointer can be casted into any other pointer, and minimum required align for any data is 1 byte.

 

at least i am honest about all that. ;-)

That is totally fine and nice that your honest.  I may try using the GCC in homebrew to at least skip all that nonsense and get right to the parts that are more OS specific.

Is it possible to run ipk3 files in vavoom? For example, this one (of course, if there were no zscripts in it): https://www.moddb.com/mods/fate-a-doom-total-conversion/downloads/fatedoom-12

6 hours ago, camper said:

Is it possible to run ipk3 files in vavoom?

sure. just use "-iwad" CLI arg.

On 1/30/2022 at 5:35 PM, Gibbon said:

That is totally fine and nice that your honest.  I may try using the GCC in homebrew to at least skip all that nonsense and get right to the parts that are more OS specific.

Do be on the lookout for those OpenGL Program handle types; they are void* in macOS.

(2021, Dec 31 build)
Played a little Hexen with this port and alas the game goes into the console when you try to go from the level of Seven portals (map02) to Guardian of fire (Map04).

Edited February 9, 2022 by Kenon

5 hours ago, Kenon said:

Played a little Hexen with this port and alas the game goes into the console when you try to go from the level of Seven portals (map02) to Guardian of fire (Map04).

thank you! yes, it's a known bug, @TDRR reported it some time ago. polyobject checker have to be much more strict for the new 3d pobj feature, and raven's maps are as buggy as id's ones. ;-) sorry, there is no workaround for now, it will be fixed in the next public build.

 

p.s.: btw, there is conlog.log file the engine creates automatically, with all the text it printed into the console. i'm ok with screenshots, no problems, just thought that you might not notice it. ;-)

Im a little late....but thanks for the new build Ketmar!!!

On 2/9/2022 at 11:09 PM, Gunrock said:

Im a little late....but thanks for the new build Ketmar!!!

thank you! text editor project is going fine (i'm already using the new editor for development of the new editor), so i hope to return to k8vavoom soon.

 

(whispers) after i play all new wads i missed… from the last summer, oops… ;-)

@Kenon fixed, should work in the next build. as i am still working on SXED (around 2 mb of C sources, at least twice as much rewritten, and i'm not done yet ;-), i think i will fix some more small bugs, and release a maintenance build around… March, i hope. ;-)

Edited February 19, 2022 by ketmar

Ketmar: nice port!  Very fun to use.

 

I was playing ftp://mirrors.syringanetworks.net/idgames/levels/doom2/Ports/m-o/ma_val.zip (yes, because Decino just played it ;), and found that there is an irritating repeating sound (which seems to be associated from the ceiling/floor fan near the entrance, see screenshot).  Repro'd in today's master and the build561231 tag, Debian 11 / x64.

 

Not entirely sure why this sound it is being triggered by the fan -- no similar sounds play here in gzdoom.  Just in case other sounds from the mod were involved, I unpacked the zip+pk3, removed all the sounds and sndinfo.lmp, and the sound remained. 

 

I did some logging and it seems to be from sound 207 (lump 65929) (plats/pt1_mid: dsstnmov). 

 

I can work around it in source for now (faking an error) and all else is fine.  File with related logs attached (using the original .pk3 and "Warning: sound" logging and my hack active).

 

edit: I realized there is a gzdoom feature to show a "video feed" near this area, which isn't in this port -- not that I'd expect all those things to work here.  But that feed seems to refresh at the same rate as the sound does.  Maybe that's related?

log.zip

Edited February 20, 2022 by pramenid : possible reason

5 hours ago, pramenid said:

Ketmar: nice port!  Very fun to use.

thank you!

 

5 hours ago, pramenid said:

and found that there is an irritating repeating sound (which seems to be associated from the ceiling/floor fan near the entrance, see screenshot)

this is thing #168 (ambient sound #7). the engine somehow choose the wrong ambient sound for that: it should be "ambient 2", but the engine took something completely different. ;-) looks like a bug, i will take a look, thank you!

 

btw, you can use "mypos" console command to tell the engine to show your exact position, sector number, and even console commands to warp to that place. ;-)

 

and thank you for trying k8vavoom, and for your investigation!

@pramenid and i was totally wrong, lol. everything is ok with ambient sounds, it was invalid detection of insta-moving ceilings. that trick is used to create fan shadows, but the engine failed to detect that it is insta-move, and started ceiling move sequence each time. of course, on the next frame it aborts the sequence, because the ceiling arrived at its destination, so all you could hear is farting. ;-)

 

fixed in master, thank you!

Edited February 20, 2022 by ketmar : wording, as usual…

Quote

fixed in master, thank you!

 

Works, thanks!

 

And thanks for the tip about `mypos`... I was trying to find some way to get that to appear on the automap but gave up, lol.  Must remember the Quake influences :)

 

While I've got your attention... this issue might be a little deeper. 

 

In that same wad, at map start, after you go through the first available door and land at "695 648 0", then shoot the lone zombieman, the horde of enemies hidden outside the map all make a lot of noise and you hear them making noise for the rest of the level.  This also doesn't happen in gzdoom (where they stay silent and you're none the wiser about them until they teleport in after hitting a switch at "423 522 0").  Something something sound-blocking linedefs?

 

Ketmar: another report from "playing WADs in different engines".  I see in Hurt (https://www.doomworld.com/idgames/levels/doom2/Ports/g-i/hurt) that the smashing columns seem to have a miscalculation of their texture coords.  Right outside the entrance ("4594 -3740 -260").

 

Not sure if this is related to the warning: "Warning: /home/ejs/Downloads/games/Hurt.wad:decorate:104: Empty state detected; this may not work as you expect!"  This WAD is pretty but full of suspicious log messages...

 

 

 

hurt-log.zip

Also, sorry to report that in Hurt.wad, this elevator doesn't work (I hear the sound effects but nothing changes):  at "3809 -4148 -223".  (Also, the "leaking sounds from monsters" issue affects this WAD too.)

10 hours ago, pramenid said:

the smashing columns seem to have a miscalculation of their texture coords

thank you! UDMF texture coords calculations are completely fucked up: they aren't properly documented (especially when some scaling is used), and allow negative scales (which is complete nonsence). each time i'm fixing something in one map, some another map breaks. ;-) i'll take a look, thank you!

 

15 hours ago, pramenid said:

the horde of enemies hidden outside the map all make a lot of noise and you hear them making noise for the rest of the level.  This also doesn't happen in gzdoom (where they stay silent and you're none the wiser about them until they teleport in after hitting a switch at "423 522 0").  Something something sound-blocking linedefs?

there couldn't be any sound blocking linedefs, because they will block shooting sounds, and the enemies in those closets will never awake... unless it is done with joined sectors, and then the sound propagates through all joined parts, of course.

 

but sure, thank you, i'll take a look at what exactly is happening there. maybe i fucked up some condition again. ;-)

 

9 hours ago, pramenid said:

sorry to report that

why, it's great that you're reporting bugs! this is the only way to have them fixed after all. ;-)

 

9 hours ago, pramenid said:

in Hurt.wad, this elevator doesn't work (I hear the sound effects but nothing changes):  at "3809 -4148 -223"

and even more thanks! will take a look too.

 

i created tickets for all your reports, so don't worry, they won't be lost. thank you for your patience and willingness (is it a right word?) to report bugs!

as we have a fuckin' war here, the project is on hold now. sorry. have to play real-life CoD/Battlefield for a little. not my favorite type of games, tbh.