Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
ketmar

k8vavoom: no good thing ever dies! (2020, May 12 build)

Recommended Posts

Just posted the release of Dissolution:Remastered in this post. Works great in K8Vavoom!! Only bug I found was that the text in the beginning map is crunched together. However in GZDoom its tiled correctly. Other than that, everything seems to run correctly.

Please report any glitches or feedback.

Thanks again Ketmar for your remarkable work on K8Vavoom!!!

Share this post


Link to post

@Gunrock great! i am working hard on a new public build right now, so expect it in a day (i guess). but i will definitely take a look later this day.

 

as for text, i see, this is ACS HUD issues. it is something that is quite hard to solve given that ACS expects a fixed screen size and font size. i had to choose between integral scaling or good positioning. both choices are bad, tbh, but this is something i cannot change yet. GZDoom does ACS HUD in a slightly different way, so what is working there won't work in k8vavoom, and vice versa. if i'll fix vertical offsets for this case, it will break other cases. i didn't found a good solution yet.

 

anyway, it is a minor issue (i believe). i may solve it eventually, but for now i simply don't know how. sorry.

Share this post


Link to post

so, without further delays, here it is! fresh and hot, the new build for you all!

 

brief changelog:

Spoiler

* implemented `SetSectorDamage`, `DropInventory`, `IsPointerEqual`, `CanRaiseActor` ACS functions
* damaging 3d floors are correctly (i hope) processed now (this includes damaging 3d water)
* skip autosaves on map enter if we loaded pwad with maps, and entering iwad map
* fixed bug in TID manager (dead objects sometimes still occupy TIDs for a tic)
* `Thing_Destroy(0)` and `Thing_Remove(0)` work now
* replaced libvorbis with stb_vorbis (should be user-invisible change ;-)
* replaced libflac with dr_flac (should be user-invisible change ;-)
* replaced libmad with dr_mp3 (should be user-invisible change ;-)
* replaced opus libraries with built-in copies (should be user-invisible change ;-)
* that is, k8vavoom now requires only SDL2, OpenGL and OpenAL external libraries by default
* added OPL music player (based on NukedOPL synth, experimental)
* menu code rewrite (slightly more logical, and menu title won't be scrolled away anymore)
* added combobox selectors to "choice" menu items
* better slider control (looks nicer, and it can be properly operated with mouse now)
* new color selection widget
* added automap color options
* use more VBOs in renderer (we're slowly moving towards full-shader rendering path)
* it is now possible to render the screen in lower resolution and upscale it (so you can lower rendering resolution for 4K monitors, for example, while still running k8vavoom fullscreen; that could save some GPU resources)
* added option to set maximum UI scale (you can set it to 1 to get unscaled UI and fullscreen HUD, for example)
* added "always run" to gameplay options menu (thanks, k_1nspired)
* fixed VavoomC compiler bug with class definition order (defining superclass after subclass could cause some bugs)
* allow animated sequences in pk3 files (some mods like Gothic Dreams:DE are using it) (thanks, Gunrock)
* `SV_PointContents()` should understand Vavoom water again (thanks, Gunrock)
* "HideConsole"/"ShowConsole" now accept "immediate" argument
* added options to disable lightmap recalculation when static light source moved/map geometry changed (see "options -> video -> advanced video")
* added optional maximum time for static lightmap recalculation (default is 5 msecs)
* slightly better sprite lighting in lightmapping mode (use light sources to determine lighting, like shadow volumes do)
* converted Strife ACS helper to VavoomC code (sorry, your Strife saves are broken now...)
* fixed rocket swallowing on hitting a sloped 3d floor/ceiling (thanks, Mr.Rocket)
* hitscan attacks somethimes may go through 3d slopes; this should be less the case now (thanks, Mr.Rocket)
* added support for missing thing UDMF properties (gravity, render options) (thanks, Mr.Rocket)
* fixed stupid copypasta bug with UDMF vertex heights for ceilings (they weren't working at all) (thanks, Mr.Rocket)
* load whole texture to memory for faster format detection (cut down LZMA-compressed PK3s loading times by at least two orders of magnitude)
* partially implemented ACS function `QuakeEx()`
* added "acs_abort_on_unknown_acsf" cvar (default is `true`)
* added "acs_emulate_zandronum_acsf" cvar (setting to `true` emulates `GetPlayerAccountName`)
* added built-in flat glow definitions for Doom/Doom 2 iwad (only) flats
* implemented "sv_disable_run" cvar
* added support for game types in lockdefs
* most console cheats like "god" now accept optional boolean argument
* added experimental HacX v1.2 IWAD support (-hacx)
* fixed bug with OpenGL light definitions (old class definitions could override definitions for replacement classes) (thanks, TerminalHash)
* it is now possible to add dynamic spotlights in VFXDEFS

 

@-TDRR- hi! ;-)

Share this post


Link to post
32 minutes ago, Cacodemon345 said:

Why the weapon lights flicker?

what do you mean? muzzleflash lights? mostly because dynamic light system works this way. and because i like it, so i don't see any urgent need to change it. not really my conscious decision, this is how Janis implemented it.

Share this post


Link to post

also, please note that intermission screens may be a little broken in this build. my work on UI is far from finished, and i always forget to check it with different UI sizes. but you can set min/max UI scale in screen resolution menu (for now it affects all kinds of UI). i'm working on that, and in the next build at least intermission should look much better regardless of resolution and UI scale.

Share this post


Link to post

very experimental lightmap tracer through texture holes. don't expect it to be much better, but it is still... fun.

 

Spoiler

xa5wsa.png

 

Share this post


Link to post
Posted (edited)

Hey there, I don't have the time to read the whole thread, I was wondering if this source port has known issues/bugs that could potentially break a level? I really like how K8vavoom looks and how smooth is performance-wise, I could see myself using it as my default source port. Anyway, I was playing the wad ''Lunar Catastrophe'' and during map 8 there is a teleporter that brings you to a room, after a few seconds in that room I get taken back to the main menu, I assume it's a crash although I don't get any crash notification. Just wondering if there are known game breaking bugs that could explain it? cheers

 

EDIT: Nevermind I read the first post in its entirety: ''MY FAVORITE MOD IS NOT RUNNING, K8VAVOOM.EXE JUST CLOSED! WUTTA?!!!

engine's decorate/acs/mapinfo support is not complete. you probably hit something unimplemented. there is "conlog.log" file with console log and error messages. you will probably find some (many) errors there. for curious: decorate scripting is not fully implemented yet. but we are working on it.''

 

I guess this must be the culprit, I should take a look at the conlog.log file.

Edited by Kafelnikov

Share this post


Link to post
Posted (edited)
5 hours ago, Kafelnikov said:

if this source port has known issues/bugs that could potentially break a level?

yeah, it is not perfect (yet). ;-)

 

the most noticable breaking things are:

1. boom transporters are not right. the speed is slightly different, and the effects too. most of the time it is still ok, but may break some maps with fragile "voodoo doll scripting". this is because Vavoom (and k8vavoom as its continuation) are the only freestep Doom engines out there. while it is very useful in alot of cases, variable frame rate makes some things harder. sorry.

2. ZDoom ACS extensions are not fully implemented. usually if the engine hits some unimplemented function, it bombs out to title screen. you can open the console (usually with "`") to check if there is some error. this may be your case.

3. DECORATE support is not complete. it is hard to implement everything ZDoom did in ten years, and some things are even impossible (like player morphing support). usually k8vavoom just ignores the things it cannot understand, but this may break some maps later.

4. some vanilla rendering exploits are not implemented. like flat floodfill bug, for example, and other renderer abuses. they're quite hard to implement properly in hw renderer. those bugs are purely visual, tho.

5. the physics/coldet is not 100% identical to vanilla too. but there are not so many maps that wants strictly vanilla behavior anyway.

6. various advanced GZDoom features (portals, PBR, zscript) are not supported, and will never be supported (due to engine differences, and/or different project vision).

 

that's basically it. k8vavoom plays alot of maps (and it is the only sourceport i am using to play Doom, of course ;-), but there are always... let's say inventive things people do. feel free to report non-working things here (link to the wad, output of "mypos" console command, and steps to reproduce), and i'll try to explain what it wrong, and maybe i'll be able to fix it.

 

and last, but not least, thank you for trying k8vavoom! i am glad you like it. i am constantly working on making it faster, better, and with more features. stay with us, we have even more sights to show you! ;-)

