Jump to content
The Dark Mod Forums

Beta Testing 2.06


Recommended Posts

  • Replies 1k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

So the suggestion is--and I agree--that FPS is capped at 60 by default (where we know physics will at least work the way it always has), and if the player wants to uncap it, a warning gets put in the

Holy crap, just built the binaries, super smooth now, with or without VSync on. Walking around something while straffing no longer has that micro stutter. Feels amazing now.

I went back through the thread and apparently it was fixed in January. No confirmation from the original reporter (Iowenz).   Just tried the new update. It fixes the fluctuating FPS I was seeing in

Posted Images

@VanishedOne and Spooks:

 

Are some of the cubicLight problems being seen for projected lights?

 

As I recall, only "point lights" were implemented in GLSL. (After much begging...)

We weren't aware of any real compelling use case for projected lights with cubemaps so it

wasn't worth the battle at the time. If you really need projected cubicLights, I'll go back and

argue the case to Duzenko.

To finally answer the question, no and yes.

 

Omni cubic lights work as intended.

Projected (spotlight) cubic lights straight up don't work, there is a very tiny spot of light somewhere in their radius, which supports what you said, that there implementation simply isn't there. As far as I'm concerned -- and as it was stated in the other thread -- there's really no point to having a spotlight cubic light if it just projects the bottom part of the cubemap, so I'm not too fussed about this.

 

Both Omni and Projected (spotlight) ambientcubic lights exhibit the same problem - they're fullbright and rectangular. As I understand it there's an effort to integrate IBL so I assume they're broken because of that? I have several of these in my WIP but they are replaceable and I've not seen them used anywhere in new FMs, so 2.06 could possibly ship with them in this broken state.

 

 

I want to point something else important about the glprogs: a bunch of the interactions seem broken.

 

Here is a custom material with a cubemap stage:

 

 

 

textures/darkmod/stone/brick/blocks_large_sandstone2
{

    stone
    description	"vine_friendly"


    qer_editorimage textures/darkmod/stone/brick/blocks_large_sandstone_01_ed
    {blend    diffusemap   
    map   textures/darkmod/stone/brick/blocks_large_whitestone
    red  .8
    green .7
    blue   .6
    }
    bumpmap         textures/darkmod/stone/brick/blocks_large_yellowstone_local

	{
		maskcolor
		map makealpha (textures/darkmod/stone/brick/blocks_large_whitestone) //here I use the specular of the texture
		alpha	0.5
	}
	
{
		blend gl_dst_alpha, gl_one
		maskalpha
		cameraCubeMap	env/skyboxes/skybox_darkland_ne/darkland_NE
		texgen      reflect

}

    {
        if ( parm11 > 0 )
        blend       gl_dst_color, gl_one
        map         _white
        rgb         0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend       add
        map         textures/darkmod/stone/brick/blocks_large_yellowstone
        rgb         0.15 * parm11
    }

	// TDM Ambient Method Related
	{
		if (global5 == 1)
		blend add
		map				textures/darkmod/stone/brick/blocks_large_yellowstone
		scale			1, 1
		red				global2  * .8
		green			global3    *    .7
		blue			global4    *     .6
	}
} 

 

 

This is how it looks in 2.05, the cubemap properly interacts with the normal map:

 

DuAuOJV.jpg

 

This is how it looks in 2.06, the cubemap does not interact with the normal map (and looks tilted, just like the screenshot VanishedOne posted shortly after the post I quoted above). The rectangular fullbright light on the right is how ambientcubic lights look:

 

Nohae4X.jpg

 

 

Here is another material, this is just your regular clear_warp, plenty of released FMs use it. The screenshots are higher res because the difference is harder to spot.

 

2.05, here it looks normal:

 

1ml9svT.jpg

 

2.06, now there are vertical bands at regular intervals that distort the image, you can see them distorting the vases and the leafing on the panelling texture on the right:

 

ktBJTxT.jpg

 

 

 

As I said, my first suspicion would be the vertex programs, stuff like heatHazeWithDepth.vfp and the interaction program that gets invoked when a cubemap stage is present in a material.

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to post
Share on other sites

To finally answer the question, no and yes.

 

