k8vavoom: no good thing ever dies!

[ketmar]

1. vccrun compilation fixed, thank you.

 

2. sure, you didn't built game.dat, and you didn't specified sources to load graphics and music from. its dangerous to go alone, take this:

vcc_run -file data/graphics.pk3 -file data/sound.pk3

;-)

 

p.s.: vccrun is mostly a testing and developement tool. running standalone apps is just a side effect, so it isn't properly documented. sorry.

[Danfun64]

How am I supposed to properly build game.dat anyways? Better question, when will Spelunky and all your other standalone vccrun mods be ported to k8vavoom proper?

On a different note, pressing ESC after entering the options menu of Spelunky causes a segmentation fault.

Edited March 10, 2019 by Danfun64

[ketmar]

5 hours ago, Danfun64 said:

How am I supposed to properly build game.dat anyways?

you don't need to. but as you have seen earlier in the thread, it is just a zip archive with all data inside.

 

5 hours ago, Danfun64 said:

when will Spelunky and all your other standalone vccrun mods be ported to k8vavoom proper?

why? vccrun can run apps just fine. it also has some VC API vavoom shouldn't have -- like access to file system or network sockets (you don't want vavoom mods that sends spam while you're playing, aren't you? ;-).

 

5 hours ago, Danfun64 said:

On a different note, pressing ESC after entering the options menu of Spelunky causes a segmentation fault.

oops. this one i cannot reproduce. it works perfectly for me. i.e. i need more info, and maybe gdb crash backtrace from debug build, if you can do that.

[ketmar]

small status update: you will prolly have to wait some more for new build. right now it is playable, but i managed to almost completely destroy cliping with my "patch and run" strategy. it is better to start cleaning up and thinking. of course, i could still push out the build for you to try, but i prefer to delay it for some time: first, my binary builds is something people using to decide if the engine is worth noting at all, so build with very visible bugs here and there can create a wrong impression. and second, tagged public builds are used to create arch linux packages, so all 1.5 people playing with k8vavoom on arch will be affected.

 

tl;dr: i am working hard on rendering improvements. while no new features were added, i fixed many small bugs, and made some things faster. you won't prolly notice visual differences, but there are alot of changes under the hood. there are some technical debts to pay, and now i am trying to close at least some bills. ;-)

[Khorus]

Looking forward to it. Definitely going to make a map or two for this once I've cleared up some projects, so keep the features and bugfixes coming :)

[ketmar]

1 hour ago, Khorus said:

Definitely going to make a map or two for this once I've cleared up some projects