Share this post


Link to post
19 hours ago, Kafelnikov said:

Anyway, I was playing the wad ''Lunar Catastrophe'' and during map 8 there is a teleporter that brings you to a room, after a few seconds in that room I get taken back to the main menu, I assume it's a crash although I don't get any crash notification. Just wondering if there are known game breaking bugs that could explain it?

p.s.: this "bug" is called "episode finale". ;-) you finished episode 1, and got finale screen. this is exactly how it should work.

Share this post


Link to post
Posted (edited)
8 hours ago, ketmar said:

p.s.: this "bug" is called "episode finale". ;-) you finished episode 1, and got finale screen. this is exactly how it should work.

 

Ahah now I feel like an idiot, the map was a homage to Phobos Anomaly and it didn't cross my mind at all.

I'm gonna keep playing them wads using K8vavoom then, thank you and really great work with the port. cheers

Share this post


Link to post
Posted (edited)

ah, don't mind it. i didn't get it too until i started the map and made may way to its end. ;-) and thanks for reminding me about this wad, i'll prolly replay it now. i mean, i'll test k8vavoom with it, of course, i don't have time to play games, only for fully testing pwads!

 

;-)

Share this post


Link to post

@Kafelnikov but there should be finale text, and it is missing. this is something i've been reported several times, and each time i'm forgetting to fix it. that's why you're so confused, i guess.

Share this post


Link to post

@Kafelnikov i fixed finale text, so it should work as intended in the next public build. thank you for the report!

Share this post


Link to post
Posted (edited)

