k8vavoom: no good thing ever dies!

[Gunrock]

22 hours ago, therektafire said:

Just started playing through silent steel remastered with the newest version and I already found what I assume to be a bug though i'm not quite sure who's fault it is, if you stand with your body between the lift and the ceiling in either of the lifts in the first area the lift just stays there and you get stuck unlike in normal doom where it goes back down. I don't know if jumping and crouching is supposed to be allowed with this wad (since it wasn't ever mentioned) but you would still get stuck even if you are crouched, so that should probably be fixed

 

Oh also alt tabbing out of k8vavoom always 100% causes it to crash for me when in fullscreen

 

19 hours ago, ketmar said:

yeah, i know that you can block yourself this way, thank you. have to check if this is my fault, or SS:R -- will do it later (right now i am still trying to untangle doom movement code, so it can be replaced with my new `traceBox()` API ;-).

 

unfortunately, this doesn't happen with me on GNU/Linux native, and with Wine. i'll try to re-check the code, though. thank you, maybe i'll be able to do something with it.

 

alt-tabbing from FS OpenGL apps always was a PITA under windows. (sighs)

I notice too that 3D floors will stick the player. In the last build it would just rest on top of the player's head and you can still move out of the way and it will just go down as normal. I wish I knew how to do a script that can crush and damage the player when it comes down on the player's head. ;(

 

:edit Just tested to see if GZDoom sticks the player on 3Dfloors too and it didn't.

Edited May 16, 2019 by Gunrock

[therektafire]

10 minutes ago, Gunrock said:

 

I notice too that 3D floors will stick the player. In the last build it would just rest on top of the player's head and you can still move out of the way and it will just go down as normal. I wish I knew how to do a script that can crush and damage the player when it comes down on the player's head. ;(

Is there a way to check the height of the 3d floor on every tick/frame while the script is executing? If so maybe you can check to see if it has stayed at the same height without reaching the top for a certain amount of time which would mean that it got stuck on the player (maybe an enemy could get it stuck too but in the area where i found out about the bug in the first map that seems like a highly unlikely thing to happen) and if it has then start hurting the player or teleport them up, whichever you prefer?

[ketmar]

20 hours ago, therektafire said:

Is there a way to check the height of the 3d floor on every tick/frame while the script is executing?

this would be a waste (it should be done by the engine), but yes, it is possible. 3d floor height is actually the height of control sector. still, there is no reliable way to check what exactly blocked it. you may guess (by looking what mobjs are in the bounding box of 3d floor), but again, ACS is not well-suited to do so.

 

p.s.: anyway, i am far from finished with new 3d floor implementation, and i'll back to it after i'll integrate new movement code (which is going quite fine -- in my PoC testbed i can run around a level, with sliding, stair climbing, height blocking and such, and fire boxes in any direction with any speed).

 

don't expect new movement code activated by default in next build, though. i am planning to have it as alternative implementation, which could be turned on via console, and gradually fill all the holes before making it the default one.

Edited May 17, 2019 by ketmar

[Khorus]

Good work, Ketmar :)

 

For an engine that isn't trying to replicate doom, new movement and collision sounds like it has big potential. I'm guessing (as a non-programmer) that it will mean things like no more bouncing off odd angled walls and other strange Doomisms?

[ketmar]

6 hours ago, Khorus said:

it will mean things like no more bouncing off odd angled walls and other strange Doomisms?

yeah. it is as fluid and predictable as Q3 motion (which was the model for my code). right now i have a PoC where i can run on "automap" (i.e. i didn't bother to implement 3d rendering in my testbed ;-), and when i am taking a break from implementing missing features, i am running through various maps, from vanilla to some complex community creations. it seems to work as intended. ;-)

 

sure, tricks like "wall teleporting" won't work anymore (they are barely working now anyway). and i'll prolly have to implement a hack to support "item grabbing", because some maps rely on that.

 

as a bonus, i have reliable `traceBox()` API now. i.e. i can fire a box in any direction, with any speed, and it won't miss a wall. ever. which is useful not only for fast projectiles, but for queries like "can mobj move in that direction, and how far?"

 

tbh, `traceBox()` was the thing i need. but once you have it, there is no reason to not try to get rid of a mess called "doom movement code". it is unmaintainable mess, anything will be better than it. ;-)

 

p.s.: original doom code has no "can i move" query, you can only command mobj to move, and check if it arrived at a destination. whcih is not that bad, but... monster/player will activate all triggers on its way. first i tried to add some hacks to disable trigger activation, but it made the code even less manageable. hence, i decided to implement `traceBox()`.

Edited May 18, 2019 by ketmar

[ketmar]

actually... why not? ;-)

 

