k8vavoom: no good thing ever dies!

[KVELLER]

Nice additions! :) At this rate you'll eventually force me to switch to your port haha.

[ketmar]

fresh meat new users are always welcome! ;-)

 

i can also (techinally) render decals on floor (most other ports cannot, for the same reason they cannot render decals on masked walls -- clipping is too hard), but my high-level decal code need some cleanup first. yeah, those splats on a floor is a 3d model, not a decal. yet. also, k8vavoom can align 3d models with sloped floor/ceiling. and i will prolly add code to align 2d sprites too.

 

i also have some thoughts of how to fix a common (mis)feature of all hw-accelerated renderers: cutting heads of bruisers and revenants in short passages. it needs some experiments, and changes to rendering pipeline, though. but it seems to be doable.

 

after all, i am far from finished with rendering code. tbh, i just scratched a surface of what i can, and want to implement/change. i have plans for better clipping (which should make stenciled lighting a little faster), faster dynlights tracing, and eventually moving renderer to separate CPU core, so the engine can simultaneously process game logic and feed GPU.

 

while k8vavoom is missing some GZDoom rendering features (i prolly won't implement pbr rendering, ever), i am still aiming to hold "the most advanced doom sourceport" achievement, at least in some areas. ;-) the only thing i really don't have enough is time to implement everything i want. ;-)

 

 

p.s.: fun fact: all the code to do this "new" decal rendering was there since i implemented decals for the first time. i just forgot to call the actual decal rendering code in one codepath, and to actually spawn decals on masked walls instead of skipping those walls in blood splat tracer.

[KVELLER]

2 hours ago, ketmar said:

also, k8vavoom can align 3d models with sloped floor/ceiling. and i will prolly add code to align 2d sprites too.

 

I'm not sure I'd agree with implementing that. It runs the risk of looking ridiculous on certain situations, especially with sprites.

[ketmar]

it is meant to be used for floor/ceiling splats (exactly as it is used now). for this case, 3d splat is exactly the same as sprite: a flat quad. only rendering a 3d model (even a simple quad) is slightly slower than a sprite. "align" means "stick to" here, and the final result will be the same as you can see on recent screenshots -- horizontal (or sloped ;-) splat.

 

this is a good approximation until i'll implement proper floor/ceiling decals.

[KVELLER]

Ohh, I get it. I was thinking about monsters.

[ketmar]

in the meantime, i am working on clipper cleanups. i removed last remnants of pseudo-optimisations from it, and now clipper seems to be rock-solid, without accidental "hole-punching" on "bad angles". also, there seems to be a bug in frustum calculation, which causes some heisenbugs in renderer (and it was there for all time, it seems, inherited from the original vavoom).

 

and another (almost) good news: i am working on solving frustum issues, and then k8vavoom clipper will get a limited (but somewhat impressive) ability to perform 2d clipping! i.e. we would be able to clip invisible geomerty when camera is looking at a floor, for example, or right at a 2-sided wall, and cannot see its midtex.

 

why is this so important? first, the less things ends up in GPU (actually, in rendering pipeline), the better. second, this visibility info is used to optimise various other things, so the less subsectors are marked as "visible", the better. third, it will eventually help with stenciled lighting (i already managed to squeeze ~5-10 additional FPS on E1M1 entrance -- which is surprisingly hard place for stenciled renderer). please note that stenciled lighting is somewhat broken now (it works, but with glitches).

 

also, huge maps should be processed somewhat faster (i got rid of some extra loops over subsectors, interleaving processing and rendering instead).

 

those with high-end PCs (anything newer than my 10 y.o. average PC ;-) will prolly not see any huge improvements, but anyway, we're becoming faster, and faster, and faster. and moving towards "multicore engine", which is a Good Thing.

 

the world will eventually be ours! join the winner now!

[ketmar]

inspired by the topic about fair play, i added some cvars, so you can disable crouching, jumping, and freelook for any map. also, i added two sv_ cvars to force pistol start and health reset, so you don't have to do "map xxx" each time (or patch mapinfo). of course, it is configurable in gameplay options UI.

[ketmar]

the quest for the holy grail vanilla leads me to adding another option: stop thing decorations from blocking projectiles. i never realised how much i used to trees blocking imp fireballs!

 

i also implemented "oriented sprites", and replaced floor/ceiling blood splat 3d models with sprites. still not decals (so no proper clipping). also spotted strange bug in render mode management, but didn't traced its origins yet.

[ketmar]

eh. of course, there was nothing wrong with frustum code after all, only my flawed logic. yet i extracted the code into reusable class (and immediately inserted more frustum checks), so my efforts weren't all wasted. i will prolly upload a new build soon, before rewriting all clipping code.

[-TDRR-]

Will you add vanilla compatibility?

[ketmar]

2 minutes ago, -TDRR- said:

Will you add vanilla compatibility?

