Search the Community

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

newer hurts to be careful though i havent noticed any misbehaviour from this filehoster , if there are then it is blocked by my router cause every online scanner i could throw at it says it is clean. still allways a good thing to be vigilant. one small hint for those that want to try and build the source, msvc 2003 .NET does work on win10 but it has a rather odd bug where the search function does not work. this is caused by win10's high dpi scaling so disable that in compatibility settings and also disable fullscreen optimizations and set it to run as admin, this will take care of the problems this old compiler has. the source uses the older dx9 sdk dxsdk_feb2006 which does not use source annotation but if you make a small hack using a dummy sal.h like in mingw-w64 you can actually build it using the latest dx9 sdk from june2010 instead, the binaries in the source are built using the latest sdk btw :). with some more work it could be ported to built with even the latest compilers but it would probably be easiest to do that using cmake scripts to recreate the build solutions for the compiler you wish to use. might even be possible to port it to use clang or gcc but i suspect that might take a good deal of work. on the other hand it could possibly help with a few of the problems like replacing the old dsound interface with openal and other stuff that win10 does not support fully anymore.

No problem. I guess most of our programmers don't do any gamedev on their daily jobs Knowledge of C++ language is more important, I would say. In general, it is not a good idea to span through text and try to optimize everything you don't like. Because most of the code should not be optimized: you will not improve performance in any way, but you can introduce errors, make it less readable, etc. It is better to use profiler to see which parts actually take time, then optimize them. Without profiler you cannot even be sure you make the code snippet faster (at least not slower). It is known that programmers are pretty bad at predicting low-level performance. Yes, compiler knows both arguments are compile-time constants, so it computes this value during compilation. While I have heard from many people that Java compiler can optimize code more aggressively because of high-level nature of the language, my experience shows that C++ compiler is much better at optimizing things. Compiler does not compute any of these values during runtime. It computes them during compilation and inserts final constants directly into the assembly code (as "immediate" values). You should get at least some knowledge about C, I would say. In C/C++, if you divide integer by integer, then no floating point numbers are involved at all. As @nbohr1more says, this whole file is not used in TDM. You can of course play with source if you like, but if you don't see a function in profiler, then all optimization efforts are useless (counter-productive, in fact). I'm not sure you will be able to get noticeable performance improvement this way. I think the toughest parts of our shaders are bound by memory access (e.g. texture fetch in soft shadows, or raw bandwidth in drawing shadow volumes). Due to massively parallel nature of GPU, it means that even if you make all computations 2 times faster, the actual performance won't change at all. At least that's my experience with soft shadows. There are a lot of computations there, but adding more will not worsen performance, because texture fetches are slower anyway. And given that fanatic optimization of computations often make them much harder to read and understand, it sounds counter-productive again...

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

now I get a different compiling error: CXX compiler/Surface.lo compiler/Surface.cpp: In member function 'bool map::Surface::rangeCheckIndexes()': compiler/Surface.cpp:47:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (indices[i] < 0 || indices[i] >= vertices.size()) ^ compiler/Surface.cpp: In member function 'void map::Surface::defineEdge(int, int, int)': compiler/Surface.cpp:228:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (silEdges[index].p2 != _numPlanes) ^ compiler/Surface.cpp: In member function 'void map::Surface::identifySilEdges(bool)': compiler/Surface.cpp:388:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (silEdges[i].p2 == _numPlanes) ^ compiler/Surface.cpp: In member function 'void map::Surface::duplicateMirroredVertexes()': compiler/Surface.cpp:440:59: error: 'memset' was not declared in this scope memset(tverts, 0, vertices.size() * sizeof(TangentVertex)); ^ compiler/Surface.cpp: In member function 'void map::Surface::createDupVerts()': compiler/Surface.cpp:529:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (remap[i] != i) ^ compiler/Surface.cpp: In member function 'void map::Surface::deriveTangents(std::vector<Plane3>&)': compiler/Surface.cpp:964:46: error: 'memset' was not declared in this scope memset(used, 0, vertices.size()*sizeof(bool)); ^ compiler/Surface.cpp:1011:48: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] unsigned long signBit = ( *(unsigned long *)&area ) & ( 1 << 31 ); // FIXME: portability? ^ compiler/Surface.cpp:1021:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] *(unsigned long *)&f ^= signBit; ^ compiler/Surface.cpp:1035:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] *(unsigned long *)&f ^= signBit; ^ Makefile:609: recipe for target 'compiler/Surface.lo' failed make[3]: *** [compiler/Surface.lo] Error 1 make[3]: Leaving directory '/usr/local/share/d3bfg/src/DarkRadiant/plugins/mapdoom3' Makefile:435: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/usr/local/share/d3bfg/src/DarkRadiant/plugins' Makefile:742: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/usr/local/share/d3bfg/src/DarkRadiant' Makefile:482: recipe for target 'all' failed make: *** [all] Error 2

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

