Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[serializer]

Hello all,

I've started taking a look at the WME sources with a view to trying to implement some features that I feel could make a huge difference to the visual appeal of the game.

But, I'm having a bit of trouble finding my way around the source code so I was wondering if anyone could help point me in the right direction

Let me just outline my thinking about these features;

- Post-processing shaders would allow a huge variety of visual effects to be easily plugged into WME games, and make a huge difference to the look and feel of 2D and 2.5D productions alike.

- Resolution independence could actually be achieved through the same system. I am thinking that the engine would need to render everything to a render target the same size as the default resolution of the game, instead of direct to the viewport (unless I am mistaken and this is already happening or at least easily possible). Then, this render target can be drawn to the screen with a shader that will scale and crop it to the actual screen resolution. This means I could develop my game for 1080p resolution but scale it down for lower-res displays. It's a shame to be confined to lower resolutions in this HD age, just so my game can be widely compatible!

- This would make it fairly easy to add fine control of effects like zoom & pan. I would also prefer to implement widescreen by designing for widescreen res, then have the game crop the left and right extremeties and pan the scene, rather than introducing black bars, so it will always occupy the entire viewport

- The render target could be redrawn with a chain of post-process shaders to allow any combination of effects

- It would be amazing to be able to render individual 2D sprites with shaders. This is effectively the same operation as drawing the rendertarget to the screen with a post-process filter. The rendertarget in that case would just be a full-screen sprite. I am just thinking here about code reuse and the fact that this could all be done in a (relatively) straightforward way once the basics are in place.

- I've already written a variety of 2D sprite and post-process shaders from a side project I started in XNA. These include: motion blur, glow and outline, colour cycling, distortion mapping, plasma beams, and a couple others. So this would be a nice library of effects I could instantly make available to other Wintermute users along with the modified source of course! Colorisation, brightness/contrast, and simple blur effects would also be pretty straightforward. There really are no limits to what you can achieve once you start playing around with HLSL

So; firstly, I do a lot of work in C#, and although many years ago I dabbled in C++, I'm a bit rusty which is where I'm struggling here.

My questions are:

1. Through the C# wrapper API are there any ways it's possible to manipulate the rendering system? (I'm assuming not)

2. Where exactly in the code are shaders being applied to 3D models?

3. Where exactly in the code are 2D sprites getting rendered?

4. Is everything being rendered direct to the display, or is it going to a rendertarget first anyway? If so, where does this get finally rendered to the display?

This will undoubtedly not be the whole story, but these pointers would really help me understand how the code fits together. I think this additional flexibility in the engine would truly mean that "anything is possible" in Wintermute and I've certainly seen other requests in the forums for these kind of features. It would for me remove all important limitations of the engine whilst we wait for the WME 2 release

Any help much appreciated,
Pete

[Mnemonic]

Hi Pete,

1. Through the C# wrapper API are there any ways it's possible to manipulate the rendering system? (I'm assuming not)

No, the dirty low-level details are not exposed to the C# API, because there was no need for that.

2. Where exactly in the code are shaders being applied to 3D models?

The D3D effects are glued to meshes via materials (C3DMaterial). The actual effect application happens during the mesh rendering, in the CXMesh::Render() method.

3. Where exactly in the code are 2D sprites getting rendered?

The final rendering of textured quads happens in CBRenderD3D::DrawSpriteEx() method. Some 2D elements are batched together for better performance (bitmap fonts, tiled images and particles). Those are eventually rendered in CBRenderD3D::CommitSpriteBatch().

4. Is everything being rendered direct to the display

Yes.

[serializer]

Thanks, that makes things a ton clearer... Although I can see quite quickly that it'll be extremely complicated to do what I want!

I'm thinking that I could perhaps play around with the vertex shader to perform resolution scaling, so long as I ensure mouse coordinates are still handled correctly of course. This would mean that on graphics cards with less memory I didn't create a problem by having a huge 1080p render target.

It's definitely going to be tricky, but it's a good opportunity for me to learn a bit more about DirectX

Thanks again,
Pete

[serializer]

I've got a small optimisation query regarding the current effects system;

AdActor3DX.cpp line 2491:

Code: [Select]


if (EffectFile && Material)
{
C3DEffect* effect = new C3DEffect(Game);
if (FAILED(effect->CreateFromFile(EffectFile)))           // ** 1st call of C3DEffect::CreateFromFile
{
Game->LOG(0, "Error creating effect from file '%s'", EffectFile);
SAFE_DELETE(effect);
}
else
{
if (FAILED(m_ModelX->SetMaterialEffect(Material, EffectFile)))
{
Game->LOG(0, "Error assigning effect to material '%s'", Material);
SAFE_DELETE(effect);
}
}
}


The above calls m_ModelX->SetMaterialEffect(...). In this we see a repeat of effect->CreateFromFile(EffectFile) :

Code: [Select]


HRESULT CXModel::SetMaterialEffect(char* MaterialName, char* EffectFilename)
{
if(!MaterialName || !EffectFilename) return E_FAIL;
if(!m_RootFrame) return E_FAIL;


C3DEffect* effect = new C3DEffect(Game);
if(FAILED(effect->CreateFromFile(EffectFilename)))             // ** 2nd call of C3DEffect::CreateFromFile
{
SAFE_DELETE(effect);
return E_FAIL;
}

// ...


The CreateFromFile function would appear to be reloading the effect each time it's called, I'm wondering is there a reason for this or could the first load attempt be eliminated to improve load times of actors with many effects? ...Or would this be of negligible improvement?

[Mnemonic]

Hmm, yes, this seems wrong, and also creates a memory leak (the 'effect' object is never deleted). I suppose I was originally passing the effect object to SetMaterialEffect directly, later changed it to filename but didn't update the code...

[serializer]

Ah, since I'm usually working with managed code, I'm not used to thinking about garbage collection   Good that I'm aware of it now, otherwise I'd have started making a right mess of things!