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

k8vavoom: no good thing ever dies! (2019, Nov 06 build)

Recommended Posts

well quakec has relatively little documentation (at least, less than most doom related scripting languages like decorate or ACS) and people get along with it just fine. Of course having the original quakec gameplay and entity definitions open source helps too. That and the fact that if you already know C or C++ there isn't much of a learning curve, the same can't be said for things like mapinfo or decorate since they are completely different so they need documentation of their own.

Share this post


Link to post

yet VaVoom C power went unnoticed for some reason, along with VaVoom client/server networking. it is fun to see zscript hype, knowing that GZDoom is ~8 year late to the party (and it still doesn't have c/s networking).

 

another fun fact: VaVoom C is way more C-like than Quake C. it is so close, that Janis were able to just cut-and-paste alot of engine code to VC, with small cosmetic fixes.

 

more fun facts: it is completely possible to move low-level LOS and coldet code to VC too. VaVoom C has access to all internal engine data, including blockmap and BSP tree. one day i'll do it.

Share this post


Link to post

IMO if a port isn't a respectable and usable *Doom* port FIRST, there is not much community interest in it for any kind of modding. Look at Doomsday and EDGE, not much interest there and they always have technical problems and bad compatibility.

 

Please poop out a binary when you're ready, so I can play through a vanilla megawad :D

Share this post


Link to post

actually, VaVoom had *better* DooM compatibility than k8VaVoom (yet k8VaVoom is more stable).

 

new binary release is scheduled for tomorrow. you will get your precious vanilla keyboard cheats, bugfixes, and more!

 

@therektafire sorry, no fullscreen fix in this build.

Share this post


Link to post

Can you quickly explain where the compatibility problems are? Do invisible sector tricks work fine?

 

And does it support all Boom stuff? Some Boom maps use "scripting" with voodoo dolls on scrolling floors for example. Do these work properly?

Share this post


Link to post
27 minutes ago, VGA said:

Can you quickly explain where the compatibility problems are?

there are (roughly) three types of problems.

 

first is purely visual, but ugly: "flat floodfill bug" from the original sw renderer is not properly emulated. for very simple cases like simple one-sector floor alcoves it works, but that's all. ceiling floodfill is not emulated at all.

self-referencing deep water is working, tho.

 

second is changed LOS calculating and monster AI. it is rarely a game breaker, but may be noticeable for expirienced player. (this includes omiting emulations for some vanilla bugs)

 

third is missing ACS opcodes and decorate actions. instacrash. include unimplemented linedef specials here. there are too many, and i am slowly implementing them.

 

27 minutes ago, VGA said:

And does it support all Boom stuff?

i don't know about all, but most stuff is supported. dolls and transporters are there, and glass windows, and "real water" (yet this seems to miss some specials). mirrors and portal-based RoR windows are buggy, tho.

 

tbh, i am not a big fan of those advanced things, so most of the time if something "advanced" is not working, i just: "meh. i bet that map sux anyway."

 

i am planning to write a new rendering backend, which should fix some FPS troubles, and some other rendering glitches. but this is completely new algo no sourceport ever did (nothing original, just different), so it will take some time, and in the end of the day it may sux even more than the current code.

 

i also should write a proper mapinfo parser one day. current one is The Ugly Hack, which just skips over most things in "modern" mapinfos.

 

tl;dr: most boom-compatible maps should work. some older zdoom maps will work too, but "modern", with uservars and scripts in decorate won't. and, of course, there will never be any kind of zscript support.

Share this post


Link to post
8 hours ago, ketmar said:

too bad that full VaVoom power is well-hidden, as nobody really tried to learn VaVoom C (except, probably, guys from Korax RPG project). but i can't really blame people here: it is not really fun to do it without proper documentation.

Well, Vavoom C is not for the faint of heart...

 

On the other hand, if one knows how to code in C, than Vavoom C won't be much of a problem.

Share this post


Link to post
3 minutes ago, HavoX said:

Well, Vavoom C is not for the faint of heart...

 

On the other hand, if one knows how to code in C, than Vavoom C won't be much of a problem.

it is not that different from zscript. the real problem is not the language itself (actually, with `auto` it even looks like a scripting language, yet with static type checking), but class hierarchy and internal engine API. after almost a year of working on k8VaVoom, i am still routinely hitting cases where i have to check both VC and C++ code to find out how to do something i want. with zscript, there is a big community to ask help, and with VaVoom C... well, even i may answer: "sorry, i don't know." feel the difference! ;-)

