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

k8vavoom: no good thing ever dies!

Recommended Posts

small update. probably the last one in 2018. mostly VC bugfixes, and proper floating numbers parsing (matters for UDMF).

 

* fixed (i hope) decals on moving midtex
* ignore more uninteresting mapinfo commands
* don't crash on invalid decorate indexed translations
* turned off force-loading of UDMF textures (this needs more work, and i am not sure that it worth it)
* hide weapon when player is dead (i broke it some time ago)
* changed default binding for suicide from F5 to F12 (heh)
* fixes for VC dictionary type
* replaced floating point to string conversion with Ryu (it is faster, platform-independent, and results are nicer)
* and string->float with (optional) D.G. dtoa code (or your system library), so UDMF maps should be parsed slightly better now
* alot of UFCS and paren-less calls fixes in VaVoom C

Share this post


Link to post

and some preview code for the upcoming new UI system. this is just a flexbox layout, created with VaVoom C code (for now, parser for textual UI definition is planned too).

Spoiler

  {
    auto win = desk.CreateWindow("test window 0");
    win.setBaseSize(10, 10);

    auto vbox = win.CreateVBox();
    vbox.vpadding = 2;
    //vbox.flexAlign = NWidget::FAlign.Expand;
    vbox.width = win.width;

    {
      auto hbox = vbox.CreateHBox('hbox1');
      hbox.hpadding = 2;
      hbox.flexAlign = NWidget::FAlign.Expand;
      hbox.CreateSpan().flex = 2;
      auto btn = hbox.CreateButton("button 1", 'button1');
      btn.onAction = &onWidgetAction;
      btn.setStyleValue('text-color', "#0f0");
      //NWidget.CreateSpan(hbox, 4);
      (hbox.CreateButton("button 2", 'button2')).onAction = &onWidgetAction;
      hbox.CreateSpan().flex = 1;
    }

    {
      auto hbox = vbox.CreateHBox('hbox2');
      hbox.hpadding = 2;
      hbox.flexAlign = NWidget::FAlign.Expand;
      hbox.CreateSpan().flex = 1;
      (hbox.CreateButton("button 3", 'button3')).onAction = &onWidgetAction;
      auto btn = hbox.CreateButton("button 4", 'button4');
      btn.onAction = &onWidgetAction;
      btn.enabled = false;
      (hbox.CreateButton("button 5", 'button5')).onAction = &onWidgetAction;
      hbox.CreateSpan().flex = 1;
    }

    win.layout();

    desk.appendWindow(win);
  }

 

 

this creates such fancy window (as you can see, window resizes itself, so children can fit):

Spoiler

newui_000.png.7ac97f021bfc50147e1b44579ef8322e.png

 

and this is default style (any property of any control can be overriden in runtime, and it supports css-like selectors too):

Spoiler

* {
  font-name: "default";
  background-color: transparent;
  text-color: #f70;

  scrollbar-vert-width: 8;
  scrollbar-vert-used-color: #ccc;
  scrollbar-vert-free-color: #222;

  scrollbar-horiz-height: 8;
  scrollbar-horiz-used-color: #ccc;
  scrollbar-horiz-free-color: #222;
}

*:focused {
  text-color: "#fff";
}

*:disabled {
  text-color: "#888";
}


NWindow {
  background-color: #333;
}


NButton {
  background-color: #444;
  bevel-up-color: #666;
  bevel-down-color: #222;
}

NButton:pressed {
  text-color: #ddd;
  bevel-up-color: #222;
  bevel-down-color: #666;
}

 

 

as you can see, almost nothing is hard-coded.

Share this post


Link to post
15 hours ago, ketmar said:

* changed default binding for suicide from F5 to F12 (heh)

 

Why does suicide have a default binding? It could be extremely dangerous for someone that's just looking for the screenshot key.

Share this post


Link to post
3 hours ago, KVELLER said:

Why does suicide have a default binding?

otherwise i'd just forget impulse number for this. ;-) also, it is historical, and left from the original vavoom days. as you cannot get any help on impulse numbers (except by understanding VC sources), i left it there. F5 was even worser, 'cause default quicksave is F6. yet nobody complained (except me ;-).

 

better answer: i am too lazy to write better structured binding configuration screen (mostly because i am not using it), so the key is hidden in default config. i should move it (along with some other "hidden" actions) to menu, of course. just never really thought about that.

Share this post


Link to post
2 hours ago, ketmar said:

Explanation

 

Ah, I get it. Speaking of which, I've always hated how F7 is used for ending the game. So much frustration after trying to save after a big fight :P Nowadays it's the first key I unbind.

 