what do you mean by that? i.e. all gameplay changes are configurable in option menus (and there are some hidden compat cvars i didn't made user-visible yet), so you can configure the engine for your liking, from almost vanilla to something strange.

 

the only things you cannot get "100% vanilla" are those which depends on engine implementation: prng is completely different, LOS checks are slightly different, freestep mode, etc. so it is impossible to add vanilla demo support without complete engine rewrite. but "game feel" can be configured to as much vanilla-like as user want, including even disabled freelook.

[-TDRR-]

1 hour ago, ketmar said:

what do you mean by that? i.e. all gameplay changes are configurable in option menus (and there are some hidden compat cvars i didn't made user-visible yet), so you can configure the engine for your liking, from almost vanilla to something strange.

 

the only things you cannot get "100% vanilla" are those which depends on engine implementation: prng is completely different, LOS checks are slightly different, freestep mode, etc. so it is impossible to add vanilla demo support without complete engine rewrite. but "game feel" can be configured to as much vanilla-like as user want, including even disabled freelook.

I was asking demo-compatibility, but anyways, it's nice to keep it close to vanilla gameplay so i'm all for these settings.

[ketmar]

12 minutes ago, -TDRR- said:

I was asking demo-compatibility

ah. nope, as i said. :-( the engine is so different from the vanilla doom, that it will basically require writing "engine in engine". of course, "impossible" here means "it is very hard and time-consuming". and it will be maintainance hell. for example, i want to switch box tracing code from blockmap hack to beveled BSPs in the future. from player's PoV it will result in more fluid movement, with less "i stuck in a wall" cases. but for demos, it will be a disaster.

 

vavoom has its own demo format, tho, based on network code. it is not yet finalised, but anyway, it is more resistant to such changes, as demo player is just a faked network client in this mode, and the server is the authority (vavoom is real client-server). of course, i'm not hoping that people will start distributing demos in k8vavoom format, but as vanilla demos are broken anyway, there is no reason to not create better demo format. ;-)

 

actually, other engines can support such demos too, as most required changes are recorded directly in the demo data -- positions and velocities of each visible thing (so interpolation is possible), all sector changes, etc. even state transitions. so other engines are not required to recreate k8vavoom logic to play demos. maybe in the distant future... ;-)

[ketmar]

new build, a very experimental one. with highly improved clipping code. the first (afaik) OpenGL sourceport that can clip with fake walls (so you won't see secret tunnel on e1m1 on automap, for example). expect various clipping bugs and other strange things.

 

* made automap key rebindable
* draw map lump name, level number and current cluster on automap
* partially implemented "HITxxx" decorate flags
* made AJBSP slightly faster, and made it default nodebuilder again (i am so good at making final decisions!)
* drop dynlights that are outside of view frustum and cannot affect it (i.e. further than light radius)
* fixed "fontdefs" parser
* implemented ACS functions `GetLineActivation()` and `SetLineActivation()`
* faster "better thing redering" algo (it should be safe to turn it on now, so i did it)
* it is now possible to have decals on translucent windows, and on "masked" two-sided walls
* fixed more "leaking" in renderer -- some invisible walls can be falsely marked as visible
* update subsectors in renderer, so we don't need to walk BSP tree several times (can win several msecs on big levels)
* respect `resetXXX` mapinfo flags
* added options to force some self-imposed constraints (disable jumping, crouching, freelook, always do pistol start, always reset health)
* jumping against a wall won't cut player's vertical velocity anymore
* detect SkullDash EE 1.1, and automatically load HUD mod
* added option to stop decoration from blocking projectiles (like in vanilla)
* do frustum checks in clipper; this allows to clip geometry when camera looks at floor/ceiling (previously, clipper was unable to clip backside geometry in those cases)
* solid midtex blocks view now (so automap won't reveal anything behind fake two-sided walls)

[kaleb.]

i really like this after trying it out for a bit

the lighting is really nice, much better than gzdooms shadowmaps.

 

i have just a few small issues tho:
whenever i go into a widescreen resolution (or up the FOV), your gun gets smaller and starts becoming unseeable and its weird

and the music just sounds really off, even when using my own SF2

 

but other than that i have nothing but good things to say about this, keep it up 👍

[-TDRR-]

Anyone has some good maps to try out the lightmapped rendering? Most wads i try have the effect be way too subtle.

[ketmar]

@kaleb. thank you!

 

as for widescreen -- i'll take a look. i am not using it, so there may be bugs. as for gun became smaller -- this is how it currently implemented, yeah. the gun is not a screen overlay, it is actual sprite in 3d world. so when the screen becomes bigger (i.e. bigger FOV), the sprite becomes smaller (as all other world sprites). this is how it was done in the original vavoom. i don't yet sure if i have to change psprite to real overlay or not (as it can be 3d model, for example, and 3d models require "proper" rendering). we'll see.

 

and the music sux, yes. k8vavoom's timidity is quite old, and sf2 support in it is... you heard it. ;-) sadly, fluidsynth requires manual midi decoding (with timidity, i am just passing .mid file to it, and it does the rest), and fluidsynth API is... let's say, i couldn't understand it. fixing music is in my TODO list, tho.

 

thank you again for trying k8vavoom!

 

1 hour ago, -TDRR- said:

Anyone has some good maps to try out the lightmapped rendering?

Silent Steel is made with lightmapped lighting in mind, i believe (and i hope that it isn't broken with the latest changes ;-). and Manor from the same author. i don't think that there are many other maps made with vavoom lighting model in mind, and i'd like to know about those maps too! ;-)

 

p.s.: i did broke it. oops.

 

p.p.s.: the fix will be in the next build. for now, turn options-> misc options -> force node rebuilding ON.

Edited February 27, 2019 by ketmar

[ketmar]

@-TDRR- i want to mention Braham Manor too. it is worth trying with stenciled lighting: doom3-like shadows on polydoors looks very impressive.

 

just search for both "Bryant Robinson" and "Gunrock" on idarchive. tbh, i don't really like neither Q2 nor Gothic aesthetics, but maps are very fun to play, and execution is great too.

[-TDRR-]

1 hour ago, ketmar said:

@-TDRR- i want to mention Braham Manor too. it is worth trying with stenciled lighting: doom3-like shadows on polydoors looks very impressive.

 

just search for both "Bryant Robinson" and "Gunrock" on idarchive. tbh, i don't really like neither Q2 nor Gothic aesthetics, but maps are very fun to play, and execution is great too.

Neat, will try them out. Silent Steel looked pretty good.

[3t0]

Hello, reporting back again. Long shitdrop again.

 

First thing, the forum on doomworld is fucked. It's fucked as any other

webshit software these days. One gets just one spurios backclick, fancy javascript

trigger or something, you never know, and your long post disappears

into the void. Doomworld seems to have some "saveshit" feature but it's

borked, as everything these days, as it routinelly misses, usually, most

important bits you wrote laterz.

 

To deal with that I started authoring posts for such crapware (eg. anything web based)

in external editor some years ago. But I don't interact on web often, so I forgot.

I suggest one (anyone) to do the same.

 

I decided to denote questions like this:

 • Q: Question?

Now with that sorted out, back to major points from our last exchange:

 

So report first:

 • I tried "out of tree" building as suggested. Once I ironed some warts (automation), it works kinda fine. Now to have repeatable build artefact flow I have three dir trees:

  • git dir

  • build dir

  • run dir

But it works :).

 • Q: Do you, ketmar, always install on rebuild yourself (eg. have 3 dirs?) ?

 

••• Lightning mode - editing lights ... only? •••

You consider adding "Lightning mode" to ease map lightning for mappers.

 

Because lighning is "tedious af". Okay.

 

Having worked in gaming some decades ago I can attest. Lightmap tuning

is indeed tedious as fuck.

 

And even worse in "offline" pipelines.

Longer the cycle editor<->engine is, more hair you lose.

I remember long qlight passes on pentium like yesterday.

 

So you say, you would consider adding a way to move static lights "in-game"?

I imagine something like BUILDs (or any doom editor's) 3D view.

 

If you are really willing to tackle this I have a semi-suggestive question:

 

 • Q: Why not go full way and provide embedded "editor", cube/sauer style?

Yeah might appear insane, but bear with me a bit. I was just thinking a lot

(not reading the code :) ), and concluded that most of the major stuff is actually right there:

  • Automap already knows to draw overhead view, zoom it, perhaps even rotate (no clue) it.

  • Node builder is embedded.

  • Lightmap builder is embedded.

 

With these three things embedded, I believe there is major code mass to move further editor way, logically.

 

As far as I understand only static thing in Doom descendant renderers is BSP.

And indeed BSP is static. Nothing is as static as BSP tree is. Any time anything

in map changes xy position, "vertex"-wise, it has to be recalculated.

 

This was problem in 486 days.

 

But not today. When I play with maps in modern editors, mostly SLADE, I don't even do BSP phase, because nodebuilder is "hassle" to setup (I don't know where my gzdoom build puts zdbsp builder, if even - and you said it's fast anyway). Loading such levels in gzdoom or k8vavoom is not even a glitch - "it" will "compile" them, on load, in a second. Most time consuming load time thing with k8vavoom is lightning recalc anyway.

 

Just testing out some stupid UDMF map designed this way (without lightmaps phase, eg. no lights and no "in editor" nodebuilding, stressing just the embedded builder), it is still instant load.

 

Given all this, let us imagine wild thing for a moment:

 

  • with '-edit <map>.wad' one starts in "edit (really 2nd, tweaked automap) mode".

 

In this mode, "editmap" mode, one can "start drawing" eg. "add" new sectors. Vertexes, linedefes, sidedefs and sectors are created dynamically in place, in memory structures, but nodes are marked as outdated and threwn out of window immediately when new sector is added or vertex is moved ... and thus actual BSP recalc is deferred only until player switches into "3D" view. Right before switching into "3D" mode, rendermode switch is postponed, until nodes are recalculated, of course, only if invalid.

 

As far as I know, from "doom's engine" point of view, once BSP is done, anything else can be changed live: "flats/textures", sector height, lightning, xyzs of things. For vavoom there is, of course, light recalc phase too, but that should be user triggerable anyway.

 

Now, I don't know how OpenGL pipeline plugs into this, and it always interested me immensely, but I am too dumb and lazy to figure it out.

 

  • Q:How does GL work in modern sourceports, and specifically this one?

 

Is it like this:

Does k8vavoom construct VBOs from all the doom structures, orders them by SSEGS or by rendered TEXTURES (or whatever) and just flushes it into GPU? Or does it use immediate mode and painstakingly draws the stuff similar way old sw renderer did, only with GL polygonal engine (is that even possible these days)?

 

Presence of .fs and .vs files, GL_ARRAY_BUFFER constants and glBindBuffer() calls suggests latter.

 

Anyway not sure how expensive rebuild of these GL structs would be after "online" nodebuilder run, in case they are cached on level load, but given this happens only on 2d/3d "switch" and only when user adds/modifies a sector or vertex(es), I would bet this would be tolerable.

 

Now, I do realise this sounds majorly crazy, given engine was never "designed" to do this, and maybe it's "almost impossible". But when thinking about it with open mind it doesn't sound so out of place, actually.

 

More like, it seems instead, like right now is the good time to start preparing scaffolding for that, while you are in these parts of the thing. It's not impossible. Maybe even not that much of work?

 

As when everybody always said floor/ceiling decals are "impossible", but you said it's "just" clipping issue. Back to that later, but I always thought they (horizontal decals) can be done. Brutal doom is a hack after all, using models for that.

 

My point is: if you can make horizontal decals work, it means despite being compiler guy, you actually know how to handle clipping math, to certain, perhaps even very sufficient degree. So there is actual potential to fix whole slew of clipping related issues and artifacts.

 

Because from what I know, real problem in doom always is sector+clipping/cutting magic, and this ties back into decals issue, tangentially.

 

I myself suck at math really hard. It's simply impossible for me to construct tesselator. But recentlish I was playing with some stuff to achieve maplike 2.5D rendering. Walls are "easy", you just pull "out" the lines into rectagles by Z and voila walls are done. What's fucking hard are floors and celings, that's why I am talking about tesselators. I just downloaded libtess, got it to compile and tweaked example a bit and was surprised. This "small" lib tesselates anything I personally tried to give it, even with holes. Not sure how numerically stable it is, but seems stable enough for my plays. Not only that, it seems that that lib can do "CSG" as well (not sure how these union/subtractions ops are caled for 2D). So should I continue playing that, I would solve floor/ceiling mesh problem that way.

 

I assume nodebuilders do something like that as well. They have to take perhaps concave polygons filled with (potentially) holes (sectors) and somehow split them into convex subsectors. Hard problem. Originally, they could get away with lot, because software renderer just fills the stuff on the screen floodfill style. But not in GL. Those GL sourceports actually need raw triangles. I do know there are some broken maps with weird sectors (or at least heard about those unicorns), but let us forget those for a bit and:

 

• Q: If I understand it right, besides BSP (rendering ordering) and PVS (potentially visible set), whole nodebuilding sectors thing is mainly tesselation problem, right?

 

And this is related to decals problem: how to cut decal square polygon against sector floor/ceiling's arbitrary polygon. And by tangent this coincides with "editing problem": if I have this sector polygon and user draws a line in editmode here, how do I cut it into two? What if user draws column (eg. hole) "inside"?

 

• Q: Given you have ability to mess with clipping, it would be possible for you to implement both "sector cut" and "draw a hole into sector" ops as generic part of the engine, right?

 

I mean it, as you designing clipping subsytem in way to be usable even for those (editing) purposes. I see those two ops as major prerequisites to have editor. I guess wall split (insert vertex), vertex "delete" (vertex merge) and vertex move are much simpler to do. You "just" add/remove respective linedefs/sidedefs and/or vertex data and invalidate nodes. Nodebuilder would be then able to do rest of the "tesselation" work, so that 3D view (GL arrays) of the map could be displayed in game. But "Sector cut" and "sector punch through" are two most major clipping operations users do in editors, when editing levels. I don't know how SLADE achieves that, but it seems to be able to use OpenGL at the same time (top textured, 3D View), so it must be doing some tessel. on it's own, right?

 

I believe with that editing stuff-in-place editmode would actually be quite realistic proposition.

 

Vavoom is already kind of "out of date" from the rest of the "modern" engines anyway. I bet not many mappers use it. By "swallowing" editor it can completely "disconnect" from the march of other sourceports (I am looking at you zdoom family) and editor support as far as map creation and map population goes. BUILD engine was done this way.

 

Outdated/weird/VavoomC scripted line specials or weird sectors (vavoom 3D floors are weird supposedly), weird lights? No problem, vavoom itself knows about them and editor is inside it anyway.

 

Also GUI doesn't have to be anything complex. Menu system already has most of the parts to display everything needed. One "just" needs grid-like graphics picker to pick wall/flat textures/things/models (like duke, cube, sauer have), perhaps with optional detail view (for sanity), and maybe some statusbar in 2d/3d editmodes - something like SLADE draws. Now with these things (for which there is already code for in the engine) k8vavoom could be an editor same way Cube and Sauerbraten are to itself. It's okay even with "Small" doomfont for most text and everything. I see clickable "button" and perhaps on/off toggles as last few missing important "gui" elements. It's all immediate in-line "menu" drawing anyway.

 

Final important thing missing would be ACS compilation, but ACS compiler can be swallowed into the engine same way as nodebuilder got eaten. Vavoom's ACS is already different from everything else, why not have it also right inside the engine like *bsp (maybe even compile inline ACS scripts on map load)? Only problem would be "live" ACS scriptfile edit, but that can be always worked around by having scheme like 'wadname.acs' and have vavoom rebuild BEHAVIOR lump in WAD, or in memory, just when the file changes (or on user request), still while in-game.

 

So to make it clear, we are not talking here about full game authoring package (gfx, sounds, music, lumps), massive editing "suite" or anything like that. Just one honest, barebones, yet dedicated, specialsied k8vavoom game targeting and just rich enough builtin "editor" following one WAD, one MAP01, one ACS, one file model. Rest can be authored "old way" in pk3s, WADs, what have you.

 

Now with this in place, in-engine light editing sounds like great next evolution step.

 

Because frankly, otherwise: one draws map in SLADE, *doombuilder or whatever, then places lights, then saves, then loads in k8vavoom, getting initial light recalc, then moves lights around, then gets nice feels, but then discovers that while atmosphere is now better, would also like to move bunch of verts and things/monsters around to match feels, so has to quit k8vavoom, then switches back to SLADE, then moves monsters/things/verts around, then cycle repeats to see results. Just doing it in k8vavoom right away, letting the rest of the stack deal with it, would feel much better and be much more pleasant.

 

Bonus points: "editor" is now never out of date (no 3D floors? no slopes? no whatever? - not here) from rest of the game as everything is stuffed neatly into single "place" - cube/sauer style.

 

  • Q: What do you think ... too much of ungrateful work? Too crazy?

 

••• 2D Clipper and skies •••

 

GZDoom is **tortured** by sparklies (skymaps shining through tjunctions - at least that's how they were called in quakes) when there is sky in view. Vavoom has similar problem but I observe less sparklies.

 

  • Q: Would new 2D clipper allow to not render skybox when not actually visible?

To minimize sparklies. Also, regarding skyboxes:

 

  • Q: Can one actually do Quake-style bitmapped skyboxes in vavoom?

 

••• Beveled BSP •••

 

You were talking about that.

 

  • Q: Is this similar technique Quake BSP hulls (1 and potentially 2,3) do?

If yes, I guess it would make player obstacle sliding much more fluid and give more solidity to the world same way it gives it to the quakes.

 

  • Q: Would there be support for some CLIP texture/Line special then?

 

I already noticed this in some wads, where one gets needlesly stuck in decoration or overly complex architecture. Quake's and Cube/Sauer standard reply is to enclose such problematic areas with "clip space" that ends up as part outside of the "hull", smoothing out player movement around such parts, increasing game flow.

 

••• Lightning mode again - rest things lightning •••

 

Looking at several maps I played it seems "spotlights" - conical lights - are simulated by putting lights into small crannies letting those form the "light cone" (lightmap only one though). One of the additions Half-Life brought (I think) was addition of spot lightning entity.

 

  • Q: would you be willing to add that one?

 

Spotlight origin and spotlight target would sound like ideal "things" for that. Too complex?

 

••• CPP/VavoomC split •••

 

I am trying to understand how codebase is split - but from cursory look it seems that more things than I guessed at the first glance are done right from the VavoomC, including all the specials and "sprite" action handlers.

 

  • Q: does it mean that CPP part is really thin (renderer, IO) and almost everything is done in VC?

 

If so, how are mobj renderer(engine's) image and VavoomC image of entity kept in sync? Or VC can access CPP object fields directly? Is k8vavoom mobj "plain old C struct" or is it an "object"?

It seems to me k8vavoom ACS can "shell out" directly into VavoomC, am I right?

 

If I want to mess with game's shotty can I somehow easily replace vavoom's default objects? Where should I begin?

 

••• "Monsters" and other mapthings •••

 

  • Q: What are "live" mapthings in vavoom? Mobs, Entities, Actors?

 

Vavoom seems bit quake inspired to use name Entity, but then there are Actors. And inherited mobjs.

 

  • Q: What is the hierarchy?

Like this:

1. Generic mobj

2. Entity

3. Actor ?

 

I guess mobj starts in CPP part but most of it's flesh in is VC?

 

Second thing is that I started experimenting with available models. Regarding models of monsters, grepping the code and model packs, it seems there is only MD2 support.

 

  • Q: Is there MD3 support?

 

Now when playing with ancient model pack from vavoom site:

 

  • Q: Models themselves seem interpolated (movement of limbs) when played through engine, but actual monster movement and monster turning is not? You said vavoom uses deltaT model, but is that for player and model mesh vertices only?

 

  • Q: Do you plan on adding more modern, less limited model formats?

 

••• Save/Load •••

 

I tried saving some fights with things (projectiles) midflight and everything seemed to load fine.

 

  • Q: Does this mean savegame subsytem works now?

 

- • -

So these are the things I would like to know that I amassed, it would be nice if you found the time to reply at least some of them. Don't kill me.

[CyberDreams]

6 hours ago, 3t0 said:

First thing, the forum on doomworld is fucked. It's fucked as any other

webshit software these days. One gets just one spurios backclick, fancy javascript

trigger or something, you never know, and your long post disappears

into the void. Doomworld seems to have some "saveshit" feature but it's

borked, as everything these days, as it routinelly misses, usually, most

important bits you wrote laterz.

 

Hmm...i don't seem to have an issue with it, but then again i don't usually type posts that are as long as yours so...maybe that's why i haven't experienced any issues?

 

On 2/9/2019 at 9:29 PM, 3t0 said:

I am "GLOnly" die hard type and I don't consider software renderer important anymore. I mean sure, it's cute that some consider it pinnacle of purity, and themselves purists, but: if you want to be "pure", get DX4 with actual phosphorus screen, put DOS on it, and have your pure experience with old exe. Otherwise you are just lying to yourself, pretending, as times have changed. These days even phones have OpenGL you know?

 

This is from an older post but it kind of "irked" me the wrong way...I don't consider myself a purist but i don't agree that you need to own a "DX4 with actual phosphorus screen" in order to enjoy Doom in a software renderer. There are plenty of great source ports out there that do an excellent enough job of doing a spot on software renderer. But if you do want to send me an older setup, i'll be sure to game on it when i play Doom and other DOS games so i can experience the most "pure" game play that i can get ;)

 

Anyway's, i don't really know much of anything about how the Doom engine (or it's source ports) work so i can't really comment/help you with the rest of your post. I haven't tried the k8VaVoom sourceport either, but i've been meaning to. However, i do think that you should possibly try to condense your ideas just a tad more or maybe just use a spoiler if it gets really long. Also just "Ctrl+c" it every once in while, just to be safe. It might still mess up the quotes when you paste it, but at least that way hopefully you don't lose all of what you typed if you are experiencing issues with the page timing out.

Edited March 1, 2019 by CyberDreams : missed a word

[Gunrock]

Thanks for the new builds ketmar. I'm about 95% done revamping Silent Steel for the new K8Vavoom build. However, I would suggest to anyone to hold off downloading and playing the old Silent Steel. This new one i'm releasing will be much better (more architectural details added, fixed bugs, and stronger monsters).

[ketmar]

@3t0: yay, a long post! let's get dangerous! ;-)

 

Q:How does GL work in modern sourceports, and specifically this one?

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: If I understand it right, besides BSP (rendering ordering) and PVS (potentially visible set), whole nodebuilding sectors thing is mainly tesselation problem, right?

yes. the worst thing is that we have complex polys with holes inside -- this is the worst case for any tesselator. BSP building elegantly solves this problem -- it is almost a side-effect of creating BSP tree. ;-)

 

Q: Given you have ability to mess with clipping, it would be possible for you to implement both "sector cut" and "draw a hole into sector" ops as generic part of the engine, right?

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.

 

Q: What do you think ... too much of ungrateful work? Too crazy?

actually, this is my Grand Plan. in-game editor will hardly be a replacement for standalone editor (standalone editors has alot of convenient features and tools, and i don't have resources to develop both engine and editor), but in-game editing is one of my big goals. i already have a full-featured hierarchical UI system written in VaVoom C, and VC code has access to most internal data structures. in the future it will be used to implement various property inspectors (so i don't have to load levels into Eureka to check various things), and i am planning to gradually evolve it into real editor.

 

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). dynamically tesselate map geometry is not hard (doom geometry is quite simple, even in most complex maps), but making everything other dynamic is. the engine was never written with this in mind.

 

Q: Would new 2D clipper allow to not render skybox when not actually visible?

this is already done in all sourceports. the "cracks" you are talking about has completely different origin: floating point inexactness. actually, vavoom has more of those than gzdoom, 'cause vavoom subdivides rendering surfaces more aggressively. in other words, this is good old "slime trail" problem from vanilla days, it just manifests itself slightly differenly. 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: Can one actually do Quake-style bitmapped skyboxes in vavoom?

if you mean "sky cubes", than they're already there.

 

Q: Is this similar technique Quake BSP hulls (1 and potentially 2,3) do?

actually, only Q3 is using proper beveled BSPs, afair. but yeah, that is it. currently, all sourceports are using vanilla blockmap for box tracing, and they're doing it by "small teleporting" -- i.e. teleport a player forward, check if player bounding box isn't collided with anything, and if it did, return player to the starting position, and try to resolve collisions. this code is messy, and error-prone. Carmack wasn't really satisfied with it too, but he didn't thought about beveled BSPs at that time. in Quake, he created BSPs adapted to most common AABB sizes, and only in Q3 he did what we're calling "beveled BSPs" today (althrough he never explicitly named that tech; the name comes from the paper written by MDK developers at BioWare).

 

If yes, I guess it would make player obstacle sliding much more fluid and give more solidity to the world same way it gives it to the quakes.

yep, that is the plan.

 

Q: Would there be support for some CLIP texture/Line special then?

there is already support for such things in doom: we have "block player" flag (and "block monster" too). map author can use linedefs with transparent midtex and those flags set to surround "detail geometry". but they usually doesn't do that. it is possibly to autogenerate such linedefs, but it will mostly be a guesswork. anyway, beveled BSP should make such "detail sticking" slightly less painful.

 

Q: would you be willing to add that one? (spotlights)

yes, spotlights are planned. they have to wait for lighting system rewrite, though. it is not hard (all lighting internally done by raycasting anyway, and it is easy to limit rays by angle), but i want to unify static/dynamic lighting first.

 

Q: does it mean that CPP part is really thin (renderer, IO) and almost everything is done in VC?

yes. basically, CPP side does rendering, sound management, lightmaps, and raycasing/box tracing. i am planning to move raycasting/box tracing to VC too -- but only after i implement rendering in separate thread, and JIT compiler for VC. currently, virtual machine can take up to 15-20 msecs to process things in a complex map (not a common case, but still) -- this is way too much. converting VM from stack-based to register-based should give me at least x2-x3 boost, and JIT compiler will make it even faster.

 

Or VC can access CPP object fields directly?

exactly. CPP classes and structs are directly exported to VC. methods aren't automatically exported, tho -- i have to manually write wrappers for them. there is a reason for VC being so "C-like" (it even supports pointers): Janis gradually moved C code to VC side, and to make his life easier, he built C-compatilbe compiler. first VC iterations didn't even had classes (and you can see this legacy in it's "god object" today).

 

If I want to mess with game's shotty can I somehow easily replace vavoom's default objects? Where should I begin?

you can take a look at basev/mods: there are "loadvcc.txt" and "loadvcs.txt" files in some mods. those are for loading "client-side" and "server-side" VC code (note that vavoom architecture is fully client/server; it is modelled after Unreal 1). you can replace (almost) any VC class with your own:

 

class MyClass : replaces(OldClass);

 

this not only makes `MyClass` a subclass of `OldClass`, but any time VC code will want to `Spawn()` `OldClass`, the VM will spawn `MyClass` instead. other than that, it is the usual "override virtual method" bussiness.

 

also, vavoom supports decorate, so you can use the usual decorate code -- and it will be compatible with other sourceports. internally, decorate code is compiled to the same VM bytecode as VC.

 

It seems to me k8vavoom ACS can "shell out" directly into VavoomC, am I right?

ACS interpreter does alot of VC calls internally, yes. actually, ACS calls for specials are done by VC code. i.e. VC code decides to run ACS script, and asks ACS interpreter to do the work. and ACS interpreter calls VC methods when it needs too -- to do LOS checks, for example, or to show HUD messages.

 

Is k8vavoom mobj "plain old C struct" or is it an "object"?

it is object. most basic thing is `Thinker` -- this is anything that wants to "tick" (i.e. anything that needs it's `Tick()` method to be called on each frame). then we have `Entity`, then `EntityEx`, then `Actor`. they're all objects with methods.

 

the reason to have `Entity` and `EntityEx` is to separate game logic from engine logic: the engine is not interested in anything game-related, but as class fields must be exactly the same for CPP and for VC, you cannot just "hide" some fields (from either side). so `Entity` contains everything the engine wants to use, and `EntityEx` contains everything other (like various AI flags, for example). and `Actor` represents entities that can be used in decorate.

 

Q: What are "live" mapthings in vavoom? Mobs, Entities, Actors?

see above. ;-)

 

I guess mobj starts in CPP part but most of it's flesh in is VC?

yes. see `VThinker` and `VEntity` classes in CPP, and VC classes i mentioned earlier.

 

Q: Is there MD3 support?

no.

Q: Do you plan on adding more modern, less limited model formats?

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.

 

Q: Models themselves seem interpolated (movement of limbs) when played through engine, but actual monster movement and monster turning is not? You said vavoom uses deltaT model, but is that for player and model mesh vertices only?

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. it is slightly more complex than that, of course, but the basics is like that: movement is interpolated, turning is not.

 

model vertices interpolation is done with LERPing model frame vertices based on state duration.

 

Q: Does this mean savegame subsytem works now?

savegame subsystem always worked, i just want to make it more resistant to future changes. i did some work there, but it is not complete yet (i.e. don't expect your saves to work across builds). still, there is so-called "checkpoint save" (the engine does it on entering new map), which contains only player inventory list, health, etc. -- this kind of save can survive format changes.

 

 

So these are the things I would like to know that I amassed, it would be nice if you found the time to reply at least some of them. Don't kill me.

ah, you're welcome! i am always glad to answer any k8vavoom-related questions. sometimes it even helps me to better understand things. ;-) k8vavoom is a complex beast (it took me almost 1.5 years to arrive to the point i am at today, and i don't have 100% understanding yet! ;-), and it doesn't have proper documentation. so until i can point people to some wiki (which will prolly never happen), i am here to answer any questions.

Edited March 1, 2019 by ketmar

[ketmar]

@Gunrock also, please note that new clipper is not bug-free yet. i.e. you can expirience "missing polys", and it isn't always your fault (most of the time it is my fault ;-). you can use "clip_frustum 0" to check if it is clipper bug (and other "clip_XXX" cvars; don't be afraid, they are not persistant; but note that the engine may crash on big levels with clipping turned off).

 

and thank you for creating great (vavoom) maps! ;-) even the best engine is useless without the actual content!

[ketmar]

a-a-a-and i was 100% right when i told you about broken frustum creation! there is indeed a bug, from ancient vavoom times: the frustum was created in the wrong coordinate system. most of the time it was unnoticeable, because frustum was used for very rough clipping, but when i started to use it for more precise clips, things started to falling apart. Janis prolly didn't noticed it due to the same reasons: in 99% of cases it works almost as expected; and some rare bugs (mostly in room-over-room situations) are hard to attribute.

 

lesson: triple-check your coordinate systems, and rotation vectors.

[Danfun64]

I compiled the most recent vcc_run and the most recent Spelunky code... and I get "FATAL: VC: Couldn't open 'timelimit.vc'" when I try to load the game.

[ketmar]

yay! you won the prize! i waited for someone who will at least try to compile it. you are the first.

 

this file is autogenerated by shell script.

Spoiler

#!/bin/sh

buildYear=`date +'%Y'`
buildMonth=`date +'%m'`
buildDay=`date +'%d'`
buildHour=`date +'%H'`
buildMin=`date +'%M'`

enddate=`date +'%Y%j'`
echo "const int TimeLimitDate = $enddate+5840;" > "timelimit.vc"
echo "const int TigerEye = 0;" >> "timelimit.vc"
echo "const int BuildYear = $buildYear;" >> "timelimit.vc"
echo "const int BuildMonth = $buildMonth;" >> "timelimit.vc"
echo "const int BuildDay = $buildDay;" >> "timelimit.vc"
echo "const int BuildHour = $buildHour;" >> "timelimit.vc"
echo "const int BuildMin = $buildMin;" >> "timelimit.vc"

 

 

[ketmar]

now, two images from Silent Steel (note FPS numbers):

first

second

 

there are still some glitches, but IT IS PLAYABLE! 19 FPS is a fuckin' slideshow, and 40 FPS is playable game!

 

note that SS is a very special mapset, where alot of lighting created with dynamic light sources. and i mean ALOT. it is silk smooth in lighmapped mode, and was completely unplayable in stenciled lighting mode.

[ketmar]

yay! i don't even know HOW it all worked before. some shader locations initialisation was completely wrong due to copy-paste errors, and some shader argument passing too. that is, in some places it all worked only by accident. this was one of the bugs that haunted me for a long time: ocasionally, very-very rare, some textures were disappearing (or blinking). also, it looks like the same bug is responsible for rare lightmap glitches (some very small subsectors was unlit for mysterious reason). i also suspect that this is the bug that caused alot of glitches on some intel integrated gpus.

 

of course, initialising shaders with alot of copypasta is bad. but i never really looked at that code, 'cause it came from the original Vavoom, and i assumed that it is valid. i bet Janis and Firebrand chased those heisenbugs for a long time, and they finally gave up. i found it only by accident -- shaders are rarely toched, after all.

 

now i am removing alot of copypasta, so the code should be more maintainable.

[Danfun64]

@ketmar

When I try to compile the latest vcc_run, I get this error in the compile log.

/usr/bin/ld: CMakeFiles/vcc_run.dir/__/source/scripts.cpp.o: in function `VScriptParser::ExpectColor()':
/home/danfun64/Documents/doom-src/k8vavoom/source/scripts.cpp:763: undefined reference to `M_ParseColour(VStr const&)'
/usr/bin/ld: /home/danfun64/Documents/doom-src/k8vavoom/source/scripts.cpp:771: undefined reference to `M_ParseColour(VStr const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [vccrun/CMakeFiles/vcc_run.dir/build.make:876: vccrun/../vcc_run] Error 1
make[1]: *** [CMakeFiles/Makefile2:282: vccrun/CMakeFiles/vcc_run.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

Also, when I try to run Spelunky on the last working vcc_run commit (4af74413b496940bd6c7d9840945daf9ea8e614d) I get this

forcing 'game.dat'
374 classes, 287 game object classes.
NEW PRNG RSEED: 0x71f00d41
NEW PRNG OSEED: 0xebf441b3
FORCED INTRO
*** NPOT textures allowed
FATAL: cannot load sprite 'sFontSmall'

 

Edited March 9, 2019 by Danfun64