-
Posts
3201 -
Joined
-
Last visited
-
Days Won
109
Posts posted by peter_spy
-
-
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.
-
Btw. Justin Marshall (aka icecoldduke), ex-id engine programmer, started a wiki for OG idtech4/5 engines, and he included a style guide there. Not sure whether this was used at id, but it might be useful.
-
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?
-
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.
-
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.
- 1
-
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.
-
IMO it's better to create test maps for such cases, who knows how AAS and monsterclip layout looks like in this mission.
Also, it might be a subjective question of how picky you are. I wouldn't mind that guard going in a general direction of where the damage came from; it kinda looks like he assumed the attacker has already changed his position, which is not a bad idea itself
-
I'd say "writeFloat" method that returns void is bigger cringe here.
-
It's amazing people still make those, and this one is really good. Also, probably the most British point & click adventure game as of late.
- 2
-
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.
- 3
-
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
-
It's an asset flip, the same face, nose, lips, even marks around the eyes, just the different hair
I played the game ages ago and recognised her immediately, so others will too. Just remove it, it's cringe.
-
FWIW, I loaded up your FM and I only had that abrupt sound at the mission start. Both transitions to other areas and loading saves from them worked fine for me.
-
That reminds me, has Heather from Silent Hill 3 (female head) been finally removed?
Edit: lol, nope:
- 1
-
-
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:
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:
While the chamfered cube has enough geometry to work with fresnel shader, even if I change texture coordinates:
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.
- 2
- 1
-
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:
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.
- 2
-
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...
-
On a slightly related note, why ambientrimcolor material keyword was removed in 2.11? Notes show that it was "unused" – was it even advertised to mappers and content creators?
-
TBH, games from last two decades conditioned me to accept static mirrors and vampire player characters so much, that I don't even notice that anymore while playing
- 1
- 3
-
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.
-
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 concavesurfaces, not just straight flat polygons? That would open up possibilities for very nice material effects (if used with moderation ).- 4
-
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:
- 3
-
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.
- 2
On code style
in The Dark Mod
Posted
Nothing that can't be resolved with proper doc comments.