Share this post


Link to post

aaaand... tomorrow starts today!

 

changelog:

* improved mapinfo parser, so BTSX works now
* dehacked par times aren't lost anymore
* restored autoaim for hitscan weapons, so people can play without mouselook
* changed default bindings, so SPACE will open doors instead of doing a happy jump
* moved some gameplay options from "misc options" to "gameplay options" (wow!)
* removed unused BPP option (no, really, it did nothing at all!)
* implemented most of vanilla keyboard cheat codes
* fixed intermission text rendering
* added sprite for pistol pickup (this is all we need to make it work, lol)
* fixed use-after-free decorate parsing bug (how did it worked at all?!)
* fixed more "player has no weapons at all, go crash" script bugs

* console output is written to "console.log", you don't have to redirect output anymore
 

please, delete your config.cfg to get new Good Defaults. also, your saves are broken. sorry. it annoys me as much as you. i have an idea for better save format, but it is not a top priority task. let's hope that we won't break saves for next builds. at least you have cheat codes now!

Edited by ketmar

Share this post


Link to post

Played a couple of maps, my suggestion is to show a message when a save or quicksave is made and to have 1-2 extra slots for quicksaves only. They should be visible in the save list I think. Also there are some crazy options clugging up the menus .... a slider for SAVE COMPRESSION LEVEL? Who in their right mind implemented that? All those node building and cache options should just be set to the best defaults and nuked from the menu, too.

 

How do I disable those particle effects? They don't fit very well with the Doom graphics.

 

Also I again noticed that on my resolution (1680x1050) and with Ratio correctly set to 16:10 the end level screen graphics aren't properly centered. Default brightness was very low on my system and I had to increase it, not sure if it's just me.

 

Gameplay was fine but that Damage thrust thing sometimes looks ridiculous, I turned it off and would suggest to have it off by default. Does that Criticals option do anything if Headshots are Off? I turned Criticals Off just to be sure.

 

The most important thing is this: The sprite decorations are non-solid! I walk through them! Like those trees in the start of MAP01 in Doom 404

 

http://www.wikiupload.com/MT5YL84WX5741HJ

Share this post


Link to post
1 hour ago, VGA said:

Played a couple of maps, my suggestion is to show a message when a save or quicksave is made

it is shown in console. it is not that important to have it as HUD message, i think. i absolutely HAET those "game saved" messages, they ruining my immersion. and i already have 100500+1 options to control various features. ;-)

 

1 hour ago, VGA said:

a slider for SAVE COMPRESSION LEVEL? Who in their right mind implemented that?

me. there is a noticeable difference between 1, 6 and 9 for huge levels, for example. that was the reason i implemented it -- i want to have some easy way to control it.

 

1 hour ago, VGA said:

All those node building and cache options should just be set to the best defaults and nuked from the menu, too.

there is no such thing as "best setting" for them. there is a line between "user friendliness" and "user dumbiness". if i have some option implemented (and i did those options 'cause i needed 'em ;-), i prefer to give a user an easy way to control it. the rule is simple: if user don't know what it does, it is better to not touch it. but i see no reason to don't even tell a user that i have some options. besides, some of those features are still experimental, or have sense only when they are used together (like caching and PVS building). some options may require a brief description (it is in my TODO list), or better grouping, but i won't dumb the things down by removing options from UI.

 

1 hour ago, VGA said:

How do I disable those particle effects?

sadly, you can't. they are hardwired into actor definitions. that is, you can copy-paste default actor decorations, and remove 'em, but that's all. and if i'll implement a switch to turn particles off, boom levels will lost particle fountains (this is the same particle engine after all). i'll think about making effects toggable without affecting a fountains, maybe i'll be able to implement it with some light hackery.

 

1 hour ago, VGA said:

the end level screen graphics aren't properly centered

the whole UI system sux. this includes titlepic/interpic too: they're just scaled, without any attempt to maintain their ratio right. this thing should be rewritten.

 

1 hour ago, VGA said:

that Damage thrust thing sometimes looks ridiculous, I turned it off and would suggest to have it off by default

i thought i turned it off. oops. will do.

 

1 hour ago, VGA said:

Does that Criticals option do anything if Headshots are Off?

nope. it is actually a "critical headshot", so if there are no headshots, there are no critical headshots too. ;-) need better wording there, tnx.

 