Share this post


Link to post

ok, it is time to bump this thread. new build for ya!

 

* license upgraded from GPLv2 to GPLv3
* fixed bug with decal sidedefs (it affects savegames too)
* fixed bug with sprite lighting in very dark sectors
* it is now possible to use C-Ins and S-Ins for copying to/from clipboard in console prompt
* better colored word wrapping in console, C-BS to delete words, more colors
* removed type conversion methods -- use language-provided syntax instead
* fixed segfault with camera textures
* fixed bug in `A_FireCustomMissile()` (z offset was added to x)
* fixed bug in FastProjectile (better step subdivision calculation, and respect subdivided steps)
* added optional tracers to BDW rifle and shotgun
* implemented `GetArmorType()` ACSF
* moved map fixer (code that fixes known bugs for various maps) to script side, so you can add your own fixes
* added support for delegate fields in structs (oops; it was supposed to work, but...)

Share this post


Link to post

and some random screenshot, to make people stay here. no spoilers, i want it to catch your eye! ;-)

 

light01.png.87a60959ed1990101d251e21cad3a5a8.png

Share this post


Link to post

yeah. just played Discharge, and thought that this shadowing could be a nice screenshot.

 

Silent Steel is even more impressive, as most of its lighting done with dynamic lights. it is really impressive, especially considering that you have to constantly re-run the map to see light changes, and calculating lightmaps was way slower back then.

 

that's why i am working on in-game UI for light management: placing and editing lights with instant feedback should make the whole thing much easier.

Edited by ketmar

Share this post


Link to post

yay. i never noticed that, but playing with frame skips (FPS < 35) was a PITA: the engine forgot to advance psprite states (actually, for additional frames player tick wasn't called at all), so your weapons shot soooo slooooow.

 

should be fixed in the next build.

Share this post


Link to post

tbh, GZDoom (relatively) recently got shadowmaps, so it can do shadow tricks too. still, vavoom does precalculated lightmaps for static lights, so you can get "almost free" lighting (with shadows) for things like torches and static light sources -- something GZDoom cannot do now. so yeah, vavoom lighting is quite competetive even despite ten-year lag in developement (and even somewhat superior in some aspects).

 

and as lightmaps are not pre-backed, as in Quake, for example, it is possible to write in-game lights editor with instant feedback -- all the code is already there. it is even possible to defer lightmap creation until the surface is first seen (that is what i did for Skulldash EE hub map, as it is HUGE, and it is better for it to be little sluggish than to wait for lightmaps to be created each time it loads).

 

unrelated note: i replaced timing calculations for windows builds, as `QueryPerformanceCounter()` may not play well with modern CPUs (as they tend to dynamically change stepping). this may fix the timing issues for @therektafire (or may not; we'll check when i'll upload the next build).

Share this post


Link to post

today i am proud to present you Next Not Really Exciting Update. as you may see, last updates are more about internal engine code, so they are probably somewhat boring without new decorate/gameplay features. still, we all have to pay our technical debts sooner or later, and i am trying to do it until it is too late.

 

@therektafire if you will get some free time, please, test this version and tell me if you still have timing issues with it. and do it without your old configs, please. don't hold your breath, though -- this is mostly blind shot. yet even if the fix won't work for you, i will know that i should look somewhere else, so negative result is good too. ;-)

 

 

p.s.: WARNING! there will be major savegame format overhaul, so expect it to be broken yet again in next builds. hopefully, after those changes, save files will be even more resistant to ketmar, and new releases wouldn't regularily kill your progress.

 

for curious: i am planning to completely change the way saves are done, by splitting savegames to logical chunks, which can be loaded in any order the engine wants, and make them properly versioned. it wasn't done in original Vavoom to save some RAM, but today we have plenty of that, so i can spare some to make your life easier (and to stop people cursing me for breaking their saves yet again ;-).

 

also, i am planning to make "checkpoint saves" on entering new maps. this won't work for hub-based games, but for most normal pwads there is no reason to save whole map state on entering new level, as it is well-defined, and can be recreated by simply loading a map. so i can just save player's health and inventory -- which is much easier to keep "unbroken", and is independent of savegames. this way you would be able at least keep your level progress (along with weapons and powerups) if i'll break savegames yet again.

 

 

now, some boring changelog.

 

