3t0

Okay understood. My initial impression was, that you are against vc scripting (besides adding support for missing code pointers) altogether. To reinterpret: you are against unneeded vc scripting for most mods, as DECORATE should be plenty powerful for usual modifications. Also, I will give acc_run a better look. Regarding compatibility, just for shit and giggles I tried to load mmdcxiv (27th century). Now, while map itself is relatively nice in GZDoom, and I can only imagine how much of work went into it, something is seriously fucked in there. I don't think my notebook is extra beefy but it's not a toy either. In gzdoom I was getting around 60-20 FPS. Though gzdoom performance, when using "modern" features, is slightly annoying (strange framedrops in certain locations etc). Anyway some areas like big plaza are absolutely killing the machine. But, as I said, curious what would happen, I tried to load that into k8vavoom, knowing fully well that many features are simply not supported... ...however "teh dataset" of the map must be awful, I got so many errors from AJBSP it blew through my scrollback into oblivion. Second run to log generates around 1GB of shit. Cosmetic note: although "LOADING..." is highlighted, I would really suggest to change it to "LOADING:", and have last processing stage slightly highlighted too perhaps? Staring for minutes into the screen really confused me there, I was not sure whether engine is not actually stuck. Back to our engine torture, now. Biggest amount of time was consumed by PVS calculation. What is this? I mean I know PVS means Potentially Visible Set, but I discovered this is specific vavoom thing, there is no PVS in normal Doom (only in Quakes) as far as I remember. Does vavoom hold compressed PVS of subsectors, similarly to how Quake did it with 3D leaves? Well, even with 4 threads this took minutes (thank god there is cache). Will get back to that later. Map load also spams with: >Warning: "textmap" line 101237: UDMF: unknown sidedef property 'smoothlighting' with value 'true' >Warning: "textmap" line 101238: UDMF: unknown sidedef property 'nofakecontrast' with value 'true' >Warning: "textmap" line 206696: UDMF: unknown sector property 'lightfloor' with value '255' >Warning: "textmap" line 206697: UDMF: unknown sector property 'lightfloorabsolute' with value 'true' >Warning: "textmap" line 207014: UDMF: unknown sector property 'lightceiling' with value '255' >Warning: "textmap" line 207015: UDMF: unknown sector property 'lightceilingabsolute' with value 'true' >Warning: "textmap" line 207428: UDMF: unknown sector property 'hidden' with value 'true' Reading the specs these seem to be (g)zdoom extensions to UDMF. Now my question becomes: how k8vavoom (or any other engine) are supposed to handle namespaces? Lets say vavoom interprets ZDoom namespace maps with some more, most of the object props are retained, but there are some extra sauce/features/extensions. Map is still in ZDoom namespace, but with to (g)zdoom unknown extensions that it will ignore on load? And vice versa? This will become important in regard to PVS later too. After lengthy lightmap calculation phase, each time that look at affected area (I guess) I am getting (maybe it is because (sub)sector is too big to be lightmapped?): >Warning: Subsector 17040 got too big T surface extents: (3067,3082) When logging this is filling logs to gigabytes. All this is relatively expected. Well I did not expect too "big T surface extents". Now map-wise, it gets worse. This map uses relatively clever trick to make 3D doors from models. When one uses the "3D" door, animation of opening the doors plays, and then linedef becomes passable (I guess? will have to look deeper). Unfortunately in k8v it works only once, then it fails with error: > Log: Unknown action special -45(1, 0, 105, 54, 22) Speaking of doors like these - I have a question (oh my again!) that was bugging me a long time - regarding the visibility culling: - Do normal vertical doom doors block visibility/occlude rest of the level geometry when closed? (perhaps, but can't understand zilch from k8v internals) - Do polyobj lines do that? (same problem like above, but I guess not) - Can one (mapper) toggle visibility/occlusion from ACS/Line specials? (I searched through ZDoom wiki and old Vavoom docs but don't readily see such toggler) - On "portal" ceilings floors? (seems like k8v doesn't support these, but there is portal visibility flag in zdoom extensions, though is it toggleable?) Why I am bringing this up? I have a hunch, that most "normal" dooms "kill" the whole subspace behind the door/lift, when they close. These model tricks, don't do that, and because of that, whole game stutters like shit (my analysis). But overall, I believe that this technique is sound. It would be much better, if engine provided simple but general(!) line special that would allow mapper to toggle visibility of huge areas of the maps through "portals"(as in "holes" for LOS propagation)/linedefs. Half-Life 2 uses similar occlusion optimization and I think it's a pretty good thing. Of course one could hack around that, if closed sector doors really culls vis, with instantly closing sectors "inside" the model, but it would be nice to have general visibility culler like that. I would go will HL2 one like, that allows to set solid color and bunch of other properties, etc. This might be lot of work not worth it and it would also require "publishing" new UDMF props and so on, but I digress. All this is slightly related to that PVS thing, I guess. If it really works as I assume, it stores vis between (somehow) discovered map chunks. Does it use sector data? In many old and new maps, tiny sectors are used as detailing tool, it's literally useless to use them for vis partitioning. Would it be possible to mark such sectors as not contributing to vis and somehow merge them into bigger chunks/cluster (per "room" for example) by defining some custom property for sector (like bool:k8vnopvs or bool:k8vpvsdetail)? I guess this map is really being killed by tiny glowing "detailing" sectors: >Log: creating BLOCKMAP... 2 >Log: building PVS... >Log: PVS: 168996 portals found (14 portals dropped) >Log: using 4 threads for PVS builder >Log: AJBSP: Reject size: 4576826 >Log: PVS building (rough) complete (141641280 bytes). .... >Log: cache: writing 141641280 bytes of pvs table Almost 140 megs of PVS data that need minutes to compute seems a bit too much for this map. It's really detailed, but not "that" big. Sauerbraten has similar problem, there is octree PVS for maps but it's practically useless, as it can take hours to compute. I think that without artist input this algorithm will have problems going more into "the future". Maybe if one was allowed somehow to "group" unimportant detail into whole "rooms", PVS would only need to store room to room visibility. But maybe I am talking out of my ass. Now what really surprised me in this map is breakage of neon "glow signs". I know 3D middtex is not supported, which I assume is used to make many neons in this map, but what is extremely jarring is that PNG translucency (alpha) is not working either. Maybe this map is doing something wrong, but I guess PNG support in engine takes into account only transparent pixels and alpha channel is ignored? Translucency is pretty important feature these days, and GL only engine should support it to the fullest I believe. Or maybe this map is somehow "doing it wrong". Finally, plaza of this map in k8v is so fucked up, that it brings engine to 2 FPS. I blame glowing floor sectors. Do you think that these issues are worth fixing ? EDIT: added property idea for PVS I forgot to add.

I didn't get much time to dive deeper into engine, but I tried messing with vcc_run. It seems, it is quite borked, or I am dumb (that is a higher possibility). I assume originally vc was compiled offline, same way quake does it. Inspecting pk3s/zips it appears that nowadays vc is just compiled on the fly, on load. And here I thought that somehow vcc_run was interpreter that would allow me to do "Hello World!" like there are tests for. Not willing to dilute your attention from your own goals, I am asking still, whether it at least used to be possible to run vc standalone like that, without a game (at least in the past)? Regarding DECORATE and Zscriptification of mods, I applaud your strong will to prevent further fragmentation of the modding scene, but I think it's a given. GZDoom is the monster here, I believe, with most users and mappers. All other engines combined cannot simply compete. More over, virtually any engine that does not limit itself artificially to vanilla, has some features pumped through incompatible language interpreters already. Engines that want to stay relevant are pulling in GZDoom stuff. Regarding cross engine mod compatibility, I really have no clue what I am I talking here about, because I have not played that many mods, but extrapolating from what I messed with, my opinion is, that mods are already pretty much engine tied, or rather GZDoom tied, should I say. It seems like one should be able to play more advanced mods on different engines but there always seem to be slight breakages, differences and whatnot. I mean maps do show up, but sometimes 3D floor might be missing here or there, switch does not trigger, lightning does not work same way or at all, monsters might break depending on what mod devs did, etc. etc. Breakage can be small, or it can render whole levels unplayable. So that makes me curious, if it is really that much worth, to keep semblance of cross compatibility - all engines are by now diverging quite a lot. Maybe this is my own deluded impression so please correct me if I am wrong. By this I don't want to say that things like UDMF, mapinfo and others are bad, quite the contrary, those are the best things that could happen to doom. But they are all assets/data description standards. I am guessing that modders would like to modify game logic more these days? DECORATE is somewhere in the middle spot of all that, but I think creators want more scripting. That is my interpretation of what I have read though. In such atmosphere, having a yet another port, that goes it's own way a bit, is not that bad or is it? I think VavoomC is actually one of the strongest features k8vavoom has to offer. Ofc as I said, I might be completely off the page here, if yes, just tell me and disregard.

Is there even anybody who uses windows these days? Just joking. That looks really nice. Are you using "official" vavoom md2 model pack? So this is kind of "continuous" box projection code, that stretches the collision box along a vector and prevents collision code from missing a wall hit because of not using discrete steps? Noting changes that you are doing to the engine, in many instances I agree with most of them (what keeps surprising me). Sometimes when I build new version I notice thing that was bugging me is suddenly fixed, thinking "neat!". But then there are these "glitches" where one can notice that you really have very specific acquired tastes. Like: portals are shit, models sux, better no direct vavoomc calls from DECORATE in my port (more about that later) :).

