k8vavoom: no good thing ever dies!

[ketmar]

6 hours ago, ENEMY!!! said:

and a couple of screenshots, one with Nearest texture filtering enabled, one with Trilinear.  Anything other than "Nearest" or "Nearest Mipmap" produces this texture glitch

now it looks like this:

Spoiler

not ideal, but much better, i hope. ;-) the whole filtering thing doesn't play well with Vavoom multipass lighting implementation... and i broke it even more. thank you, i "unbroke" it back now. ;-)

[ENEMY!!!]

I'll be able to separate out the imp at some point, probably in the next week or so, like I did with the flak cannon earlier.  In the meantime I've managed to get a moving train working!  There is also surprisingly little lag despite having created a somewhat more complex structure than was used in any of the test maps, and all linked polyobjects move perfectly along with the master/primary one.

 

There are some issues when the train rotates - if the player is stood against the walls of the train it can block the train from rotating, and when I get the train to play a sound, the sound seems to stay put rather than moving with the train (there are hacky ways of working around that for now, but it's worth mentioning).  I've still got a bit of refinement to do, but I should be able to post what I've come up with shortly, again probably within the next week or so.

[forgettable pyromaniac]

Yo.

Decided I'd mess with this for a sec cuz I needed a break from wad creation, and although it runs like ass on my 10 year old machine, it does look pretty cool ngl.

 

I only found two things that were funky:

1. Slapping exit switches doesn't make the switch "KACHUNK" sound, which felt weird but isn't necessarily important. It could totally make the noises and I just got the short end of the stick and it doesn't for me but ech.

2. Crashes. Granted, I was curious to see how bad it ran while using OBS (not the port, my cruddy lappy), but even when not using OBS I've had it crash once or twice, probably from too much ram usage. Also using Lightmaps mode while running OBS made it refuse to run and crash when loading but whatevs.

- but despite, it's still a really neat port I'll keep around on my drives for somethin when I'm in the mood to kill my integrated intel graphics.

[ketmar]

5 hours ago, ENEMY!!! said:

I'll be able to separate out the imp at some point, probably in the next week or so

great, thank you!

 

5 hours ago, ENEMY!!! said:

In the meantime I've managed to get a moving train working!  There is also surprisingly little lag despite having created a somewhat more complex structure than was used in any of the test maps, and all linked polyobjects move perfectly along with the master/primary one.

that's great to hear! ;-)

 

5 hours ago, ENEMY!!! said:

There are some issues when the train rotates - if the player is stood against the walls of the train it can block the train from rotating

yeah, unstuck code is a gross hack. objects in Doom always using axis-oriented bounding boxes, so on rotation object that was free may stuck in a wall. unstucking is far from good and reliable, tho. it should be rewritten, and for this, i need more test maps! ;-)

 

5 hours ago, ENEMY!!! said:

and when I get the train to play a sound, the sound seems to stay put rather than moving with the train

it's very possible. afair, sound is spawned (it has 3d coords), but doesn't linked to source pobj. i simply didn't thought about that. so, test map again, i'm really waiting for it! ;-)

 

that's exactly what i meant: you started doing the real thing, and found various bugs. it's great, we'll fix them. thank you!

[ketmar]

1 hour ago, forgettablepyromaniac said:

Slapping exit switches doesn't make the switch "KACHUNK" sound, which felt weird but isn't necessarily important.