Wow, this is impressive I think crash on shader compilation is like getting internal compiler error from ordinary C++ compiler. Except that GLSL compiler is embedded, so consequences for crashing are much worse. Luckily, the problem can be worked around by simply removing the manylight shader. I think the black screen issue will return back to you after that By the way, do you want to go into the quest of reporting the issue to AMD? I recall I did it with the bug that texture fetches in global variable initializers didn't work, and got response like "upgrade GLSL version". At least that was response from someone from AMD, as far as I understood. Maybe a crash will get more attention. Also, it is very easy to debug if you attach a full crash dump...

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

Manjaro seems to have gcc-12 so it's nice to know I compiled and tested with that. Wonder how much the compiler usually makes a difference in performance. Also curious how much running TDM on Wayland over X11 will help with any extra FPS (not expecting more). KDE / Plasma has been slow to become stable on WL but it seems in recent months they finally got there for the most part: If my drawing tablet is also detected by Gimp and power saving works and all, I plan to give it another try soon. IIRC the engine now uses SDL which should already be Wayland native so any potential improvements should be supported.

Yeah, I don't think it helps much either. Compiler can use more instructions, but it can rarely help... maybe BMI could make a difference. By the way, usually people write -march=native to compile for their CPU.

Recently I have learnt about new cool toy for analyzing build time in Visual Studio: C++ Build Insights Basically, MSVC build tools now generate events for various things, which allows to see timelines, aggregated information, etc. The events are based on Event Tracing for Windows, which is a relatively known framework among some very cool guys. Since I was thinking about picking up the DarkRadiant side again, I decided to give it a run on DR projects. To make timings easier to understand, I limited parallelism to 1 project and 6 compiler threads at a time (I have 6 physical cores). I built vcperf from sources (the latest tag on GitHub), because stock VC2019 build does not include information about templates, and that's the main problem usually. I used VC2019 to build Debug x64 build. I think release build does not matter much, since developer usually work with Debug and have to wait for it all the time. I'll try to explain the findings. Here is the overview of stuff: it explains how much time each part of compiler takes: In most cases, I will only look at "Exclusive Direction". Inclusive stuff is too bad because it takes common stuff into account many times when we sum up the values. CPU Time is a better metric in general, but most of low-granularity timings don't provide it --- and that's what we want to analyze. Besides, I have specifically ensured that there is one thread per physical core so CPU time and duration should be more or less the same. So, the whole build takes 986s. Out of it, C1DLL takes 785s. That is the frontend part of compiler, which most likely contains parsing C++ code and doing template instantiations. At least, an image in this article says that template instantiation is part of frontend. And otherwise numbers simply don't match. The backend takes something like 175s --- most of the other time. Clearly, the 80% of the time is spent in frontend, so let's given it a closer look. First of all, let's look at C++ code parsing: The whole parsing takes 172s. By filtering items containing some substring, I learned that: Parsing Eigen takes 31.5s Parsing Wx takes 32.6s Parsing MSVC standard headers takes 34.5s Parsing Windows SDK headers takes 24s Parsing w32deps includes except Eigen and Wx takes 11.4s Parsing all the rest takes 38.5s The number for Wx is OK, since it is very important for DR. Standard includes are also understandable --- that's STL and windows.h. But isn't Eigen excessive here? Note that parsing time can be reduced almost to zero by using precompiled headers properly. According to the stats I see, windows.h is parsed 63 times, which gives 33s in total. If it is always in PCH, than it would be parsed at most 19 times.... Anyway, parsing takes about 17% of total build, so it is hardly a real problem. Now we come to template instantiations --- the root of evil for slow C++ builds I computed sum of all Durations in this list, and got 605s --- this approximately matches 785s - 172s (frontend - parsing). And that's 60% of whole build time. Quite obviously, Eigen is the king here: all the most expensive instantiations come from Eigen. Here is breakdown: Eigen::* takes 461s std::* takes 122s All the rest takes 22s Unless someone decides to use boost, STL is usually the most offensive part of template bloat. However, Eigen manages to top it in 4x times. So the conclusion is: adding Eigen slowed down build in at least two times. If it was wxWidgets, it would be OK, since GUI is the most important part of DarkRadiant. But such cost for 4D vectors and matrices? Seriously?! Does it even offer any added value in DR? UPDATE: Given that backend most of the time generates machine code for the template instantiations, I bet the real slowdown can be even 2.5-3 times. If someone remembers when Eigen was integrated, it can be checked directly.

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