1 hour ago, VGA said:

The most important thing is this: The sprite decorations are non-solid! I walk through them!

they are *sometimes* non-solid (that is, everything is ok on E3M1, for example). and i were pretty sure that it is something level author intentionally did, lol. now, i checked it in gzdoom, and oops... looks like a bug. tnx, i'll take a look at it.

 

thank you for testing! i will prolly upload a new build when i'll find out why those trees are suddenly became spectral.

 

as for titlepic, it will have to wait for some time. i know that it is ugly as fuck, and it hurts me too, but... rewriting UI system is tedious task, and i have some rendering bugs to fix; i'd better try to address rendering issues first.

 

but i may look into particles. tbh, i like 'em, but i think i would be able to find a way to implement a toggle. only... it may break your savegames yet again. i have better serializer implemented in standalone VC runner, but it is not trivial to backport it into VaVoom code.

Share this post


Link to post
10 hours ago, ketmar said:

also, your saves are broken. sorry. it annoys me as much as you. i have an idea for better save format, but it is not a top priority task.

I wouldn't bother trying to make a save format that is future proof.  I spent a great effort doing that with EDGE (long ago), but consider it a waste of time now.  ZDoom broke savegames all the time, and nobody stopped using it because of that, people will just finish their current game before upgrading.

Share this post


Link to post

Thanks for working on this! I have fond memories of checking out VaVoom builds to see new oddball features. Though it was never really a good port for actual playing, k8VaVoom already feels much more usable. A couple of things I noticed playing Doom 2 map01-map07 from the Oct. 17 windows build (another thanks for those!):

 

  • The pistol and chaingun don't have perfect accuracy on their first shot
  • The firing animation for the chaingun and plasma are both broken. The weapons function correctly (beyond the chaingun's first shot accuracy) but visually it looks like it skips one of the firing frames in the animation. I recall this being there back in regular VaVoom days and fixing myself in the decorate files.

 

I'll be keeping my eye out for future releases, best of luck with the hacking :)

Edited by Khorus

Share this post


Link to post
2 hours ago, andrewj said:

I wouldn't bother trying to make a save format that is future proof.

yeah, it is hard. but i know how to at least make it much better. as savegames are mostly dumps of the game objects, and the whole game lives inside VaVoom C VM, the only thing i have to do is to write objects as "field name, field type, field value" triple (i have all this info easily accessible). as saves are broken 'cause i added a field to some game class, on loading i can just set missing fields to default values (and ignore fields i removed). most of the time it may work, and when i know it isn't, i can bump save file version. i have this implemented, but vavoom's save system slightly more complicated than this (it intersperse VM data with C++ data written from `Serialise()` methods), so i have to slightly redesign the thing.

 

tbh, i am mad 'cause i just lost several saves with various interesting rendering glitches. i also want be able to get saves from people and if not load them, then at least inspect and reconstruct. anyway, i think that having file format with extra data is useful in many cases, and worth doing.

 

still, thanks for a nice insight. i myself usually really MAD when upgrade breaks saves. but i think with k8VaVoom i can say that we don't really have "releases" per se, and developement snapshots are expected to break things. sounds reasonable. ;-)

 

1 hour ago, Khorus said:

The pistol and chaingun don't have perfect accuracy on their first shot

wow. another vanilla quirk i completely forgot. i.e. it was working this way in original VaVoom, but worth fixing anyway. ;-)

 

1 hour ago, Khorus said:

The firing animation for the chaingun and plasma are both broken. The weapons function correctly (beyond the chaingun's first shot acccuracy) but visually it looks like it skips one of the firing frames in the animation. I recall this being there back in regular VaVoom days and fixing myself in the decorate files

tnx, i will check decorates. this is the part i didn't touched, assuming that decorate definitions are ok. they seem to be taken from older version of ZDoom, so i'll look if i will be able to simply upgrade decorates from some pre-zscript [g]zdoom release (as i am obviously too lazy to manually check each one ;-).

 

1 hour ago, Khorus said:

I'll be keeping my eye out for future releases, best of luck with the hacking :)

thank you!  it is great that people still remember VaVoom after all these years, and willing to spend time testing things i am throwing at 'em. ;-)

 

after this initial rush development will probably slows down somewhat (too little hours per day, i need irl console to change that cvar), but fear not! i always dreamt to be "known as a DooM developer", so i won't leave. as i can't make a playable map even to save my life, i'd better go with sourceport development. ;-)

Share this post


Link to post
6 hours ago, ketmar said:

yeah, it is hard. but i know how to at least make it much better. as savegames are mostly dumps of the game objects, and the whole game lives inside VaVoom C VM, the only thing i have to do is to write objects as "field name, field type, field value" triple (i have all this info easily accessible).

That sounds like a reasonable approach.  If I were you I would use plain text, omitting fields containing default values -- much nicer to debug.  Quake did this (if I remember correctly).

Share this post


Link to post

yay. you probably will never guess what made trees "spectral": it is dehacked processor! nope, not some bug with flags, wrong guess. it is about thing heights in the vanilla. tree (and many other things) are of height 16, while with current engines TorchTree is of height 64, and BigTree is 96. so the engine sees that new tree is so small, and doesn't count it as an obstacle. even if dehacked never touched that thing's definition. great.

 

p.s.: fixed. will do a bugfix release after some more testing.

p.p.s.: also fixed "first shot is perfect" (i accidentally it when tried to make some brutal shit code working).

 

1 hour ago, andrewj said:

If I were you I would use plain text, omitting fields containing default values -- much nicer to debug

it basically does exactly this. only writing values as binaries instead of plain text -- it is slightly easier to (de)serialize this way. but i can convert it to text and back with a simple tool, and that tool doesn't even know about VaVoom, VC classes and such. and it takes less space this way too, as strings/names are referenced by numbers. it doesn't omit default values, tho, just marks 'em as "default" -- in case i'll decide to change a default later (or to see what default value engine got -- like that dehacked bug i described above; dehacked parser changed all the defaults ;-).

 

p.s.: there is some binary data from the engine in savegames too, and it is interspersed with class data. so it is really easier to stick with binary format. i can just put a "binary blob" chunks, and skip 'em if necessary.

Edited by ketmar

Share this post


Link to post

new update (or, rather, quick bugfix):

 

* real mouse cursor will be correctly replaced with in-engine one when "allow mouse in UI" option toggled
* there will be no real mouse cursor in fullscreen mode, ever
* separate option to filter UI font and UI pictures
* fixed game-breaking bug in dehacked parser: it forced all things to vanilla heights, thus making some of them "spectral"
* added Stalagmite thing (5050)
* restored perfectly accurate first shot from pistol and minigun (actually, fixed refire bug i introdiced while tried to make some brutal shit code working)
* added experimental options to turn off various types of particle effects
 

@Khorus decorate for plasma is exactly the same as in GZ. it looks like some rendering bug with weapon models, or something. don't know yet.

Edited by ketmar

Share this post


Link to post

oops. original VaVoom thing coldet code is clean and nice... and completely broken for some cases. it was almost impossible to chainsaw fatso or spiderdemon. this is not the game i love! rewritten with GZDoom code, now it is DooM again!

Share this post


Link to post

Keep all the controls and settings that you want.  I am sure that my selections will vary until I find the right one, and may differ for different maps.  I am sure it will be different than what you would want.  And highly likely different than those who think there is only one good setting.  I prefer having the choice on anything that is questionable.

 

Don't have to make the savegame format future proof.  Just save a savegame version number in it.  I made DoomLegacy capable of loading the previous savegames since it got a version number.  Not that hard to maintain as it is the same optioning of old loading code, which is the similar to any other compatibility code.

I actually put a whole header on the savegame so I could identify some other things, like which wads it needed.  People tend to forget that when they come back to play it again.

 

Share this post


Link to post
4 hours ago, wesleyjohnson said:

I actually put a whole header on the savegame so I could identify some other things, like which wads it needed.  People tend to forget that when they come back to play it again.

yeah, savegame has version, and even chunked header with some data for UI. bad save usually won't even appear in UI (and won't load, of course). i am one of those people, for example. ;-) still, i prefer to have a limited number of slots, like in vanilla. so there is only date/time extra info for now (and some internal data).

 

problem with supporting old versions is that there is almost zero explicit savegame i/o code in the engine. most of savegame file is a dump of current VM state. if i change object layout, or some field type -- boom! saves are broken. but i'll switch to better format later.

 

4 hours ago, wesleyjohnson said:

I prefer having the choice on anything that is questionable.

yeah, me too. if engine has some option, i usually see no reason to not expose it. yet i really need to show descriptions in UI. one the first thing i did with VaVoom code was adding mandatory description to each cvar. those are mostly one-liners now, but i am planning to extend 'em, and use that help text in UI. and move most UI code to something like menudef.

 

