TDM Engine Development Page

[revelator]

Heh somehow my answer ended up being posted before the forum decided that you had posted your's.

[revelator]

Dooh seems i forgot the ! before height fixed now.

[RPGista]

Replaced old TGA code with the more recent TGA2 code, benefit is that we no longer require the image flipping code hacks that has plaged TGA for years.

Also it supports way more formats 8, 15 ,16 ,24, 32 bit with RLE or without.

 

Visually it's a bit crisper, but nothing fancy.

 

This sounds pretty good, man. BTW, we definitely dont thank our coders enough, all you guys are real cool...

[nbohr1more]

Latest SVN still in good shape except this stove in Penny Dreadful 2: All the way Up:

 

 

This is producing some sort of shadow geometry cracks.

 

Any chance there was a missed case for model geometry in your precision change?

[duzenko]

I'll let Duzenko chime in there.

 

As I recall, there was this strange stub function on the game side for activating the cvar which is why

I was having a little trouble with some of the fix mechanisms for initialization operations like reloadImages.

 

In my mind r_postprocess shouldn't be doing anything on the game side and should work like all other render cvars.

 

I guess the some of this game side design stems from the use of r_postprocess with effects like influence vision (scripts)

for when the player is cursed, etc. They wanted modders to have more SDK access to these effects

so they moved some rendering control to the game side but it really doesn't belong there in Doom 3 GPL branches.

I can't comprehend the commit 7620.

It's full of formatting changes like this.

-		basePath = Mem_CopyString(buff.c_str());
+		basePath = Mem_CopyString( buff.c_str() );

Any attempt to find actual changes is going to turn to a waste of time.

When I did a bulk formatting change by mistake in 2016 I got a slap on the wrist from @grayman.

[Bikerdude]

Any chance there was a missed case for model geometry in your precision change?

There are gaps in the shadows, because there are gaps in the model. The shadow mesh just needs to be tweaked.

Edited August 17, 2018 by Bikerdude

[revelator]

Formatting was an error, it was set from one of My own projekts but I forgot to turn it off. Thats fixed for future changes now though. In case you want to see My changes just search for revelator, i commented All of Them.

[Springheel]

There are gaps in the shadows, because there are gaps in the model. The shadow mesh just needs to be tweaked.

 

Is that a custom model? I've checked and neither furnace_round model has any kind of shadowmesh.

[Bikerdude]

Is that a custom model? I've checked and neither furnace_round model has any kind of shadowmesh.

If it has an opener, than its one I made which is a clone of the original you made.

[Bikerdude]

Is that a custom model? I've checked and neither furnace_round model has any kind of shadowmesh.

Any chance there was a missed case for model geometry in your precision change?

If I update this model and post the link here, would one of you like to add it to SVN..?

[Springheel]

If it has an opener, than its one I made which is a clone of the original you made.

 

If it's not a custom model, then the problem is not related to a shadowmesh, since neither of them have shadowmeshes. (Neither really need them either, as they're already low poly.)

 

What makes you conclude the "shadow geometry cracks" NB mentions are due to the model itself?

[Bikerdude]

What makes you conclude the "shadow geometry cracks" NB mentions are due to the model itself?

The light is shining through the gaps between the opener and the main model, when I created it I was to realistic. as in a left small gaps between the opener and the main model.

[nbohr1more]

Yes, I should be clear.

 

The shadow behavior is new to the latest SVN revision that Rev made.

It's not just light bleeding out, it's a strange flickering pattern of lines extending from the model.

 

That said, if the model design is more susceptible to errors due to "high precision" vertex coordinates,

it may be worthwhile to get a better version anyway.

 

I'll recheck tonight as Duzenko just made some further changes (but they are unlikely to affect this).

[revelator]

Might be caused by me adding lightdepthbounds to glsl stencil shadow code, it looked as if it was missing there and I also asked if it was intentional. It is easy to revert it so ill do that when i get home.

[duzenko]

Ok upped my recent changes.

Fixed an attempt at minimizing scissoring in tr_render.cpp.

Non FBO DepthCopy and FrameCopy refined a bit.

