Posts by EmilMacko

Change the resolution of the game so it's twice the size on each dimension (in your case 672x480), then go into the application properties, into the Window tab (the same tab where you specify the resolution of the game).
And then at the very bottom, tick on the box that says "Do not center frame area in window", now when you play the game you'll be able to view twice as much as before. Then in your CRT shader, you'll have to create another shader that takes the upper right quarter of the screen and stretches it so it fills the entire screen, get the new 2x scale output and use it as input in your CRT shader.

The only downside to this is that the game will render 4 times as much of the game (if your level is greater than the original screen resolution, otherwise the rest will just be the border color). It would be nice if you could just apply the border color to the rest of the screen, instead of the game rendering everything that you normally wouldn't be able to see. But since this is a pixel game with such a small resolution it probably wouldn't affect performance that much (if at all).

Edit; Sorry for reviving a semi-old thread, but there was no comments so I thought I'd give my knowledge, in case you were still trying to deal with this problem.

I just understood what you meant with the red channel. I read Please login to see this link. with the same sort of problem, and they meant to use the red channel of the source image (input), which I NEVER thought about... I thought you meant I had to use the red channel of the palette. But now that I know this, I've completed the shader, and it works perfectly. The only down-side is that all images in the game are gonna have to be a very dark red (so only the index data of the red channel is there, 0-63 colors), then again, that would probably frustrate anybody who tries to rip the game's graphics to find secrets or what-not, which is nice.

Anyway, thanks for the help Looki

I've looked into using one of the channels like that, but the thing is I'm using the NES Palette here, and each of the channels have shades of R/G/B that are shared with other colors
I even checked to see if I could use two of the channels together, but there's still duplicates no matter the combination.

Changing the colors defeats what I'm trying to do, so that's out of the question (for now).