Spoiler

 

[ketmar]

also, i just realised that with this new collision code implementing portals is almost a no-brainer. no, i won't do that (i still think that this is a misfeature), but it is easy. if our box touches a portal plane, just apply portal transformation, and continue tracing. that's it. and if doing slide move, we should do inverse transformation on planes used for sliding if our cube is partially inside a portal (this is easy to check). as all new physics code is based on box tracing (and it doesn't care about sector shape, it works with walls), after applying portal transformation to origin and velocity everything else with automagically work.

[Gunrock]

Great work as usual Ketmar!!!

 

I'm currently reworking another old deathmatch project of mine to take advantage of Ketmar's new deathmatch bots and the K8Vavoom engine.

 

Project should be done and ready for testing before the month is over.

 

 

 

 

[ketmar]

please note that bots are far from ready (yet i did some much better work on automatic waypoint placement). especially, they don't know anything about navigating with 3d floors. eventually i'll implement that logic, but for now -- alas. tbh, they aren't that good at navigating at all: they know where to run, but loves to bump into walls and corners. ;-)

 

i really have to implement directional light sources, to make proper sunlight without "huge point light" hacks.

[ketmar]

eh. slopes sux. it is freakin' hard to implement good movement on slopes with doom idiotic separate movement code. i managed to implement something that almost works, but it is very fragile. at this point i am not even sure that "vanilla compatibility" (which we don't have now anyway) is something worth keeping, while i'm trying to retain idiotic doom physics.

 

have to let it rest for some time. maybe i would be able to come with something better after i let my brains to process it in background mode. ;-)

Edited May 20, 2019 by ketmar

[3t0]

On 5/16/2019 at 2:38 AM, ketmar said:

alt-tabbing from FS OpenGL apps always was a PITA under windows. (sighs)

 

Is there even anybody who uses windows these days? Just joking.

 

On 5/19/2019 at 5:10 AM, Gunrock said:

I'm currently reworking another old deathmatch project of mine to take advantage of Ketmar's new deathmatch bots and the K8Vavoom engine. 

 

That looks really nice. Are you using "official" vavoom md2 model pack?

 

On 5/18/2019 at 10:41 AM, ketmar said:

i have reliable `traceBox()` API now.

 

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?

 

On 5/19/2019 at 1:52 AM, ketmar said:

i just realised that with this new collision code implementing portals is almost a no-brainer. no, i won't do that (i still think that this is a misfeature), but it is easy.

 

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) :).

[3t0]

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.

[ketmar]

2 hours ago, 3t0 said:

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?

exactly. this is the same "swept AABB vs level geometry" test that is used in all engines out there these days.

 

still, doom movement code is very quirky (it insists on strictly separate XY and Z motion), which complicates everything alot. this is what i am struggling with now. it would be much easier to simply do everything in 3D (and maybe i'll try that approach later), but for now, i want to emulate doom weirdness, only this time with proper box tracing API.

 

2 hours ago, 3t0 said:

Noting changes that you are doing to the engine, in many instances I agree with most of them (what keeps surprising me).

maybe this has something to do with the fact that i hate C++. "pro/contra C++" are usually very distinct mindsets. ;-)

 

