Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Posts

    8629
  • Joined

  • Last visited

  • Days Won

    65

Everything posted by OrbWeaver

  1. Check nvidia-settings on Linux, it's possible that it has some kind of force V-sync option in there.
  2. My interpretation of what I saw, combined with the discussion in this thread, is that Bloom is amplifying a particular problem, spreading invalid colours across the screen in large boxes, but Bloom itself is not the cause of the original invalid values. The invalid colours disappeared when I switched color depth from 64 to 16. Assuming that "64 bit" means "double float" and "16 bit" means "integer", this would be consistent with the appearance of NaNs in some part of the rendering backend. Integer arithmetic does not have NaNs, which would explain why the problem went away.
  3. Adding an additional check in the shader for the GPU vendor is going to introduce a branch and a performance penalty of its own, which won't necessarily be any better than just doing the isnan check on all GPUs. I don't think there should be any vendor checks within the shader itself. If there are critical driver bugs that cannot be worked around in a standard-compliant way, it would be better to have separate shaders for each vendor and choose these once, at application startup. That way we could have shaders optimised for each GPU type without any additional branches.
  4. Inspiring alternative gameplay approaches is all well and good, but in my opinion it needs to go hand-in-hand with game mechanics to avoid an overwhelmingly frustrating experience. By far the most frequent reason for me reloading is not because I am detected or killed, but because of some unforgiving gameplay mechanic resulting in a loss of scarce resources. If I only have 6 water arrows and my attempt to put out a light fails because it's entirely non-obvious where I am supposed to aim the bow, I'm sure as hell not going to waste another shot — I will just reload and try again. Constantly reloading is indeed a very boring thing to do, but restricting the save/load mechanism doesn't solve the problem at all. Combining the restricted save system with more forgiving game mechanics (for example: you can put out a torch for free every 5 minutes, and only consume resources if you want to put out another one within the cooldown time) might make for more interesting gameplay rather than just adding more frustration and punishment for failures.
  5. It wouldn't make sense as a reason anyway: if somebody wants to steal TDM and upload it to Steam as their own game, they could do so right now using our open-source code and assets. Putting TDM itself on Steam does not increase the risk of that happening; in fact it arguably decreases it because Steam would already know about TDM and be less likely to accept a fake version of it uploaded by someone else.
  6. Not legally they can't. A lack of a license file doesn't mean "free for all", it means "all rights reserved". The only way for a game to become public domain is if it is explicitly released as such (or with an equivalent license like CC0). It may also become public domain some decades after the death of the copyright holder, but I don't imagine that is a situation which applies to many computer games at this point in time.
  7. Right. And legally speaking, there is no distinction between "technically violating the terms of the license" and "violating the terms of the license". Once you do that, you are at risk of being sued, or at least sent a bossy letter from a lawyer which will require you to retrospectively delete material from your already-released content pack in order to avoid being sued. Of course it's up to individuals to decide if they want to take that risk, but I would recommend not doing so to avoid potential headaches down the line. How can you be sure of this? Copyright does not depend on what the rest of us think the author really meant, it depends on what the license actually says. What it says in this case is "You may not redistribute these textures as part of another texture pack, even if you give it away for free". I don't see any obvious room for manoeuvre on this point, although perhaps a lawyer will correct me. Sure, somebody could certainly contact him and ask "Is it OK to redistribute some of your textures in a free texture pack, even though your license quite literally says that nobody can redistribute your textures in a free texture pack?", but I wouldn't hold out hope for a positive response.
  8. Yep, those definitions are clear. The license holder himself defines "competing product" to include "texture packs" and specifically mentions that the license terms make no distinction between selling the textures or giving them away for free. The only way this texture pack could be legally safe is if (1) it does not in fact include any textures from www.textures.com or other sites with restrictive licenses, or (2) it only includes textures from before those licensing terms were imposed (but proving that is difficult). As tempting as it may be, I wouldn't touch this with a ten foot pole.
  9. That's what we do in DR (although DR is not exactly an authority on the correct way to implement lighting shaders, particularly with regard to performance).
  10. Provided all of the sound files are either original or under a license compatible with the Creative Commons license used by the mod, there should be no copyright issues at all. It would only be a problem if the sounds were actually copied or extracted from another game, but it doesn't sound like this is what you did. To me they all sound excellent and I would be quite happy to see them added as the default sounds, although that's not my decision to make. The fact that you have achieved consistency between run/walk and jump is a major improvement on what we currently have, where the jump sound bears no resemblance to anything else. If they do ever get integrated, I hope you will be able to provide uncompressed original WAVs as well — the fact that many of our sounds only exist as compressed OGGs (even in the source repository) is a significant shortcoming which makes editing risky (it will introduce generation loss artifacts).
  11. You'd be better off setting them up as entities — that's what entities are for after all, creating interactable objects with whatever sub-models and entities/lights/emitters are needed to make them work. You could look at some of the existing entities (within the def virtual folder of the core assets) and use that as a template. Once you've done this, you can just right-click, Create Entity and choose your new lamp to place one in the mission. Another option is to export them as prefabs, which you can then import using DR's menu wherever you like. This is probably easier to set up than creating a custom entity, but it will be slightly heavier on the map file (because each prefab will have its own copy of the light+emitter combo, which all need to be saved into the .map file). However entities by themselves do not require massive amounts of data, so this is still a workable solution. That wasn't really the point of the comparison. TPW is one of the largest maps ever, and wasn't particularly well optimised at release (although its second version was considerably improved). The vast majority of maps are considerably smaller, especially first releases by new mappers which tend to be less ambitious than large team projects. Releasing something larger than TPW isn't necessarily broken and it doesn't mean that people won't play the mission. But if your map isn't actually designed to be huge (e.g. a massive outdoor city area with numerous playable houses), and it still results in a package which is much larger than the current largest mission(s), this does suggest that there is some problem which optimisation or data storage which might cause other issues when people try to play it.
  12. Making relatively low poly meshes in DR and exporting them into ASE/LWO models is fine, as Dragofer explains. Making fine detailed meshes with brushes and patches and copying them around repeatedly without ever exporting them as models is going to cause problems. If they are exported to models the geometry only needs to be stored once. If they are copied around, every single copy has its own set of brushes and patches, which is probably the reason Geegee has ended up with a .proc file four times the size of The Painters Wife. Fortunately, if this is the cause of the problem it should be easy to fix. Just find the duplicated models, and replace them with a single LWO or ASE func_static (exported from DR if this is how you want to make it), then make sure the original brushes and patches are deleted. You can then duplicate the func_static as much as you like without increasing the size of the map file.
  13. There's definitely something going wrong there. By contrast, The Painters Wife has a 56 MB .proc file and a 38 MB .map file — so your map is almost four times the size of the largest map ever released. TPW also has a 1141 MB models/ folder full of custom ASE files, so I would say the model sizes probably aren't the main problem (they should compress well). I would check your map carefully to make sure you don't have any embedded models converted into brushes — if all you did was convert the model then export to a new ASE/LWO file, this should not increase the size of the .proc file provided you didn't leave the brushwork in the map.
  14. Well, you probably don't have to throw away the whole map. Just re-think the approach to customising models, in order to avoid overly complex brush geometry. For example, you could stick with the stock models to begin with, and see if this reduces the excessive disk size and FPS problems, then start customising the ones you want (by repainting textures, creating skins, or editing the LWO models in your 3D app of choice) until you have a look you're happy with. It's quite possible my guesses are way off base, and customised models are not in fact the cause of the size and performance problems. But this is certainly consistent with what you have reported with regard to low FPS and a huge maps directory.
  15. How do you get 432 MB for just maps? Do you have a gigantic number of tiny brushes and patches or something? You don't need to include _ed textures in a released FM package. The normal maps can be compressed to RGTC DDS format (I believe there is support in the latest game version) which should save a bit of space. That might be the cause of the huge maps. It seems like a terribly inefficient way to create models to me. Brushes and patches are not designed to duplicate the fine detail of LWO models. The data will be huge, brushes do not have smooth shading, and the map compilation will probably run into problems (out of memory, missing triangles, etc). Sorry to say, I think you need to go back to the drawing board with this approach. You don't need to make copies of models just to change textures (you can use skins, or just override the material shader in your PK4), and if you do need to copy a model, converting it via DR brushes is absolutely the worst way to do so. DR's model export is designed for exporting simple brush and patch geometry into your 3D tool so you can create matching detailed models, it is not a model editing or conversion tool in itself. Even if you do persuade people to download a 1.7 GB map, I think people are going to run into huge problems with memory usage, crashes, low FPS, rendering problems and all the other consequences of trying to embed detailed LWO models as brushes in your map.
  16. I would like to see this too, but as I understand it the game doesn't support it very well, because it assumes that FMs and user settings can be saved into the main installation directory, rather than in a user-specific directory like ~/.config/darkmod.
  17. It still seems like an overreaction to me. As far as I can see CGTrader is a legitimate online marketplace, and your credit card is not at risk just because a single individual uploaded some models in violation of their license. If you order something from EBay which turns out to be junk, you might seek a refund through EBay but I can't imagine anyone would advise you to cancel your credit card. Nevertheless, you must do whatever you feel comfortable with.
  18. You are panicking unnecessarily, and have cancelled your credit card for nothing. That is a site which allows anyone to create an account and sell assets, much like Etsy or Ebay. The individual who uploaded those models does not own the site, and does not have access to your credit card details. The site charges your credit card and then sends the money to him, just like when you sell something on Ebay with PayPal. If you have evidence that somebody is selling stolen assets, there ought to be a way to contact the site and report them, although I can't see an obvious link from the main page.
  19. It sounds like the DR frustum is OK, but we already know that the preview light rendering is broken for projected lights. So some changes are definitely needed, but they may not be related to this recent work. I already tried a simple copy-paste of the game code to fix the rendering, but it didn't work. However that was right at the beginning when I had no idea what the X/Y/Z/W values were supposed to be doing in the matrix, so it was basically cargo cult programming. Now we have a better idea of the correct behaviour as well as more thorough unit tests, so perhaps a careful integration of the game code would be more successful.
  20. D'oh, I should have looked more carefully at the commit history. I'll make a branch off the 2.14.0 tag for the Linux DEB release, then resume debugging in master.
  21. Unfortunately my commit a64abd187518645fa300efaeff264982b9a16ac5 appears to have introduced a bug whereby rotated models gain additional rotations after you move them. I suspect (but haven't yet proved) that it is something to do with either double or missing invocations of some spawnarg-changed callback. @greeboFor the time being, it might make sense to make a new branch for 14.0.1, starting from a commit before this one (nothing afterwards is important — it's all just internal refactoring).
  22. The idea would be that every new XY window starts off as a floating dockable widget, which you could then drag into place according to the rules of the wxWidgets dockable UI. This allows you to dock windows to the edges of the main window (but not the center, which is considered a separate area and currently always filled with the initial XY view), or have them as separate floating windows which you can manage like any other. In theory this should be up to the window manager, however it looks like the current floating windows are not considered regular top-level windows, which means that in Linux I cannot drag them to the side and have them take up half the width like most windows. Possibly this could be fixed by setting the appropriate flag in wxWidgets, but I don't know if this would have other consequences like removing the always-on-top property.
  23. If I understand correctly, you want 2 main XY windows docked in the main window, and a 3rd XY window as a floating window on a separate monitor? I think this could be achieved if we make "New XY view" generate a Dockable window, rather than a free-floating window. This way you could dock it to one side or another (with the default XY window taking up the "center" position, which it always does), or leave it floating as you prefer.
  24. clamp does not appear anywhere in this light shader as far as I can see, so is not relevant here. If it did appear, its meaning would depend on whether it is a global material keyword or appears within the table declaration, as I believe the iddevnet documentation makes clear. zeroClamp means "guarantee 0,0,0,255 edge for projected textures" i.e. black with full alpha outside the texture boundaries. I assume this is needed to stop light textures from extending outside the light volume during rendering (if there was no clamping, the GPU might default to repeating the texture or extending the edge pixels indefinitely outwards). This might be something which has changed since the original Doom 3 implementation, since I recall some recent discussions about the clamping behaviour of projected light volumes.
  25. I guess that will be useful if you want to simulate a disco. I think you can safely get rid of the colored declaration, since I don't think it's doing anything if you set the RGB channels explicitly (I could be wrong though).
×
×
  • Create New...