Is there any way to use a post processing shader with non-standard screen resolutions? I've been using Sylex3, which is great, but SLX3SwitchResolution() only accepts a standard 3dgs video mode. I use video_set() to set the screen to resolutions not included as one of the standard 3dgs video modes--such as 1920x1200 for example. Since there is no standard video_mode value for every possible resolution, I can't use Sylex3 for post processing (unless there's some other way to change the Sylex3 resolution). Has anyone else run into this and found a way to use post processing shaders at resolutions not included in 3dgs video_mode? Any help would be appreciated.

I actually don't think non-available resolutions would make post processing impossible. But it depends on two options:

- are you running in window mode ?
************* or *********************
- are you running in fullscreen mode ?

Just to make it clear, there is is difference in use with video_set. In window mode, arbitrary video resolutions are supported as long as they fit on the desktop screen and sufficient video memory is available. For full screen mode, only a few video resolutions are supported, dependent on the 3D card.

Further more there is one other aspect, I think trying it via video_switch is a better option because it supports up to 1920x1200 but then again you can't allowing arbitrary video resolutions like in video_set.For now, try setting it through video_switch, it seems the best option to work around the limited resolution reach from video_mode but a clear disadvantages is that you're bound to is the number that determines the screen resolution which is anti-arbitrary

Hope that helps, if not then I'm completly wrong And you should ask other users who already have had experience with Sylex3 like Guitar.

Cheers

Frazzle

Frazzle:

Thanks. I'm using fullscreen mode only. I'm also sure I want to continue using video_set instead of video_switch. For me, the main question is how to use a post processing shader when the resolution is not a standard video_mode resolution. If there's some trick to using Sylex3 with non-standard video_mode resolutions, that would be great. If not, are there any other Sylex3-like dlls out there that might support any imaginable resolution? If Guitar or anyone else has any advice, I would much appreciate it.

I'm no longer a fan of Sylex3. It's very dependant and not too stable. Try using the New render-to-texture (RTT) DLL that was posted in the User Contributions. It'll take more coding, but it's well worth it

EDIT: Oh, and to answer your question, as far as I know, Sylex3 doesn't support using any video modes other than the default. There's an english translation of the manual floating around here somewhere if you need it...

Thanks for the idea. I hadn't considered RTT for fullscreen postprocessing shaders, so I experimented with it a bit. I got to the point where I had the camera rendering to a bitmap for a panel covering the full screen at any resolution. Then I realized there was no way to run the bmap object through a shader--at least none that I could find in the docs and on the forum. Everyone seems to agree it's theoretically possible, but no one seems to have code showing how. So, I was stuck again.

Then that led me to discover that A7 allows materials to be applied to views, allowing for fullscreen postprocessing shader effects on the camera view itself without needing Sylex, RTT, or any other workarounds. So, I guess that's one more reason I just need to migrate my project from 6.60 to A7 (along with antialiasing and hopefully an icon fix).

Thanks for the advice. If I'm missing something and it's possible to do this in A6, I'd love to know about it, but for now I'm out of ideas.

Yeah, one thing

...You don't render it onto a panel, that would be too easy . You need to render it to a screen entity; using an image as the entity. Then you just need to properly align it.

Guitar: Yikes. I was afraid of that. If migrating to A7 gets too painful, I'll definitely try that. Of course, there are obvious drawbacks to using an image in 3D space and aligning it to the screen--the alignment problem itself being one and another being slight image distortions that inevitably result from inevitably imperfect screen alignment. Thanks again for your expertise. You've saved me a lot of time banging my head against the computer trying to knock a non-existent solution out.

haha, I know exactly what you mean

It's not too difficult to align it properly, and as long as you use a view entity (below) it should work fine.

I figured out a little (linear) equation for adjusting the scale to meet the screen, I'll post it here when I get home

alignment isn't even necessary well, not perfect alignment. as long as it covers the entire screen, then you can texture it in screen-space (does this ring any bells, guitar?)

just looking through my stuff...

Code:

---

const float4x4 matWorldViewProj;	// World*view*projection matrix.
const float4x4 mat2Tex = {
	0.5f, 0.f, 0.f, 0.f,
	0.f, -0.5f, 0.f, 0.f,
	0.f, 0.f, 1.0f, 0.f,
	0.5f, 0.5f, 0.f, 1.0f
};

texture mtlSkin1;
sampler ScreenSampler = sampler_state
{
	Texture = <mtlSkin1>;
	AddressU  = Clamp;
	AddressV  = Clamp;
};

void ScreenMapVS(	in float4 InPos		: POSITION,
						in float4 InNormal	: NORMAL,
					
					out float4 OutPos	: POSITION,
					out float4 OutTex : TEXCOORD0,
					out float4 OutNormal : TEXCOORD1
					)
{
	OutPos = mul(InPos, matWorldViewProj);
	float4x4 matOffset = mul(matWorldViewProj,mat2Tex);
	OutTex = mul(InPos,matOffset);
	OutNormal = InNormal;
}

float4 ScreenMapPS(	in float4 InTex : TEXCOORD0,
							in float4 InNormal : TEXCOORD1,
							in float4 InPos : TEXCOORD2) : COLOR
{
	float4 sPos = InTex;
	float4 colScreen = tex2Dproj(ScreenSampler,sPos);
	colScreen.bg = 0;
	return colScreen;
}

technique Project2ScreenTechnique
{
	pass P0
	{
		VertexShader = compile vs_2_0 ScreenMapVS();
		PixelShader  = compile ps_2_0 ScreenMapPS();
	}
}

---

this is pretty basic. mat2Tex is just a matrix that, when multiplied by matWorldViewProj, will give a matrix that, when multiplied by the object's coordinates as passed to the vertex shader, will convert its screen coordinates to texture coordinates. these can be used when sampling the texture, which in my example is given by a render-to-texture by a view that's identical to the camera (those details aren't in my example... it's just basic RTT).
the blue and green components are removed so you can see where the object is in this example.

this'll be a tad easier in the next update... can't wait!!

here the shader has been applied to a sphere.

if you have a view-entity easily covering the whole screen, then you won't have to worry about adjusting the model for different screen-ratios, camera arcs, etc. the shader will handle that. as long as both views have identical properties.

Quote:

---

the alignment problem itself being one and another being slight image distortions that inevitably result from inevitably imperfect screen alignment.

---

this'll sort that out

julz

JulzMighty, that's a pretty brilliant approach. Ironically, I can't seem to get both RTT and your shader working even though I've had no problems getting your shader to work properly in my environment and I've had no problem using RTT assigning the camera.bmap to a bitmap for a panel. Do you have any CScript code showing how you used RTT with your shader? Here's the code I've been using unsuccessfully:

bmap shader_postprocessor_camera_bmap = <postprocessor.tga>;
function mtlPostprocessorEvent()
{
mtl.skin1 = shader_postprocessor_camera_bmap;
}
material mtlPostprocessor
{
event = mtlPostprocessorEvent;
flags = tangent, enable_render, enable_tree;
effect = "Postprocessor.fx";
}
function ... (called once after game load)
{
...
camera.bmap = shader_postprocessor_camera_bmap;
...
you = ent_create(shader_postprocessor_bmap, temp, NULL);
you.material = mtlPostprocessor;
}