* if no game was specified, try to autodetect what game PWAD requires (DooM/DooM II)
* you can use experimental "-k8runmap" CLI arg to immediately load the first map in PWAD, to skip all menus and go straight into the action
* gore: floor blood spots should not stuck in walls anymore (at least not that often)
* replaced D.G. dtoa with plan9 strtod
* advance psprite states in skipped frames, so player weapons won't dramatically slow down on FPS drops
* all Player methods starting with `Cheat_` are automatically exposed to command console (i.e. mod authors can add new cheat codes without modifying C++ code)
* implemented map-local textures (so full-path textures from UDMF should work, and saves should not be broken anymore)
* "warpto x y [z]" console cheat
* "am_default_whole" boolean cvar to set initial automap size
* some code to fix empty cracks near badly aligned slopes (it is not ideal, but many levels will look better now -- kdizd z1m1, for example)
* wait for graphics initialization before execuling CLI console commands (so you'll have something to look onto while the engine builds BSP and calculates other data)
* numbers with signs will be appended as CLI console command arguments instead of being interpreted as commands themselves
* replaced `QueryPerformanceCounter()` with `timeGetTime()` API for windows: QPC is unreliable, and 1ms resolution is enough for the engine
* rewritten texture animation subsystem (it is still sometimes wrong for legacy animation defs, but at least it is less wrong now)
* saves should be resistant to different texture loading order (and therefore incompatible with old saves; oops, i did it again...)
* fixed mobj sorting, so translucent and additive objects are rendered in the right order
* moved ACS script executors to separate list, so they won't constantly retrigger GC
* added ACS watchcat that will kill simulation if some ACS script is not terminate in some sane time
* fixed some VC codegen bugs
 

Edited by ketmar

Share this post


Link to post

Downloading now!!!!

 

I'm planning on re releasing Silent Steel Adamantium with a few changes and bug fixes very soon to go along with ketmar's new Vavoom.  

Share this post


Link to post
4 minutes ago, Gunrock said:

I'm planning on re releasing Silent Steel Adamantium with a few changes and bug fixes very soon

great! feel free to PM me if you need something special or hit some weird bugs, so i can shuffle my TODO list a little. ;-) i am actively working on engine internals now, and may break some feature you may need, and schedule it as "meh, will fix later... maybe". so ping me if you'll need something fixed ASAP, and we'll try to find a solution. ;-)

Share this post


Link to post

wow. as it happens each time, right after uploading a build, i found two MAJOR bugs. first prevents map-local textures from working, and second loads totally invalid TEXTURE1/2 lumps from slade-broken pwads. tbh, i am very close to declare slade as unsupported fubared crap, and to remove all slade-related hacks from the engine.

Share this post


Link to post

Um, that's kind of a bad idea considering Slade is basically the best resource editing program out there at the moment and there ix basically no point in using any others like XWE (in fact I think slade is the only doom resource editor that is even being currently supported and updated, I could be wrong on that though)

Share this post


Link to post

slade is absolutely fuckin' broken. it creates non-conformant zips (multiple records with same file name are not allowed in well-formed zip file), it does the same with wads, and its crap rely on unspecified file loading order, which works only by accident. basically it works only because several source ports wrote their archive/wad loaders in a very specific way. i am really bored of writing workarounds for broken shit that slade vomiting.

Share this post


Link to post

It's not a very good idea to ask people to use other editors instead of SLADE3 for editing. Much of the other Doom lump manager stuff I have seen are dead.

Share this post


Link to post

Well, if the wads that SLADE produces work in vanilla Doom, Chocolate Doom and all source ports, then you have to support them!

 

Also, I am not sure but maybe there are reasons of backwards compatibility that force these things.

Share this post


Link to post
16 minutes ago, VGA said:

am not sure but maybe there are reasons of backwards compatibility that force these things

nope. it doesn't try to keep vanilla compatibility. it is just using the fact that [g]zdoom does the things in some specfic (and dumb) way, and the fact that most archive readers in source ports were modelled around original wad reader. neither is a good way to do things fast and clean. thus instead of creating archives that can work with any reading algo, slade enforces its way of doing things on everything. and all this for nothing, 'cause it is abolutely possible to build non-fucked archives without compromising user expirience. but slade authors doesn't care, and i really hate eating somebody's else shit.

Share this post


Link to post
8 hours ago, ketmar said:

it does the same with wads

 

If WAD files aren't supposed to have multiple lumps with the same name, I guess all wads ever created that contain more than one map are non-conforming.

 

Share this post


Link to post

Something that completely prevents many mods from running on this is the fact that it bombs out when a replaced type isn't found, when it would be better to just print an error to the console and continue as normal. Basically anything that adds support for other mods or Skulltag content will never work without modifications in this thanks to that.

 