Omni cubic lights work as intended.

Projected (spotlight) cubic lights straight up don't work, there is a very tiny spot of light somewhere in their radius, which supports what you said, that there implementation simply isn't there. As far as I'm concerned -- and as it was stated in the other thread -- there's really no point to having a spotlight cubic light if it just projects the bottom part of the cubemap, so I'm not too fussed about this.

 

Both Omni and Projected (spotlight) ambientcubic lights exhibit the same problem - they're fullbright and rectangular. As I understand it there's an effort to integrate IBL so I assume they're broken because of that? I have several of these in my WIP but they are replaceable and I've not seen them used anywhere in new FMs, so 2.06 could possibly ship with them in this broken state.

AmbientCubic lights use a new irradiance method. I tried to advocate for as little variance from 2.05 as possible but Duzenko wanted a conceptual justification

for this type of light so I had to offer industry examples and he settled on something that there is documentation and tool workflows for. The current system works

best if you pre-bake the irradiance cube images in AMD's cubemap gen but we do have new makeIrradiance image programs to mostly cover that (doesn't look quite as good).

 

I want to point something else important about the glprogs: a bunch of the interactions seem broken.

 

Here is a custom material with a cubemap stage:

 

 

 

textures/darkmod/stone/brick/blocks_large_sandstone2
{

    stone
    description	"vine_friendly"


    qer_editorimage textures/darkmod/stone/brick/blocks_large_sandstone_01_ed
    {blend    diffusemap   
    map   textures/darkmod/stone/brick/blocks_large_whitestone
    red  .8
    green .7
    blue   .6
    }
    bumpmap         textures/darkmod/stone/brick/blocks_large_yellowstone_local

	{
		maskcolor
		map makealpha (textures/darkmod/stone/brick/blocks_large_whitestone) //here I use the specular of the texture
		alpha	0.5
	}
	
{
		blend gl_dst_alpha, gl_one
		maskalpha
		cameraCubeMap	env/skyboxes/skybox_darkland_ne/darkland_NE
		texgen      reflect

}

    {
        if ( parm11 > 0 )
        blend       gl_dst_color, gl_one
        map         _white
        rgb         0.40 * parm11
    }
    {
        if ( parm11 > 0 )
        blend       add
        map         textures/darkmod/stone/brick/blocks_large_yellowstone
        rgb         0.15 * parm11
    }

	// TDM Ambient Method Related
	{
		if (global5 == 1)
		blend add
		map				textures/darkmod/stone/brick/blocks_large_yellowstone
		scale			1, 1
		red				global2  * .8
		green			global3    *    .7
		blue			global4    *     .6
	}
} 

 

 

This is how it looks in 2.05, the cubemap properly interacts with the normal map:

 

DuAuOJV.jpg

 

This is how it looks in 2.06, the cubemap does not interact with the normal map (and looks tilted, just like the screenshot VanishedOne posted shortly after the post I quoted above). The rectangular fullbright light on the right is how ambientcubic lights look:

 

Nohae4X.jpg

 

Please open a tracker about this one. It's clearly broken somehow.

 

Here is another material, this is just your regular clear_warp, plenty of released FMs use it. The screenshots are higher res because the difference is harder to spot.

 

2.05, here it looks normal:

 

1ml9svT.jpg

 

2.06, now there are vertical bands at regular intervals that distort the image, you can see them distorting the vases and the leafing on the panelling texture on the right:

 

ktBJTxT.jpg

 

 

 

As I said, my first suspicion would be the vertex programs, stuff like heatHazeWithDepth.vfp and the interaction program that gets invoked when a cubemap stage is present in a material.

This is an artifact from the use of FBO with "Shared Depth".

I'll have to play with cvars tonight to give a clear answer. Earlier in development you could cure this via r_fboSharedDepth 0

but it seems that Soft Shadows always causes this regardless of that setting in the latest builds.

 

See if setting r_useFBO 0 cures it.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites

The next package build is ready for testing.

 

7281 – Fix r_fboresolution + r_smp flickering (duzenko)

7286 - Fix invisibility of briefing scrolling arrows (stgatilov)

