TDM Engine Development Page

[Tels]

Funny, how history repeats:

 

------------------------------------------------------------------------
r5439 | tels | 2012-05-08 21:12:22 +0200 (Tue, 08 May 2012) | 1 line
Changed paths:
  M /trunk/renderer/draw_arb2.cpp

take glasswarp out (thanx serpentine!)

 

Look at the date

Edited October 4, 2014 by Tels

[Tels]

Confirmed that none of TDM materials use glasswarp. And the .vfp file isn't there, anyway. So here is a patch to remove the glasswarp:

 

http://swift-mazes.c..._2014-10-04.txt

 

However, I cannot test it, as the compilation on Linux is broken again:

 

game/Misc.cpp: In member function ‘virtual void idStaticEntity::ReapplyDecals()’:
game/Misc.cpp:1302: error: no matching function for call to ‘std::list<SDecalInfo, std::allocator<SDecalInfo> >::erase(std::_List_const_iterator<SDecalInfo>&)’
/usr/include/c++/4.4/bits/list.tcc:107: note: candidates are: std::_List_iterator<_Tp> std::list<_Tp, _Alloc>::erase(std::_List_iterator<_Tp>) [with _Tp = SDecalInfo, _Alloc = std::allocator<SDecalInfo>]
/usr/include/c++/4.4/bits/stl_list.h:1092: note:				 std::_List_iterator<_Tp> std::list<_Tp, _Alloc>::erase(std::_List_iterator<_Tp>, std::_List_iterator<_Tp>) [with _Tp = SDecalInfo, _Alloc = std::allocator<SDecalInfo>]

 

Edit:

 

Here is a patch to fix the above issue:

 

http://swift-mazes.com/pub/tdm-patches/tels_patch_l_fix_linux_2014-10-04.txt

 

And here is another patch to get it to compile on linux again:

 

game/Entity.cpp: In member function ‘void idEntity::SaveOverlayInfo(const idVec3&, const idVec3&, float, const char*)’:
game/Entity.cpp:4066: error: ‘FLT_MAX’ was not declared in this scope

 

http://swift-mazes.com/pub/tdm-patches/tels_patch_m_linux_fix_2014-10-04.txt

Edited October 4, 2014 by Tels

[revelator]

Yikes thats ancient seems there was a bit confusion about this though but atleast we now have confirmation from a trusted source .

 

C++ crankyness (shudder) glad im not the poor soul who had to fix that good job though.

[SteveL]

And here is another patch to get it to compile on linux again:

Thanks. Problem #1 shouldn't have compiled on Windows either imo, never mind that I coded it. The MSVC standard lib implementation lets you delete an object through a const pointer? Apparently so.

 

The float definition problem #2 is thorny. idLib does some unfortunate stuff there, importing <float> then redefining some of its constants. So if we just reimport <float> in a module, we redefine those constants back again. Unless someone wants to take the time to map all that out we might be better off using a custom constant instead of FLT_MAX.

[Tels]

The float definition problem #2 is thorny. idLib does some unfortunate stuff there, importing <float> then redefining some of its constants. So if we just reimport <float> in a module, we redefine those constants back again. Unless someone wants to take the time to map all that out we might be better off using a custom constant instead of FLT_MAX.

 

Well, no matter what we do, using FLT_MAX in Entity.cpp without defining it doesn't work. I just looked at other places that use it and they include <float.h> so I followed. If you have a better idea, no problem. But something needs to be done, otherwise TDM doesn't compile.

 

So, if we include Math.h, would that be better?

 

Index: game/Entity.cpp
===================================================================
--- game/Entity.cpp	 (revision 6118)
+++ game/Entity.cpp	 (working copy)
@@ -36,6 +36,7 @@
#include "Inventory/Cursor.h"
#include "AbsenceMarker.h"
#include "Objectives/MissionData.h"
+#include "math/Math.h"