yay! it would be great. i am also planning to improve lighting system: add spotlights, and special directional light sources. right now, if you will use huge light to emulate directional sunlight, it will dramatically slow down stenciled renderer ('cause the engine has to render alot of shadow volumes, hitting fillrate limits; most Gunrock maps are slow at places due to this, for example). the same is true for emulating spotlights by surrounding light source with occluding geometry. i have some ideas of how to make it all faster with special light types. with this improvements, i hope to stay within 40-60 FPS for maps with dynamic sunlight even on my decade-old GPU.

 

the good news is that most "normal" maps (which has lights sourced from decorations) are already silk-smooth most of the time. E1M1 entrance, for example, was going on ridiculous 38 FPS, now it does 85 FPS. The Achievement, i'd say! ;-) and E1M1 exit (the room with grates) was even worser (yeah!), now it has solid 56-60 FPS. that is, one can actually play with "doom3 style lighting", not just make impressive screenshots. ;-)

 

p.s.: even your "The Warlock's Hearth" is now playable on my GPU! it has occasional hiccups where clipper is failing, and FPS drops to 30-15, but those cases are quite rare. most of the time it is going with 50-60 FPS.

Edited March 12, 2019 by ketmar

[3t0]

@CyberDreams : "This is from an older post but it kind of "irked" me the wrong way".

 

Heh, thinking about it in hindsight, maybe I, subconsciously, wanted to "irk" somebody like you. Frankly, sorry!

Let us not feel salty. If you want to read more, mental dump is in the spoiler, honoring what was suggested above.

 

Spoiler

Let us keep open mind (it's all just fun and games anyway :) ).

 

First, if you really want authentic "DX with phosphorus", I guess ebay, craiglist or something like that is your best bet.

 

I mean I still own one DX/2 (I think it is) Compaq with 12 Megs like this (image from net):

 

As it is last one of mine (I had like 4 before), I refuse to give it up :). It takes a lot of space in basement to dismay of my family. Once a blue moon I turn it on. It is probably unrealistic to ship anywhere, besides neighboring country perhaps, as these things are fucking heavy (I think this one is 15-25 kilos, but am too lazy to put it on some scales). This makes shipping it anywhere too expensive. You would be better served by your "local" vintage "community".

 

Also not sure if you are aware of the fact, that besides OLED family, all LCDs are subtractive, while rest of the "real light" tech like plasmas, CRTs, (AM)OLEDs, LASERs are additive. Unfortunately 99% of displays in the wild nowadays are "subtractive" LCDs. At least on desktop systems and notebooks (and even on "DTP class" ones). That means you can never get same "colors" out of the Doom on LCD, as you got from CRT when it was released. More over, CRTs are "blurry", and LCD pixels are spot on.

 

I couldn't care less about color purity, but it all means, that it is virtually impossible to emulate "the feels" most of us got, when we first encountered Doom. That's also why recently released "work images" of monsters and patches by Romero, look so "brownish". Kinda like having been submerged in serious shit and piss bath for all those twenty, or so, years. I 100% assure you they didn't look that much "brown" "in person" on NeXT/DOS CRT displays. Doom palette always had slight brownish tint, but it was quite "lighty"/"glowing".

 

But me, personally, I am actually thankful for those LCDs, even if colors are completely bogus (I don't care), simply because even you, probably, wouldn't stare into 120-200W, provably radioactive, light-bulb, 6-12 hours a day, even if I paid you. Decades later I sometimes wonder, what that devil's device did to my brain. Yuck, I still feel the "pain" at back of my "brain" when I remember those days.

 

Then there is matter of resolution. Vanilla always meant 200p to me. Before that, only Duke Nukem 3D, and later Quake, could use some weird high resolution VGA modes (like X Mode), and well before advent of GLQuake derivations, perhaps even some VESA modes (if you were lucky - owned right card (not GPU :) ) - sometimes even requiring special TSR "drivers"). I mean there were some obscure titles, that could do it too, like perhaps Descent, but "nobody" remembers those. All this gfx dealing also meant "Classic DOS" with no "Windows" on top, more often than not. Closest you can get to that today, is DOSBox.

 

Now, if you have seen 320x200 window on modern Full HD display, I bet you realize how inadequate such a "viewport" feels. It has size of a "big icon". And it must look beyond ridiculous on 4K class display. Software scaling is not the answer either. Just hack-around.

 

Regarding all that, I personally consider "Doom 95"/"Final Doom" the "vanilla breaking point" (if I am not mistaken sourceports were already underway when that came out anyway). Once you break free from confines of VGA 13h Mode mode, Doom is not the same beast it used to be anymore. For example, simply because at higher resolutions, you can aim at things, that you were not supposed to aim at in 90s.

 

But most importantly, we are all past that. And it's a good thing.

 

After breaking free (from the ossified VGA memory model), what does it matter that you have added vertical look up/down (using skewing in software renderer), or that there is fully vectorised 3D mlook available (in GL ports) even? It all has becomes matter of preferences now. There is no way to get "real vanilla feel", that many of us grew up with in 90s anymore, simply because most of the shit that "feel" depended on, rightfully, belongs to a museum now.

 

You have to understand, that to somebody like me, artificially limiting yourself to horizontal mouse turning + autoaim without all the related shit (dealing with stupidly complex "out of game" (by today standards) manual mouse configuration, frollicking with expanded memory "drivers" and DOS extenders, soundblaster fighting and "windows (tm)" hack-arounds) feels like posturing, especially if you are using viewports well above 200p+ anyway. I personally perceive (probably unwarranted) certain hypocrisy and posturing there.

 

I mean if you want to have "vanilla-like feels" go for it by all means, but when used in discussions as leverage point to "prove one's vanilla-ness", it feels void. Especially to those of us, elder fags, "who were there". Maybe you are one of us, so you should know better ;). To all such "posturing" people I would often like to say: Just don't think about your style of play as being superior/above that of "others".

 

I don't care about demos either. It's almost impossible (or rather not worth the effort) to replay them, especially in world of Linux, where I hang out these last decade.

 

But maybe I am just bitter, because of brain damage from CRT radiation.

 

Anyway, I, on the other side, am infinitely grateful for high resolution, full console(s), in game key bindings (lifted from Quakes), mlooks, GL rendering, hires textures, 3D models, dynamic lightning and all that crazy shit. It's just mind boggling how well this game aged, given chance of evolution through open source. And if those features are there, I also want to use them.

 

Funnily enough, original game content is still playable on such advanced sourceports, and levels and monsters still "work".

 

Enemy dynamics might have changed a bit, as now some enemies are "easier" to deal with, BUT "modern" WADs take that into account and are actually "offsetting" it by dumping more enemies on you. I think overall, even with new features, whole thing holds together pretty well. And that's why I became so "vanilla" sensitive. It doesn't matter.

 

More over, k8VaVoom doesn't seem to be vanilla oriented :), thankfully.

 

So sorry for irking you, I hope I made my reasons for holding my opinion bit more clear. No hard feelings.

 

[3t0]

Somehow I manged to merge my stuff from textfile with forum SW so here we go:

 

On 3/1/2019 at 1:08 PM, ketmar said:

