Gildoran

I agree, but at least the first version of readables will pop up a full-bright display, since the display is implemented entirely as a GUI. (whereas an in-world readable GUI can use its rendered object as a background, allowing it to be lit) Having the books interact with lighting will require the book to be rendered as a model in the game-world, like a weapon, which I'm not yet very knowledgable about.

Yes, that is the plan, and it's also why most books will be portable inventory items - if you're a slow reader you can take the book to some safe shadow and read there.

Don't worry, D3 can handle T1/T2 sized levels without need of loadzones.

Dram: Have you thought about experimenting with detail textures? There's all sorts of fun things you can do with alpha-maps, modulation and scaling, and it doesn't use up half as much memory as one huch texture.

Because it's easy to set up that way, allows us to adjust frob intensity, and would later allow us to upgrade the frob code so that the frob highlight fades in/out as you highlight different objects, if we wanted to do that. Changing it later would be a lot of work. If we set it up correctly from the start, it's practically no extra work.

It sounds like you're describing a hack, which is again Badly Designed Programming.

I suspect Sparhawk may have snapped at you because he's tired of (I'm not saying you're one of these people) idiots who confuse the capabilities of an engine with the style of a particular game that runs on it. A classic example, is people who think that HL2 can handle large open areas better than D3... HL2 and D3 both use CSG engines, so they handle outdoor areas in the same way, and with approximately equal performance. (on the other hand Farcry is better at rendering outdoor areas than D3 or HL2, though more cumbersome for indoor areas) Having to replace the whole physics code is exactly what I'm saying is bad.

Let me try to rephrase my point to see if I can make it clearer: if you wanted HL2 physics to work with altered gravity, or non-euclidean geometry or some other feature that the designers never thought of, you'd have to scrap it and replace it with another system. It would be difficult or impossible to build off of what has already been done, so adding new features to HL2 physics would be a complete pain and would require a lot of work. With Doom 3, you can tweak the physics and add any missing features without having to recode it from scratch. For example, the original D3 game didn't have water, so it was unneccessary to include water physics, but we've added code to the physics engine to take bouyancy and friction with liquids into account. The point of me mentioning this, is not that it was possible to do water physics in D3. The point is that it was possible to cleanly extend the D3 physics engine to do new things with minimal effort.