/*
===============================================================================

 

One more thing: Why does Entity.cpp include files, and Entity.h, too? In other places, f.i. Heap.h, Math.h is included in the .h file. Is there a standard for this?

 

Maybe this would be better:

 

Index: game/Entity.h
===================================================================
--- game/Entity.h	   (revision 6118)
+++ game/Entity.h	   (working copy)
@@ -24,6 +24,7 @@
#include "OverlaySys.h"
#include "UserManager.h"
#include "ModelGenerator.h"
+#include "math/Math.h"

class CStimResponseCollection;
class CStim;

[revelator]

Probably the best place for this would be precompiled.h as its global to all the source ?.

 

Heh even BFG reinterprets the float values but atleast it uses a more modern way IEEE-754.

 

I toyed a bit with it changing vanillas FLT_EPSILON to DBL_EPSILON so far it works fine but im not sure its correct for all cases.

[SteveL]

Well, no matter what we do, using FLT_MAX in Entity.cpp without defining it doesn't work. I just looked at other places that use it and they include <float.h> so I followed. If you have a better idea, no problem. But something needs to be done, otherwise TDM doesn't compile.

 

Well, it already *is* included of course else we wouldn't be able to compile it on Windows/MSVC.

Entity.cpp --> precompiled_game.h --> precompiled.h --> math/Math.h --> <limits> --> <cfloat> --> FLT_MAX

Is there a capitalization problem or library naming problem again? Better to fix that than add extra includes.

[Tels]

Well, it already *is* included of course else we wouldn't be able to compile it on Windows/MSVC.

Entity.cpp --> precompiled_game.h --> precompiled.h --> math/Math.h --> <limits> --> <cfloat> --> FLT_MAX

Is there a capitalization problem or library naming problem again? Better to fix that than add extra includes.

 

Not on Linux - or at least not on my system

 

According to:

 

http://www.tutorials...ry/limits_h.htm

 

<limits> does not define FLT_MAX.

 

And further, idlib/precompiled.h does not contain the string "Math.h". The only thing it contains is "math.h", but not "math/Math.h".

 

It does include "idlib/Lib.h", which in turn includes "math/Math.h", tho. However, only for MacOS:

 

#ifdef __linux__
#include "../../sys/sys_public.h"
#include <cassert>
#endif

#ifdef MACOS_X
// greebo: Include this for ID_INLINE
#include "../../sys/sys_public.h"

// for square root estimate instruction
#include <ppc_intrinsics.h>
// for FLT_MIN
#include <float.h>
#endif

 

So, yes, there is something missing on Linux.

 

Maybe adding "#include <float.h>" for Linux is in order, too.

 

Edit: Wait, that doesn't make sense. If I include "math/Math.h" in Entity.cpp, it works, but the already included "precompiled_game.h" doesn't work, even tho it ends up including the same file. Huh? (The entire pre-compiled stuff doesn't work with gcc, anyway, but I'm not sure this is related).

Edited October 4, 2014 by Tels

[SteveL]

Yeah, sorry I missed Lib.h out of my include chain above. It should go after precompiled.h as you noted.

 

I think we have found the right solution. Linux needs to include float.h explicitly at the top of math/Math.h.

 

In Windows/MSVC, float.h gets included there already because it includes <limits> which always includes float.h.

 

On Mac OS, float.h gets included a step later, as you noted -- so presumably limits.h on Max doesn't include float.h.

 

Presumably your Linux compiler (gcc?) doesn't include float in limits either. I expect it's Microsoft departing from standards.

 

Either way, precompiled.h does define FLT_MAX on Windows and Mac, just not apparently Linux, so I reckon you should add it. I can't help test it though.

 

It's Math.h that makes the amendments to float.h's defines, so including float.h at the top of Math.h makes sure we won't get clashes in downstream code.

[SteveL]

Back to rendering stuff, does anyone know how the right way to suppress depth testing in a material? Can we do it in a material decl? I can't see a way, so maybe idTech4 doesn't have any native materials that aren't depth tested. I'm thinking of soft particles again. Ideally we want their alpha fade to kick in where they exceed the current depth but that means disabling the standard draw method that clips the particle where it crosses the solid geometry in the depth buffer, and leaving it to the fragment shader to hide the parts that shouldn't be visible.

[SteveL]

Materials already have the maskDepth keyword but that only prevents writing to the depth buffer, it doesn't disable the depth test.

[Tels]

Yeah, sorry I missed Lib.h out of my include chain above. It should go after precompiled.h as you noted.

 

I think we have found the right solution. Linux needs to include float.h explicitly at the top of math/Math.h.

In Windows/MSVC, float.h gets included there already because it includes <limits> which always includes float.h.

On Mac OS, float.h gets included a step later, as you noted -- so presumably limits.h on Max doesn't include float.h.

Presumably your Linux compiler (gcc?) doesn't include float in limits either. I expect it's Microsoft departing from standards.

Either way, precompiled.h does define FLT_MAX on Windows and Mac, just not apparently Linux, so I reckon you should add it. I can't help test it though.

It's Math.h that makes the amendments to float.h's defines, so including float.h at the top of Math.h makes sure we won't get clashes in downstream code.

 

Hm, part of the confusion was that gcc creates a file called "game/precompiled_game.h.gch" and when you make certain changes, and only compile one file, they are ignored unless you delete that file.

 

So, here is the hopefully final patch for this issue:

 

Index: idlib/math/Math.h
===================================================================
--- idlib/math/Math.h   (revision 6118)
+++ idlib/math/Math.h   (working copy)
@@ -26,6 +26,8 @@
#ifdef __linux__
#include "../../sys/sys_public.h"
#include <cassert>
+// for FLT_MIN and FLT_MAX
+#include <float.h>
#endif

#ifdef MACOS_X

 

It compiles on Linux and quick test shows nothing unusual running the game.

[SteveL]

Committed both changes for Linux.

 

Any idea on my question a couple of posts up, whether there's any existing method to suppress depth testing for a material stage? Otherwise I'll try adding a material stage keyword for the time being so I can test it.

[Tels]

Committed both changes for Linux.

 

Thank you

 

Any idea on my question a couple of posts up, whether there's any existing method to suppress depth testing for a material stage? Otherwise I'll try adding a material stage keyword for the time being so I can test it.

 

No, I'd have to rummage through the source code, too. Maybe this helps:

 

http://fabiensanglard.net/doom3/renderer.php

 

If I'd be able to make a wish, having soft-alpha (aka translucency instead of just per-pixel is/is not would also be high on my list That way you could "fade out" things at a distance, instead of having them "pop". But don't le me distract you

[motorsep]

If that's for LOD, it's quite an elaborate setup to make one LOD iteration "softly" transition to another. Even AAA games you straight LOD transitions. Crysis 2+ uses alpha blending afaik. Not quite sure about other games.

[Tels]

If that's for LOD, it's quite an elaborate setup to make one LOD iteration "softly" transition to another. Even AAA games you straight LOD transitions. Crysis 2+ uses alpha blending afaik. Not quite sure about other games.

 

No, the LOD transitions between stages are mesh-deform (e.g. morph one model into another). The "fade" is for the last stage, where the model should vanish. If you wander through a field of grass,the grass at the far end should not simple vanish, but fade from 100% opaque to 0% over a short distance. But currently you can only have a alpha-test, which determines if the pixel is visible, or not, there is no "make it half transparent".

[SteveL]

Otherwise I'll try adding a material stage keyword for the time being so I can test it.

ignoreDepth is working! Baby steps I know, but my first openGL tweak

[Tels]

ignoreDepth is working! Baby steps I know, but my first openGL tweak

 

Hurrah!

[revelator]

Nice one that gets rid of the hack in sikkmod then, instead of doing a pushback on it in the game dll, me like .

[revelator]

Not related but i finally completed work on my new Msys2 based compiler suite for MinGW64.

 

Might be nice for those people here switching between coding for linux and windows to use some known posix tools

 

64 bit Msys2 based version here https://sourceforge.net/projects/cbadvanced/files/CB%20Msys2%20version/x64/installer/

32 bit Msys based version here https://sourceforge.net/projects/cbadvanced/files/CB%20Msys2%20version/x86/installer/

 

Msys2 is based on Cygwin like the old one but this one is synced to to the latest Cygwin version, the difference is that this creates pure windows code without relying on the Posix dll like Cygwin eg. (cygwin1.dll) The msys2 version is named Msys-2.0.dll though.

 

The suites are packed with lots of tools and support libraries like boost and intel threading building blocks, besides a ton of image libraries GTK and QT OpenAL several other Sound libraries and decoders / encoders and the latest gcc and binutils versions 4.9.1 and 2.24. My gcc builds also default to linking statically with the gcc runtimes but if prefered you can still link to the dll versions.

If you want to link to the dynamic versions be aware that this gcc is patched to allow throwing exceptions from the static libraries so if thats you'r reason its not needed .

The installers autopatch QT to the path they are installed in so QT works right out of the box.

I also included the basic postgresql console tools and a batch file for creating the default database.

Just type postgresql in the windows shell tab or cygstart postgresql in the Msys2 shell, and it will initialize and start the default database. For more advanced work its easier to get the free pgadmin III frontend.

The batch files for the compilers can be modified by removing the rem on 2 lines to support native windows symlinks and or use qtcreators gdb frontend for debugging.

Theres a modified CodeBlocks IDE included that supports my compilers, it needs updating (made it some years ago) but it works fine most of the time.

 

Hope someone finds them usefull

[nbohr1more]

A web-based GLSL shader editor:

 

http://shdr.bkcore.com/

 

source:

 

https://github.com/BKcore/Shdr

[SteveL]

That's rather cool. It doesn't work properly on my mobile but I'll give it a try on the pc later. I'm struggling with my particle shaders right now, getting some unexplained stuff on screen, but I'll carry on plugging away. Also I'm having trouble testing whether my depth capture is working. I spent yesterday evening trying to write the generated texture as a tga file but either the capture or the export isn't working. Not sure which yet. I need to think up some debugging methods that'll tell me which it is.

[motorsep]

I would be nice to have Cg shader editor

[revelator]

Hmm found this while searching but im not sure its for windows.

 

http://forum.unity3d.com/threads/shader-forge-a-visual-node-based-shader-editor.191595/

 

I do have a GLSL editor though, no not rendermonkey ill see if i can dig it up on my overfilled harddrives.

[revelator]

Hmm and as for exporting the depthmap textures, might have to write some code for that, maybe take hints from the SaveTga function ? maybe we can use it without even writing a new function, ill see what i can do.