final part...

Limit removing continuation... what a drag...

Ah fuck! I forgot we are not supposed to technobabble in the open here, I guess.

You are probably talking about "death roll" effect, where the view slowly rolls to side when you die. I personally love it (it would be awesome if mod authors could somehow use it in custscenes wink wink). I think original(!) duke3d has it too. Anyway you can disable it with `cl_deathroll 0` in your config/console wherever that is.

Okay so this means that actual light level is "lifted" from sector light level, then if some light ray hits the surface, lmap is calculated and surface is lightened, and finally dynamic light projects it's own blob onto result. Thus rules for lightmap lightning are same like for gzdoom's dynamic lightning: mapper makes sectors darker and then lights them up with vavoom light "things" ... but original doom "crisp sector" lightning is stilll preserved (not counting stencil shadows). Also, if I am interpreting you correctly, this allows following thing: to have "quake-like lit" area of a map smoothly transition into solely "sector lit" area (by stopping using light things in that part of map) and then back (by starting using light things again). And ofc. people using advanced renderer, will get sharp doom3 like lightning with sector lightning only, mixed in similar way. I hope this is correct interpretation. As vavoom considers itself advanced port I too think that going full floats is logical. I was just confused by doomwiki, which is written in a way that suggests that fixed point is still being used in general in sourceports, which might not be the case at all even; at least for anything using GL probably. I guess. I was confused by finding segs related structs using float when I expected ints. I see, this makes me remind initial quake/unreal dichotomy. I was always doomer/quaker, my colleague was unrealist (we are talking about ureal 1). We always got into arguments about those engines. I never mapped for unreal, but was once explained, that level starts as infinite solid and then you use brushes to carve out the level. Never verified this claim, but I believe it. At first I considered that really strange, but these days I think it was amazing design decision on unreal's guys part. Consider how many BSP leaks were avoided and room modelling was sped up (and thus man hours saved) just by that. My friend considered that a sign of technical superiority of unreal. But your description of vavoom algorithm made me realize that doom, too, basically tracks "empty spaces" as well, same way as original unreal did. Doom's environments really are carved from infinite solid. Looking at it this way, it seems vavoom approach of tracking empty space, indeed really is the proper way. When thinking once about how true room over room in 2.5D engine should work I too realized that "holes" structure for walls would be probably most proper way to go about it. I hope this won't affect "solidity" feel of the engine in the long run :). No, I understand that this is classic quake design. It too shuffles network messages between memory buffers when playing SP, simulating network play, but in essence the two simulations (server and client) are completely isolated. That is one thing I like about vavoom. I remember skulltag and zandrom being only other client/server dooms (not sure how it is nowadays and not so sure about zandronum), but I still am too lazy to dig out, whether they actually use quake client/server model for single player too. Understood! In-memory network simulation must always be there or game cannot work. That is okay. What I wanted to say, is that at some point, k8vavoom should initialize only "fake" singleplayer network by default, and not to attempt to init other network "drivers" until multiplayer is actually attempted. Even then, failure of such initialization should not make engine bail out into console (exit) as "in-memory network" is always there as failsafe. Maybe one must create drivers beforehand, but should defer socket binding to later? Would that be possible as quick fix? Also see below about "-ip" too. So this is indeed same as quake. This causes me to ask several more questions about client/server IO and VavoomC processing: Q: Is this used to record vavoom native demos like quake does? As that would indeed mean that vavoom-native demos are (have possibility to be) future compatible. Or there is no such thing as vavoom-native demos? Q: Is there any updated entity limit like in original quake (eg number of mobjs that can be synced), or thanks to garbage collector vavoom client (renderer) can track as many mobjs as there are sent from server? Q: Finally, regarding this matter, I assume then, that both parts, server and client, run their own instance of VavoomC bytecode interpreters akin to modern quake's serverside QuakeC and clientside QuakeC (CSQC)? In effect ftequake seems to have menu QuakeC instance too, are UI's in Vavoom yet another VavoomC instance? If so, would you be so kind to point out where these things are happening (cpp/vc) side? This does not seem to be simple callback based system where scripting engine host calls out into "progs" function at specified spots. Rather, it seems, this is OOP-y heavy thing, where, somehow, one must probably "subclass" a class and override it's methods to "hook" into the parts of gameloop cycle. Am I right? Hoping my oopspeak is right (I hate oop). I tried "grepping" around trying to locate the "hook" spots, but amount of classes and other shit is massive. I can't imagine how anybody dove deep into this stuff. If so where should one start reading (preferably file path, line) just to get idea of: - one server tick (simulation step)? - one client tick (simulation step)? - one menu tick(?) or is menu simply declarative + ui classes hooks/overrides? - one clientside render hook (or can one inject vavoomC into render cycle)? Also Vavoom "wiki" (which came back from the dead it seems) states: "VavoomC supports only class member functions." However dox_vavoomc/vavoomc.txt says UFCS is supported. If I understand UFCS right, it cannot work fully, without supporting freestanding functions as well, where first paramater is converted from "this/self" into first function call argument, or am I missing something? Yeah I re-found it later, after writing about "-host" (should be probably "-hostname"), and it indeed "solves" the problem, however... Does this mean that once one does "-ip 127.0.0.1" embedded server will actually bind there and client will use that connection to play single player? I actually see "127.0.0.1:45250" being bound. If yes, I believe that, unlike "-nolan" (which I imagine to copy messages in-memory buffers only), it sounds bit suboptimal. Also, while we are at it, why not just bind to "*.*.*.*:45250" and no hostname would be needed that way. But I guess this is way outside of this discussion. Seems to work now. Your engine, your pace. Frankly, I am not a big fan of sharp doom-3 like shadows on the other hand. But even in their current form they, lightmaps, look pretty good. Now in stencil shadow mode, I do see level geometry, lamp posts and myself cast shadows, but monsters seem shadow-less. Is this normal or a bug on my system? Speaking of lightning modes, would it be possible to have 3rd "ultra" mode :)? Eg. both lightmaps+stencil shadows? For glorious 10 FPS. Speaking about rendering, I recently had nice time with QuakeSpasm, and was reading bit of their features and also Tesseract (Sauerbraten evolution) code. From comments and descriptions it seems, that these engines render sky polygons into stencil (or something like that) and then use that stencil to render sky cubemap. This way skybox texture really occupies only pixels marked by sky polygons, occluding even geometry which would be visible, if sky polys were simply not drawn. Not sure what mechanism k8vavoom uses (it seems it just starts rendering with skybox everywhere as soon as it knows there is some sky surface in sight), but thinking about it I came to believe this approach would easily "solve" the issue with skybox sparklies (or rather default black glclear color would make them less visible). It certainly would be easier to do than to mess around with polygonal subdivsion. What do you think? Q: Last thing I would like to know is what editor/IDE do you use, because my QtCreator seems mighty confused by .h/.hpp (it defaults to C for .h, which in case of vavoom they are not marking loads of stuff as errors).