they prolly do, but you can't hear it, because the game starts transition sequence, therefore destroys the map, map objects, and all their sounds almost immediately. of course, for the player it is the same as "no sound at all". i'm so used to that that i never payed any attention (i'm playing exclusively with k8vavoom for years, so it becomes a "normal thing" for me ;-). i'll see if i can keep some sounds playing for a little longer, thank you!

 

1 hour ago, forgettablepyromaniac said:

integrated intel graphics

this. sorry, intel drivers are so broken that it is impossible to workaround. k8vavoom renderer doing many things in a way that "normal games" aren't, and tend to hit driver bugs. especially in intel drivers — it ranges from "driver reports as supported features it cannot support" to lost geometry and crashes. of course, sometimes it's me doing something wrong, but in majority of cases (98 of 100, i'd say ;-) it's intel driver's fault.

 

i'm sorry again, there's not much i can do with that.

 

i should prolly stop trying to keep OpenGL2.1 compatibility, and bump minimum required OpenGL to at least 3.3. the engine requires GLSL120 in any case, and most GPUs that can support this are able to support OpenGL3.3/GLSL330 at mininum. and this will allow me to optimise some shaders (especially shadowmap shaders).

 

of course, i'd like to support several shader versions for different GPUs, but alas, i don't have enough resources. supporting two render pathes (lightmaps, and shadowmaps/shadowvolumes) already quite hard. and by bumping minimum OpenGL version i'll be able to mostly unify their code.

 

anwyay, i'm glad you liked k8vavoom, thank you for trying it, and providing feedback!

[ketmar]

@forgettablepyromaniac added hack to keep last used switch sound playing on map exit. this way most of the time you will hear exit switch sound. thank you! ;-)

[forgettable pyromaniac]

1 hour ago, ketmar said:

@forgettablepyromaniac added hack to keep last used switch sound playing on map exit. this way most of the time you will hear exit switch sound. thank you! ;-)

glad I could do something lmao

also yeah don't worry about the graphics thing i was just fuckin around with the port. And like I said, taking away my shitty lappy, it LOOKS pretty damn clean. Nothin I would use continuously but the menus + how it looks is pretty cool, so respects on that. Keep it up my dude.

[ketmar]

@forgettablepyromaniac thank you! i hope to be able to work on k8vavoom for a long time, i have HUGE roadmap! ;-) k8vavoom already can do things no other sourceport can, and there will be even more, both for players and for mappers. just wait 10 or 20 years (we are not in a hurry, aren't we? ;-).

[ketmar]

lightmapped mode had overbright support from the very beginning, but shadowmaps/shadow volumes hadn't. so i finally fixed this.

 

shadowmaps, flashlight, no overbright:

Spoiler

 

shadowmaps, flashlight, overbright:

Spoiler

 

if you wonder what overbright is, it is simple: internally, light level is not capped on 255, but can go beyond that value. this way, adding dynamic lights to walls with light level 255 will still brighten them (this is more-or-less what Quake is doing too, and most other engines with dynamic light support).

 

this requires floating point texture support, and hopely will fallback to "no overbright" if the engine cannot create fp textures. also, overbright mode for non-lightmapped rendering is slightly slower than non-overbright (fp texture, and one postprocessing pass). of course, you can turn overbright on/off on the fly from the video options menu.

 

p.s.: you do know that k8vavoom has built-in flashlight, do you? ;-)

Edited August 2, 2021 by ketmar

[ENEMY!!!]

Here's a train test map (I thought it would take me longer, but I dedicated a fair amount of time to it this evening).

traintest.zip

I have the train moving along a railway track, taking a bend to the right, passing a bit of scenery along the way, and then stopping.  The train contains sliding doors which open when the train stops.

 

I also uploaded a quick gameplay video for the benefit of those who want to see it in action but don't want to bother downloading the WAD.  Despite the clipping and sound issues, I'm somewhat impressed - this has worked far better than I'd expected it to.

 

Edited August 3, 2021 by ENEMY!!!

[ketmar]

@ENEMY!!! yay! that's freakin' great!

 

sound issues will be solved soon: i'll link sound to the origin pobj and will move it, it's doable. the poor old sound code just didn't expected that somebody will move pobj across the whole map. ;-)

 

and i'll try to reproduce stucking, and fix it. i think this is due to too much details, or some trivial bug (or i really have to look into something like Box2D, and steal properly working unstuck code ;-).

 

also, i will implement line translucency to control alpha of top and bottom textures (yay, everything is inside-out! ;-). it doesn't work right yet (you can set translucency, but the rederer will draw midtextures twice), but i'll fix it soon. i mean, you will be able to create a proper semi-transparent windows. ;-)

 