UI system was one of the last things Janis moved to scripts: it looks more like a placeholder code. it ignores aspect ratio settings, it can't properly scale fonts and images, it has a full-featured hierarchical widget system for nothing (and hardcoded limits for some things -- despite fully implemented dynamic arrays in VaVoom C). it couldn't even remember cursor position after closing a menu.

 

p.s.: DoomLegacy rocks! it was my first expirience with sourceports.

Share this post


Link to post

Nice work you put on there. However, the MIDI seriously sounds like ass and I didn't find (or don't know) any option to change the MIDI playback system. It seems locked to TiMidity. Is there any way to change the soundfont it uses?

 

Also, what does the -bdw option mean?

Share this post


Link to post
16 minutes ago, Cacodemon345 said:

Nice work you put on there.

thank you!

 

16 minutes ago, Cacodemon345 said:

It seems locked to TiMidity.

yep. currently there are no other options.

 

16 minutes ago, Cacodemon345 said:

Is there any way to change the soundfont it uses?

"snd_timidity_patches" cvar can be used to set path to timidity config. note that you need proper timidity.cfg, just specifying a path to sf2 won't work.

 

16 minutes ago, Cacodemon345 said:

Also, what does the -bdw option mean?

this is built-in mod that will add (somewhat heavily modified) Assault Rifle and Shotgun from brutal doom. i like to play with those weapons instead of standard pistol and shotgun.

Share this post


Link to post

yay, new week, new update!

 

* fixed automap rendering, added "am_show_parchment" cvar
* restored "ddt arrow" on cheater's automap
* brand new code for thing coldet -- it is now possible to chainsaw fatso and spiderdemon!
* added "real" and "scaled" fullscreen modes (the later is using "letterbox mode")
* if GPU supports NPOT textures, the engine will not rescale textures anymore (UI and psprites will look MUCH better)
* raised player shot origin a little, so line attacks will go through crosshair (can be turned off)
* some code to show help for UI items
* always use internal blockmap builder (i'll need it later anyway, so why not?)
* it is now possible to set SF2 soundfont for Timidity with "snd_timidity_sf2_file" cvar (note that SF2 support in engine's Timidity is far from the good, though)
* you can put "gzdoom.sf2" to the directory where "vavoom.exe" is, and it will be autoloaded
 

@therektafire i added "scaled fullscreen" mode, which may solve your issue.

Share this post


Link to post

quick bugfix: it was almost impossible to hit things from above/below. hope this is fixed now.

Share this post


Link to post

I can't change the resolution, after i try to set it the port just "crashes" and keeps running in the background.

Share this post


Link to post

are you trying to set "real fullscreen" mode? k8VaVoom doesn't check if your videocard is capable of setting the mode you requested, it blindly believes that you're know what your doing. pls, try windowed, or "scaled fullscreen" instead.

 

otherwise, it looks like something on your side. this is the first such report i got, and i cannot reproduce the bug on my end. especially "keeps running on background" part is suspicious: the engine should either work, or "crash cleanly", shutting down itself. this may be GPU-related problem, dunno. to solve it, we need at least specs of your computer, and someone with (rougly) the same system to confirm the bug. sorry for inconvenience.

 

p.s.: you can try to workaround this by specifying resolution in command line, like this:

vavoom.exe +screen_width 1280 +screen_height 1024 +screen_fsmode 0

if k8VaVoom is able to init video for the first time, this may work.

Share this post


Link to post
4 hours ago, ketmar said:

p.s.: you can try to workaround this by specifying resolution in command line, like this:

vavoom.exe +screen_width 1280 +screen_height 1024 +screen_fsmode 0 

if k8VaVoom is able to init video for the first time, this may work. 

 

This worked, thanks.

Share this post


Link to post

yay. one brave person ported k8VaVoom to nintendo switch (with homebrew sdk). eat that, GZDoom! ;-)

Share this post


Link to post

not yet. i am mostly playing without statusbar, so it got almost no love. it is not even aspect-corrected.

 

that is, there is a way, of course: write mod in VaVoom C, 'cause all the drawing is done via scripts. but nothing user-friendly yet. tbh, i am not sure how to implement it. not code-wise, but how to design it, so it will be both flexible and user-friendly. ideas are welcome! ;-)

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
×