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

k8vavoom: no good thing ever dies!

Recommended Posts

wait no more, my friends, we have a new build here! remember, remember the saints in november!

 

gibbing in smoothdoom is not working, i know. but don't know why. ;-)

 

* created some textual menu definitions for UI, so mods will be able to extend menus without writing VC code (not finished yet)
* properly quote bindings, cvar values, etc. (WARNING! your old config may be partially broken!)
* changed save file format -- it should be more tolerant to internal changes now
* almost half of game menus are defined in common "uidef/" now
* don't send UI events to dead widgets
* added `float` constants support in decorate
* added support for `A_JumpIf(cond, +number)` to decorate (SmoothDoom is using that, for example)
* more decorate actions and extensions (as usual ;-)
* implemented CVARINFO parser
* implemented limited support for gzdoom-style MENUDEF
* implemented `A_Quake()` decorate hack (hey, SmoothDoom, you're doing it wrong!)
* implemented most of `AAPTR_xxx` flags (in terms of VC code support, not for all decorate actions yet)
* fixed bug in lockdef parser: class searches should be case insensitive
 

Share this post


Link to post
37 minutes ago, ketmar said:

@slash004 bdlite is not crashing anymore. yet it is still not working right -- no sounds, and keys not working.

Do you know why sound a keys ain't working btw? About gibs I think this is due to decals (I may be wrong), there is an obscure mod called mega-blood.wad which  has decals based gibs working correctly under k8vavoom.

Share this post


Link to post
1 hour ago, slash004 said:

Do you know why sound a keys ain't working btw?

not yet.

 

1 hour ago, slash004 said:

About gibs I think this is due to decals

dunno. i have to look into decorate code to find out what goes wrong. i didn't really looked what smoothdoom does yet, just implemented the things k8VaVoom complained about -- and it worked. ;-)

Share this post


Link to post
13 minutes ago, ketmar said:

not yet.

 

dunno. i have to look into decorate code to find out what goes wrong. i didn't really looked what smoothdoom does yet, just implemented the things k8VaVoom complained about -- and it worked. ;-)

And yet SmoothDoom is pretty much fully featured under k8vavoom (excluding the gibs part). Quite impresive stuff @ketmar :)

Share this post


Link to post

aha. i see. missing gibs has nothing to do with decals, or sprites, or anything else: this is bug in label resolving, so `A_JumpIfCloser(128, "XDeath")` (and other A_XXX label jumps) sometimes got "empty destination" (which simply removes an actor). of course, this bug may affect other mods too. now i only have to fix it, and gibs will be there. ;-)

Share this post


Link to post

@ketmar are keys working for you with SmoothDoom?

I remember from my first test working but somehow keys aren't working anymore, just like on BDLite.

Share this post


Link to post

Welp, I forgot to mention that I played with SmoothDoom's options, perhaps that is how I did break keys, shall try out with a clean config, just in case.@ketmar

Share this post


Link to post

@slash004 check if you updated all .pk3 files. also, yep, consider starting with new options.

 

some more exciting news for you: bdlite keys are working now.

Share this post


Link to post

Hm so after downloading the newest version it seems like the gameplay is a lot faster than it should be to me, not sure what that is about.

Share this post


Link to post

@therektafire dunno, it didn't changed for me. try to delete "config.cfg", it may be broken (i changed writing/parsing code a little). otherwise, there should be no changes (and i see no changes on my side)...

 

@slash004 ok, bdlite sounds are working now too.

Share this post


Link to post
15 minutes ago, therektafire said:

Hm so after downloading the newest version it seems like the gameplay is a lot faster than it should be to me, not sure what that is about.

 

I've been noticing some timing issues. On my zen Win10 desktop, the game feels like its 3/4 real speed when capped at 90fps. Uncapping the framerate shot it up to several hundred fps and it felt like the gameplay played at the speed it should.

 

This is on the last version though, will test on the new one later.

Share this post


Link to post
7 minutes ago, ketmar said:

@therektafire dunno, it didn't changed for me. try to delete "config.cfg", it may be broken (i changed writing/parsing code a little). otherwise, there should be no changes (and i see no changes on my side)...

 

@slash004 ok, bdlite sounds are working now too.

Rly? Nice! I shall give a shot tomorrow. Btw idk if this is an issue related to k8vavoom, but with bdlite the vanilla pistol is the start weapon instead of BD's rifle, you likely know this issue but pointing it out does not hurt :)

Share this post


Link to post

@Khorus i just checked it again -- it seems to be the same speed as gzdoom. i didn't changed anything related to game speed at all, and honestly don't know how it can be different. anyway, after uploading the last build, i removed some hacks in decorate parser, and cleaned up some code (back). will prolly upload another build soon, maybe it will solve those heisenbugs.

Share this post


Link to post
13 hours ago, ketmar said:

@Gunrock alot.

first, implement md3 support. doable, and in my TODO list (yet it is not a small task -- i need to basically rewrite the whole model rendering code).