2 hours ago, 3t0 said:

Like: portals are shit

only in doom engine! ;-) if only i'd design 2.5D engine from scratch...

 

2 hours ago, 3t0 said:

models sux

only monster/player. tbh, i am playing with modified vavoom 3d model pack, which replaces decorations and pickups with models. i will eventually release it (when i'll fix some model quirks).

 

1 hour ago, 3t0 said:

I tried messing with vcc_run. It seems, it is quite borked

vccrun wasn't present in the original Vavoom, this is my own creation. it always meant as a testbed for VC compiler, and i never bothered to make it "user-friendly". but sure, you can use it to run standalone VC code. actually, my new movement testing code is all Vavoom C (yay! but don't try to run it with udmf maps, it requires very specific UDMF, with segs, subsectors and nodes; your usual UDMF map doesn't have that).

 

what made you confused is that vccrun requires its own VC packages to run, and it doesn't even try to look for them anywhere except current directory. that is, you have to use "-Ppath/to/packages" CLI arg (see "packages/" directory in vccrun source dir). also, it won't allow you to load files from directories it doesn't know about (i.e. from dirs outside of cwd).

 

actually, Spelunky remake in the first post is using unmodified vccrun, it is simply renamed. so yeah, it is not only possible to run standalone VC code, but you can write a whole different game with it! ;-)

 

1 hour ago, 3t0 said:

mods are already pretty much engine tied, or rather GZDoom tied, should I say

you're both right and not right here. ;-) actually, most pre-zscript mods are working if engine implements proper DECORATE code pointers. that is, alot of such mods are working in k8vavoom now (including some very big mods), after i implemented alot of missing code pointers.

 

of course, if map depends on exact monster behavior, or doom movement quirks, it will break. but tbh, such maps are quite rare. but many weapon and monster replacement mods can be made working without implementing 100% GZDoom compatibility. they may not work exactly as in GZDoom, but they will still work, and will be playable.

 

also, if people want to write some heavy-weight TC, which does extensive changes to the gameplay, i won't object using zscript/vc for that, of course. after all, doing such things with pure decorate would be very hard, if possible at all. but when people just mindlessly replacing "actor" with "class" and such, to convert perfectly working decorate code into zscript code for no reason at all... that is what i really don't like (hate ;-). in-engine scripting is a great tool, but it should be used wisely (as any other tool out there ;-).

 

that is, i'd like to see some TCs written for k8vavoom with VC (like KoraxRPG/Scattered Evil for original Vavoom, for example), but i believe that if people just want new guns, or some new monster, it is almost always possible to implement those with pure decorate, and this is The Right Way.

 

p.s.: as of more scripting -- there is ACS. yes, it is not the best tool out there, and it has its own set of warts, but it is mostly compatible between implementations. like, Silent Steel:Remastered is using ACS extensively, for example. it can be replaced with VC code, of course, but then you won't be able to play SS:R in GZDoom, for example. this may be something good for k8vavoom, but it is bad for Doom community as a whole, i believe.

 

of course, i can't order people to "stay compatible". after all, people doing all that for free, and i can't just command them to invest even more time to support a wide set of existing sourceports. but if there is a way to achieve that with minimal pain... it is worth at least trying, i think.

Edited May 21, 2019 by ketmar

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

Edited May 21, 2019 by 3t0

[ketmar]

eh. first, don't do PVS at all: it is absolutely not needed. like, really useless. there is nothing run-time clipper cannot do better than it. especially considering the fact that PVS is not exact, it is rough approximation. even help text on that menu item hints that PVS is useless. so i guess we can skip PVS-related questions. ;-)

 

6 hours ago, 3t0 said:

how k8vavoom (or any other engine) are supposed to handle namespaces?