Reading backlog I see you already know about the water, disregard then.

After some slack and bit of Quaking, I pulled in new changes and tried Gunrock's new Silent Steel. So far so good but I must say "new" weapons feel a bit flaky. BUG: I am on 33dfee11988e6ac9629e3bd87e5ff4d06d6f6ecf and water seems tragically fucked. It seems that when you are in water sector, k8vavoom is picking you under water as being on air (z below water surface) and above the surface, as being inside the water instead. Seems to me like comparison flip somewhere, but no clue. BUG?: I am also not entirely sure but I think, that light now leaks through 3d floors in Wispers and Silent Steel and others. Because silly me didn't note the last commit I was playing with before, I am unable to rollback where I think it didn't leak. Were there any changes in light rendering code? BUG: this was fucked sice first compile I did but as I got around it, I forgot to report it, but unless -nolan is specified game cacas itself with: Log: Sys_Error: UDP_Init: Couldn't get local host by name blablabla, Log: Check your /etc/hosts file. For singleplayer (probably by default) it should not try to bind (or what it does) to anything, and it should not start network subsystem unless multiplayer is wanted or started explicitly. More over, on muti-homed hosts binding to gethostname() by default, which I assume it is doing, in this day and age, might be a bit silly. I believe it would be much better, if it pre-filled this into the UI but still allowed "custom hostname"/"direct ip" input (and allowed sysops to set this with some params like -hostname/-listen if they want to run dedicated server). Unless dedicated server, it should certainly not allow engine to fail, if network settings cannot be deduced. In attempt to multiplayer, once started, it should definitely not quit either, if it cannot deduce it's own ip, but it should warn user instead. Q: Playing all vavoom wads that I have a bit, I now studied blood/gore decal quads more. They show up everywhere, which is nice, but these are not "yet" clipped to sector shapes when on ground, this is to be expected? Q: Second question related to decals is: how I can get hitscan after-bullet-puff holes show on ground? Or this is not yet working? Q: In Silent Steel Remastered I am seeing also some light artifacts on walls and floors, like darker sector(floor)/square(walls), is this related to some ligthmapping changes? Q: Studying these artifacts, got me thinking how does k8vavoom playing-time "light equation/model" works? In following "models" sign '+' does not represent actual mathematical processing happening, but rather mixing operation, whatever that is actually used (whether it is multiplication, addition or what). Studying dynamic lightning in GZDoom a bit (just messing with few room levels, no code reading because too lazy), I think it's "model" works like this: sector_light + dynamic_lightmap = resulting_light. Lightmap is basically a circular blob that is mixed with original darkened texture of floor/wall polygon. It seems lights in GZDoom can have a modified conical textures, aka pie cuts (arcs) of "circles", if they are put in small alcoves and such. So to "light" level with "lightmaps" in GZDoom, one makes completely dark sectors and then adds light sources to light them up with point lights as needed. These are not "true lightmaps" in Quake' sense, but analyzing some better dynamically lit wads for GZDoom, I learned that it can look pretty good, if done properly. But I am unable to get grasp how k8vavoom does this. Does sector light contribute to resulting light or not when there are ligthamps? It seems not but I am not entirely sure. For now it seems to me that light "model" works like this: sector_light + static_lightmap + dynamic_lightmap = resulting_light. This however happens only and only if there is at least one vavoom light in the level and lightmaps thus can be calculated. If there are not any vavoom lights in a level, engine reverts to gzdoom-like mixing where it does: sector_light + dynamic_lightmap = resulting_light. This is observable in ID original maps. By dynamic_light I understand blobby ligthmaps emitted by things like powerups (armors, health vials and such). This would mean that level designer actually has two lightning models (three , when including doom3 like shadow volume lightning) at their disposal. One based on lightmaps and one based on ligthning levels solely with sector_lights + dynamic_lights (eg. things). Is this interpretation correct? Just blurping to myself: reading code a bit it seems that most modern engines actually use float for vertex positions and thus fixed point math is never used. K8vavoom certainly does this. I am not sure, what, besides original dos doom and maybe chocolate doom (which I have not looked at) actually fixed point even. Q: Few things I would like to know regarding 3D floors. In the end, it seems, that each port went it's own way. I personally remember the first time I saw 3d floors, it was in Doom Legacy and it was awesome. I think it was way before any major port actually had ones, but maybe I am mistaken. They were rock solid to move on. Then I saw them in original vavoom and it was realy long time ago too, and I vaguely remember they felt like shit sometimes. Whole vavoom movement back then, especially in certain areas like water tanks in demo maps, was always quite a bit weird. Then I saw them in Risen, I think, and they were not that "solid", but pretty good. It took some time till we got them into (g)zdoom, if my memory is right. Whether they were any good in EDGE, I don't know. But messing with them (running jumping and strafing recentlish) I hit some corner cases especially in combat. Anyway creation wise, I admit that so far I only played with 3D floors in gzdoom. From my current understanding is, that even mapping wise, true vavoom 3-D floors are somehow weird. If I understand it properly, main reason is that floor and ceiling are reversed. What other engines call ceiling of "3D floor slab" is floor of "3D floor in vavoom" and vice versa, more over, zets of these surfaces have to be flipped so vavoom floor of "3D floor slab" is actually higher than it's ceiling. Now I see this as weird editor/model sector wise too, but it makes sense logically wise, somewhat. Is there a reason for it to be somehow better? And if I understand it right gzdoom still converts such floors into it's own things when reading that in map, right? Returning back to actual game physics, playing vavoom maps in k8vavoom, I never had an enemy "teleport" down through seam of 3D floor and normal sector or something like that, but I distinctly remember getting that in gzdoom. Maybe I was just lucky/unlucky but somehow I think vavoom 3D floors even implementation wise, are somehow fundamentally different than in other engines, is this correct? For example I read on zdoom forums, I think, that in zdoom family of engines they don't block visibility? Is this same for vavoom then? Given one is creating map for vavoom and there is no gzdoom-way conversion yet, I presume that for vavoom only maps, one should limit strictly to vavoom-type, is this correct? Also do these vavoom 3D floors support lower texture tricks and such as well (so that one can have textured 3d switches), from wispers it seems that answer is yes? Thanks for reply in advance.