p.s.: i really should invent something to avoid those packs of link and spawn objects, they are prolly PITA to manage.

 

p.p.s.: you can join several contours into one sector, like i did with pillars in the cabin example. this is fully legal and supported, and sometimes may even work slighty faster than alot of sectors.

Edited August 3, 2021 by ketmar
typos

[ketmar]

@ENEMY!!! sound is fixed, it will move with its respective polyobject now. we prolly need some flag to tie it to the player origin while the player is inside the pobj, so train sounds works in a more natural way. but at least the sound is moving with the train now. ;-)

 

p.s.: you can add

 

$pitchshiftrange 0

 

to the beginning of your SNDINFO, to avoid pitch shifts on train and door sounds.

Edited August 3, 2021 by ketmar

[ketmar]

good news: i found at least three bugs in complex 3d pobj processing code! ;-)

 

first bug: invalid building of "affected by rotation" mobj list — this is why unstuck code didn't do anything: it just couldn't notice that it has to unstuck something.

 

two other bugs are in unstuck code itself: if an mobj is not standing on the floor while the pobj is rotating, that mobj won't be unstuck, and will block the rotation (and hence the movement). it's a more complex thing, that consists of at least two bugs. i think i know how to fix them, and make complex 3d pobj movement better. (fingers crossed ;-)

 

so, i'm working on the fixes now. hope to fix it for the next public build.

 

thank you alot, @ENEMY!!!, i couldn't found those things without your map!

Edited August 3, 2021 by ketmar

[ENEMY!!!]

I particularly like the sound of the translucent upper textures - I didn't flag that up as an issue, but it was definitely an issue for me when I was assembling the parts of the train.  See-through grates and fences "get the job done", but on the kind of train I've been going for, translucent windows would work better.

 

I expect that there might well always be some clipping issues, as I remember that even Half-Life had occasional problems (I have vague memories of dying because I got clipped to the side of one of the user-operated trains), but it sounds promising that they can probably be reduced significantly from where they're at now.

 

Yes I did wonder about merging sectors into one after seeing the pillars, I think for my first attempt I just went with the way that was the easiest/most obvious but not necessarily the best.  It could work well with some of the train's walls in particular.

 

I'm pleased to have got the opportunity to be actively involved with this - it's partly for my own personal benefit too, for I had earlier forays into Half-Life and Doom 3 mapping and, since returning to Doom 1/2, I have often especially missed 3D "movers" from those later games, so I'm keen to contribute towards rectifying that.

Edited August 3, 2021 by ENEMY!!!

[ketmar]

6 hours ago, ENEMY!!! said:

I particularly like the sound of the translucent upper textures

it's somewhat problematic due to sorting, tho. currently, the engine expects all translucent walls to be in strict front-to-back order (BSP guarantees that). this is used to "interleave" sprites, and for other rendering tasks. yet polyobjects currently are not split by subsector boundaries for rendering (read: they will violate ordering). so i'm currently thinking about good method to solve this.

 

(the problem is that translucent surfaces should be rendered in strict back-to-front order, otherwise translucency will look wrong.)

 

6 hours ago, ENEMY!!! said:

I expect that there might well always be some clipping issues, as I remember that even Half-Life had occasional problems (I have vague memories of dying because I got clipped to the side of one of the user-operated trains), but it sounds promising that they can probably be reduced significantly from where they're at now.

yeah, due to Doom quirky physics it's not possible to implement everything "right". but i already see what i did wrong in my first implementation, and i think that i can redesign it to be both somewhat simplier, and more… ahem… solid. ;-) i'm expecting several iterations of this code, so be ready to see funny bugs for some more releases. ;-)

 

your "sector soup" map is of huge help here, i would never craft something like this for testing. and i fully expect that people will… abuse ;-) 3d pobjs well beyond the limits i thought as possible. that's why i added linked pobjs in the first place: i was absolutely sure that people will immediately try to build something complex, and move it with fragile ACS hacks.

 