some engines does VBO, some still using good old `glVertex()`. k8vavoom is a mix of both: it is using VBOs for models, but `glVertex()` for the actual map data. i am planning to switch to VBO for map data too, though. and it is not hard to rebuild VBOs: the engine already does surface rebuilding when sector height changes, and is using prebuilt vertices after that. i.e. all the code is already there anyway.

 

  • Q: So this means that VAO+VBO should be possible in the "future" once you get to it, right?

 

On 3/1/2019 at 1:08 PM, ketmar said:

not really. decals doesn't do any clipping at all: i just refused to solve this problem. ;-) decal rendering is using stencil buffer: any surface with decals modifies stencil buffer, and then i simply render decal with stencil test. that's why i absolutely don't care what kind of surface has decals, and that's why i can render decals on middle textures with holes: GPU just does all the clipping for me. ;-) i.e. there is no math involved at all, just a simple brute-force pixel visibility testing.

 

So to re-intepret: when you detect that there are decals present on floor/ceiling (or transparent 2 sided sidedef) you draw that element second time (or alongside initial render) into stencil buffer, and then use stencil as mask for decal "sprite" drawing. Am I correct?

 

  • Q: Is this advanced decal thing in git master? I don't seem to be getting it, even though gore.pk3 is there.

 

On 3/1/2019 at 1:08 PM, ketmar said:

the hardest thing here is not a tesselation per se, but dynamic changes to level data structures. most engine expects level data to be at least partially immutable -- it stores pointers to varuous things in many places, VC itself heavily relies on data being placed in arrays and won't change neither it's RAM address, nor order (like subsectors number and ordering, for example).

 

  • Q: So you are saying that reference counting and garbage collection, essentially heap management, of the game data chunks (lines, sides, sectors, actors, gfx) is more of the problem than raw geometry manipulation? How realistically do you see such manager added accompanied with modified VC interpreter, being able to actually handle such dynamism?

 

  • Q: With your "editor mode" plan, are you still considering in-game level geometry, aka sector, editing? Or do you just plan for mobj movement/inspection/edit?

 

On 3/1/2019 at 1:08 PM, ketmar said:

that is, the line drawn from (for example) (1.39537,2.40684) to (8.95067,6.409306) is not always touching the same pixels that the line drawn from (8.95067,6.409306) to (1.39537,2.40684) (numbers are completely random). so while adjacent surfaces has the same vertex coordinates, edges are rasterised in a different direction, and some pixels are not touched. what you will see in those untouched pixels depends of renrerer implementation -- it may be skybox, or pixels of solid color, or pixels from previous frame...

 

  • Q: Okay so sparklies are actually caused by Doom's fixed point nature?

 

I always wondered how sourceports do GL.

 

  • Q: Does it mean that there are actually two computations going on? Actors and level geometry is handled in fixed point math and right before GL drawing (given you said that immediate mode is being used for map data) values are converted into GLfloats (assuming from glVertex*f() calls), for GL consumption?

 

  • Q: If above is the case, and sparklies appear due to fixed point math, do you have any idea what would happen, if the whole engine used floats internally for everything (even map/actor handling)? Eg. fixed point values from data lumps would be converted into floats immediately on map load and used as such to run actual game? I mean, I realize that it would probably break most of the game, but am also curious, if you think, that it would be able to solve the sparklies (and perhaps other precision) problems? Also, would it be worth the effort?

 

On 3/1/2019 at 1:08 PM, ketmar said:

we have "block player" flag (and "block monster" too).

 

Of course I am aware of block "player flag", I had rather "clip movement" flag (probably more "doomish" solution than "quakish" special texture) in mind, in sense it would clip everything moving, not just players. But yeah, after you pointed me in that direction, I realized "block player" + "block monsters" could be used to emulate that. Still, as Doom does not do BSP "sliding" the way quakes do it, it would probably not work as well as it does in quakes. At least until bevelled BSP would land. Still worth an experiment though, thanks.

 

Regarding all things VavoomC.

 

My memory was bit hazy about a details, so I did some research and it seems that Quake 1's QuakeC is not directly related to LCC derived Quake 3's QVM. I already forgot there were distinctions. I presume VavoomC is "lifted" from Quake 1's QuakeC. Given you said Server VavoomC and Client VavoomC is inspired by Unreal, I wonder whether other parts of bytecode interpreter are inspired by more modern QuakeC compiler/interpreter systems like DarkPlaces' or FTEQCC.

 

  • Q: So, which QuakeC "fork" current VavoomC is descendant of ? Or is it it's "own thing" directly from Quake 1, with features inspired from Unreal and other QuakeC runtimes?

 

Also thank you very much for explaining k8VaVoom mobj hierarchy, especially `VThinker` and `VEntity` relation. I slowly started doing some occasional reading but I still don't get the overall system. C++ is also quite different from what I am used to (C, lua, bits of PHP).

 

I also noticed that my decorate experiments seem to work.

 

On 3/1/2019 at 1:08 PM, ketmar said:

it is planned. the whole model support code is a mess, i need to completely rewrite it. for now, it is using internal MD2 details alot.

 

When reworking model renderer, especially if you plan to add MD3, I seriously implore you to  consider adding IQM model support.

 

