Jump to content
The Dark Mod Forums

peter_spy

Member
  • Posts

    3201
  • Joined

  • Last visited

  • Days Won

    109

Posts posted by peter_spy

  1.  

    7 hours ago, thebigh said:

    Although consistency is nice, if it's a choice between clarity and consistency I choose clarity.

     

    Not sure why you think these are mutually exclusive. Good coding standards strive for clarity as well.

  2. IMO it's one of these cases again, where you try to solve asset-level problem by making changes on the engine level. What I'm interested the most though: let's say I have custom candle assets / entities in my WIP that work like in Thief 3 (first frob extinguishes candles, second one picks them up). Will these changes break it?

  3. Just now, HMart said:

    I also hardly always follow programing "rules"

    They are there for a reason though, not just because someone said so. If you want to communicate with people and you work on the code with someone, you need to share some common principles. And while I agree that things like clean code can be a bit extreme at times, I've never seen anyone questioning it super hard; neither stuff like solid principles, for example. Obviously, you can be a rebel if you want to, but you'll probably end up working alone.

  4. 1 hour ago, OrbWeaver said:

    What value should a setter return? The same value it was given as a parameter? That's entirely pointless because the calling code already has that value. It could return the previous value, but such a value isn't necessarily defined (and doesn't appear to be relevant in the case of writing something to a file).

    Sometimes setters return the object itself, so you can call them in a chain

    Ah, you're right, it can be more language-specific or even project-specific. We often used setters that returned this, so we could use method chaining, but this isn't a general rule.

    • Like 1
  5. It seems to me like this is ignoring basic naming conventions in programming, stuff I was taught during my first days of work. If a method gets or sets a value of a certain type, it returns that value type. On the similar principle, all methods that return boolean always start with isSomethingSomething, etc.

  6. 57 minutes ago, Skaruts said:

    It very much is. I've been goofing around in DR for a decade, on and off, and about two years ago I said to myself "that's it, I'm gonna actually make a mission for once". (And then about a year ago I started making this one.)

    Thank you for sharing this. People need to hear more stories like that, since designing stealth levels is probably one of the hardest things to do, and it's easy to get burned out and drop it.

    • Like 3
  7. I've never been into deck building games, but this one is excellent. Fairly complex, but unfolding slowly, and super addictive. The "just one more go" syndrome is strong with this one :D

     

  8. It's an asset flip, the same face, nose, lips, even marks around the eyes, just the different hair :D

    https://duckduckgo.com/?t=ffab&q=heather+from+silent+hill+3&iax=images&ia=images&iai=https%3A%2F%2Fi.pinimg.com%2Foriginals%2F0f%2F20%2Fcd%2F0f20cdfccec60eab127aff236c63b3de.jpg

    I played the game ages ago and recognised her immediately, so others will too. Just remove it, it's cringe.

  9. 1 hour ago, STiFU said:

    Shouldn't the behaviour of the Rim shader be independet of actual geometric complexity and normal map based complexity? If the answer is yes, then brushes should also look fine because the applied material provides geometric complexity.

    IIUC, fresnel uses view direction and surface normal vectors. This is a comparison between simple brush cube and one with chamfered edges on geometry, both using the same tiling material:

    image.png

    Brush cube is on the right; in the background you see a cube with chamfered edges. There is a thin line on the bottom of the brush cube, because it matches the normalmap, the mortar part of the bricks. But as soon as I change texture coordinates of the brush:

    image.png

    While the chamfered cube has enough geometry to work with fresnel shader, even if I change texture coordinates:

    image.png

    So it seems to work as described, it needs either geometry normals or details faked on normalmap. I think fresnel in other pre-pbr engines, like UE3, works the same or similar way.

    • Like 2
    • Thanks 1
  10. I think you mean Reshade. I used it a couple of times, it has a few interesting tricks up its sleeve :)

    Also, maybe this will help to illustrate the problem better:

    Fresnel-differences.jpg

    As you can see with image 2 & 4, the geometric complexity, whether with actual polygons or faked via smooth edges on normalmap, does matter. And I bet when most users think 'fresnel', they mean the last example.

    Most TDM geometry is brushes and models textured with simple tiling materials. They won't look like the last example, until they have enough polygons.

    • Like 2
  11. Btw. you know that fresnel on brushes and simple models that use tiled materials looks differently than e.g. models with higher geo density, or smooth edges faked on normalmaps? Might be hard to adjust it for all cases. Unless you meant the PBR-compatible calculations, I guess...

  12. Thanks for such detailed info!

    12 minutes ago, stgatilov said:

    I'm not sure what exactly you want. If you want the mirrored view to be distorted by normal map, then yes: this is definitely not supported. The reflected texture is generated as if reflected by a perfect plane. Maybe we can add some kind of warp shader that deforms the image mathematically according to the normalmap, but this would be a new feature.

    I'm not sure if adding that warp shader is worth the hassle then, the current state seems like a feature, not a bug :) Personally I'm pretty happy with what I can do with a cubemap, and IMO that should be the way to go in most cases.

  13. On 1/8/2024 at 4:16 PM, stgatilov said:

    There are some issues, but in general it seems to work fine.
    Of course the performance on such scenes is abysmal.

    Since you're working on this, have you tried restoring the original functionality, i.e. ability to set up a resolution for these? That might help with performance.

    Also, when I was working with mirrors, I noticed that they disable normalmaps in the material. See how a cubemap version has those damaged surface details on the mirror surface, while real-time mirror bypasses all that.

    Last but not least, have you tried making mirrors work on convex or concave surfaces, not just straight flat polygons? That would open up possibilities for very nice material effects (if used with moderation :D).

    • Like 4
  14. 11 hours ago, Wellingtoncrab said:

    Are we supposed to pretend the original games are not a huge reason why most of us are here at all?

    TL;DR version:

    I don't think it was original T1/2 as much as the disappointment with Deadly Shadows and its shortcomings when it comes to levels, editing tools, and movement model. And since we're onto meme territory:

    8d5okl.jpg.f980dfdd7ac1be48507050cfc073a2a0.jpg

    ;)

    • Haha 3
  15. I did play Thief and FMs, but I don't play it any more, except for major things like Black Parade. The clunky movement and antiquated Dromed editor is what discouraged me from interacting with it over the years.

    I regularly play and sometimes make content for TDM, because it has much better movement model than Thief. I know that most missions don't use it well, but if you construct your geometry (gaps, ledges, distances) using power of two measurements, movement and mantling feels fast and snappy. There's no need for regression in that regard, in my opinion, there's a need for assets and missions made with the movement model in mind, to showcase its strengths properly.

    Even if TDM originally intended to "simulate the stealth gameplay of Thief, many things will be familiar to veteran Thief players" the actual mod history was a bit different. The team came up with a mission platform that has its own identity when it comes to mechanics. The way assets were made might have been a huge mistake, but that didn't prevent the platform from growing.

    Since you like anecdotal evidence, noone other Skacky once said that TDM movement model was super clunky, after playing The Painter's Wife. It was really hard to convince him that if a mapper places geometry this poorly, and isn't aware what spatial measurements play to the strengths of a movement model, no movement model will save his mission. And there is no fixing of this problem on the engine side, although it's not the first time when TDM team tries to address the asset problem with engine changes, which I suspect will ultimately lead to even more problems down the line.

    In game development, things like core mechanics and player tools are locked-down first, in one of the pre-production phases, because all the levels will be constructed around them. Making changes in core mechanics in a project this mature is very risky, I assume you don't plan on going through all playable spaces in all released TDM FMs to check for errors.

    Instead of making incremental changes in fundamental mechanics, I'd encourage you to create a fork, or some kind of major version bump candidate, like 3.0, where all things could be revamped: movement, player tools, UI, new frob mechanics, perhaps with UI contextual icons, new training map to incorporate all that, etc. Once all new elements fall into place and create something new, with a map or maps to back it up as relevant changes, it will be easier to convince existing player/author base that it was worth it. I assume the existing fanbase is already fragmented, as a result of all those heated discussions around the topic.

    But with multiple versions available for download, the transition to hypothetical "TDM 3.0" should be easier. It could be similar to UE2 and UE3, and you could also use this as an occasion to draw the line for backwards compatibility. I know there are old systems and variables kept in place just in order not to break existing missions. This way you could e.g. redo the LOD system, implement lights using math functions instead of textures, etc.

    • Like 2
×
×
  • Create New...