eh. spent almost three days rewriting big part of VC compiler codegen. as Janis left us with no compiler tests, and my tests are far from having good coverage (i also found a bug in one of my tests, lol), let's hope i didn't fucked up too much.

 

technobabble for those who are interested in changes, for some strange reason.

Spoiler

VavoomC is not as easy as one may think. it has two data types which need to be managed: strings and dynamic arrays. both those things are dynamically allocated, and the compiler should take care of deallocating them automatically.

 

in the original VavoomC Janis was simply collecting all local variables in one big list, and emiting cleanup code right before `return`. that was elegant, and it worked. there was another little problem, tho: foreach iterators.

 

internally, foreach iterator is dynamically allocated too, and it should be freed after using. Janis did this by tracking all allocated iterators while the function was running, and killing them all together at exit. not the best way, but hey, it worked too, and it was simple. (actually, it was slightly more complex, because "proper" loop exit will destroy iterator by itself, and remove it from the list; but the maing thing is that those iterators aren't kept in any local variables, so they had to be tracked separately).

 

later, i added several more foreach types (iota, scriped, on array), and iterator management started to being unmaintainable. i wrote a very-very dirty solution with manual scope tracking in codegen, and it worked (to some extent), but it was REAL UGLY.

 

also, with the scheme Janis used, i couldn't implement stack space resusing. i.e. there was no way to reuse stack slot for different local variables in different scopes (due to destruction code emited before `return`).

 

i finally decided to remove my hack, and rewrite scope management code. internally, scope information is available, because of recursive nature of the compiler. i.e. block statement (`{ ... }`) has `Emit()` method, that will call `Emit()` methods for each statements inside the block. i.e. in each `Emit()` we have a perfect list of all "upper" scopes.

 

when i realised that fact (yeah, call me slowpoke and idiot here, you'll be right!), i removed my old hack, and changed local variable allocation scheme: now, if we have any locals, they are allocated at the beginning of `Emit()`,  and "released" at the end (with proper destruction, if necessary). this way i can reuse stack slots, have perfect knowledge of all active locals at any time (so i can generate proper destructor calls on `break` or `return`), and more -- i can track all foreach loops, and generate proper opcodes to deallocate hidden iteration objects.

 

the most frightening part here is "stack slot reusing". of course, i can turn it off, and simply go with the old scheme (never "releasing" stack slots i don't need), but it is not fun.

 

ah, if you don't know (and i bet you don't! ;-), there is no "uninitialised variable" problem in VavoomC, because all variables are guaranteed to be initialised to some default value (zero, `none`, `nullptr`, empty array, etc.).

 

so, with the old scheme i could simply `memset()` all the slots the function is using, and have my default values in place. but with stack slot reusing, some local could take a slot that is "dirty", so i have to detect that fact, and zero such slot.

 

sure, the easiest way is to simply zero each slot before using. but this emits alot of unnecessary VM opcodes, and each additional opcode adds to the execution time. so i had to write some logic to avoid unnecessary clears. this logic is quite complex (because there is no need to clear freshly allocated slot, for example, but only if it is not inside some loop -- because on each loop iteration the code expects all loop scope variables to be cleared), and it was hard to debug it (especially without the proper test suite).

 

and you know what? i found some really old bugs in the compiler while writing all this. "in-loop" variable clearing may sometime fail (yet i knew that, and wrote most of new k8vavoom VC code with that in mind, heh ;-), for example. and one of my tests that checks such thing had a bug in it, so it was actually checking if the bug is still in place instead of if it is gone. ;-)

 

anyway, the rewrite is almost finished now, i added some more tests for the bugs i found, and i am quite happy with the current compiler design. and we are one step closer to register VM. and when we'll have register VM in place, it will be MUCH easier to integrate libjit, to run VavoomC with native speed instead of in VM.

 

i don't know why you're still reading this, but i hope that my wall of text had at least something interesting to justify all your time wasted on it.

 

Edited by ketmar

Share this post


Link to post
Posted (edited)
5 hours ago, ketmar said:

I don't know why you're still reading this

 

I'm a guy geek who asked GZ 'when are we getting property accessors in ZScript' - that answer your question? :p

Share this post


Link to post
Posted (edited)
5 hours ago, Martin Howe said:

I'm a guy geek who asked GZ 'when are we getting property accessors in ZScript' - that answer your question? :p

(whispering, but loudly) VavoomC is more powerful than ZScript! dynamic arrays of arbitrary types (including any user data types, and other dynamic arrays)! dictionaries with arbitrary key/value pairs (almost)! recently added methods for structs (not really needed with UFCS, but why not)! UFCS! paren-less function calls! references and pointers! four types of `foreach` iterators! string slicing! come close, it doesn't bite! ;-)

Edited by ketmar

Share this post


Link to post
Posted (edited)

trying to figure out portal code. if you won't move the camera, it looks great. of course, it breaks horribly if you'll try to walk, but hey, at least i can make pretty screenshots!

 

Spoiler

qrk7yk.png

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×