second, implement gzdoom modeldef. doable, absolutely not in my todo list.

otherwise -- i just made another decorate fix, and it works. yet it is very hard to play without graphics. ;-)

 

p.s.: i'll look later if it will be possible to write a conversion tool to translate gzdoom modeldef to vavoom's models.txt.

 

little explanation: i will implement gzdoom definitions support only if it is possible to do in pure VaVoom C. currently models cannot be defined from VC (lack of design and API, mostly), so no support to modeldef.

 

in the future i will try to move almost everything (map loaders, other parsers, etc. -- except decorate parser, of course ;-) to VC side. the more things i will move to VC, the more gzdoom misfeatures we'll be able to support. like cvarinfo and menudef, for example -- they're done completely in VC, no C++ engine changes were made.

Thank you again ketmar for explaining that to me. The Quake weapons and items mod was one of my favorite mods to use.

Share this post


Link to post

@Gunrock it is not that hard to guess from your SSA. ;-) anyway, this is not something i can hack in weekend, so sorry -- you'll have to wait for some (probably long) time until it will work. besides that, VaVoom model rendering is hardcoded to use md2 data structures and layout. alas, i need to completely rewrite that code, and currently it is not something i really want to do -- tbh, that code is a mess. most of VaVoom code is great, but model rendering looks like something that was hacked in for "to be replaced with proper implementation later", and then it stuck. ;-)

Share this post


Link to post

seems that i found some obscure shit bdlite is doing with playerpawn, so playerpawn replacement is working now. i.e. bdlite is almost fully working. that is how far i'll go with it: brutal doom is shitload of shit, and bdlite is just shit. sorry. no offences to bdlite author, but brutal cannot be recovered, it should be burned with fire.

Share this post


Link to post
On 10/29/2018 at 12:41 PM, ketmar said:

yep, GNU/Linux systems are DIY. i am not planning to create any kind of binary packages -- compiling the sources is The Right Way. it is not hard at all (easier than to find a matching pair of socks, actually ;-). once you'll stop worrying and love compiling, you will become rich and famous.

 

less schizo: i am unable to do binary GNU/Linux builds anyway -- my binaries just wouldn't work on your system. or on most other systems out there. you need either volunteer maintainers to build packages for your OS, or build from sources yourself. i recommend the later.

Thanks for the answer.  Though, I have had bad experiences when compiling from source code in the past.  From 6 program tries, 3 programs compiled successfuly.  It's frustrating when you receive an error like 

recipe for compiling 'something.cpp' failed

No idea what went wrong, very hard to look help for an specific error/topic like that, I'm no programmer, so I prefer to go for *.deb, or *.run installers, or at least adding a custom personal PPA like the TeamDRD one and install it from there. 

 

Thanks for the help anyway

Share this post


Link to post
7 hours ago, ketmar said:

seems that i found some obscure shit bdlite is doing with playerpawn, so playerpawn replacement is working now. i.e. bdlite is almost fully working. that is how far i'll go with it: brutal doom is shitload of shit, and bdlite is just shit. sorry. no offences to bdlite author, but brutal cannot be recovered, it should be burned with fire.

Fair enough, but now thanks to your hardwork, tons of non-zcript mods should work now :)

Btw I tested several days ago the PSX Doom TC and didn't work, any chance to support it? I think PSX Doom is worth of a try.

Share this post


Link to post

@Gato606 i'd say that 50% success rate on something you don't have expirience in is a very high number! ;-) sure, i understand that you (and most other people) want to use program to solve their tasks (or play games ;-), not circle-strafing it, dodging errors, and waiting until boss dies it builds. ;-) let's hope that someone will step in to build binary packages.

 

funny thing: cross-compiling monolithic (static) binary for windows is way easier. not because windows is better, but because on windows nobody ever cares about proper packaging, library versioning and such stuff. so one can just dump some binary mess and call it a day. and i don't even have windows installed! ;-)

 

you still may try to compile k8VaVoom, and PM me with your questions. i don't promise to answer correctly (i am on Slackware, after all, our ways of doing things are quite different ;-), but once we'll do it right for the first time, next builds should be flawless and effortless.

 

@slash004 heh, i'm not stopping improving decorate support. i just stopped turning k8VaVoom code into pile of shit while trying to support other pile of shit. from now on, MOD AUTHORS SHOUD FIX THEIR BROKEN CODE. not vice versa. ;-)

 

as for PSX Doom -- chances are very low. i don't remember right now what is wrong with it, but i remember for sure that it had something VERY wrong. so wrong that i didn't even left it to check later, but outright deleted the whole thing. which usually means "it FUBARed."

 

p.s.: still, bdlite looks like working. at least i was able to complete two or three levels, with usual bd screen crapfx on players' helmet glass and such. of course, it starts with proper weapons now and so on. and it even screams after dying (yep, in bd, dead body screams).

Edited by ketmar

Share this post


Link to post

something wicked this way comes... and brings you yet another update!

 