I believe @stgatilov was asking that you provide comparisons of the basics: 1) Hard Stencil beta vs svn 2) Hard Maps beta vs svn 3) Soft Stencil beta vs svn 4) Soft Maps beta vs svn That should triangulate the affected area. On review of the code change, in theory it "should" perform much better since the blur operations are done on the GPU (thus freeing the CPU for other work) but I guess there may be a pathological GPU pattern that looks good on paper but the hardware or compiler doesn't execute well.

2 years later... well my cleanup of jupiter has come to a grinding halt due to me not having enough knowledge about C++. While i got the engine building with msvc 2010 it was somewhat unstable and crashed a lot, even with numerous fixes by several people me included. what works so far is building it with msvc .NET 2003 sp1 against the directx 9 june 2010 sdk. yes the renderer actually uses d3d9 not d3d8 which the original NOLF2 engine used, but it used a very early versions of the sdk for Win9x so i had to make a few changes for it to build correctly with the much newer june version. I also rebuilt all the tools even the ones using borland compilers like crud.exe (originally used borland C++ 6.0 rebuilt with embarcadero C++ 2010) . to use msvc .NET 2003 sp1 on win10 you need a few things, a dummy sal.h header copied to the compiler include dir (needed for the newer directx sdk) sal is for source annotations but the old compiler did not have that nor is it supported so the macros in the dummy sal.h are just for show. the directx 9 june 2010 sdk. and lastly while not strictly nessesary you can use the Microsoft Platform SDK for Windows Server 2003 R2 with it (this adds the ability to do 64 bit builds though only from the command line). the structure of the jupiter sdk was changed a bit and several batch files have been written to ease building it. i would also advise adding the directx sdk includes and library dirs to msvc .NET 2003's vcvars32.bat. theres a demo.bat in the development\TO2 directory which will allow you to play the first lvl of NOLF2. ill pack it up later today after work.

To everyone who can compile from source: try rev 10211. Also, I would be glad if you actually compare the performance to that of 2.10. Even if this issue was the greatest one, there could be other reasons for slowdown. By the way, GLSL specification says that all function arguments must be copied. Although it is normal to expect from GLSL compiler to inline all function calls, then find def-use relations and not copy read-only data. Maybe AMD had to block this particular case for some reason... Also, I have launched Radeon GPU tools on TDM, and I like it a lot! Yeah, it has a bit of AMD roughness (most recent version crashes, I had to backtrack about 1 year into the past to find working version), but I like how open they are. They just write down all the information they measure, without trying to protect developer from information overload. So much stuff there... One interesting thing is that AMD profiling tool shows everything exclusively in Vulkan terms, nothing related to OpenGL. I wonder whether they merely represent internal driver routines in Vulkan terms, or they internally convert OpenGL into Vulkan completely. I've heard that Intel is converting OpenGL to Vulkan on recent drivers --- I guess that's the trend today.

It seems that when I pass vec2[150] to a function, AMD compiler honestly generates copying instructions Copying 1.2 KB of data on every fragment is quite slow...