k8vavoom: no good thing ever dies!

your maps are looking great, so post more of those, please! people love to see cool screenshots, and i can use those shots to make people think that k8vavoom is really that stylish! ;-)

p.s.: i still hope to implement proper shadow maps one day, so we could have those transparent textures to cast shadows too. it would look great, i guess.

Yeah, that would be neat.

Even though not too much, the shadows and lighting in the screenshot look awesome.

Silent Steel: Remastered Edition v1.3

-fixed and updated a few scripting lines.

-Updated and changed some architectural and lighting details here and there.

-Added a few more decorate effects.

-Updated and added some sounds.

-Reworked some files in the pk3 file structure.

Unfortunately, however, With the latest K8Vavoom build, it will randomly crash Map5 "Hold Out" complaining about "script 12 took too long to execute" 

Also, I dont know if this also is a bug, but right after Map3 "Storage Facility", the game will cut to a ending text screen even though I stated in the mapinfo file not to do so.

Thanks as always Ketmar for all your hard work and dedication;)

@Gunrock yay! i'll try to find out what is wrong there. thank you for updates, and for your bugreports!

p.s.: it's good that i decided to delay a new build a little. ;-)

@Gunrock ok, the bug with script 12 is in the condition:

while (monstercount[0] + monstercount[1] + monstercount[2] + monstercount[3] + monstercount[4]
       <= monstertotal[0] + monstertotal[1] + monstertotal[2] + monstertotal[3] + monstertotal[4])

here, it should be "<", not "<=". because with "<=" we still entering the loop when all monster counts are saturated, and that second "while" will never find something that is not spawned to the limit. so k8vavoom is completely right here. ;-)

(GZDoom aborts this script much sooner, and it's not fatal to abort the script in GZDoom by default, that's why you prolly never seen anything wrong there.)

and with map03: by default, all Doom2 maps are belong to clusters 5 and higher. GZDoom resets cluster number on the replacement map, but k8vavoom doesn't do that. so when the player moves from map03 to map04, in k8vavoom it also moves from cluster 5 to cluster 1. and cluster 5 has "infested starport" exit text, so k8vavoom shows it. the easiest way to fix this both for k8vavoom and for GZDoom is to add dummy cluster 5 defition with empty exittext:

clusterdef 5
exittext ""

Thanks!!! I updated the Mapinfo file as well as the script. If anyone finds any glitches, bugs, or suggestions that I missed, please let me know so I can finally upload Silent to the idgames.

Hey Ketmar. Can you take a look at my updated Mapinfo file. Is this correct?

Mapinfo.zip

6 hours ago, Gunrock said:

If anyone finds any glitches, bugs, or suggestions that I missed, please let me know so I can finally upload Silent to the idgames.

just give us (me, specifically) several days to play it again first. ;-)

3 hours ago, Gunrock said:

Can you take a look at my updated Mapinfo file. Is this correct?

yeah, it looks ok. it was enough to simply append empty clusterdef, tho (i specifically checked that it works). but offseting all cluster numbers works too.  i mean, you could do less work for the same, and avoid converting mapdef to "new" format. don't get me wrong, please, this conversion is a good thing, it is my laziness talking. ;-)

p.s.: and upload fixed "map05.wad", please, so we can avoid manually fixing bytecode. ;-)

10 hours ago, ketmar said:

p.s.: and upload fixed "map05.wad", please, so we can avoid manually fixing bytecode. ;-) 

I will!

and the new build, as i promised. it might be slightly buggy and unstable due to some major incoming VavoomC changes, but shouldn't really break anything. at least it "works for me", as usual. ;-)

brief changelog

@-TDRR- nothing really interesting this time, but still... ;-)

Just a small bug: if I use the -nomonsters parameter, monsters will still spawn with ACS's SpawnSpot and friends.  Not a major thing, just slightly annoying when testing maps or going through to take screenshots.

4 hours ago, Remilia Scarlet said:

Just a small bug: if I use the -nomonsters parameter, monsters will still spawn with ACS's SpawnSpot and friends.  Not a major thing, just slightly annoying when testing maps or going through to take screenshots.

Try it like this: k8vavoom.exe -doom2 +NoMonsters 1 +map map01