it is all there, in specs. different namespaces adds various properties, and sometimes changes some defaults. this is exactly what k8vavoom does: if it sees some extended namespace it knows about, it checks for additional properties from that namespace. there shouldn't be any unknown properties in known namespaces (otherwise it is violation of specs). yet k8vavoom doesn't support all properties from zdoom. some of them are more important (slopes, for example), others are decorative (different lighting parameters). still, k8vavoom simply ignores the things it doesn't know about (and dumps ignored keys to console, so both me and user can expect broken map).

 

6 hours ago, 3t0 said:

I did not expect too "big T surface extents".

basically, that means that lightmap calculation is borked. probably due to either map size, or map being too broken by itself.

 

6 hours ago, 3t0 said:

Unknown action special

yeah, there are alot of those were introduced since original Vavoom development stalled. as everything else, i am implementing missing specials "on demand".

 

6 hours ago, 3t0 said:

Do normal vertical doom doors block visibility/occlude rest of the level geometry when closed?

yes. i believe that all modern sourceports do this with 1D beam clipper. additionally, k8vavoom's clipper can clip with two-sided walls if their midtex is out of frustum (not that it really helps much, but why not).

 

6 hours ago, 3t0 said:

Do polyobj lines do that?

most of the time, yes. sometimes no. that is, if polyobject obeying original polyobj placement restrictions, than it can clip geometry. but if those restrictions aren't respected... alas. k8vavoom tries to detect such cases, but that detection is not reliable at all.

 

6 hours ago, 3t0 said:

Can one (mapper) toggle visibility/occlusion from ACS/Line specials?

i haven't the slightest idea. yet it is possible to change sector heights, and most engines considers "closed sector" as blocker. i.e. in Doom, "closed door" is a sector where ceiling height is equal to floor height. this can be used to block view.

 

6 hours ago, 3t0 said:

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.

sure, it would be a good thing. yet no engines currently have it, so i won't bother designing and implementing it too. considering number of mappers mapping for k8vavoom, it is totally doesn't worth the efforts. ;-)

 

also, i have some ideas on better clipping. i'd better invest my time into those, so existing complex maps can automagically work better without changes. but i have to change some things in renderer to make it possible. matter of time, as usual.

 

transparency is half-broken now too. this again is due to renderer overhauling. as i HAET doing gfx, i found an excuse to not work on renderer (how could we live without `traceBox()`, and shiny new movement code?!).

 

 

basically, my current policy is this: "huge maps are not officially supported. if it works for you, than it's fine, you're so lucky." from my PoV, most of the time it doesn't worth the efforts. while those huge creations may look cool and all that, there is often either no real gameplay, or gameplay is boring. and for me, doom is all about gameplay. so optimistations for such maps is somewhere at the bottom of my TODO. the same goes to various "cool features" and "advanced tricks".

Edited May 21, 2019 by ketmar

[kb1]

On 5/15/2019 at 5:33 PM, therektafire said:

Oh also alt tabbing out of k8vavoom always 100% causes it to crash for me when in fullscreen

This can cause a window resize, which might change the buffer size, hence crash. Just an idea.

[ketmar]

more likely lost OpenGL context, which didn't survived resolution change.

Edited May 22, 2019 by ketmar

[ketmar]

new movement code PoC is slowly progressing. now i am working on slopes support. tbh, i am somewhat concerned, as it may take quite a long time (i know what to do, i see how to do it, but the actual implementation, with all the bugs ironed and such is something that may take a long time). and for that amount of work it worth only one line in changelog. ;-)

 

i think that i will work on it for some more time, then it will be integrated into the engine, but it will be hidden until i polish it enough to be playable. so next build will prolly come in the next month, and won't have many user-visible changes. but don't worry -- render improvements, level designer tools, and bot AI aren't forgotten. it is just sometimes you have to work on the code that is invisible to players, to lay out a foundation you can build more advanced things upon. don't switch your TVs, we will return soon! ;-)

 