7287 - Turn OFF default beep sound for missing sounds to keep it from being heard in existing maps (grayman)

7288 - #4669: fixed bloom w/o FBO (duzenko)

15076 – GLSL: ambient cube light bugfix (duzenko)

15082 - Fix white sparklies with enabled antialiasing, enhanced ambient shader and GLSL (stgatilov)

15083 - Fix Epifire's broken material file "tdm_epi_shader_2.mtr" (Goldwell)

15086 – More fixes to "tdm_epi_shader_2.mtr" (Springheel)

  • Like 1
Link to post
Share on other sites

I wonder whether that HeatHaze problem is the same as the one I mentioned with the juddering fountain. I'll add that to the tracker later.

 

Btw. are there any practical examples of using AmbientCubicLights in Dark Mod? I tested those briefly in 2.05, and they work fine, but honestly, I can't think of any use for them in a mission.

The cubic lighting thread has a test map in the download package linked from its first post (you have to noclip to see most rooms). If you're asking for an actual mission, I think the feature's too new and experimental to have been used in any released mission I know of.

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to post
Share on other sites

Where can I test the warp material?

I'm seeing these artifacts in all transparent materials. Glass, water, etc.

The quickest examples that come to mind are the water in the NHAT mission 1 cave

and the transparent Windows in Lords and Legacy.

 

I've outlined the places in Spooks screen where the artifacts are so you can see them more clearly:

 

post-3763-0-82026800-1510862231_thumb.jpg

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites

r_useGLSL doesn't affect this, r_fboSharedDepth is set to 0. r_useFBO 0, however, makes the graphical glitch disappear, so nbhor1more hit the bullseye on that one.

 

Will proceed to file the cubemap issue to the tracker.

 

 

EDIT: Can someone elevate my privileges on Mantis, please? I wish to be able to assign relationships or tag these bugs correctly as 2.06 and not SVN at least.

Edited by Spooks

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to post
Share on other sites

Soft shadows/ new shaders/ video format support/ improved GUIs. Awesome work guys.

 

Minor main menu gui bug. http://bugs.thedarkmod.com/view.php?id=4672

 

Was any work done on the ai_darkmod_base scripts or definitions? If so where can I get that information? I've got several new AI in my next mission and I want to make sure they're compatible with 2.06.

  • Like 2
Link to post
Share on other sites

The next package build is ready for testing.

 

7281 – Fix r_fboresolution + r_smp flickering (duzenko)

7286 - Fix invisibility of briefing scrolling arrows (stgatilov)

7287 - Turn OFF default beep sound for missing sounds to keep it from being heard in existing maps (grayman)

7288 - #4669: fixed bloom w/o FBO (duzenko)

15076 – GLSL: ambient cube light bugfix (duzenko)

15082 - Fix white sparklies with enabled antialiasing, enhanced ambient shader and GLSL (stgatilov)

15083 - Fix Epifire's broken material file "tdm_epi_shader_2.mtr" (Goldwell)

15086 – More fixes to "tdm_epi_shader_2.mtr" (Springheel)

Still the savescreenshot problem use FBOresolution:

 

newjob_2017-11-16_23.06.40.jpg

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites

FYI, it you want to hear new OpenAL EFX system in action, Volta is one of few missions that use efx settings for rooms. I looks like a few things need to be tweaked here and there, but the overall impression is great. The environment feels much more alive.

Edited by Judith
  • Like 4
Link to post
Share on other sites

AmbientCubic lights use a new irradiance method. I tried to advocate for as little variance from 2.05 as possible but Duzenko wanted a conceptual justification

for this type of light so I had to offer industry examples and he settled on something that there is documentation and tool workflows for. The current system works

best if you pre-bake the irradiance cube images in AMD's cubemap gen but we do have new makeIrradiance image programs to mostly cover that (doesn't look quite as good).

 

I've tried the makeIrradiance keyword since I didn't want to stitch together a proper cubemap to load in AMD's cubemapgen. The result was the light just becoming brighter (which I suppose is normal with how irradiance maps work) and the rectangular, no falloff behavior remaining. Is this just something that works in SVN but not in the beta branch?

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to post
Share on other sites