MD3 is pretty well known from Quake 3, but just like MD1(MDL) (which is extremely barebones) and MD2 (current format, with basically no live tools support - most of the things I found are pretty dead and outdated), it is only morph based.

 

If I remember correctly MD2 spec also has some sad places (something related with normals and such). From your previous reply I guess that it is the part of "leakage" you were talking about. MD3 has at least bigger limits, vertex normal (if I am not mistaken) and proper model compiler, that is alive by means of ioQuake (3) (and Blender).

 

Although morphs seem like fine choice for static decorations and simple animated objects (like flags and leaves - eg. animated decorations), usage of morphs for actors like monsters in this day and age seems rather wasteful. Or rather skeletal animation option would be nice addition, given Vavoom prides being most "advanced" :).

 

Skeletal animation allows for longer, more memory efficient animation sequences, with actual bone structure frames decoupled from morphing logic.

 

While some engines (I think EDGE/hyperEDGE) went with MD5/MD5ANIM and SMD/MDL, I consider former rather weird and ineffective (but who knows what happens when MD5 is zipped in pk3 though) and latter encumbered by Valve.

 

On the other hand, IQM - "Inter Quake Model" format, has grass-roots origin in Sauerbraten and Quake sourceport communities. It is unencumbered binary format and it is well supported in many engines like Sauerbraten, Tesseract and various Quake 1 sourceports like Darkplaces, FTEQuake and recently it was even added to ioQuake 3 too. It is fully skeletal, animation friendly format, using quaternions internally (eg. no gimbal locks), that comes with tools, Blender exporters and example implementations available in IQM project repo. It has also cleanly defined extension mechanism to allow storing of additional, custom, game specific data in the model. I think FTE engine uses that one.

 

Strangely, besides Doomsday and EDGE/hyperEDGE no other Doom sourceport bothered with skeletal format and even in those engines testing those models seems more like dark magic. I never got to even try it.

 

Non existing skeletal support is perhaps caused by tight Sprite <-> Frame mapping used in Doom, often abused by AI too? And due to simplicity of frame based implementation.

 

Q: Should you decide on supporting IQM, would you be willing to devise and add frame to skeletal sequence mapping subsystem that would allow one to map in-game actor frame logic to "decoupled" skeletal animation of model in actors (Doomsday seems to have something like that)? Like it would be possible to map single ACTRA0 sprite ID to single but whole skeletal sequence. Or something like that.

 

On 3/1/2019 at 1:08 PM, ketmar said:

monster movement is "interpolated" with velocity vector (most code just sets velocity, and the engine does the rest), but turning is not: angle changes are instant.

 

Q: Hmm despite you saying "movement is interpolated", monsters, even Cacos, with MD2 models, seem to be "jumping" around during steps, instead of at least linearly "sliding", as I would expect. Are you sure this subsystem is operating properly?

 

Regarding documentation, I think that instead of wiki, a (perhaps) markdown rendered (only optionally) "book" would be much better. Given you don't even have site, it would live somewhere in docs dir and those willing to modify it would edit it/build it. I believe that would scale much better than wiki, which can get eaten by spam on small projects, with not enough administrative bureaucracy. Book is also easier to publish by web server, especially if presented as "static site".

[ketmar]

let's fly! ;-)

Spoiler

1 hour ago, 3t0 said:

Q: So this means that VAO+VBO should be possible in the "future" once you get to it, right?

yes. not that it really helps, tho: even complex doom maps doesn't have alot of vertices. the engine will still need to build sorted render lists for various parts of geometry, and such. that is, i don't consider VBO support as high priorty thing. it may help a little with some really huge levels with alot of open space and details, but meh... moving renderer to separate thread, so we can feed GPU while CPU is computing the next frame will have much better effect.

 

1 hour ago, 3t0 said:

So to re-intepret: when you detect that there are decals present on floor/ceiling (or transparent 2 sided sidedef) you draw that element second time (or alongside initial render) into stencil buffer, and then use stencil as mask for decal "sprite" drawing. Am I correct?

yes. slightly optimised, as you noted: i know beforehand that there will be decals on the given surface, so i can turn on stencil operations for that surface, and don't bother with stenciling other surfaces (which greatly improves fill rate). yet you got the overall idea absolutely right.

 

1 hour ago, 3t0 said:

Q: Is this advanced decal thing in git master? I don't seem to be getting it, even though gore.pk3 is there.

yes, it is there. yet it is slightly less noticeable than you may expect: flying blood doesn't leave marks on 2-sided walls. that is, there are two types of blood in the engine: first, when you damaged something that can bleed, the engine fires some short hitscans in the (rough) direction of attacker-prey, and if those hitscans hits any walls, blood decals are spawned. this is what spawns blood on 2-sided walls. also, with gore mod, there is second type of blood, some visible and invisible projectiles that flies in various directions, and spawns blood when they hit a wall. such projectile ignores 2-sided walls, so it doesn't spawn blood on it.

 