I really like how it looks and the Quake effects are neat, but the rendering interpolation feels very laggy, you press a key and there's a noticeable delay until your character actually does it, especially moving.

 

Also, does this already support checking x, y and z values in DECORATE, along with ACS libraries? If that's the case then it should be pretty easy to make a dynamic light pack for the IWAD maps.

 

EDIT: Wait this runs BDLite already?!

EDIT2: Aw, but it doesn't run DUBG, would have been cool with the new effects.

EDIT3: You should also try The Adventures of Square to see which features work and which don't. If that doesn't run you can try my backport of it

Edited by -TDRR-

Share this post


Link to post
6 hours ago, Gez said:

If WAD files aren't supposed to have multiple lumps with the same name, I guess all wads ever created that contain more than one map are non-conforming.

maps resides in pseudodirectories. pseudodirectories are ok. but having several lumps with the same name one after another is absolutely wrong.

 

 

6 hours ago, -TDRR- said:

it bombs out when a replaced type isn't found

it also doesn't like many more bugs that gzdoom tolerates. decorate has no way to conditionally compile actors, and ignoring errors is not something i really want to do. that is, mod that tries to use unknown actor is broken. while i understand why people doing that, this is ugly hack that works only because gzdoom sux on proper error processing. that is, i may implement this sooner or later, but i really-really-really don't want to do it.

 

6 hours ago, -TDRR- said:

but the rendering interpolation feels very laggy, you press a key and there's a noticeable delay until your character actually does it, especially moving.

there is definitely something wrong on your side. the engine has no interpolation at all, it is not a lock-step engine. ;-)

@therektafire reported some timing issues earlier. as i cannot reproduce that on my system, i am currently doing blind shots hoping that one of them will magically fix it all. don't get me wrong -- i am not blaming you for anything, and thanks for your report. but currently i don't know what is the cause of this slowdowns and how to fix them, i only know that this is timer issues caused by some windows/cpu combinations. maybe if we'll get a developer with real windows things will go better.

 

6 hours ago, -TDRR- said:

Also, does this already support checking x, y and z values in DECORATE, along with ACS libraries?

em... what API do you mean exactly? many things were supported long time ago, and i implemented many more things in last year. so chances are that it does. ;-)

 

6 hours ago, -TDRR- said:

Wait this runs BDLite already?!

yep. ;-) with some undocumented hacks and other magic tricks i won't tell anyone it runs even BDv20, BDv21, and PB. not that they're working right, tho -- they are so broken in so many places, that i don't want to support them at all.

 

6 hours ago, -TDRR- said:

DUBG

i don't even know what it is. tbh, the only mods i am using to play doom are those included with k8vavoom (bdw weapons and gore). most fixes in decorate and mod support were done thanks to one great person. he literally spamed me with reports for alot of mods, and constantly re-checks them when i fixed/added something. the real hero, great thanks to him.

 

i mean -- until people will PM me with bugs for their favorite mod (with download links and repro cases), chances are it won't be working. ;-) currently k8vavoom has only one developer, so i simply don't have enough resources to do it all myself.

 

6 hours ago, -TDRR- said:

You should also try The Adventures of Square to see which features work and which don't.

yeah, that hero person tested it. GZDoom port of it mostly working. there are some breaking bugs not related to scripting, though, and some of them require redesigning of engine internals. so it is not officially supported, but runnable if one knows what undocumented cvars to tweak. ;-)

 

 

thanks for your feedback! i am sorry if my answer looked rude/defensive, that wasn't the intention at all. i mostly tried to explain design decisions behind some things, and sources of some bugs. yet my English sux, and it may looks like i am shifting the blame to end users. it is not the case, any feedback is welcomed.

Edited by ketmar

Share this post


Link to post

Here's DUBG

 

Yes, it's made by me and while it is nowhere near being one of the best mods i still enjoy playing it.

It doesn't use super-complex tricks nor anything out of the normal, so fixing support for it should be adding the following:

Player.UseRange (property)

Player.Colorset (property)

Player.Face (property)

A_FireSTGrenade (codepointer)