p.s.: in k8vavoom, slopes are quite shitty and buggy. new code is still glitchy, but it already feels way smoother, and in the end it will have much less bugs. like, now you can completely stuck on some sloped surfaces (yellow key in kdizd z1m1, for example -- you can walk on it, and stuck there). this is something that should be fixed, of course, but it is almost impossible to fix with the current movement code.

[kb1]

22 hours ago, ketmar said:

more likely lost OpenGL context, which didn't survived resolution change.

That too! You're probably right. Very easy to trap via window handler, and reacquire context. But you're not running Windows, right?

[Gunrock]

On 5/20/2019 at 8:42 PM, 3t0 said:

That looks really nice. Are you using "official" vavoom md2 model pack?

 

Not really. I never really cared for Vavoom's md2 model packs

[-TDRR-]

On 5/18/2019 at 7:52 PM, ketmar said:

implementing portals is almost a no-brainer. no, i won't do that (i still think that this is a misfeature)

Hold up, why the heck do you think something that allows you to do room-over-room x10 times cleaner, easier and faster than 3D floors is a "misfeature"?

 

Have you at least tried to make a furnished three-story building using only 3D floors? If you have, you probably know it sucks ass because there comes a point where you can't add anything at all unless you were to simplify a lot the whole building.

 

I understand than from the programming end of it, it probably is pretty dumb to have a crap ton of checks all related just to portals, but IMO it's well worth the gains.

[ketmar]

46 minutes ago, -TDRR- said:

why the heck do you think something that allows you to do room-over-room x10 times cleaner, easier and faster than 3D floors is a "misfeature"?

let's start with the fact that RoR/3D floors is a massive misfeature too. the engine simply wasn't designed for that. 3D floor hack is so ugly, that i'd prefer to never know about it at all. but it is already there. alas. yet tbh, if it wouldn't already in vavoom code, i'd never implement it, for the same reasons: it is a massive misfeature. but ok: i don't like to throw away features that are already there, and working, and used by people. but introducing new misfeatures? nope. from programmers PoV, it is a massive time sink, with very little gain. like, i am not expecting people to magically start mapping for k8vavoom if i will implement that feature, especially considering that gzdoom already have it, and it is widely known. that is, the only realistic way to have portals is to implement them exactly as gzdoom does that. not something i really want to do. i already had to introduce massive clusterfuck aka "gzdoom-compatible 3d floors implementation", and it still hurts.

[-TDRR-]

41 minutes ago, ketmar said:

let's start with the fact that RoR/3D floors is a massive misfeature too. the engine simply wasn't designed for that. 3D floor hack is so ugly, that i'd prefer to never know about it at all. but it is already there. alas. yet tbh, if it wouldn't already in vavoom code, i'd never implement it, for the same reasons: it is a massive misfeature. but ok: i don't like to throw away features that are already there, and working, and used by people. but introducing new misfeatures? nope. from programmers PoV, it is a massive time sink, with very little gain. like, i am not expecting people to magically start mapping for k8vavoom if i will implement that feature, especially considering that gzdoom already have it, and it is widely known. that is, the only realistic way to have portals is to implement them exactly as gzdoom does that. not something i really want to do. i already had to introduce massive clusterfuck aka "gzdoom-compatible 3d floors implementation", and it still hurts.

Yeah, maybe had to see from a popularity perspective. k8Vavoom isn't popular at all for mapping, so adding portals is unlikely to have much benefit without anyone taking advantage of it.

 

In all honesty though, if GZDoom didn't have portals or 3D floors, i really can't imagine it being as popular as it is today for mapping. Having more freedom on the z axis is really important for many of the awesome things we have gotten up until now, because you know, instant raising floors/ceilings and teleporting can only get you so far. It is not a misfeature at the slightest for mappers, but i can see where you are coming from with all you said.

[ketmar]

14 minutes ago, -TDRR- said:

It is not a misfeature at the slightest for mappers