basically, monster should stand really close to a 2-sided wall to make it bloody. ;-) i will prolly add a special flag to gore mod projectiles later, so the would leave blood marks on 2-sided walls they're passing through.

 

1 hour ago, 3t0 said:

Q: So you are saying that reference counting and garbage collection, essentially heap management, of the game data chunks (lines, sides, sectors, actors, gfx) is more of the problem than raw geometry manipulation?

sometimes. they both eating precious CPU time. that's why i want to move rendering into a separate thread: there is hardly any PC that is able to run k8vavoom, and doesn't have at least two core CPU. and second core is just sitting there, unused, doing nothing (at least nothing interesting for me ;-). by having one thread for "thinking" and one for rendering, each part will instantly get a full frame time to do its things, instead of both competing for frame budget.

 

1 hour ago, 3t0 said:

How realistically do you see such manager added accompanied with modified VC interpreter, being able to actually handle such dynamism?

it is doable, and not that hard, but i don't want to do it, 'cause it will make JITting much harder. while i can insert memory barriers into VM opcodes now, with JIT compiler i will be forced to generate such code manually for each memory access. that is, VM can decide if it needs memory barrier in execution time, but JIT compiler should decide it at compile time. it is doable too, but makes things more compilcated that i want them to be.

 

 

Edited March 12, 2019 by ketmar

[ketmar]

let's go with the second part (damn you, DW software! ;-).

Spoiler

 

1 hour ago, 3t0 said:

Q: With your "editor mode" plan, are you still considering in-game level geometry, aka sector, editing? Or do you just plan for mobj movement/inspection/edit?

in the far future, yes. i have some ideas for that, and it will also allow us to make our levels more dynamic, 'cause scripts will be able to manipulate level data in runtime. but i don't know how well it will go yet: i have only very rough ideas of what can be done. it will require alot of experimenting to see if this whole thing is really worth doing. in the end it can just compilcate the engine, and still be hardly usable.

 

1 hour ago, 3t0 said:

Q: Okay so sparklies are actually caused by Doom's fixed point nature?

not exactly. things are more compex under the hood. tbh, i am still not sure what the exact cause of those cracks in k8vavoom. ;-) surface subdivision for lightmapping seems to be the biggest offender (advanced renderer doesn't subdivide, and it has much less cracks). but cracks are still there.

 

1 hour ago, 3t0 said:

Q: Does it mean that there are actually two computations going on? Actors and level geometry is handled in fixed point math and right before GL drawing (given you said that immediate mode is being used for map data) values are converted into GLfloats (assuming from glVertex*f() calls), for GL consumption?

i don't think that there are still GL-enabled sourceports out there that does such thing. i believe that all of them (except prboom, maybe) moved to floating point math. at least they are using fp math to calculate various things like segment lengthes, angles, etc. of course, k8vavoom is fully floating-point too, considering its free-step nature, that require fp math. there is no reason to emulate it with fixed point these days: after all, the whole Quake was able to run with fp math even on old pentium-90! ;-)

 

also, internal k8vavoom node builders are floating point too, so there is no precision loss due to converting built nodes to fixed point and back.

 

so this is something i have to investigate further. what i wrote is a "big picture", but i still have to find the real cause. i.e. i know what is going on, but i don't know why it happens. ;-)

 

1 hour ago, 3t0 said:

I presume VavoomC is "lifted" from Quake 1's QuakeC

nope. at least in its current incarnation is seems to be written completely from scratch. there were at least two VC compiler incarnations: first was very simplistic thing, even without a proper tokenizer. something Janis created to just "have things done", and start moving game code to scripts. there seems to be second incarnation, which was more smart, but still bad. and finally, there is third, current incarnation, which is a proper compiler, with separate parsing, semantic and codegen phases. i.e. current VC compiler first parses all the source to AST, then does semantic analysis and some optimisations, and finally does code generation. yes, it is a full-featured compiler, not some quick-and-dirty ad-hoc solution.

 

1 hour ago, 3t0 said:

Q: So, which QuakeC "fork" current VavoomC is descendant of ? Or is it it's "own thing" directly from Quake 1, with features inspired from Unreal and other QuakeC runtimes?

so, this is "it's own thing" now, not even related to Quake or Unreal compilers/VMs. and it supports features which zscript, for example, would prolly never support, like dynamic arrays of any data types (including other dynamic arrays), and dictionaries of any key/value types. still, its VM is stack-based (this is the easiest VM to do). rewriting it to be register-based will make things much faster. that is, in stack-based VM, `a = b+c` compiles to something like this:

load b

load c

add

store a

while in register-based VM this is usually just one instruction:

add rega,regb,regc

not all cases are so good, of course, but register-based code still has much lower overall instruction count. and VM has to do much less dispatches, and even less memory copies (no need to copy values to temporary stack slots and back). this will give a huge speedup. usually, register-based VM is at least x2-x3 faster, and in many cases it can be up to x10 faster.

 

1 hour ago, 3t0 said:

When reworking model renderer, especially if you plan to add MD3, I seriously implore you to  consider adding IQM model support.

yes, i know about IQM. basically, when i separate internal model management and data from external representations, i would be able to load many model formats. after all, it all boils down to having a set of vertices with some attributes. ;-) so once low-level code won't expect to see MD2 data layout, i would be able to load almost everything that has triangle data. ;-)

 