i just thought that i can add "link pobj range" thing, that will automatically link all pobjs between two tags. we also need some way to set anchor point relative to the link root/previous linked object, i think, and spawner that will then spawn the whole link chain. this way mappers will be able to build everything, and spawn it with one spawner. i think it will be much easier to manage.

 

it's fun that i didn't thought about that earlier, but somehow i had to see the mess you had to work with to make me think about ways to simplify it. ;-)

Edited August 4, 2021 by ketmar

[ketmar]

i implemented some accessibility options, as a result of discussion in this thread. but we need help from colorblind people there, to find something that fits them better. so if you're reading this topic, but not that, and have some expirience in this field, please, come there to help us. let's make Doom more enjoyable for as much people as possible! ;-)

 

p.s.: screenshot of accessibility menu (there's more than eye can see there, some options are not boolean! ;-).

Spoiler

 

Edited August 4, 2021 by ketmar

[Gibbon]

17 minutes ago, ketmar said:

i implemented some accessibility options, as a result of discussion in this thread. but we need help from colorblind people there, to find something that fits them better. so if you're reading this topic, but not that, and have some expirience in this field, please, come there to help us. let's make Doom more enjoyable for as much people as possible! ;-)

 

p.s.: screenshot of accessibility menu (there's more than eye can see there, some options are not boolean! ;-).

  Reveal hidden contents

 

You've done some incredible stuff!

[ketmar]

3 minutes ago, Gibbon said:

You've done some incredible stuff!

thank you! to be honest, most of those things were already implemented in some form in the engine, i only had to create a menu, and to add some more cvars and conditions here and there. so most credits go to Gez and other people in that topic, for sharing their ideas.

Edited August 4, 2021 by ketmar

[ketmar]

ah, and while i'm at it, LightAmp powerup now has the option to boost map lighting and make things fullbright (not making the whole map uniformly fullbright). actually, each powerup with colormap effect has such option, among a wide set of colormaps to choose from.

[ketmar]

i rewrote 3d pobj coldet code, let's hope this iteration will be better. at least i couldn't stop the train by touching a wall anymore, and (mostly ;-) didn't fell out of the cabin by running into a window. ;-)

 

p.s.: also, i just added some hacks to proper jumping from moving 3d pobjs. i.e. jumping inside a train cabin will try to add cabin velocity to the player velocity, as it happens in the real world. most of the time this works, and jumps at a moving 3d pobj are more "natural" (i.e. pobj will not move away ;-).

 

it's not fully reliable, but still better than nothing, i guess. ;-)

Edited August 7, 2021 by ketmar

[Gunrock]

Hey Ketmar. Just wanted to bring up a possible bug issue when it comes to the handling of underwater rendering.

Here is how GZDoom renders underwater effect.

Here is how K8Vavoom handles underwater effects using the same parameters(Sector set 3D floor, translucency at 192, and blue color lighting for underwater).

Notice how water is still visible on the floor surface. Dummy control sector's ground level is the same as real sector's floor level which is -64 units below.

Also, color lighting rendering is not correct. Instead it displays a white hue like filter.

 

 

 

Water.zip

[ketmar]

10 hours ago, Gunrock said:

Notice how water is still visible on the floor surface.

yes, this is because both base sector floor and 3d floor floor ;-) are on the same height. there is no way to specify what 3d floor flats should be rendered, and this kind of 3d floor is translucent, so the engine renders both flats. this is how CSG works. for now you can simply lower the floor of control sector: technically, 3d floor with out-of-bounds values is wrong, but most engines support this, afaik.

 

tl;dr: thank you, not technically a bug, but how CSG works. there is no specification for "underwater style" 3d floor rendering, so techincally my approach is valid too. ;-) (i prolly fix it later, but for now simply use a workaround. sorry.)

 

 

10 hours ago, Gunrock said:

Also, color lighting rendering is not correct. Instead it displays a white hue like filter.

