Jump to content
The Dark Mod Forums

HeresJonny

Member
  • Content Count

    25
  • Joined

  • Last visited

Everything 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.
  2. 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.
  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.
  4. 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.
  5. Wow, didn't realize NC was a TDM hotbed! Not a native, but moved to Charlotte a few years ago.
  6. Should be an easy enough fix. Your .mtr file goes in testmission/materials, and your "goth_cab" on the first line should be "textures/darkmod/furniture/gothcab" instead. I'm not sure about the "\" vs using a "/" in the MATERIAL_NAME within your model, but I'd imagine that's ok.
  7. Here's an alternative approach: https://drive.google.com/open?id=1wHJGv1txRJrpcYnqR94BL3_kBRsVAn1n 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.
  8. There is a major shader overhaul in 2.08, so shaders written for one won't be compatible with the other. 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.
  9. Because I'm a programmer and I'll go to any length working on cool things that help me avoid tedious/repetitive work! 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. 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. 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... 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.
  10. 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.
  11. It's really easy to try the 2.08 beta if you want to, but I plan to keep posting progress videos to make it easy to see how it works.
  12. Yes, of course! Are you using the 2.08 beta? I didn't try 2.07 but I'm 99% sure it won't work there. 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.
  13. 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.
  14. 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. 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.
  15. 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.
  16. 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!): https://drive.google.com/file/d/1jrlVFd6AerWYHdBxyJJjVVPe0Q1sodY5/view 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!
  17. From a player's perspective, the difference is that a cubemap moves with you whereas this is fixed in place. I fixed it up to work in the 2.08 beta and I'm putting together a better demo now. I'll upload it shortly...
  18. 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.
  19. 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!
  20. 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.
  21. 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. splat.vs: #version 140 #pragma tdm_include "tdm_transform.glsl" INATTR_POSITION in vec4 attr_TexCoord; void main() { gl_Position = tdm_transform(attr_Position); } splat.fs: #version 140 void main() { gl_FragColor = vec4(0.8, 0.4, 0.2, 1.0); } splat.mtr: textures/splatmap { qer_editorimage textures/splatmap { //blend blend blend diffusemap program splat } }
  22. 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...
  23. 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. https://drive.google.com/file/d/1iHUUXFzGO9oAy5oRpjPKwlGs1YVLGuFG/view?usp=sharing I tried adding the "translucent" keyword, and this makes the material disappear entirely.
  24. 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: textures/splatmap { 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?
×
×
  • Create New...