* implemented `CheckFlag` and `SetFlag` decorate actions and ACS opcodes (not properly tested yet)
* more reliable "+n" resolver -- no more special per-mod hacks
* accept some wrongly-typed arguments for decorate actions (and show warnings) -- even less per-mod hacks
* fixed decorate bug with "Super::Name" states as action arguments (inverted condition)
* `FindStateLabel()` method now correctly finds old label names like `XDeath` (gibs in smoothdoom works now)
* `FindInventory()` should check for entity replacements too (so replaced keys will work, for example)
* search for sounds in more places, so more SNDINFO will work
* spawn proper replacement items for default player items
* implemented "-nomenudef" CLI arg to skip gz-menudefs
* implemented player classes from MAPINFO (and CLI arg "-nomapinfoplayerclasses" to disable it)
* replacement player pawns without some required states still works (and no more bdlite support code evar!)
* implemented (partial) parsing of new-style skilldef in MAPINFO
* fixed `A_BarrelDestroy()` decorate action; added "sv_barrelrespawn" option support
* added gameplay option to turn off pushable barrels
* some fixes to HUD display -- fullscreen cutscenes with custom HUD now looks better (but not fully correct yet -- should not be rendered over statusbar)
* "r_statusbar_draw" cvar to turn off status bar (some mods looks better in fullscreen without statusbar)
* better ACS `GetPlayerInput()` handling (more keys works, so you can control/skip more cutscenes, lol)
* process thing 9200 (decal); this is not a real thing, so you cannot control it with scripts

 

 

p.s.: thanks to all testers. i don't know what caused speed problems you're observing, tho. maybe this build fill fix it. please note that if you're testing with bdlite, the game will indeed look faster, and with more aggressive monsters!

Share this post


Link to post

Ahh, another sweet update as always, thanks @ketmar :)

Btw I'm not quite satisfied with how k8vavoom handles blood fx on mods, for example, there is the [URL=https://forum.zdoom.org/viewtopic.php?f=19&t=50448]Nash Blood mod[/URL] and the blood looks quite plain under k8vavoom. This is how Nash Blood should looks like:

 

 

Edit: on the [URL=https://forum.zdoom.org/viewtopic.php?t=59260]Universal Gibs mod[/URL] is way more evident, instead of showing the Q3-style gibs, it just shows vanilla gibs.

 

Edit. Nvm, Universal Gibs uses zscript shit.

Edited by slash004

Share this post


Link to post

sure nashblood looks bad -- it doesn't work at all. it doesn't even loads, so i don't know how did you managed to test it. ;-)

Share this post


Link to post
3 minutes ago, ketmar said:

sure nashblood looks bad -- it doesn't work at all. it doesn't even loads, so i don't know how did you managed to test it. ;-)

I tweaked it by wiping A_SpawnItemEx :)

Share this post


Link to post

so don't expect it to work as intended then -- you broke it, and it is broken for sure. ;-)

 

also, we don't have floor-aligned sprites yet, so floor blood splats will look like shit. actually, i can do proper floor decals, but as gzdoom cannot into that, there are no mods to support 'em (and i don't spawn decals on floor/ceiling). the code doesn't care, though -- it can render decal on any surface, be it a wall, a floor/ceiling, or a slope.

Share this post


Link to post

@slash004 but i implemented missing actions, so nashblood loads properly now, and sprays those funny blood sprites. as for floor splats -- they're in md3 format, and there is no support neither for md3, nor for modeldef in k8VaVoom (yet).

 

p.s.: please, provide links to download sites that works without javascript (like catbox.moe), so i'll be able to check mods. this one was lucky, but dropbox/googledrive is usually "cannot download, wontifx". sorry.

Share this post


Link to post

@ketmar Why is it that k8VaVoom can render decals in flats but GZDoom can't? Is it because of how their rendering engines are coded?

Share this post


Link to post
28 minutes ago, KVELLER said:

Why is it that k8VaVoom can render decals in flats but GZDoom can't? Is it because of how their rendering engines are coded?

yeah. GZDoom needs to calculate exact decal texture coordinates, which is easy for walls (clipped decal will always be a rect), but much harder for floors (you need a full-featured polygon clipper for that). and you often have to recalc clipping when something's changed in sector.

 

and i am really lazy, so in k8VaVoom i didn't bothered to do any math clipping, i am using stencil buffer instead. so i can clip decal to arbitrary rendered shape with zero efforts.

 

it is not GZDoom fault, tho: Graf did his decal renderer at the times when stencil buffer was at max one bit deep, and sometimes it wasn't available at all. but it is 2018 now (yay, almost 2019!), and k8VaVoom require a GPU with FBO support, which pretty much guarantees 8-bit stencil buffer. for various reasons using the same tech in GZDoom is much harder.

 

so, to make a long story short, i just cut some corners by requiring a more powerful GPU. it is good to live in 2018! ;-)

Share this post


Link to post
Guest
This topic is now closed to further replies.
×