I discovered that Clickteam can use the shader-version above ps_2_0, which is ps_2_a. This gives me 512 of those things that were limited to 64 (can't remember what they were called).

So now, I have a functioning shader that (for some yet unknown reason) doesn't produce quite the output I'd expected

sampler2D img;						// Input screen (per pixel)
sampler2D Palette: register(s1);	// Palette
float Xoffset;						// X offset value
float Yoffset;						// Y offset value
int Mode;							// 0 = Normal, 1 = Rainbow, 2 = GameBoy


float4 ps_main(in float2 In : TEXCOORD0) : COLOR0
{	
	float4 o = tex2D(img, In);
	float2 PaletteCoord;
	PaletteCoord.x = 0.0;
	PaletteCoord.y = 0.0;
	float4 p = tex2D(Palette, PaletteCoord);
	
	for (int i = 0; (o.r != p.r || o.g != p.g || o.b != p.b) && i < 63; i++)
//	for (int i = 0; all(o.rgb != p.rgb) && i < 64; i++)
	{
		//PaletteCoord.x = (fmod(i, 16) / 16);
		//PaletteCoord.y = ((floor(i / 16)) / 4); // Putting the index coordinates in like this yields a laggy shader that gives errors.
		
		PaletteCoord = ((fmod(i, 16) / 16), ((floor(i / 16)) / 4)); // But for some reason putting them in with this, works fine.
		p = tex2D(Palette, PaletteCoord);
	}


	//PaletteCoord.x += (Xoffset / 16);


	if((PaletteCoord.y + (Yoffset / 4)) > 0.75)
	{
		PaletteCoord.y = 0.75;
	}
	else if((PaletteCoord.y + (Yoffset / 4)) < 0)
	{
		PaletteCoord.y = 0.0;
	}
	else
	{
		PaletteCoord.y += (Yoffset / 4);
	}


	o.rgb = tex2D(Palette, PaletteCoord).rgb;
	return o;
}
technique tech_main
{
	pass P0
	{
		VertexShader = NULL;
		PixelShader  = compile ps_2_a ps_main();
	}
}

This makes my test-image (all colors except black) all cyan (the cyan color at 12,3 to be exact, counting with zero), the alpha of the input is preserved however, so what's transparent in the input is transparent in the output as well (transparency with pink as the transparent color).

This is the slightly modified NES palette I'm using: Please login to see this attachment.

The only changes are that I've removed the duplicate grey-scale colors, so they are in one column instead of two, and I added the colors from the GameBoy (which are only gonna be used for GameBoy-mode).

Okay, so after tinkering with this. I've found the definite problem to this seed-calculator thing.

There's just too much going on for D3D9. I have no idea why, that's just how it is.

Yeah I've never really had a good sense of how powerful computers are when it comes to calculations like these... especially with Clickteam being 32-bit and all.

Anyhoo, I believe I fixed the shader for now, all that's in my way is the fact that it's "too complex" according to Clickteam (there are "more active values than registers", apparently).
I've tried my best to remove un-needed variables, but to no avail.

sampler2D img: register(s0); 			// Input screen (per pixel)
sampler2D Palette: register(s1);			// Palette
float Xoffset;						// X offset value
float Yoffset;						// Y offset value
int Mode;							// 0 = Normal, 1 = Rainbow, 2 = GameBoy


float4 ps_main(in float2 In : TEXCOORD0) : COLOR0
{	


	float4 Out = tex2D(img, In);
	float2 PaletteCoord = (0.0, 0.0);
	//PaletteCoord.x = 0.0;
	//PaletteCoord.y = 0.0;
	float4 PalOut = tex2D(Palette, PaletteCoord);


	for (int i = 0; i < 58; i++)
	{
		if(Out.r != PalOut.r || Out.g != PalOut.g || Out.b != PalOut.b)
		//if(Out.r != tex2D(Palette, PaletteCoord).r || Out.g != tex2D(Palette, PaletteCoord).g || Out.b != tex2D(Palette, PaletteCoord).b)
		//if(tex2D(img, In) != tex2D(Palette, PaletteCoord))
		// ^^ I tried several different ways to if-check this, the first one makes it lag horribly with an error saying
		//    the shader is too complex, while the second one creates the error "float expected".
		{
			PaletteCoord.x = fmod(i, 16) / 16;
			PaletteCoord.y = (floor(i / 16)) / 4;
		}
		else
		{
			i = 58; // I tried break; but it didn't work, so this breaks the loop instead.
			// There are 57 different colors, but 8 of the 64 spots in the palette are the same pink color which is used for transparency, and I have no need for 7 extra colors.
			// so 56 colors + 1 transparent color (pink).
		}
	}
	


	//PaletteCoord.x += (Xoffset / 16);


	if((PaletteCoord.y + (Yoffset / 4)) > 0.75)
	{
		PaletteCoord.y = 0.75;
	}
	else if((PaletteCoord.y + (Yoffset / 4)) < 0)
	{
		PaletteCoord.y = 0.0;
	}
	else
	{
		PaletteCoord.y += (Yoffset / 4);
	}


	Out.rgb = tex2D(Palette, PaletteCoord).rgb;
	
	return Out;
}
technique tech_main
{
	pass P0
	{
		VertexShader = NULL;
		PixelShader  = compile ps_2_0 ps_main();
	}
}

I've tested the shader where I removed the for-loop/color-index-search and instead just put a predefined index value (pointing to a specific color), which successfully colored the entire sprite in that color + offset, and the offset's limits also worked the way they should.

The error used to say something about there being 32 values when D3D9 only allows 31, but now that I've removed some unnecessary values, it now believes there are still more than it has been able to register.
Any idea on how this could be fixed?

Edit: I just tried switching the number of times the for-loop would run, and it appeared to fix it. With the way the for-loop is designed now (+ the if-statement thingy inside) Clickteam can only afford to run the for-loop about 5-6 times... So yeah a for-loop is most likely out of the question...
But anyway, this brings me back to another method I was trying out before I saw your reply Looki, which is to use the RGB values of the input to make a unique seed, which can be used to get a pre-defined index value in an array. The only problem with it was that it was difficult to find a way to generate a seed that would be unique for each color, since all the colors Red and Green values here are divisible by 4, and the Blue values are divisible by 8, there's a lot of similar numbers. But I found a way, by writing a program in C# that would calculate each color with this seed-generator. And then use a "check list for duplicates" website.
The thing that stopped me from doing it this way before, was that Clickteam would lag horribly every time I used the seed-calculation to find the index value (which is in an INT array with 2048 spots, that btw works fine if I skip the calculation and input a certain seed-result instead). The problem persists. The seed-calculation must be too long...

I made the shader work (sort of), although it required the removal of the for-loop. I also fixed some syntax-ish errors (the coordinates were not scaled correctly).

sampler2D img;						// Input screen (per pixel)
sampler2D Palette: register(s1);			// Palette
float Xoffset;						// X offset value
float Yoffset;						// Y offset value
int Mode;							// 0 = Normal, 1 = Rainbow, 2 = GameBoy


float4 ps_main(in float2 In : TEXCOORD0) : COLOR0
{	
	float4 Out = tex2D(img, In);
	float2 PaletteCoord;
	PaletteCoord.x = 0.0;
	PaletteCoord.y = 0.0;


// This for-loop is what's making the shader not work.


	[loop]for(float PaletteIndex; Out.rgb != tex2D(Palette, PaletteCoord).rgb; PaletteIndex++)
	{
		PaletteCoord.x = (PaletteIndex % 16) / 16;
		PaletteCoord.y = (floor(PaletteIndex / 16)) / 4;
	}
// I tried the shader without the for-loop, and the shader behaved as expected.
// It turned every pixel in the sprite into the color of the current indexed color on the palette + offset


	//PaletteCoord.x += (Xoffset / 16);


	if((PaletteCoord.y + (Yoffset / 4)) > 1.0)
	{
		PaletteCoord.y = 1.0;
	}
	else if((PaletteCoord.y + (Yoffset / 4)) < 0.0)
	{
		PaletteCoord.y = 0.0;
	}
	else
	{
		PaletteCoord.y += (Yoffset / 4);
	}


	Out.rgb = tex2D(Palette, PaletteCoord).rgb;
	
	return Out;
}
technique tech_main
{
	pass P0
	{
		PixelShader  = compile ps_2_0 ps_main();
	}
}

I've literally just today entered the wonderful world of pixel shaders, with the wish of making a specific palette shader for a game I'm working on.

I'm planning on making the game with the a slightly altered NES palette, and I've looked at some other Palette shaders to see how it would be done (and to see how HLSL generally worked).
The game would run at a very low resolution (similar resolution to the NES, albeit with a different aspect ratio), and I'd then scale it up after everything else in the shader.

Every single tile and sprite will already be fixed to this NES palette, therefore I don't need this shader to make other colors into the nearest colors in the palette.
I'm not going to use any form of half-transparency or ink effects (only pixels that are pure pink, or 255, 0, 255 in RGB, will be fully transparent)

I wanted the shader to find which index the color (of the current pixel) has in the palette, where the pixel's color (index) then would be shifted in the palette by a given offset value (primarily in the Y dimension)
This would allow me to make everything 1 level (or more) darker or lighter, I'd then save an X offset for something like a constant shifting rainbow effect if that was needed, either that or lock the entire X dimension to a single column of colors, so everything could be in greyscale (or even GameBoy-like green colors).

I've written an experimental shader that should be able to do the Y Offset part (that would also make sure that any colors above or below the palette-spectrum would reset to the limits).

sampler2D img;					// Input screen (per pixel)
sampler2D Palette: register(s1);			// Palette
float Xoffset;						// X offset value, currently unused
float Yoffset;						// Y offset value
int Mode;							// Greyscale, rainbow, GameBoy, etc. Currently unused


float4 ps_main(in float2 In : TEXCOORD0) : COLOR0
{	
	float4 Out = tex2D(img, In);
	float2 PaletteCoord;
	PaletteCoord.xy = (0,0);


	for(float PaletteIndex; tex2D(img, In).rgb != tex2D(Palette, PaletteCoord).rgb; PaletteIndex++)
	{
		PaletteCoord.x = PaletteIndex % 16;
		PaletteCoord.y = Floor(PaletteIndex / 16);
	}


	//PaletteCoord.x += Xoffset;


	if((PaletteCoord.y + Yoffset) > 3)
	{
		PaletteCoord.y = 3;
	}
	else if((PaletteCoord.y + Yoffset) < 0)
	{
		PaletteCoord.y = 0;
	}
	else
	{
		PaletteCoord.y += Yoffset;
	}


	Out.rgb = tex2D(Palette, PaletteCoord).rgb;


	return Out;
}
technique tech_main
{
	pass P0
	{
		PixelShader  = compile ps_2_0 ps_main();
	}
}

This doesn't work for some reason. Later on I then learned that it wasn't very efficient to use for-loops in shader-code (I should've predicted it, having to compare a color to 64 other colors for every pixel on the screen, 60 times a second, that's gotta be rough).
My problem is that I can't see any other way to find out what color has what index in the palette, that is without making a 64-layered if-nest that compares the input to each color in the palette (which I think would almost be worse than a for-loop).

I need a way to find the index in the palette of the colors from the input, from there I'm pretty sure I'd know how to manipulate the index numbers to make the outputs get their neighbor-colors in the palette and such.

To me, that sounds more complicated than doing what I'm trying to do.

I think this is actually a very simple task because of the fact that the sprite would be very small, and only have 2-3 different colors (including transparency).

I'm not trying to do this because I know people will rip all the sprites out of the game to find all the secrets, I'm doing this in case people will do it. I haven't heard of any game that's done this exact kind of thing before (at least not for this exact purpose), so I thought I'd give it a shot.

I'm planning to make a pixel game in the style of NES games, and I want to hear if this little thing would be possible in an extension.

Basically, I'd want to have a secret character/entity whom I'd like to remain a secret until discovered deep in the game, and not by—for example—ripping the sprites out of the game.
The sprite would be extremely simplistic, in a size of something like 32x32 pixels (or smaller, maybe). Only using up to 3 colors; transparent, black, and white (or just 2 colors if it's necessary).

I'm thinking of a 32x32 array that would hold values like 0, 1, 2 (each representing a predefined color), which could then be interpreted into a "fake image".
I'm saying "fake" because it shouldn't be an actual bitmap file which is generated at runtime, because then it would be rip-able from RAM when the game is running.
I'm not that big on graphics-programming, but I imagine there could be a way to have a particle-like system to host a bunch of 1-pixel-sized objects with a color corresponding to that objects coordinate in the array, and then maybe even have the transparent ones be non-existent if possible. Or maybe by utilizing some form of vector-graphics if that's possible in Clickteam. If this "sprite" should be animated then it wouldn't be any more than 2 frames.

This thing would be solely to have an actual secret which won't just be ripped from the game, I realise that hardcore hackers could find this secret but since everyone can rip textures these days I imagine that doing this would go a long way to secure the secret.

Any answer/help is appreciated.

All I can think of is that it might be a limitation on Clickteam's side, though you could always experiment with compressing your images, so they don't contain a lot of colors (either that, or make them darker, which also lowers the color-use)