1 hour ago, 3t0 said:

Should you decide on supporting IQM, would you be willing to devise and add frame to skeletal sequence mapping subsystem that would allow one to map in-game actor frame logic to "decoupled" skeletal animation of model in actors (Doomsday seems to have something like that)? Like it would be possible to map single ACTRA0 sprite ID to single but whole skeletal sequence. Or something like that.

i am not sure that skeletal animation worth the efforts. after all, we don't even have good 3d models for monsters yet. no, don't point me to existing ones, they're all awful in one or another aspect. and throwing in skeletal animation code won't solve the problem, which is tied to how animation is done within DooM itself.

 

even if you will be able to assign poses to animations frames, the movement still won't be fluid or convincing: there are just not enough time to make good animation. not CPU/GPU time, but state time.

 

the thing is that with sprite, you can do two-frame animation with different legs position, and our brain will do the rest. actually, legs cannot move with that speed smoothly, but our brain don't care -- it is very good at adding "missing frames" mentally. ;-)

 

but when you have smooth animation, the illusion breaks. enemies are either "float" like they are in some sort of liquid, or their movement is so unnatural (sometimes very fast, sometimes very slow), that it is absolutely impossible to believe.

 

to make doom 3d animation look good, one have not only to create a full set of models with proper poses, but rewrite the whole enemy AI. not just add frame here or there, but completely redesign it. and it will be another game, not doom. but if we decide to abandon doom, there is no reason to go with doom engine too -- there are much better engines out there.

 

1 hour ago, 3t0 said:

Q: Hmm despite you saying "movement is interpolated", monsters, even Cacos, with MD2 models, seem to be "jumping" around during steps, instead of at least linearly "sliding", as I would expect. Are you sure this subsystem is operating properly?

not sure. this is something i have to check later. Janis may intentionally "lock" it to not break game logic too much.

 

1 hour ago, 3t0 said:

Regarding documentation, I think that instead of wiki, a (perhaps) markdown rendered (only optionally) "book" would be much better. Given you don't even have site, it would live somewhere in docs dir and those willing to modify it would edit it/build it.

while it is better, the wiki has a great advantage: it can be written by other people besides myself. you don't have to learn what git is, how to send me patches, and so on. you just open the site in your browser and start writing. considering that i'm getting zero patches from other people for the engine, i don't think that i will get way more patches for the documentation. ;-) and i definitely have no energy/resources to write documentation by myself. with wiki, there is at least a chance for other people to step in, and write something they know.

 

 

so copy-paste somehow doesn't work for me. let it be two posts then. and i think we should hide our little chatting into spoiler tags, so other people won't be forced to scroll those walls of text. ;-)

[ketmar]

yay! due to hard work, i managed to make most Gunrock maps playable with stenciled lighting! and by "playable" i mean >35 FPS (55-60 in most places, sometimes 40 or so). the biggest offender is Dark Wispers, which has alot of huge lighs placed in geometry-heavy rooms to emulate sunlight (i am planning to add special light sources for doing that in the future), and it drops to around 20 FPS at those places.

 

being able to actually play with stenciled shadows after all those years is... incredible. mind you, i have decade-old GPU, and it wasn't the best even back then. people with better GPUs should have almost rock-stable 60 FPS even on light-heavy maps, i guess.

 

and i must confess that once i turned stenciled lighting mode from slideshow to something playable, i am starting to think that it looks way better than lightmaps. ;-)

 

p.s.: no new build yet, sorry. i have some quite serious clipping bugs to iron out. let's hope that i got such big FPS counts due to my smart optimisations, not due to some nasty bug that will kill it all again once fixed.

[Gunrock]

6 hours ago, ketmar said:

yay! due to hard work, i managed to make most Gunrock maps playable with stenciled lighting! and by "playable" i mean >35 FPS (55-60 in most places, sometimes 40 or so). the biggest offender is Dark Wispers, which has alot of huge lighs placed in geometry-heavy rooms to emulate sunlight (i am planning to add special light sources for doing that in the future), and it drops to around 20 FPS at those places.

 

being able to actually play with stenciled shadows after all those years is... incredible. mind you, i have decade-old GPU, and it wasn't the best even back then. people with better GPUs should have almost rock-stable 60 FPS even on light-heavy maps, i guess.

 

and i must confess that once i turned stenciled lighting mode from slideshow to something playable, i am starting to think that it looks way better than lightmaps. ;-)

 

p.s.: no new build yet, sorry. i have some quite serious clipping bugs to iron out. let's hope that i got such big FPS counts due to my smart optimisations, not due to some nasty bug that will kill it all again once fixed.