yes, underwater currently always works like this. internally, 3d and pre-3d underwaters handled in a huge chunk of code inherited from MBF, and written with the usual Lee Killough style. and most of that code seems to be useless with hardware rendering, but… but i simply afraid of touching it. one day i will reverse and rewrite it, but for now… sorry.

 

tl;dr: thank you. known bug, not sure how to solve it yet. i'm still thinking.

 

and thank you for the test map! i LOVE bugreports with test maps! ;-)

Edited August 8, 2021 by ketmar

[Graf Zahl]

1 hour ago, ketmar said:

not technically a bug, but how CSG works. there is no specification for "underwater style" 3d floor rendering, so techincally my approach is valid too. ;-

 

The rules here come directly from how Doom Legacy implemented its 3D floors:

- inside top and bottom flats are only being rendered if there's a gap to the real floor or ceiling or a neighboring 3D floor - if both planes match up precisely the inner one will not be rendered.

You may be right that it never was officially defined, but this is really the only way it can work as intended.

 

 

[ketmar]

1 hour ago, Graf Zahl said:

You may be right that it never was officially defined, but this is really the only way it can work as intended.

yet it is not in the wiki, and i used that as an excuse. ;-)

 

and there are more things that never mentioned in the wiki for swimmable translucent 3d floors, like the fact that flats of those 3d floors are rendered fullbright. so it is marked as "GZDoom render bug workaround" in k8vavoom renderer now. ;-)

[ketmar]

@Gunrock i fixed extra water flat, but the lighting is much more complicated. k8vavoom doesn't split walls with non-solid 3d floor flats, so it is impossible to render two different light levels on such wall.

 

that is, the wall internally may consist of several "surfaces", and i can recolor such surfaces as i want to. but surface creator cannot do necessary splits now. i.e. low level rendering code can do it, but high-level one can't. so this is the best you can have now:

Spoiler

 

as you can see, it's not right (side walls have invalid lighting), and quite fragile too (the light is applied only when the camera is under the water, and heuristics are not fully right). it is applied only when the camera is underwater, tho, so it won't affect "normal" rendering.

Edited August 8, 2021 by ketmar

[ketmar]

ok, with new CSG fixes we have this now: ;-)

Spoiler

 

[Gunrock]

Thanks as always ketmar. I figured test maps are more helpful than just posting pics.

[ketmar]

1 hour ago, Gunrock said:

Thanks as always ketmar.

no, thank you! ;-) i knew about this for a long time, but moved it further and further away. then you gave me the map than can be easily used for tests — and it is fixed (i hope). so you did most of the work (because convincing me to fix something is the hardest part! ;-).

Edited August 8, 2021 by ketmar

[ketmar]

@Graf Zahl oh, and i almost forgot to say BIG THANK YOU to you and GZDoom team. you solved (or workarounded ;-) alot of problems in GZDoom, and while it's usually not possible to simply copy-paste your code (sighs), it's way easier to look what you did and start from there than starting from the scratch.

 

also, i understand that the documentation is done by volunteers, and nobody's obliged to write it in the way i want it to see. it's much better than Vavoom and k8vavoom documentation anyway! ;-) but my twisted sense of humor tells me that it is fun to pretend that there is some animosity between our sourceports. old and stupid joke, i know, but hey, Nostalgia Critic and AVGN could pull it off, so why can't i? ;-)

[SilverMiner]

Reporting a bug.

Boom scrollers seem to be slowed down in k8.

https://s6.gifyu.com/images/MAPDoorbug.gif
K8 July 18 build behavior^

https://s6.gifyu.com/images/MAPDoorbugPrboom.gif

What's expected^

Here's the map (mapslot 12) + resources needed to run

https://www.dropbox.com/s/pspk36dfnjj7ajy/painlord.wad?dl=1

https://www.dropbox.com/s/2vqz11z2wjyw225/prcp2texv1.wad?dl=1

EDIT:

replaced gifs with links

Edited August 13, 2021 by SilverMiner