Also note that the ordering of the commands is pretty important, I found this out the hard way heh.

I have not tested while using ACS scripts though.

It would be nice if k8vavoom used the more common simple method eg: -nomonsters without the included 0-1 switch in the parameter, which is seen in pretty much every engine including Doom.exe its self. 

Though I have not asked for ketmar to change this to the current standard, as he usually has more important things on his plate.

If I could make a request besides this, it would be to have mouse UI enabled by default, this way the mouse buttons could be set without needing to enable the UI mouse control first.

5 hours ago, Remilia Scarlet said:

Just a small bug: if I use the -nomonsters parameter, monsters will still spawn with ACS's SpawnSpot and friends.  Not a major thing, just slightly annoying when testing maps or going through to take screenshots.

Same with ZDoom-based ports. I remember for ZDCMP2 we went through all the scripts to make sure they were nomonster-compatible by putting in a lot of GetCVAR("sv_nomonsters") checks everywhere (scripts that spawn monsters don't spawn monsters; scripts that wait for monsters to be killed just run instantly, this kind of things).

56 minutes ago, Gez said:

Same with ZDoom-based ports.

Hmm, I seem to remember this not being the case in GZDoom.  Though I almost always use the -nomonsters command line, not the cvar.  That might be the difference.

Or I'm mistaking it for Quake, and misremembering GZDoom, where I also have O bound to kill all monsters.

18 hours ago, Remilia Scarlet said:

Just a small bug: if I use the -nomonsters parameter, monsters will still spawn with ACS's SpawnSpot and friends.

i always thought that this is how it should work. but i can change it, no big deal. then the function will simply return `false`, even forced spawn one. i haven't done that because it may break some scripts, and generally, "-nomosters" should prevent spawning map things, but don't touch others. and i somehow don't feel like putting another config option for this is good -- we already have too many options, i think. ;-)

dunno, i can change it, and we'll see. i have to think about it. as @Gez wrote, you may still have to fix the scripts, because some things may not spawn even if you forced that. it may break boss sequences and such. in the end of the day it may do more harm than good. also, in k8vavoom cvar is named simply "NoMonsters".

for now, i added the check and pushed it to the repo. we'll see it if will stay, tho.

14 hours ago, Mr.Rocket said:

It would be nice if k8vavoom used the more common simple method eg: -nomonsters without the included 0-1 switch in the parameter

but that's exactly how it should work. the difference is that setting cvar (+nomonsters) is "local change" (i.e. you can play single-player game, and then set "nomonsters" and create a server), but "-nomonsters" in command line affects everything right from the start, including sp games.

15 hours ago, Mr.Rocket said:

If I could make a request besides this, it would be to have mouse UI enabled by default, this way the mouse buttons could be set without needing to enable the UI mouse control first.

it should work regardless of that option (and it worked some time ago). this is definitely the bug that should be fixed, thank you!

5 hours ago, ketmar said:

but that's exactly how it should work. the difference is that setting cvar (+nomonsters) is "local change" (i.e. you can play single-player game, and then set "nomonsters" and create a server), but "-nomonsters" in command line affects everything right from the start, including sp games.

Ah this must have been fixed, I was thinking this wasn't working in a previous version but apparently it is!

/me goes an tests again..

~ yeah it's working.. -deathmatch 1 or 2, or +Deathmatch 1 or 2 doesn't do anything for in-game host however.

Works fine for k8vavoom-dedicated though.

5 hours ago, ketmar said:

it should work regardless of that option (and it worked some time ago). this is definitely the bug that should be fixed, thank you!

Oh ok, nice! np. 

shadowmapping experiments.

don't expect it to get into the engine, tho. at least not soon. there are still alot of problems, including messed up cubemap -- this one works only because the light is at (0,0) (and the orientation is still not right). and something that is much worse: moire and peterpanning. while i may try to combat moire with dynamic comparison bias, peterpanning is much, much harder (if possible at all) to get rid of.

peterpanning is that light bleed you can see behind the vines. the problem is that our geometry is paper-thin, and shadow maps really hates such geometry. i guess that it is possible to do something with it, but i don't have any ideas yet.

anyway, even if i won't be able to make this thing work right, it was worth trying. i'm not really a gfx guy, and i'm still learning. so failed attempt is fine too -- there is no learning without failing. ;-)

Either way, it's pretty freaking badass..

still not working right, of course, but i simply cannot resist the temptaion: lo and behold, The Grate Floor!

that's what i hoped to see all that time, yeah. ;-) don't mind those visible shadow edges: first, i like it that way. second, i will try to implement PCF of something when i got everything working.

p.s.: yeah, abysmal FPS due to alot of huge lights, and alot of transparent textures. most of the time shadowmaps should work much faster than this, and faster than shadow volumes. i also may implement some kind of shadowmap caching later, and there are tons of possible optimisations. but it is too early to think about that.

A banging 23fps,my kind of experience! Feels like my old potato already.

I hope this ends up somewhere, I'm really digging these shadows 👍.

48 minutes ago, seed said:

A banging 23fps,my kind of experience! Feels like my old potato already.

ah, this particular place is very-very "light-heavy". it is 9-12 FPS if you'll look at the whole room. that's why i'm using it to test things. actually, 23 FPS is really big here. ;-) don't worry, most of the time it should be something inbetween of lightmaps and stenciled shadows (at least i think so ;-).

52 minutes ago, seed said:

I hope this ends up somewhere, I'm really digging these shadows

thank you! ;-) yeah, i like them too, they aren't perfect, of course, but considering that Doom geometry was never created for such kind of things... and new maps can be tuned to produce better lighting.