Nice work!!!!!

[Gunrock]

Hey ketmar!! I was testing out some of my old Vavoom maps using the latest K8Vavoom build when I noticed a lot of odd visual anomalies everywhere. What I mean is that most of the textures, rooms, doors, etc have excessive glitches all over the place. Did you change some code around recently?

 

Here are some pics of what I'm talking about.

[ketmar]

@Gunrock latest uploaded build is probably one of the glitchiest ever. while it is better to replace it with something that actually works, i don't want to upload yet another glitchy build. and current git code is broken too, because i am in the middle of big changes in renderer. don't worry, it won't stay this way. ;-) i already fixed alot of bugs in shader management, and i am rewriting clipper. then things will eventually settle themselves, i hope.

 

and thank you for you maps! besides being fun, they are invaluable for testing lighting system!

[Khorus]

The new lighting ideas sound great, and being able to fly around in-game to work on lighting will be sweet. Doomsday's bias lighting has a similar system but remained unfinished (all sprites were black when in bias lighting mode for example), but you could see the potential.

[ketmar]

how to kill your FPS for fun. no, it is unplayable in this mode. but screenshots are looking gorgeous! just open the spoiler. sadly, FPS counter on those screenshots is true too. but for screenshots, shadows from 3d models are invaluable! ;-)

 

Spoiler

 

yes, helmet light is placed inside the helmet, and shines through helmet's "eyes".

[therektafire]

33FPS is totally playable, at least for me :D I assume these screenshots were taken with the latest build?

[Gunrock]

On 3/15/2019 at 8:41 AM, ketmar said:

@Gunrock latest uploaded build is probably one of the glitchiest ever. while it is better to replace it with something that actually works, i don't want to upload yet another glitchy build. and current git code is broken too, because i am in the middle of big changes in renderer. don't worry, it won't stay this way. ;-) i already fixed alot of bugs in shader management, and i am rewriting clipper. then things will eventually settle themselves, i hope.

 

and thank you for you maps! besides being fun, they are invaluable for testing lighting system!

I want to continue making more maps for K8Vavoom so it can get the recognition it deserves while also getting more people interested in mapping for it.

Also the glitches that I mentioned in my earlier post has to do with the nodes builder. I used GLBSP

to compile all my old Vavoom mods.

[therektafire]

GLBSP is an old nodebuilder, you should probably be using either ZDBSP or AJBSP (i believe that's what they are called anyway), those are the most up to date ones @Gunrock

[ketmar]

21 hours ago, therektafire said:

33FPS is totally playable, at least for me :D I assume these screenshots were taken with the latest build?

not latest published build, it is from developement git version. but i'm not done yet. if i'll find out how to implement zp+, we'll get ~x2 speed boost for stencil shadows. that is, @Gunrock maps would be playable at 40-60 FPS even at open places with alot of lights. but don't hold your breath. ;-)

 

also, you will prolly need something better than intel GPU to get such framerates. stencil shadows are very fillrate-demanding, and intel is notoriously bad at this. still, with zp+ you will prolly get 30-40 FPS even on intel.

 

ah, and turning off model shadows brings it back to sane FPS numbers, of course. model rendering code in k8vavoom sux. it is great in some places, and the worst piece of shit i've ever seen in other places. it should be rewritten (i'll keep the good parts, of course ;-).

 

 

21 hours ago, Gunrock said:

Also the glitches that I mentioned in my earlier post has to do with the nodes builder.

i should simply turn off loading external nodes in the engine. k8vavoom can build nodes on the fly anyway. my node loading code is very glitchy, btw -- i.e. expect all kind of weird bugs if you're using prebuilt nodes. ;-) just turn on "force node rebuilding" and turn off "allow pwad z-nodes" in misc options. it is the safest settings.

 

and yep, AJBSP is the successor of GLBSP, it is faster, newer, better and all that. zdbsp is very gzdoom-centric, tho, and does some strange things. nothing fatal, and it is fast as hell, but i'd still stick with ajbsp.

 

21 hours ago, Gunrock said:

I want to continue making more maps for K8Vavoom so it can get the recognition it deserves while also getting more people interested in mapping for it.

that would be great. and i am planning to give you (and other mappers) at least directional light and spotlight (dynamic at least in stenciled lighting mode).

 

and i am playing with deformable geometry idea. somewhat limited, but maybe you will be able to at least make rotating (or sliding left-right) doors without resorting to polyobjects.

 

 

p.s. fuck you, doomworld software! the worst forum software i've ever seen! (sorry, Linguica, i know the complicated situation with dw, but still...)

Edited March 17, 2019 by ketmar

[Gunrock]

Hey ketmar. I hate to bother you with such a stupid question, but in the past all of my Vavoom mods pk3 file structure is set up in a folder with xmodels.pk3, xmusic.pk3, xgraphics.pk3, etc....etc. Is there a better more practical way to set this structure up better or should I take the "if it aint broke, dont fix it approach" ? What do you think?