i see how it can be useful for mappers. but i am talking from programmer PoV (because that is what i know best ;-), and from that PoV, it is a massive misfeature: it doesn't fit into engine design even a slightest. besides, i have a huge roadmap ahead (like, several years of full-time work for a game studio-scale; abmitious, i know ;-), so some things just have to be cut. it is not like i'm removing something, but i have alot of other things to improve. i need to move rendering to separate thread. rewrite VM, so it will be faster. improve GPU utilisation, so big maps will work better. and so on. adding portals on top of that will only make things worser.

 

if only i could design everything from scratch... but alas.

[kb1]

3D floors are a massive clusterfuck in the Doom engine. Portals can actually be a better fit than 3D floors. 3D floors completely defy the BSP approach to rendering, and essentially must be drawn like Z-buffered sprites. At least, with portals, you get to use the BSP to eliminate overdraw and handle hidden surface removal, for the software renderer, at least.

 

An enhanced 3-dimension-aware BSP algorithm might be able to be utilized to solve some of the 3D floors issues. But for both 3D floors and portals, rendering is only half the problem: Objects must be able to clip with both structures, and as soon as you allow more than ceiling, middle, and floor spaces, everything becomes an entire dimension more complex (pun intended).  I can fully understand not wanting to implement either approach. But, yes, they're fun, if they can be made not to glitch.

[ketmar]

yeah. but if i'd be able to roll out my new movement code (i am still not sure; i made alot of progress, but in the end it may be scrapped anyway, if it will break too many things), actually doing portals can be quite easy: it is only a matter of applying translation matrix when box tracer hits a portal line. then the box is translated to "portal space", and i can simply continue tracing. sure, there are some complications like "object is partially inside a portal", recursive portals, and such. but comparing to vanilla movement code, it is really a no-brainer. but only because vanilla code is fubared. almost anything will be a no-brainer if one can throw vanilla code away. ;-)

[kb1]

Yeah, portals should be a lot cleaner. Unlike 3D floors, portals follow Doom's rendering "philosophy", so to speak. And, if done right, you get cameras, mirrors, and split-screen for low cost (if you're not already there).

[ketmar]

actually, vavoom has portals, and they're used exactly for such things -- mirrors, stacked sectors, etc. that is, internally it implemented with portal-like code. but no "interportaly physics". and i turned that code off anyway, because it doesn't play good with current renderer arches, and should be rewritten (eventually). eh, i wonder if there's anything that should not be rewritten, lol. "add one feature, rewrite half of the engine".

 

p.s.: the hardest thing in fixing this portal code is to not accidentally start writing "full" portal support. it is hard to control feature creep. ;-)

[ketmar]

1 hour ago, kb1 said:

Unlike 3D floors, portals follow Doom's rendering "philosophy", so to speak.

yeah. but as k8vavoom has only OpenGL rendering, it is not that big thing. while rendering 3d floors is completely "off" for software, collision fits quite nice. as i wrote in some of previous posts, at least in k8vavoom 3d floors are just generalisation of "opening list". it doesn't really matter if a sector has one empty space, or several empty spaces -- it is still the same data structure.

 

actually, the real PITA is slopes: they're breaking almost everything. now, you cannot simply build openings for sector once, because the real heights depends of x/y position. and you cannot just perform "ray-vs-plane" checks, because you have to write additional logic to discard "out-of-sector" hits. and so on. tbh, if i'd have a choice "would you agree to kill slopes, but add portals", i'd say "YES!!! anytime!" for almost whole this week i am trying to force my new movement code obey slopes. this alone took more time than writing other parts of it.

[therektafire]

Well tbh I think that portals would be more important to have than slopes since portals are a much more valuable mapping feature in my opinion especially if you are trying to make non euclidean type maps or psuedo 3d enviornments.Slopes would be nice to have but i feel like they don't have nearly as much utility and are just more of an aesthetic nicety unless we're talking about UDMF vertex slopes of course, those can be used to make stuff like realistic looking terrain (or well as realistic as you can get in a doom derived engine)