Gildoran

No, that's not technically possible with stencil shadows. The stencil buffer is used to partition the screen in areas that are in light and areas that are in shadow. Stencil shadows are an efficient way of doing things, but they don't allow for "intensity" of shadows. Mappers can sometimes fake soft shadows a little bit with carefully designed light fall-offs and filter blend lights, but in general soft shadows will probably never be a part of TDM.

I generally think it should be a complete pain to kill people, but if somebody can do it despite all the consequences (screams, bloodstains, whatever), then let them. As for removing moss, I think it would be better to just frob it.

Yeah, that's the crux of the debate... Some people think that in the interests of gameplay, guards should merely comment on the moss. Other people think that it'd still be useful as a temporary tool to get you past a tricky area.

While I agree with you that it's generally a bandaid fix, there may be cases when it would be more useful to have an aspect ratio of 3:2 for example. Perhaps DR could warn if any of the source images (except the editor image) aren't powers of 2, but when setting texcoords, take into account the original dimensions of the editor image?

I don't know if anything is decided for sure yet, but we're thinking of adding info about locations, so that guards don't care about moss outside, but panic if it sprouts up in a bank vault. We were also debating about whether or not it should be possible for a Thief to clean it up. (if it causes a panic, then the thief probably should have a way of removing it) Even if the thief can remove moss, they probably won't be able to recycle it, to encourage them to strategically decide where to use it.

I'm not sure I'd recommend drawing a skybox by hand. It's difficult to draw them by hand without shattering the illusion of the skybox not being a cube. There is a program to help you draw skyboxes by hand without perspective problems but I can't remember what it's called. Another possibility would be to create a 3D mockup of the skybox, then paint on top of the mockup.

I can... usually photographed textures are noticeably lit from one direction - almost always from above. Most people don't seem to notice this when looking at the photo (hence why I suggest rotating photos 180 degrees). When it comes time to turn it into a D3 texture, photos with shadows screw with the lighting and make the texture look wrong. D3 is designed so that you can have beautiful 3D-looking textures if you do them right, but most photo-sourced textures are designed for older engines and work against D3 rather than with it. Don't get me wrong, when I "hand-paint" textures, I extensively use photos, but the diffusemaps are more like photo-collages than snapshots with tiling added.

Yeah, I've always thought "particles can't be lit" was a load of bull (thanks to D3 using a unified rendering system). Anyway, lit particles are how I constructed the volumetric lighting effect. I think the reason the smoke doesn't look as good is because the particles aren't rising fast enough, so it looks way too slanted. However, I advocate avoiding using smoke for anything of a persistent nature (eg, torches held by guards). Floating skulls may have been able to get away with it because there were only a few in existence at any one time, but if we have numerous fire-elementals or torch-holding guards roaming a map and they each have a smoke effect, it could slow down the map to a crawl.

I completely agree, but everybody seems to want to keep even the bad ones. Maybe I'll start a thread for textures that might not be worth keeping... If you provide an editor image, the editor bases the scale off of the editor image, so the source images can be powers of 2. However, D3ed will scale the editor image to a power of 2 before deciding how to apply the texcoords, so the net effect is as though all the images had been scaled to a power of 2. If DarkRadiant pays attention to the original scale of the editor image, that'd be useful. That's controlled by the image_roundDown cvar. It defaults to true, but perhaps quality settings affect it.

I don't think it has to do with bounds... what I'm saying is that normal particle systems don't keep track of the individual particles... You give it a time, variation and position, and from those three variables it will generate the current state for the entire particle system, figuring out which particles exist, and where. It doesn't pay any attention to where particles were the previous frame. Smoke systems are more like most engines' particle systems - a smoke system keeps track of where each particle is located and applies movement/etc to them each frame. This has the advantage that you can have smoke trails, but the disadvantage that in order to calculate the next frame, it needs to know about the previous one - so smoke systems need to be calculated each frame to be correct.

I'm not sure if I'm understanding you, but a normal particle system doesn't leave a trail, since it's parametric; when you move the origin, the whole particle system moves, as though each particle were bound to the origin. (you can even do things like rewind time by editing their shader-parms) In order to get trailing, you need to use a smoke system. However, smoke-systems are always calculated, so you only want to have a few on a map at the same time. In a game like D3, it's ok to use smoke systems for things like muzzle-smoke or perhaps flaming shrapnel, since they only have smoke for a short time, and that short time will only be when the player is nearby. In a game like TDM, where you might have several guards in the map with torches, you want to avoid using smoke systems for torch fire.

I'll try to get these up tonight or tomorrow... However, I should note that if you don't scale the images to a power of 2, D3 scales them down anyway, resulting in lowered quality. When I put them up, I'll scale them to a power of 2 so D3 doesn't have to, and so that it doesn't waste space.

I just wanted to point out that using a heat-haze type effect, it may be possible to do what T2 did and have it be distorted as though you're looking through a lens, and even have the scratches and such "refract" light.

Oh, ok, I know what you're talking about then... I didn't create that screenshot, I just pointed out that it was due to lack of depth-sorting, and that maybe we shouldn't have transparent glass.

Are you sure it was me who posted a gas arrow example?

Strange... I was under the impression that pixel shaders were rendered when the scene was rendered, which means they would have already been applied by the time the overlay was drawn... I'll have to test to find out where my misunderstanding is, though that'll have to wait 'til tommorrow.

How are you testing the pixel shader effect? Are you testing it as part of the HUD or using the cvar you talked about?

Does it really make sense for it to be only underwater? I thought the whole idea was that when the player is almost completely out of air, s/he gets tunnel vision, and it only lasts while their air meter is very low regardless of where the player is.

The reason why I preferred the shrink-to-center one was because a shrink-to-side one looks really lopsided and ugly to me when centered. IMHO, shrink-to-side bars only look good if put to one side of the screen, like the D3 stamina bar.

And the bubbles are easy to remove, as they're in a separate material from the other stat-bar materials.

Yes, as a player it's possible to grab and position individual limbs. I've even found that if you try hard enough, you can lean unconscious guards up against walls to make it look like kinda like they're standing.

I could easily do something like that... I'll go get a prototype working so you can see if you like it or not. Edit: Ok, I've added animated bubbles. I've also made the bar a somewhat fuzzier, though I can easily tone it down. I'm not sure if I care for the animated bubbles, since the air meter would need to be made taller to really see them (and I assume people would have a fit if I did that), and even though I don't have them too bright, they're still a little bit distracting.

I've added one more fix... (before you would run out of health/breath slightly before the meter ran out)

Yeah, I agree. I wanted to see if I could make that effect, but as a player I wouldn't like it at all. Edit: I've just replaced the bubble meter with something a little more reasonable... It's not perfectly like Springheel's concept, but it's in the same style.

I managed to get the bubble idea working... It's very distracting and hard to tell just how much air you have, but I wish to shamelessly gloat about my technical achievement with this texture! (can you tell I'm quite proud of myself?) I managed fake an alphatest-like effect without using the depth-buffer! The information about which bubbles to turn on/off based on the player's air is all stored in the bubble image. Don't worry, I think Springheel's air meter would be the best way to go, and I'm not going to ask that we use my bubble texture. But until Springheel gets the meter working (I'd be willing to volunteer to implement it) mind if I upload the bubble meter?