Now using c++11 nullptr in places where NULL was used, In C++ NULL is not a pointer to 0 but an octal integer 0 in C NULL is a pointer to 0 but that does not apply to C++.

Fixed a function which was shadowed by another function of the same name.

Made some changes to make lightdepthbounds more uniform, cut down on having to use the same cvar all over to one.

Added lightdepthbounds to the GLSL renderers stencil shadow part also since it was missing there, was this intentional ?. (no adverse effects and i tested it extensively so id reckon no, but who knows).

Reordered a few ugly externs, i hope the readability is a bit better now .

Can you explain why this code was deleted from FB_ToggleShadow in svn rev 7618?

	if(r_shadows.GetInteger() == 1)
	if ( on ) {
		if ( r_softShadowsQuality.GetInteger() < 0 && shadowOn )
			shadowResolution = r_softShadowsQuality.GetInteger() / -100.;
		else
			shadowResolution = 1;
		qglViewport( 0, 0, glConfig.vidWidth * shadowResolution * r_fboResolution.GetFloat(), glConfig.vidHeight * shadowResolution * r_fboResolution.GetFloat() );
		FB_ApplyScissor();
	} else {
		if( primaryOn )
			qglViewport( 0, 0, glConfig.vidWidth * r_fboResolution.GetFloat(), glConfig.vidHeight * r_fboResolution.GetFloat() );
		else
			qglViewport( 0, 0, glConfig.vidWidth, glConfig.vidHeight );
		FB_ApplyScissor();
	}

[cabalistic]

@revelator: Just a quick remark, I don't think it's necessary that you flag every place you replaced a 0 or NULL with nullptr with a comment. In my personal opinion, comments should be written to help developers understand the *current* state of the code, not its history. The reason being that in most instances, developers won't know the history and the comment is thus fairly useless to them, and also code evolves fairly quickly and these comments are then often left untouched and completely outdated. Commit messages are the right place to comment the history, imho

 

(Also, your comments are somewhat misleading. They make it sound as if the replaced 0 or NULL were a bug in the code that needed to be addressed. That is not the case. It is safe and well defined to assign 0 to a pointer. It's just no longer best practice, because the nullptr keyword introduced with C++11 has the advantage that it isn't ambiguous and can thus prevent potential subtle bugs if function signatures change or are overloaded.)

[revelator]

Duzenko, was that codepiece added rently? It might have gotten deleted by mistanke if My changes where uploaded just as the commit went in. It was certainly not something i intended to delte from code, not sure what happened there.

Using 0 is fine in most case, i believe i Even left in a comment about that in the copyrender code, im sorry if it sounded like it was an error, the comment was in regards to a previous comment in that particular place, and was ment to only correct a misconception there.

The reason i changed to nullptr was that certain recently added code was allready using it instead of plain NULL, so it was just to keep things a bit more consistant.

[cabalistic]

Yeah, and I'm not against it, just no need to leave a comment

[revelator]

Did I comment it elsewhere also?

If i did it must have slippe My mind.

[revelator]

Im home again tomorrow, should i revert adding lightdepthbounds to the glsl stencil code?, or did the accidentally deleted codeoiece duzenko mentioned maybe cause this.

[duzenko]

Im home again tomorrow, should i revert adding lightdepthbounds to the glsl stencil code?, or did the accidentally deleted codeoiece duzenko mentioned maybe cause this.

Yes, please restore the FB scissor thing and make sure that r_softShadowsQuality -NN has effect (pixelated shadows).

It was added back in July.

[revelator]

Will do, not sure what happened causing that codeoiece to get deleted, visual studie crashed at one point though while i was working on it i remember, cause i had to redo som changes afterwards, but it shouldnt have deleted allready existing code i Hope.

[revelator]

I would not be adverse to using ue4 if this was a New projekt either. Or Even bfg for that matter, but since it is not we might end up loosing more than we gain.

[revelator]

Ok reverted duzenkos code, though im at a loss as to how it was changed in the first place, i think i would remember changing it in the first place or else im coding in my sleep

Gremlins ?

[revelator]

Could anyone test and see if everything works as it should now ? before i revert the lightdepthbounds added to the GLSL stencil shadow code permanently.