Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Last visited

Posts posted by HeresJonny

  1. Here was my workaround:


    Basically, set it up as a windowed app sized to your native resolution and then tell your window manager to make it borderless.  I would expect this to work on Wayland as well, unless there's another issue preventing it from running even in windowed mode there.

    I started working on modernizing the fullscreen code but have been busy with real work lately.  Since we have a workaround I wasn't going to push for a change in 2.08 and instead was planning to take the time to make sure the reworked code works out-of-the-box in both Wayland and X.


    • Like 2

  2. On 5/9/2020 at 3:17 AM, duzenko said:

    Feel free to remove screen resolution change code COMPLETELY and just maximize the window. That's what happens on Windows since a few years ago.

    The engine now renders 3D in offscreen framebuffer and its dimension is controlled via render scale GUI option.

    I'm sure the less legacy burden we need to carry on Linux, the better for everyone.

    Nice!  I never paid much attention to the render scale option, I assumed it was just something for DPI scaling.  We'll still have to grab the screen resolution at startup but everything else should be simplified after that.  I'll look at the Windows code for comparison of the logical results. 

    Taking care of this should lead to a better first impression and overall experience on Linux.

    • Like 1

  3. It was easy enough to find the relevant code so I took a first look at this.  Here's what I found:

    • On Windows, there's a function to get the current desktop screen resolution and use it on first run. 
    • On other platforms that function is a no-op and you end up with an 800x600 resolution by default.  Without going into details, this function is called too early in the startup process for it to work on Linux.  I've got 2 possible ways to work around this that I'm trying out.
    • The current mode-setting code for choosing a resolution uses the original, old-school X API calls.  These aren't very multi-monitor friendly and librandr has superseded these calls for quite some time now.  Since the platform-specific windowing code is really self-contained, I don't think it will be too hard for me to swap it out and see if things improve.
    • The same area of the code already sets some X Window hints, I believe I could tack on a few more here to create a borderless mode equivalent as I previously described without much additional effort.  It seems like this is more or less what several other fullscreen applications do on Linux too.


    • Thanks 1

  4. On 5/4/2020 at 9:50 PM, imaginaryboy said:

    When I start it, it forces my external display to mirror my laptop display, then displays the game on both monitors, with one somewhat distorted due to it having the wrong aspect ratio.  Even after the quitting the game, it leaves the display setting to display the same image on both screens, which I have to fix manually. 

    I've actually got the same situation with dual-monitors on my Linux desktop.  I was recently reminded that this happens out-of-the-box by wiping settings for the 2.08 beta (where it does still happen).

    The workaround I've always used is to run it windowed at the full resolution of my monitor.  Then (in KDE at least, I'm sure others have similar settings), apply window- or application-specific properties to select a monitor, remove the window border, and disable compositing.  This also has the benefit of letting you access your other monitor whenever you open the in-game console.

    I believe there are some window manager hints that we could set to automatically achieve this, this sounds about like the Linux equivalent of "borderless" mode anyways. 

    I don't think the poor experience is a driver-specific issue, just the fact that multi-monitors in linux has always been a pain, and also changing the resolution on the fly tends to ruin your desktop even if the program is nice enough to change it back for you afterwards.  It might also be better to detect the current resolution on first run and use it by default instead of resizing to whatever the current default value is.  I think forcefully changing resolutions like that was more acceptable back when Doom 3 came out than it is now.

    As far as X vs Wayland goes, fullscreen is one of the areas where native X vs the XWayland compatibility layer may not work identically.  I'd expect XWayland to disallow some of the more invasive screen resolution changes, but I haven't really played with it to know for sure.

    For reference, here are my relevant specs:

    • OS: Arch Linux
    • Graphics driver: AMDGPU
    • Desktop: KDE (plasma5) using Xorg

    I could do a little research and see if there are any modern guidelines/best practices for fullscreen on Linux and at least make some recommendations.  If I get enough free time I might be able to look at the code as well.

    • Like 1

  5. Here's an alternative approach:


    The difference here is that instead of generating a cubemap, you have a single texture with the front wall in the center and the sides/ceiling/floor in perspective:


    I feel like this will be easier for a mapper to make, either in-game or from an external source.  For this one I took a 1024x1024 envshot from roughly where the window would sit (I didn't try to be too precise), and kept only the _forward texture.  I brought that into Gimp and scaled it so that the front wall was a centered 256x256 square in the middle of the 512x512 texture (use the same ratio at any size).  It doesn't matter if you end up with overhang on the edges of the image that get cropped off, but conversely you don't want to end up with empty space. 

    The new shader will follow the same pattern of perspective and slide around the UVs according to your position.  My problem at the moment is that it only works if you're facing one direction.  I'm not sure what coordinate space all the incoming parameters are in and how to transform them into a space relative to each face.  Can someone help out here?  I think the fragment shader is correct and the vertex shader is wrong.  Once that works, I think we could add back in the room scaling parameters too.

    For reference, I tried to follow the approach here: https://github.com/OBKF/Fake-Interior-Shader-for-GodotEngine. I took out the reflect() in the vertex shader because it was messing things up and that's where I think there's a clash in coordinate spaces or I was failing to normalize things properly.

    For those casually curious what this looks like, the github link has a sample video of this in Godot, you can see his input textures and the ability to scale the depth.


    • Like 1

  6. 12 hours ago, NeonsStyle said:

    Is there a reason why you all seem to be able to view this, and I cannot on 2.07?

    There is a major shader overhaul in 2.08, so shaders written for one won't be compatible with the other.


    22 hours ago, NeonsStyle said:

    I"m guessing this is a 2.08 thing. I can't use that atm while I'm working on a level.

    You could copy out a segment of your existing map into a new one for trying this out in 2.08 without messing up the work you've done.  And once this feature gets settled and 2.08 is out you could update your full map accordingly.

  7. 20 hours ago, stgatilov said:

    Meanwhile, I have a question to everyone who wants to use interior mapping: Why can't you just make a real cubicle for every room?

    1. Because I'm a programmer and I'll go to any length working on cool things that help me avoid tedious/repetitive work! 😀
    2. A case could be made that once you've built up a handful of cubemaps, placing prefab windows with this material becomes a piece of cake.
    3. Relative to a plane with an interior map, a physical cubicle clutters up the map and is a lot harder to move around once you make it.  Although, realistically this is something you'd do as a final detail pass after your map's layout and major details are all totally done.
    4. There was some interest in trying this in conjunction with a visportal that you close from a distance and display an interior map impostor at the same location.  This might be hard to get lined up correctly.

    Honestly though, you're probably right.  The real work is in making the cubemap and having to make actual room geometry as well shouldn't be a deal-breaker in terms of mapper effort or performance.

    That said...

    20 hours ago, stgatilov said:

    Support additional layers inside rooms. Basically, that would allow mapper to add alpha-textured planes inside the room, parallel to the back wall. Such planes can contain various objects like tables or cupboards. They will be flat of course, but will look closer than the back wall when player moves.

    Maybe you could repurpose the side of the cubemap that you never see as the alpha plane and use the 4th value of the vertexParm to choose its depth within the room.  Also, I tried your example and the room is currently tipped on its side... nice work though!


    And maybe a better compromise on mapper effort and complexity would be to use a single parallax plane instead of the whole cubemapped room.  It won't look as believable when you get up close, but you could also have it fade to the window texture or something else to simulate fresnel at a sharp viewing angle where the effect breaks down.



  8. 9 hours ago, stgatilov said:

    Allow writing custom GLSL but warn that they can get broken during future engine updates

    I'm fine with this, with a couple conditions:

    • We make a reasonable attempt not to break things in an update without a good reason
    • Breaking changes get documented in the beta release notes so fixes can get applied before the final release

    If this is going to be officially "blessed" we'll want a wiki page detailing how to use it.  I can probably help out with that if needed.

    • Like 1

  9. 11 hours ago, NeonsStyle said:

    Can I ask one thing. When you get it worked out, can you share please. :) 

    Yes, of course!

    11 hours ago, NeonsStyle said:

    [Edit] When I load this map up, it's not working like it does in the video. It's just a 2D glass window

    with nothing behind it.  Am I doing something wrong???

    Are you using the 2.08 beta?  I didn't try 2.07 but I'm 99% sure it won't work there.

    11 hours ago, NeonsStyle said:

    Question. The video, and the Interior Mapping, isn't that just a cubemap though?

    A standard cubemap moves with you, you can never get up close to the side and see the perspective shift.  I'm going to try and get this to run off of a standard cubemap texture, but you can create each side (wall/ceiling/floor) manually if you wanted/needed to.  Unlike a standard cubemap, the borders between each image don't need to be seamless.


  10. 59 minutes ago, duzenko said:

    Your GLSL math look complicated

    What I'd want to start with, is somehow pass the room size/location

    Can you do that via e.g. the texture matrix?

    It was just a straight port of the original CG shader from the link in the OP, I'm sure there are things I could optimize (one part is specifically there to work around the lack of an if statement).  I'm going to pass in the room size with a vertexParm, and I'm hoping to base the location off the actual object location in order to avoid the room tiling at inopportune locations.

  11. 25 minutes ago, duzenko said:

    you can add `forceHighQuality\uncompressed\highquality` after slot number to force RGB format, that should workaround it

    I did see that overwrote the TD_BUMP flag and was going to try it.  I don't know if I'd want to rely on such a hack, though, since a code change could break it without warning.

    25 minutes ago, duzenko said:

    you can add `cubeMap` to load all 6 sides into a single texture slot and sample it easily in the shader

    That's the main optimization I was going to play with, so thanks for the additional information around that.  As you noted, the fun part is figuring out new math to sample from the cubemap instead.

  12. 4 hours ago, duzenko said:

    Hopefully will look later this week. If not. ping me in PM on week end.

    I did some code spelunking and found this in idMaterial::ParseFragmentMap:

        // unit 1 is the normal map.. make sure it gets flagged as the proper depth
        if ( unit == 1 ) {
            td = TD_BUMP;

    So I'll just figure out the best way to avoid that slot.

  13. I made a few tweaks and fixes, here's a better demo of what this does:


    I've also got the map for download if anyone wants to play with it (probably 2.08 beta only!):


    To load it from the console, the map name is "im".

    I also left the room where I took the envshot in the map.  It's a bit tricky to line it up right yourself, to take one you can move the playerstart on top of the nodraw pedestal in the room.  The light in the room has specular turned off, since that's based on your position it will look incorrect otherwise.


    @duzenko I've found a really weird issue, if you look at my material file you'll notice I have two materials: textures/interior_map and textures/interior_map_wtf_green.  If you replace the regular one with the wtf_green one, the texture in fragmentMap 1 takes on a greenish tint.  My workaround was to put a texture I don't use into that slot and move the one I wanted to slot 5 instead. If you do a diff on the shaders you'll see that's the only change.  If you put the same texture into 1 and 5, both turn greenish so I think whatever goes into that slot gets corrupted somehow.  And even if you use the same texture on a totally different material it still goes green!


    • Like 2

  14. Something a bit like this, perhaps?


    Translating the shader over into a proof-of-concept wasn't bad at all.  Here's what we'd have to figure out:

    • How to get this in-game.  At the moment I'm using the techniques from this thread:It's only running properly with the special build from there.  If custom shaders are going to remain a more experimental thing in 2.08, this might become something to spend some time and make well-rounded enough for general inclusion in the following release.
    • What is the best way to supply textures to the shader.  It would be neat if a mapper could build some rooms and take envshots of them, and use those as an input.  We could get fancy and randomize which walls to use within a room, or get even fancier and have detail layers on top of the walls.  Also have a mid-plane with alpha cut-outs for more depth...
    • How to set the size of the rooms.  Right now it's hard-coded, and the repeating nature works better for skyscrapers than strewn-about buildings.  You wouldn't want a wall running down the middle of your window, so we'll have to work around that.
    • What do to about lighting.  I'm drawing the shader itself full-bright as lights shining on its surface would ruin the effect.  That's unavoidable, the question is how to achieve lighting within the fake rooms.  The original code simulates a light within each room (which I didn't port over), but I'm leaning towards keeping it simple and relying on the envshots having pre-baked lighting in them.  I haven't thought through the implications either way when it comes to normal/specular maps.
    • How to put a window in front of this.  Should we leave it as-is and rely on the mapper to put a transparent material in front with their desired effect?  I'm leaning towards that in order to keep things flexible, but I haven't tried it yet.

    I'm fairly busy the rest of the week but I think this is really cool and plan to keep working on it.  I'd welcome any input from others with more experience.


    • Like 3

  15. I had an idea for a plague-related FM a couple years ago, I built out some bits and pieces but never saw it through.  I've tinkered with a couple other random things since then but I've never developed a full FM from beginning to end before, maybe this would be a good excuse for me to try!

    • Like 3

  16. 4 hours ago, duzenko said:

    I hope you don't want your material to interact with lights. It's possible with blend modulate but I advise against using it due to massive performance cost of multi-pass rendering

    That's exactly the result I was looking for, blend modulate did it:



    Too bad it can't be done without killing performance, it would be interesting if a custom shader could be plugged in at an earlier stage.  I assume the vertex color blending support doesn't have the same performance issue, because its functionality is in a pre-defined shader that's called in the correct place?

    Looks like there's a fair amount of interesting stuff buried in some of the old threads here, thanks for pointing those out.

    I guess I just answered this question from 2015 🙂

    Anyways, it's not that important to me, I was just playing around to see what was possible.  I'd be happy to help out where I can, though, if any work happens in this sort of direction.



  17. I updated the shader to match the others and also stripped this down to the bare minimum, still getting the same result using your build.  Using the following shaders/material,  "blend blend" will display a solid color, but switching to "blend diffusemap" yields black instead.


    #version 140
    #pragma tdm_include "tdm_transform.glsl"
    in vec4 attr_TexCoord;
    void main() {
    	gl_Position = tdm_transform(attr_Position);


    #version 140
    void main() {
    	gl_FragColor = vec4(0.8, 0.4, 0.2, 1.0);


    	qer_editorimage textures/splatmap
        	//blend blend
    		blend diffusemap
    		program	splat


  18. On 8/19/2019 at 1:12 PM, VanishedOne said:

    How did this (the material stage GLSL support) turn out? I see it made it into 2.07 but I don't remember any fanfare for the new feature. (Hence also no documentation I know of, though glsl.h seems to provide clues about available uniforms.) Is it considered available for mapper use, or is it unstable?

    It sounded like this made it into the 2.07 release, which I am using.  I tried your latest build and indeed nothing shows up at all.  I'll grab the svn version so I can look into the new uniform names...

  19. 1 hour ago, duzenko said:

    Can you upload a test map?

    Also, I can only see one stage in your material

    Here's the test map I've been using.  I meant to say it works using a later blend stage, not an additional blend stage.  In splat.mtr, you can swap out the commented blend line to see what is happening.


    I tried adding the "translucent" keyword, and this makes the material disappear entirely.


  20. I decided to play around with using a custom GLSL shader just for fun.  I put together a splatmap shader that uses a simulated texture height for better blending, it worked surprisingly well:



    Unfortunately, there is one problem.  I can only get it to show up using an additional blend stage in my material:

    	qer_editorimage textures/splatmap
    		blend blend
    		program	splat
    		fragmentMap		0		textures/splatmap
    		fragmentMap		1		textures/darkmod/nature/grass/short_dry_grass
    		fragmentMap		2		textures/darkmod/nature/dirt/dry_earth_stones
    		fragmentMap		3		textures/darkmod/nature/dirt/sand_purplish

    I want to use this as the diffuse map so it can get lit properly, but when I change to "blend diffusemap" the material goes black.

    I know the custom GLSL feature was basically experimental, but should this scenario work?




    • Like 1
  • Create New...