Jump to content
The Dark Mod Forums

HeresJonny

Member
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

20 Good

About HeresJonny

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Charlotte, NC

Recent Profile Visitors

93 profile views
  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.
×
×
  • Create New...