Search the Community

This was discussed briefly on Discord some time ago, I wanted to bring it up here as well for consistency. I don't believe it's an emergency but do consider it an important change especially later down the road, as Linux is slowly moving away from x11 with many distros already going full Wayland by default. In my case I'm pretty much waiting for KDE Plasma to fix a few bugs left with the DE before permanently switching from X11 to wayland too, I might be able to make use of it rather soon if they do. With the new input and rendering system introduced after 2.09 and available for testing in the dev builds (GLFW) we're on our way to having a Wayland compatible build of our engine. Meaning the engine is able to render natively to the WL pipeline, without having to go through the fake x11 server simulated by the Wayland session for compatibility with X exclusive apps. This not only offers proper compatibility for Wayland users, but may improve performance on various fronts which was one of the goals of the new rendering framework. From what I remember @cabalistic telling me, we can't have the same engine for both x11 and Wayland: It must be compiled against different system packages to produce one version or the other. For Linux users the installer may need to offer two engine binaries in this case, or an option to pick which version you'd like to install if that's better. Other than that I understand it should be able to produce in theory, as SDL2 and GLFW both offer Wayland compatible libraries to compile the engine against. I'm not familiar with the C++ code in the slightest so I'll let the experienced developers complete this with the proper technical additions.

https://www.youtube.com/user/keeroyz/videos Two Minute Papers is an excellent YouTube channel that reports on many science articles related to machine learning and cutting-edge computer graphics techniques. The graphics-related videos have obvious relevance to the TDM community. And then there's fun stuff like these: One common refrain from the guy who runs the channel, Károly Zsolnai-Fehér, is that the pace of this type of research is so fast that you can expect a particular ML/graphics technique to be obsolete within months. Just imagine what "deep fakes" will look like in 2028 after years of algorithmic and hardware improvements. We'll probably see completely synthesized videos that look genuine at first and second glance... rendered in real time. Trust No One.

https://bugs.thedarkmod.com/view.php?id=5068 Sometimes, when going underwater, the shader responsible for blurring the view will shrink the image to roughly 1/4 of the screen (1/2 both horizontally and vertically) and position it in the lower-left corner, while leaving a jumble of textures to display in the background. This only seems to happen on rare occasions; My latest test suggest it occurs if the player has taken any damage and the health bar is showing up on the HUD. I'm running TDM 2.07 x64 on Linux (openSUSE Tumbleweed) with the free video drivers (amdgpu).

As most players will surely agree, one of the things that make TDM great are its visual capabilities, which come from idTech 4 having been so well designed. As I've been playing more with rendering and game engines during the last period, I realized this is something worth bringing up in the graphics department. I dare suggest it since frankly, TDM has some of the best graphics in the world of open-source games today... the idea of adding a common effect that would rocket its visual quality even higher sounds acceptable enough to post about. Typically there are two light occlusion effects, though I can imagine them combined in one by a smart renderer: Ambient Occlusion to simulate darkening in tight spaces, and Global Illumination to simulate light reflecting off surfaces. They're often costly to calculate for realtime lights, but there are engines that do it right... Tesseract (FPS based on Cube 2) offers a great example of doing FPS-cheap GI! A more serious problem specific to TDM is that this would affect the brightness of areas, and in turn the gameplay on existing maps... it would need to be an user option for this reason. I'm mostly curious on the opinions of the devs; Could at least SSAO be considered at some point, if not an implementation for radiosity? Some examples of why this is so awesome.

Hello. Sometimes when I jump in the water, 3/4 of the screen is "captured" in a freeze frame while the lower left 1/4 continues to show what's actually happening to me. This seems to have an approx. 50/50 chance of happening every time I dive into the drink. I am not quite sure what is causing it. I have attached a summary of my system specs and graphics hardware to this post. I am using the latest TDM version (2.07). GFX Info.pdf System Info.pdf

I hope this isn't a useless thread, just thought it would be constructive to let everyone know about it. I was looking up some TDM related concerns, and accidentally stumbled across another fork of the idTech4 engine. It's called fhDOOM, and it seems to have a lot of neat graphical improvements over the stock engine. eXistence/fhDOOM There are definitely things in there that TDM could consider grabbing! Some important ones highlighted on their front page: Modern renderer based on OpenGL 3.3 core profile. Any up-to-date engine should have this as a norm.Parallax mapping. Not sure if we have this already... I only know the original engine had simple bump mapping.Soft shadows. A heavily desired and long awaited feature.Alpha textures affecting shadows. This allows light to shine through textured grates, which is a very beautiful improvement.Soft particles. This one we already have now however.An example of the old lighting system (ours) versus lighting with shadow mapping (fhDOOM): As the obstacle to new features is almost always finding someone willing to code them, discovering those improvements for our engine is a goldmine... since unless they conflict with any of our changes, I assume they should be easy to just plug into the code. Can any of this good stuff please be considered for inclusion in TDM's version of the engine?

For mysterious reasons, anti-aliasing never worked for me in TDM. Since I hate it when edges make the pixels of my screen stand out, I would like to change this! The menu option is enabled, and r_multiSamples is saved at the value of 4. I have an ATI Radeon 6870 card, and the free video driver for Linux (MESA 11.0.5). FSAA works in most games although there are exceptions, while MESA is configured to do what the application says in this regard.