It's not necessarily as bad as you might assume - I believe that the if statement in material files will cause a render pass to be skipped entirely if the condition isn't met (admittedly, I'm not 100% sure), so the extra render pass probably only applies to the object with the frob highlight, rather than all frobables. As for how much performance the extra render pass takes... it's like adding a specular map to a texture that never had one. (and I've noticed that we haven't exactly been stingy on where we've used specular maps...) As for changing the brightness of frob highlights, that'd be easy to do without needing to modify material files every time... Instead of passing 0 or 1 through renderparm11, we should pass 0 or X (where 0<=X<=1, and X is probably determined by a cvar), and let the material adjust its frob brightness accordingly.

Macsen is saying that it's hard to see what's in your peripheral vision. I know that if I look at the black bars at either side of this forum, I can't read the text because it looks too blurry.

It'll be possible to write things directly to the screen, though it might take some scripting from the map author. Actually, the way I've been trying to set up books is by providing the necessary script functions so that the code for readables can be mostly written with D3 scripting. Currently, there isn't an option to go into full-screen paused reading mode, but I'd like it to be possible to construct such readables. There's no guarantees about that happening though. As for handling post-frobbed events, I'll probably add optional settings for activating triggers or calling functions when a player starts/stops reading a book. That way, to simulate the necromancer tower in Life Of The Party, you could maybe set something like "stopTarget" to "reviveZombies" on the necro book and then have an entity named "reviveZombies" that brings them to life. Then, the player can read the book safely, but as soon as they stop, the zombies would stand up and attack the player. Likewise, I could probably add options for setting off things when the player reaches a certain page.

I'm not saying D3 is superior or that I want to replace the physics engines... I'm saying modifiability is important. With HL2, you could probably write your own physics engine, but as you said, why would you want to? But, the fact that HL2's physics code is closed off makes it difficult to arbitrarily extend it.

@Springheel: The way textures are lit/rendered, is that first the texture is set to black, then for each lighting pass, the values from that lighting pass are added to the texture. Usually textures have only one or two lighting passes (normally a diffusemap and sometimes a specularmap), but they can have more. For example, you could have multiple diffusemaps. There's normally no reason to do that, but in the case of frobbing, using the same diffusemap for two lighting passes will result in the object being twice as bright (or if you want the object only 1.5 times as bright, you could set the rgb of the second lighting pass to 0.5). If you take a frobable material and change the line blend add to blend diffusemap, it'll increase the light the object receives rather than adding the full values of the diffusemap to the texture without regard to lighting. Edit: In other words, the SDK code never actually detects how bright the object is, the material files just tell the engine to increase the amount of light it recieves.

Magnesius: Yep, that's possible with splines in D3ed. Heh, that'd be great if Snails ended up being a signature of TDM, much like how burricks and the word "taffer" are for Thief. PS, I swear it looks like those two snails are ... Well, I guess we know why there's so many snails on that table.

Although Prey may have access to more than just the SDK, it IS possible to entirely change gameplay/physics in D3 due to the fact that all physics and gameplay code are stored entirely in the SDK. Changing the player's orientation/gravity is one thing, but having physics systems interact properly with different gravity fields is entirely another... Do the cyberspace sections have physics objects in them? I know that HL2 has some great physics (I've had fun playing on maps with collaspable lookout towers), but my point is that no matter how good a physics system is, there's always things that aren't possible, unless you have access to change its code, which I believe you don't in HL2.

Shall I set up some demo frobbable textures so team members can try them out and see what they think?

Yes, it's easily possible to make frob highlighting scale the amount of light an object receives. (but it requires the material shaders for frobable objects to be set up properly) Currently, however, we use a scheme that more resembles T1/T2.

Currently it doesn't blur the background, but the background does darken some to indicate the player is in a "mode".

Alexander: To give an example, if you wanted to make a mod where gravity can change directions in certain areas, (this could be cool for MP maps set in space - imagine being about to walk around a centrifuge and shoot at players "above" you) you'd probably be very hard pressed to get it to interact with physics, even with access to the SDK. Doom 3 on the other hand... well, you've probably heard about Prey. Yes, you can do a lot with HL2 physics, but there's always something that the designers had no way of anticipating, so there's a need for being able to extend it.

If I remember correctly, HL2 uses a licensed havok physics engine, which means modders aren't allowed to look at its code, let alone modify it. (though I suppose they could add their own physics engine) The Doom 3 SDK, however, comes with the full sourcecode for the physics engine, and you can modify it any way you want.

What about this one from our very own forums?

Thank you for the praise! I'll hopefully be able to do more work on the readables during spring break. The current plan is that readables will have %100 detail in the game world, and will perfectly match what you see on-screen when you read them. Here's a high-res cropped image of the readable on the desk, where I got very close to it, but didn't actually use it. (the reason Dram's readable appears brighter is because it's highlighted by the frob code in that shot) As you can see it's exactly the same as what pops up on-screen while reading, except that it interacts with lighting.

Then you'll be happy to know that $blah isn't used for referencing variables. $entityName is more or less shorthand for sys.getEntity("entityName"). Actual variables are referenced just by name, like in C. BTW, you don't need the SDK to use D3 scripting; D3 can read scripts without the aid of an external compiler. All you need is D3 and notepad.

@Dram: I've seen numerous dark reddish-purple trees. Not to mention that the trunk of the tree, which often has more mass than the leaves combined is usually brown! Yes, you heard right: BROWN! Clearly you need to research the topic more before spouting such ignorant gibberish as "trees are green"! (heh, is that the response you were hoping for?)

This has already been suggested on the dev boards, and I think there's a good chance it'll be done.