Somehow I manged to merge my stuff from textfile with forum SW so here we go: • Q: So this means that VAO+VBO should be possible in the "future" once you get to it, right? 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. • 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? • 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? 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. 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. 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".

@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.

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.

It has been some time since I have been on dooming spree like these days. Game engines, especially underdogs like Doom, Quake, Cube, Sauerbraten are fascination of mine. It's on and off thing for me. And I am now in one of such phases, thus this will be long so please, bear with me. Or not. Your call. BTW/ bullet points are "kinda questions to answer" by somebody. Long story short, I wasted quite some hours recently with some of these elder games of yesterdays. After learning about ZDoom's unexpected death and playing few days with GZDoom, I decided to give a ride to few "other" vehicles. One of them was Vavoom. I did not know what I was getting into, though. 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? I started with "pure" on 486 and Pentium and lost so much time with it does not even register anymore. After burning my and friend's monthly allowance together on copy of book of "Doom strategy" with DEU on a CD (none of us had reader - but we managed through third friend), I quickly hit visplane overflows and internet was not yet (in my country at least), eg. to get source ports. Over time I became all OpenGL (because it works perfectly everywhere, maybe besides shitty Windows and looks really good), WSAD, +mlook, noautoaim guy who loves UV (old oned - current UV wad authors are serious madmen) and very sporadically some NM in first levels of D2. "Pure" Doom with fixed yaw feels like shit to me these days, so much for it. I love how my doom experience only gained and I lost nothing. If I wanted purity, I would just dust that old 486 in basemented (it works perfectly till these days). I want fluidity software cannot easily provide, that's why I play source ports. So back in actual land of GL ports, situation seems rather stagnant, or stable, maybe even stale? Well "everything as usual". And don't get me wrong, I consider that a very good thing! STABILITY IS A GOOD THING. You can build on stable. Not so much on the opposite. But there is something else besides stability I am interested in and care about, and it's related to the future. But I wouldn't call that futurething of interest "modernity" though. Everyhting I learned about "modern" is, that it is old bullshit that somebody is trying to sell you as cool new shit, but it still the same shit as always, maybe only sideways. And I am not even that old. The thing that I really care about these days is progress! Now. Now. That good old progress. It is something different then "the modern". Progress usually loves to take it's time and you cannot just readily see it. You have to evaluate it agaisnt that time it took. See thing before, see same thing after some time and only then you can gauge progress it made. So overall, in source ports land, I did not detect much progress. Doomsday is relatively good looking, traditionally, heavy as shit, as always, having weird ass launcher (is it here or not? I never can get that crap to build) or something pulling in dependencies on stoopid packages that game should never need. It was cool, when it gained fake radiosity and flat glows some time back, but besides frollicking with UI and menus it did not made much observable progress in recent years. Internally maybe, but who knows? Now other ports are nowhere near as complex and feature-filled as GZDoom is. That one seems constanly ahead of the pack, most single player and mapper/modder friendly source port there is. Rock solid, but there are occasional stutters sometimes. Story-and-feature-wise all wads I tried work. "New" portals tech is very cool, full GPL compliance too, so much progress, as usual! PrBoom+ felt most "vanilla-like" (not that it matters to me), but both the +mlook and movement feels fucked up. I haven't noticed any real progress. Not bad. At least it's stable. EDGE/Hyper3DGE always seemed pretty dated to me visually, despite it being quite powerful and most daring to progress. Yet for some reason I am getting black layer of blinking shit around any 3D floor platform in EDGE demo maps (circular room with moon and such). Also the slight quake-like roll to side when strafing, with wobbly steps, doesn't feel right in most levels, vanilla or not. But I can imagine it might be cute for some kind of mod though. There was certainly some progress, but I don't feel it. With Zandronum, that still rules at multiplayer for me, all other ports like Risen and others, are trying hard to survive in their little pockets of community, but are more or less similar. Not perceiving much progress. Then, I suddenly remembered there was a doom port with light-mapped environments. Lightmaps in 2.5 Doom? Now that is some serious progress! I wanted to see that. And after some time of thinking really hard I even remembered the name: Vavoom! I always considered it intriguing. But, in the past, I never had a good luck with it. Each time I tried it, it was stuttering like shit and generally felt very unstable overall. Like ready to tip over at any moment. But that was ten years ago. Maybe progress happened and things got better! But no! Reading of wiki and searching the net showed, that it died unexpected death, seemingly. I was so sad! I wanted to try it, to gauge progress it made! But we didn't even had a chance! Well, but sometimes, I am persistent maggot and was willing to give it a try anyway. I really wanted to, given I never had much fun with it in the past, and I really wanted to see ligthmaps in Doom. As I refuse to muck around with outdated binaries in vms (or wine), and source is open, I checked out the repo from what seemed to be canonical upstream (there were even some spurious commits logged until recentlish - huh, so there might be a chance it will compile, I thought). Once checked out, for shit and giggles, I tried to compile it right away. This is on relatively modern distro, Void Linux, my daily driver. Despite not being the teenage edgelord of nerdy Archers, it is not completely stale piece of shit that Debilians and Boobuntus are, and so it has been some time already, since extra shitty GCC 8 landed here (to immeasurable joy of many, I presume). <siderant> Why "for shit and giggles"? Well ... I learned myself some bits of C in recent years (nothing ground breaking though), and one thing I came to believe, based on that experience, is that C++ is fucking disaster. An abomination that should have never ever existed and as soon as it appeared it should have died. Yesteryear was late. C is definitely more robust thing than C++ can ever hope to be. Don't get me wrong, OOPy shit and C++ features might be sexy for you as a coder (or maybe not), but there is one thing that I am 100% sure and that can be 100% empirically proved and confirmed by anybody willing to and that is that C++ is fucking disaster for the user! And I don't give a fuck about what hipsters are saying about how boost shit and C++ 2025 geriatrics, or what, are gonna save us all. Reality is, that not only we have army of shitty C++ compilers (MSVC, gcc, clang) of which not a single one does same things right or at least same way as any other, but any C++ code compilation is essentially "onetime" affair: Fact that something in C++ compiled yesterday is completely tied to that moment, it does not mean it will compile tomorrow. It means just that "it compiled" (today) and nothing more, and nothing less. You cannot know whether it will compile in the future. So much for stability. Also no real progress. But C++ is definitely modern. Tsssssh, I will tell you a secret everybody sane knows, but we don't talk about it much. C++ is in fact pseudo random error generator. And GCC is, by far, worst offender in that. At least in my personal experience. Case in point: I have some old toy C++ engines covered in dust, lying in storage, like Quake3 BSP loader demo that I found onnet in 2005. Things like that are essentially impossible to compile these days. And what's worse, they are impossible to fix yourself as well, at least, unless you are C++ guru, that is. And if you are that much of a C++ guru, then it's already too late for you. You brain has been C++-ified. So take a note, if you see some 1 month old C++ code, only way to tell whether it will compile is to try it. But there is 90% chance it won't work, though. So don't bother. Electricity is expensive resource :). Funny thing is, that in the mean time, even several years old (though revised) K&R C examples from the book I got as gift from brother, will compile today just fine and probably will do so even in following decades, aka future. And they will bring us progress, and should that compile once fail, there is still sizable chance you will be able to fix it yourself, as mere user, just by reading compiler error output. No "modern" randomness of the day. So when I saw quite a few .cpp's in vavoom's checkout, I knew it will be "for shit and giggles". But one can have dreams ... or not? </siderant> Thus I started the build ... and, unsurprisingly, after one zilliard of undecipherable C++ random error messages "of not cool enough", probably about vavoom not being following proper C++ fashion du jour, the build died on something fatal. I tried to muck around with letters for a bit, moving them back and forth, but as expected, it went nowhere, and I had to give up on vavoom once again. The one, I never got the chance to try out properly! I have to admit, there were tiny tears in my eyes. Feels. Next evening, still refusing to let go, somehow, this thread finally got into uncle Gees database of my personal filter bubble (asshole probably saw me searching for Vavoom stuff like mad), and I found this fork. I was really excited, holding my breath. I did: git clone blabla k8vavoom.git cd k8vavoom.git mkdir build cd build cmake .. And watched percents scroll by ... and ... besides single something not fatal ... it compiled! I could not believe my eyes! Then me and k8vavoom fought a bit about command line arguments ... Regarding that thing, first note: please make k8vavoom understand '-h', '-help' and '--help' so it says something meaningful instead on insisting that I forgot to specify IWAD dir. Incantation synopsis with list of arguments supported would be really nice. While at it, teaching it '-v' and '-version' would be cool too. And finally with all path and game args supplied ... it consistenly died on me with: So close, so fucking close ... This cannot be! Did I say I am maggot sometimes refusing to give up? Such was the case now and so it all started. I reset build dir several times, zapped and checked out the tree, moved around in last commits with full, in-between, zaps, trying to find out whether something did not break WAD/PK3 access on my system - but no avail. Finally reading the old readme, I noticed that engine was always built in place, inside the tree. So after another full zap and: cd k8vavoom.git cmake .. ... it worked! One magic invocation later I got to Doom screen! I was joyous! Regarding that, are not out of tree cmake builds of k8vavoom supported? Finally we got to have some one on one quality time, me and k8vavoom! After some mucking around with resolutions, due to my multimon and keyboard bindings, I got nice stream of classic "vanilla" dooming up to "Trick and traps", when I got bored. Vanilla worked great! What surprised me most was overall stability and swiftness. Engine didn't seem unstable one bit! What I was most pleasantly surprised was great doome-y movement with perfect quake-y +mlook. This port's movement definitely feels best to me so far! Also apparent framerate seems very very consistent and fluid, no peaks or lows... Is that your doing, ketmar or was Vavoom always like this? Or it's just that hardware is so overpowered these days that vavoom feels great? On that note it seems that built-in developer FPS counter is permanently stuck at 90 FPS for me, unless it drops, that is (more on that later)... But I wanted to see two Vavoom killer features the most: 3D Floors and Lightmaps. I wanted to see progress. Dling and running official demo level first, left me a bit lukewarm. Slopes in first room and 3d floors in another, both were totally fucked up. So much for good swift engine.... But reading this thread before, I remembered ketmar had some problems with zdbsp, so I switched back to ajbsp, and voilá, level was playable again! So question is why is zdbsp needed, why bother with it? (due to mods?) Speaking of FPS, those seemed to be locked to 90FPS, and if they are, I certainly missed something and am sorry for bringing it up. Anyway with stencil lightning FPS tanked drastically to around 40 FPS in certain angle. Does it mean that "new" lightning model is still very unoptimized, or that is realistic cost it has? Last thing regarding demo, map besides some architectural scale issues, it worked as adveritsed, albeit lightmaps were looking like crap. The whole map is really bad, but i discovered some rather serious issue with vavoom: Water handling is uber tragic! Seriously, I was studying it big and is disappointing First, when you jump into the water, you sink. That is normal, but it is not happening normally here. You sink like a rock! I guess armor and all those weapons and ammo are pulling you down like mad :). Second, it is virtually impossible to get out of the water normally, by reaching the edge of the pool and getting out. You can jump (not) and you can rub the linedefs, but you cannot simply get out of the water in Vavoom (at least I can't). But then I discovered you can actually jump out of the liquid by doing small "curvedive"! First you reach the surface, then you mlook down to bottom and do small dive, that while holding "run" (or on autorun). When you reach about a meter of depth, you then mlook back up, surfacing. This movement gives you sizable momentum, so when you penetrete the liquid's surface you will fly out of the water with speed of the rocket that is following (impossible) parabolic trajectory. This is ridiculous! While I have to admit I have lost too much time to count jumping in and out of the water tank in demo map, and that it is quite funny thing in it's own way, this waterborne behaviour is just silly. Especially since you cannot simply climb out of the water at edge of the water body, no matter what (or it is really hard). Sinking down at a speed of freefall doesn't help the case either. It bears to mention, that actual moverment in water is superb: back-forward-strafe and mlook wise it works great, albeit too speedy. What I suggest: As this funny water mechanic is rather funny, I believe it should be preserved for posterity. I suggest cvar g_funny_water, which if set maintains this exact behaviour. Then I suggest to add check in the engine that when you are surfacing from the water to stop you at the water surface level, maybe allowing small wobble even but no straight "jump out". I believe player's momentum should be removed or severly dampened when reaching water surface from bottom (top one that is). This will stop the incredible "dolphin jumps" out of the tanks. Then I suggest to add bigger sideways up/down movement friction while in water (this will prevent player from gaining impossible speeds while waterborne). You cannot swim faster than you can run or jump. Then gravity needs to be seriously dampened in underwater scenarios, especially when idle. Sinking speed of Quakes, Half-Life or Saurbraten should be emulated. Water does not feel like water if one just falls through. Finally, climbing out of the water at the edges of the tank needs to be fixed. You should be able to climb effortleslly out of the liquiquid but only near 2 sided linedefs, where adjacent sector is not too high (maybe at maximum stair height?). Without this it would be impossible to get out of the water once dolphin jump becomes impossible. Where this should be fixed, I have no clue. Is it in VavoomC part? Or in C++ parts? Maybe it would be good to have some tweakable "liquid movement model" with flags like "can jump out through top surface", "can climb up at edge", and properties like "antigravity friction (buoyancy?)" and "movement friction (viscosity)". The point is not to have physically based model, these are simple additive/subtractive values, similar are used for effects Doom already does, so intent would be to add only something simple, relatively similar what we already know. With such "model" in place, perhaps for all actors, it would be possible to have some default values, for say water, that are active by default when thing is underwater, and then maybe have Thing that mapper can place into the "water" sector to tweak these values. High "buoyoancy" and high "viscosity" would create something "thick", and paired with "lava" texture, sector damage and thick traslucent red color inside of the sector, one can create really nice "lava pit of despair" which is really hard to get out of. Once actor would enter normal sector the model would be deactivated completely. There even seem that something like that is already happening behavior wise (current water seems to increasing friction a teeny teensy bit), but it's very unnoticeable. Well sorry, this was just a thinktrain I got into, being tortured by Vavoom's water for some time (everywhere not just demo map). After playing jumping out of water in the demo I got bored. I wanted to see more of the lightmaps. So I searched for all the vavooms wads I could find and tried them all: Slayer's, Whispers, Storage and Silent Steel. Now finally I saw the progress. Lightmaps, aka static lights, are absolutelly stunning (relatively, eg. that is for doom engine), very Sauerbraten-y (I guess due to lightmap renderer constraints of being level load time eg. online). Demo map does not give the engine enough justice. Atmosphere and ambience of the properly lit levels was phenomenal and combined with 3D floors I was finally experiencing something new. 3D floors felt rock solid, I never got any glitch. Slopes were bit hairy and water was awful. Combat was superb especially on bridges and such. It all felt very quake-y, looked gorgeous, and unlike in Quake, I had great automap (which is also very tastefully done). Only problem I have with the wads is, that there is too few of them. I must honestly say, I was flabbergasted. Full disclaimer: I am one of those weird guys who considers lightmaps superior to anything, and stands by it. I think the one reason why even young kids don't laugh at Quake 3 is that is uses lightmaps. You can be completely inexperienced, you can be dumb, but you cannot fool a gut feel, that lightning cues provided by global illumination techniques like radiosity provide to yout vistual cortex. They simply look "realistic". Modern game lightning is shit. Most of it are hacks. It's basically simple sharp point lighning fom 90s with pile of hacks to not look so sharp. Real world light is much softer. Lightmaps can provide that. But. Ask anybody raytracing architecture, how much it takes to trace proper GI for a scene, and ee are talking about hours if not weeks of constant 100% all core and memory tortures. That's the price for soft "leaking" lights. And that's how long qlight phase took on some crazy maps, we were making when Quake came out and when both algorithms and machines were shitty as fuck. Today's q3map2 is pretty good gauge of progress we made since then, and although it is somwhat dead, still more people are baking lights into the models in unities and blenders. Static lights are superior because they are offline, can be pre-computed expensively using most complex algorithms and then be reused quickly and repeatedly. So one of my nest questions is: would it be possible to have calculated lightmaps stored in lumps of map's wads itself? Currently it seems engine recalcs them each load. Lightmaps have only two disadvantages: they are static, so nothing in the world that is casting a shadow can ever move and they consume memory. I think Vavoom hits sweet spot in both looks and efficiency. After all it's ligthning model seems one of the simpler ones. Some people say all this can be achieved in GZDoom and dynamic lights too, so if you know of any tastefully done wads like that here with them! I am quite skeptical, though, and so I want to see such result with my two bare eyes. Anyway, great engine! If it is unstable as they say, I have not hit, it miraculously. Thanks ketmar very very much for bringing it back to life. I hope you will maintain to maintain it :)!