A_Warp (codepointer, this isn't as necessary, merely for PvP glorykills)

 

I meant checking like this A_JumpIf(x == somenumber, "Lolz")

 

You should add a -laxdecorate parameter that ignores the same errors GZDoom does but with a huge message window before starting that says something like "DO NOT REPORT ANY BUGS WHEN USING THIS PARAMETER, YOU HAVE BEEN WARNED"

 

Also, who cares if this can't run BD? Performance is bound to be SO BAD that you couldn't possibly play it in many levels.

 

EDIT: I edited DUBG a bit and got it running but the weapons barely work, they don't eject casings and the animations are all very messed up, i suppose TEXTURES animation confuses Vavoom.

Edited by -TDRR-

Share this post


Link to post

tnx, i'll take a look at DUBG, and will prolly either fix it for next build, or report progress here. ;-)

 

8 hours ago, -TDRR- said:

Yes, it's made by me

which is very good: i love when authors themselves comes to report bugs. it usually means that we can resolve things from both sides (i.e. if i stuck). ;-)

 

8 hours ago, -TDRR- said:

I meant checking like this A_JumpIf(x == somenumber, "Lolz")

ah. sure, this works. it worked even in original Vavoom.

 

8 hours ago, -TDRR- said:

You should add a -laxdecorate parameter that ignores the same errors GZDoom does but with a huge message

i currently doing something like that (if you aren't lucky, you can see "FIX YOUR BROKEN CODE" diagnostics on startup). the stopper is that k8vavoom if very different from GZDoom, and some errors are hard to ignore. that is, VaVoom C is a full-featured compiler (and VaVoom C itself is a very powerful language, on par with slightly simplified C++/C#/D). some errors are found only on semantic analysis stage, and compiler is written in such way that when it hits some error, it stops producing any code, and expects host application to terminate. so some errors cannot be ignored without adding ugly hacks (and i generally don't like the idea of ignoring errors). but as i cannot rewrite all mods in the world, i am gradually adding workarounds, of course. ;-)

 

also, you almost guessed one of undocumented developer parameters. ;-)

 

8 hours ago, -TDRR- said:

Performance is bound to be SO BAD that you couldn't possibly play it in many levels.

yeah, BD perfs is abysmal sometimes. it is still playable on small levels, though. the culprit is not map size, of course, but the number of actors BD spawns. GZDoom is using incremental garbage collector from Lua, but k8vavoom is simple mark-and-sweep on each frame. so if mod will spawn alot of short-lived objects, it is kind of PITA for the engine.

 

8 hours ago, -TDRR- said:

i suppose TEXTURES animation confuses Vavoom

in current release it is somewhat broken. i rewrote it, tested it, published a build -- and then immediately found several major flaws. as usual. ;-) as we don't have huge userbase here, i rarely do hotfix releases (only when i broke something vital, so even vanilla iwads are unplayable), usually fixes goes into next build. that is, it should be fixed in a week or something.

 

 

p.s.: if you are using MD3 models, then it won't work. i didn't wrote MD3 support yet, only MD2 is there. model loading and animation code is somewhat messy, and should be rewritten to allow adding more formats later (now it is built mostly around intimate MD2 details).

Edited by ketmar

Share this post


Link to post

@-TDRR- also, i must confess that networking is somewhere at the bottom of my TODO list. that is, it works, and it has good design (by Janis), but it needs more love (finish some things, and polish other things). as i am not playing mp games, i only fixed some obvious bugs, and that's all. there is only so much time one man can spend on coding, so i have to manage priorities. ;-)

 

i will prolly implement `A_FireSTGrenade`, but `A_Warp` is HUGE. i looked at it several times already, but it is so full of various flags and other crap, that it is a PITA to implement (it should be several different code points, but it is too late, of course).

 

as k8vavoom replaces unknown code pointers with NOP, omiting `A_Warp` should not be fatal.

Share this post


Link to post
9 hours ago, ketmar said:

maps resides in pseudodirectories. pseudodirectories are ok. but having several lumps with the same name one after another is absolutely wrong.

 

I invite you to look at SW18_7 in DOOM2.WAD. And at all the music and sound lumps in DOOM.WAD.

 

Now, sure, those are pointless. But they're here; they're in the most important data files your engine has to support, and you can't blame them on SLADE.

Share this post


Link to post

oh, yeah. vanilla had some bugs, so let's repeat the same bugs with our tools. now instead of only detect and workaround that for vanilla iwads (their signatures are well-known, and it is easy to workaround), let's declare it as "feature", and carry it with us to the end of times. definitely a good way to create a toolset, what could possibly go wrong?

 

p.s.: note that you can ignore duplicates in iwads. it is not so for other duplicates slade loves to create. try to ignore duplicate decorate lumps, for example. or pnames. but you have to ignore some other duplicates. that is what i am whine about: it is all inconsistent, and not really well documented. slade was in position to fix that, ignoring the way broken zdoom loader works, and forcing the right layout... but it choose to not do that.

Edited by ketmar

Share this post


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