FYI, it you want to hear new OpenAL EFX system in action.

Exactly my idea/wish. Thanks!

Edited by lowenz

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to post
Share on other sites

 

I've tried the makeIrradiance keyword since I didn't want to stitch together a proper cubemap to load in AMD's cubemapgen. The result was the light just becoming brighter (which I suppose is normal with how irradiance maps work) and the rectangular, no falloff behavior remaining. Is this just something that works in SVN but not in the beta branch?

Please post your test map in the cubemap thread

Link to post
Share on other sites

Is anyone else noticing that (after an FM intro plays), you must press a button at the end to get out of a black screen and progress to the objectives/difficulty screen?

 

Not here.

 

FM?

O/S?

32- or 64-bit?

Resolution?

Link to post
Share on other sites

So, doing a fresh update with the latest package, the sparkly problem is virtually gone. I noticed it in one spot on one model, but only because I was looking for it.

  • Like 2
Link to post
Share on other sites

Your machine does not like compression :o

 

On 64-bit Debian, when I try to launch the game, either 32 or 64-bit version, I get a black screen when the main menu should show. At the top of the screen, it just says "Invalid GUI:guis/mainmenu.gui. Prior to this, TDM 2.05 ran fine. I wonder if I am just missing some libs. I don't see anything about it in the console output, which follows.

 

Repacking /home/kevin/darkmod/tdm_gui01.pk4...
WARNING:Cannot close file video/briefing_video.roq in /home/kevin/darkmod/tdm_gui01.pk4

...
-------- Initializing Session --------
WARNING:Couldn't load gui: 'guis/mainmenu.gui'
WARNING:Couldn't load gui: 'guis/restart.gui'
WARNING:Couldn't load gui: 'guis/msg.gui'

These messages show that TDM starts repacking tdm_gui01.pk4, because it has video briefing_video.roq inside it and TDM wants this file not to have compression.

However, the repacking process fails: MiniZip meets some problems with reading video/briefing_video.roq from your original tdm_gui01.pk4, so it returns an error. After this error, the pk4 becomes unavailable for the current game session.

 

Most likely this means that tdm_gui01.pk4 was corrupted, although I have no idea why.

 

Editing darkmod.cfg made no difference. I wonder if my game files are damaged... Another oddity is that attempting to run the updater again with the --keep-mirrors option freezes when comparing definitions. Shall I hash them and post the output here in a spoiler? Will go test the installation in a Windows environment right now.

Probably the updater also looks inside the corrupted pk4 and cannot make any sense of it?

 

For me, attempting to save on any mission causes the mission to bomb out to a full-screen console (TDM itself is still running but progress is lost).

The above happens on the 64-bit Linux version. I tried to see if it would happen in the 32-bit version, but the 32-bit version (linux as well) fails to load any missions!

 

--------- Game Map Shutdown done -----

ERROR:idSaveGame::FinalizeCache: compress failed with code -5

This happens at the end of savegame process, when the whole savegame data gets compressed with zlib.

Zlib's compress function returns Z_BUF_ERROR, which is hard to explain especially in x64, unless your savegame e.g. has size more than 2 GB.

Of course, disabling tdm_savegame_compress would remove it, but would your savegames load properly after that?...

 

And here's a dump of the 32-bit version crashing when I try and load a mission.

 

--------- Game Map Shutdown done -----
ERROR:Script events internal check failed!

This is very weird.

This comes from script self-checking code which I added when I tested scripts under 64-bit platform.

You can see the calls in tdm_base01.pk4/script/tdm_player.script in player::init method. The counterpart from TDM engine can be seen in game/Player.cpp e.g. in idPlayer::Event_TestEvent1.

These calls are performed on game start and they simply pass some data of various types to TDM engine and get some data back. Whenever TDM engine sees a mismatch, it prints the error message you see.

I have no idea how this message can appear on one machine and not appear on another one, given that both use the same executable file. And I guess there are other beta testers on Linux here, and they do not see this error.

You can of course comment out the code in tdm_player.script, but even if the game starts, you will most likely see errors and corruption on every step without script events working properly.

 

I don't like saying this, but did you try stress-testing your RAM and CPU?

Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...