[ketmar]

52 minutes ago, Gunrock said:

I hate to bother you with such a stupid question

any qustions are welcome! after all, if you don't ask, you cannot know for sure. ;-)

 

52 minutes ago, Gunrock said:

Is there a better more practical way to set this structure up better or should I take the "if it aint broke, dont fix it approach" ?

you can safely put it all in one pk3, i think. these days, people usually have much better internet connection than ten years ago, so i don't think that offering separate downloads has much sense. and it is much easier for people to drag-n-drop one pk3 on a shortcut to run the game. as for me personally, i don't mind, i am mostly running the game from my terminal anyway. but for GUI people self-contained pk3 is much easier, i believe.

 

p.s.: especially considering the fact that i nuked vavoom launcher, and support for other launchers is in "i don't know, it may work for you" state. ;-)

 

p.p.s.: gzdoom cannot do it (yet), but k8vavoom can run pk3 from zip, so for k8vavoom users you can just pack all your pk3 into one zip (and upload it to idarchive ;-). but gzdoom people won't be happy.

Edited March 18, 2019 by ketmar

[ketmar]

let me tease you with some interesting FPS numbers.

 

before

after

 

as you can see, i am working hard. ;-)

[KVELLER]

3 hours ago, ketmar said:

as you can see, i am working hard. ;-)

 

You sure are! That's a pretty impressive boost in performance.

[ReaperAA]

@ketmar That performance improvement is impressive.

 

Spoiler

Any chance that u can work with GZDoom devs to help improve its performance too. Please

 

[Graf Zahl]

2 hours ago, ReaperAA said:

@ketmar That performance improvement is impressive.

 

  Hide contents

Any chance that u can work with GZDoom devs to help improve its performance too. Please

 

On what type of hardware? Don't forget that Vavoom and GZDoom are very different engines internally and have vastly different bottlenecks. Fixing some inefficiency in old Vavoom code is very unlikely to do anything in GZDoom because chances are that equivalent code does not even exist there.

 

[ReaperAA]

36 minutes ago, Graf Zahl said:

On what type of hardware?

 

Cough *AMD GPUs* Cough. Though I am hoping that Vulkan renderer in future might mitigate this to some extent.

 

36 minutes ago, Graf Zahl said:

Don't forget that Vavoom and GZDoom are very different engines internally and have vastly different bottlenecks. Fixing some inefficiency in old Vavoom code is very unlikely to do anything in GZDoom because chances are that equivalent code does not even exist there.

 

Yeah ur right that they are very different. But still there may be something of value that developers of GZdoom and Vavoom and learn from each other and help each other out. My real intention was just to lure Ketmar to help in GZdoom's development (add an extra manpower for GZdoom).

[Graf Zahl]

First te

5 minutes ago, ReaperAA said:

 

Cough *AMD GPUs* Cough. Though I am hoping that Vulkan renderer in future might mitigate this to some extent.

 

 

First tests of the Vulkan renderer have shown that it will provide the same performance on AMD than on a comparable NVidia card. As of right now, OpenGL does still have a slight advantage on NVidia though (slight meaning less than 5%), it's hard to beat a driver that is well optimized and doesn't incur needless overhead.

 

The main performance blocker for AMD is and has always been the excessively high draw call overhead in OpenGL, but that will apply to any OpenGL based engine - the more draw calls, the slower it will get.

 

The main problem with Vulkan is that the API is so low level that the most minor of development mistakes often results in a crash or broken visuals. That's where we're currently at. The renderer is nominally complete but not everything is working right yet.

 

[ReaperAA]

13 minutes ago, Graf Zahl said:

The main performance blocker for AMD is and has always been the excessively high draw call overhead in OpenGL, but that will apply to any OpenGL based engine - the more draw calls, the slower it will get.

 

Maybe ur right, as in my case most OpenGL games run slightly worse on the dedicated GPU (AMD Radeon 530) than even my integrated GPU (Intel UHD 620), but only slightly worse. However GZdoom runs a lot worse (like 50% less performance) on the dedicated GPU.

 

Also I havent't used Vavoom beyond playing IWADS. But atleast IWADS ran smooth when dynamic lights and particles were turned off using dedicated GPU. In GZDoom, the dedicated GPU lags even when dynamic lights are turned off.

 

However when I use Integrated GPU, GZdoom runs IWADS smoothly even when dynamic lights are on. Vavoom's performance was improved too, but not as drastically as in case of GZdoom.

[Graf Zahl]

You have an interesting setup there - according to www.videocardbenchmark.net your dedicated graphics card is not really that much faster than the integrated solution (1231 vs. 1036 performance points.)

 

With such a combination it is not really surprising that driver overhead plays a large role in performance characteristics. One thing with AMD is that I have read stories that their cards work better with Legacy OpenGL than with a modern core profile, but I haven't been able to confirm that part myself, but that might explain why GZDoom is so badly affected while other Doom ports are not. One more reason to get Vulkan operational...