the most important thing is that the algorithm is working. sooner or later i will fix all major bugs, and players will have three different lighting systems to choose from. also, it is possible to combine stenciled shadows and shadowmaps (currently, shadowmaps are hacked directly into stenciled shadow renderer, and activated by a simple cvar). so i may add a flag to light sources, which will tell what type of shadowing it should use (none, stenciled, shadowmaps). this way map authors will be free to tune their maps.

4 hours ago, ketmar said:

most of the time shadowmaps should work much faster than this, and faster than shadow volumes.

What's funny is that I often see the opposite, where stencil shadows are fastest XD  Might just be my new map or GPU.  I built the code from git and tried out the new shadowmaps.  Even in their unfinished state I'm impressed ^_^  They'll be perfect for what I have in mind.

Anyway, how do you get the tops of 3d floors to not be fullbright in your pictures?  The ones with the point light below, that is.  I noticed some of mine started showing up fullbright after a recent build.  This was not the case just the other day when I posted a shot of the same room

Also, random thing I noticed: I can't bind mouse buttons in the control menu unless I have the mouse enabled in the menu.  Normally I disable it because I never use it in the menu.

i finally fixed the bug that prevented shadows rendering from more than one light source. and i can't resist giving you yet another screenshot!

there is no model lighting or shadows from models yet, but even with models i expect shadowmaps to be 1.5-2 times faster than shadow volumes on light-heavy (i.e. with alot of huge lights) areas. of course, things like PCF and other shadowmap filtering mechanics i may implement will slow it down, but i'll give you the choice between speed and quality, as usual. ;-)

15 minutes ago, Remilia Scarlet said:

What's funny is that I often see the opposite, where stencil shadows are fastest XD

it highly depends of geomerty complexity, number and type of lights, and light sizes. shadow volume renderer is more optimised than lightmap one, and it is often faster. but we're talking about alot of huge light sources, and here lightmaps are usually faster.

15 minutes ago, Remilia Scarlet said:

Anyway, how do you get the tops of 3d floors to not be fullbright in your pictures?

everuthing is in semi-broken state now. i merged shadowmaps simply because i got tired of switching branches, but it is not ready yet. and i may broke things while hacking in shadowmap support. yet if you'll manage to produce a small test map, i'll take a look.

tbh, lighting on 3d floors (with sector light levels) was broken since... always, i guess. ;-) at least it doesn't do the same thing as GZDoom (which is de-facto standard), and sometimes it is plainly wrong. i'd like to get test maps for such bugs.

15 minutes ago, Remilia Scarlet said:

Also, random thing I noticed

yeah, Mr.Rocket already reported that on the previous page. ;-) it used to work, but then it broke. i'll fix it later, thank you.

some more (buggy) screenshots. look at FPS.

stencils:

shadowmaps:

yep, light bleeding (or peterpaning, call it as you like to ;-). yes, some jagged edges. i may find a way to make light bleeding less noticeable (i hope so), but speed difference is huge. ;-)

most of the time the difference won't be that big, of course, this is very pathological case with huge lights and alot of small map details (each bar is a sector). still, it already looks... let's say "acceptable". and it is possible to craft your maps in a way that will hide most light bleeding artifacts (i will try to write some guidelines for this later).

so, i added the final part of the puzzle: 3d models. now they are properly lit and can cast shadows too.

of course, some parts of the puzzle was put into place with a hammer, but meh. ;-) as i said, the full implementation is still far away (especially that nasty moire and peterpaning), but you will prolly get a preview in the next build. just don't expect it to be perfect, consider it as a proof-of-concept for now. i need to read more papers, and learn alot of things yet.

ah, btw, you will need at least OpenGL3 capable GPU for that. the engine will not allow you to turn on shadowmaps on a weaker GPUs (because i need GLSL130, which is available only on OpenGL3).

just for the fun of it, you can have shadows from sprites too. ;-)

it doesn't always look good (i really tried to find a good view ;-), but it may look... interesting. i doublt people will really play with this mode turned on, but hey, sometimes it looks great on screenshots! ;-)

2 hours ago, ketmar said:

just for the fun of it, you can have shadows from sprites too. ;-)
 

it doesn't always look good (i really tried to find a good view ;-), but it may look... interesting. i doublt people will really play with this mode turned on, but hey, sometimes it looks great on screenshots! ;-)

I dunno, I was just playing some Doom 2 with it and found it fun as hell XD  Nicely playable framerate, too.  Most of my major FPS drops came from having the gore mod numbers completely at max >_>

I did notice a (probably) unrelated bug, though.  I originally noticed it in my current WIP map and was getting ready to make a small test map for you.  But then I noticed it again in map17 of Doom 2 with a lift (my level does not have a lift).  Basically, the first screenshot shows how the floor should look.  But when the lift is moving, this fake floor (brown in the 2nd screenshot) gets rendered.  My level doesn't have a lift, but the same thing happened in a small step-down area, where a fake floor got rendered.  Changing the geometry slightly removed the fake floor
 

46 minutes ago, Remilia Scarlet said:

Most of my major FPS drops came from having the gore mod numbers completely at max

yeah, it spawn things as crazy, and it puts alot of decals too. it can easily put 100+ decals on a wall at max setting, and it may slow down things alot. i tried to limit that, but tbh, decal code is a mess. it was the first major addition to the engine i wrote, and i didn't fully understand what i was doing. it should be rewritten, but... eh. it kinda works, so... ;-)

46 minutes ago, Remilia Scarlet said:

I was just playing some Doom 2 with it and found it fun as hell XD

yeah, it looks better than i expected. ;-) the shadows are completely wrong, of course (i'm just rendering sprites facing the light, and hope that nobody will notice that it is wrong). luckily, most of the time you don't have time ;-) to stop and take a closer look, so it is... passable, i guess. anyway, it will be the option, as usual.

46 minutes ago, Remilia Scarlet said:

But when the lift is moving, this fake floor (brown in the 2nd screenshot) gets rendered.

oh... this must be fakefloor/bridge detector. GZDoom tries to do it in real time, but k8vavoom precalcs this data, and it never changes. most of the time detector does its job, but sometimes it goes crazy. that code is a mess too. you may try to toggle options in "map hacks". please, note that save/load may not work, you have to restart the map with "map" console command. dunno if i'll be able to fix it -- i really need a small test map with a geomerty that confuses my detectors. and even in that case i'm not sure if it is fixable.

maybe i'll just add some flags to MAPINFO, so you will be able to override default settings. those detectors are there mostly to support vanilla rendering hacks. or maybe i will simply turn 'em off for UDMF maps -- i think that with UDMF people will use proper tools instead of rely on vanilla render bugs.

added very simple and dumb PCF-like filtering:

no filtering:

4 samples:

8 samples:

16 samples + cubemap bilinear filtering (without filtering shadows are worser, i think, and some detailing is lost; filtering doesn't really affect performance anyway):

not the best thing out there, of course, but hey, it took only about 30 minutes! ;-)