The unofficial BSNES pixel shader thread

[FitzRoy]

Perhaps you could help get PGO working with the new versions, instead?

We need to find which code messed it up first. And which build had it last working. Sorry that I haven't been paying much attention to the dev process to find where.

I would also like to know this info, I could put it in my bounty description. Might help if people knew where to look.

[mudlord]

Hmm. Can I help you test this?

Sure, if you have MSN, Yahoo, or AIM, we could try to fix whatever it is that is messing up.

[Verdauga Greeneyes]

Wasn't it libco that broke PGO? Meh, my memory is worthless

Sure, if you have MSN, Yahoo, or AIM, we could try to fix whatever it is that is messing up.

I'm on MSN most of the time; I'll PM you a link.

[FitzRoy]

I think it was one of the WIPs between 018 and 019. If we could get the source for that and the one before it, package them together, and link to it from the bounty, that would be nice.

[byuu]

Yes, it was between v018 and v019. I don't have anything prior to v019's release, either, except the oldest copy I have -- v002 ir9. Accidentally erased the backup drive I kept them on, forgot I didn't have copies on my main PC.

But anyway, it was already semi-broken long before. Only the first two or three releases since I started using it (around v011 or v012) worked correctly. After that, more and more games would break it if they were profiled, and I had to try more and more profile runs to get a working binary.

Right now, it always bombs out after the switch(opcode) { ... } in the CPU and SMP cores. Tells me to simplify the line below it, which is "status.in_opcode=false;" ... yeah.

I've tried using both a switch table and a function pointer table there, no difference. I'm using the switch table now because it makes the binary smaller, it compiles faster, and there's no perceptible speed loss.

[mudlord]

Updated.

And fixed VG's issue. Was a issue with paths not being long enough when I was loading and hooking D3D9.DLL

Thanks Nach for the info in your blog about paths.

[Verdauga Greeneyes]

Here's the scanline filter again, as requested It uses 224 for the vertical resolution, right now. I tried using rcpres (reciprocal of the resolution?), but it didn't work the way I expected..

Code: Select all

texture tex1;
float2 rcpres;
sampler s0 = sampler_state{ texture = <tex1>; };

float4 NormalColourPass(in float2 Tex : TEXCOORD0): COLOR0
{	float4 color = tex2D(s0, Tex);
	color.a = 1.;
	return color;
}

float4 PixelPass( in float2 Tex : TEXCOORD0 ) : COLOR0
{ float4 color = tex2D(s0, Tex);
  if(frac(Tex.y * 224.) >= .5) color.rgb *= .5;
  color.a = 1.;
	return color;
}

Technique T0
{ pass p0{ PixelShader = compile ps_2_0 NormalColourPass(); }
  pass p1{ PixelShader = compile ps_2_0 PixelPass(); }
}

[mudlord]

Updated shader pack.

[krom]

I don't have anything prior to v019's release, either, except the oldest copy I have -- v002 ir9.

byuu, if you want I can give you your original bsnes bin/source's zips of V's 0.13, 0.16, 0.17, and 0.18

Just say If you would like these, and I will give you a link to them =D

P.S did you ever try out my opengl 2.0 glx/wgl post process shader pack I P.M'd you?
(Just a bit of fun if you are bored!)

mudlord I have given you a P.M if you want to see how I converted your shader pack to work in linux and windows.
You might also like some of the shaders I converted from other sources

[mudlord]

I have given you a P.M if you want to see how I converted your shader pack to work in linux and windows.
You might also like some of the shaders I converted from other sources

Holy crap! They are amazing! Thanks so much! If its okay, is it alright if I implement these in the NES emulator I am writing? It currently uses OpenGL, DirectInput, and DirectSound, so it should work on old PCs, and I was hoping to add shader support to it, as AFAIK, shaders and 3D rendering haven't been added into a NES emulator before....

Thanks for the updated Ruby GL files, too!

[krom]

If its okay, is it alright if I implement these in the NES emulator I am writing?

Of course you can, I would love to try out your NES emu =D

[mudlord]

Coolness!

Currently there is only one issue with it: Colour output.

Namely, I need to convert 16-bit RGB colour to 24-bit RGB, then I render the data from the NES video buffer to a OpenGL texture. From there, I am all sorted.

The emulator is based on Nervegas's NESCore, mainly due to me wanting to have very low system requirements. And plus, its interface fits nicely in what I want to accomplish.

Anywayz, back to the main issue. I am having issues determining the best code to render:

Code: Select all

void NESCore_Callback_OutputFrame(word *WorkFrame) {
        register int x;
        register int y;

        byte *MyDisplay = (byte*)GLTexture;

        for (y = 0; y < NES_DISP_HEIGHT; y++)
        {
            for (x = 0; x < NES_DISP_WIDTH; x++)
            {
                word pixel = WorkFrame[( y << 8 ) + x];
                *(MyDisplay++) = ( ( pixel & 0x7c00 ) >> 7 );
                *(MyDisplay++) = ( ( pixel & 0x03e0 ) >> 2 );
                *(MyDisplay++) = ( ( pixel & 0x001f ) << 3 );
            }
        }
    }

Currently, thats how I am getting the texture data and converting 16-bit RGB to 24-bit RGB. Then, GLTexture (the texture buffer), is used to update a texture via glTexSubImage2D. Problem is, I am having major problems in getting it to work correctly, with proper colours. Blargg wrote a sample here with SDL, if that helps. If I could have a code sample as to how to properly convert this texture info to a useful texture with correct colours, that would be a massive help, as I was trying GL_RGB and setting 24-bit colours in the PFD, and it made no difference at all.

[mastershake1]

Yes, it was between v018 and v019. I don't have anything prior to v019's release, either, except the oldest copy I have -- v002 ir9. Accidentally erased the backup drive I kept them on, forgot I didn't have copies on my main PC.

This site appears to have several backups of the source:

Code: Select all

http://snesemu.black-ship.net/emus/

[byuu]

P.S did you ever try out my opengl 2.0 glx/wgl post process shader pack I P.M'd you?

Yes, I couldn't get any of them working on Linux (well, I noticed slight color shifts on some, but the actual pixels were always the same), but I didn't try the Windows one.

This site appears to have several backups of the source:

Yes, tukuyomi's page is awesome. The only problem is that we need the WIP releases in-between to pin-point the exact change that broke PGO. But honestly, I don't think it'd be helpful, anyway. The compiler tells us where the problem is, and I can't simplify that section any further.

[Verdauga Greeneyes]

*(MyDisplay++) = ( ( pixel & 0x7c00 ) >> 7 );
*(MyDisplay++) = ( ( pixel & 0x03e0 ) >> 2 );
*(MyDisplay++) = ( ( pixel & 0x001f ) << 3 );

If all you're asking for is the correct colour conversion, this was discussed at length in the old monster bsnes topic.
RGB565 -> RGB888:

Code: Select all

*(MyDisplay++) = (255 * ((pixel        ) >> 11) + 15) / 31;
*(MyDisplay++) = (255 * ((pixel & 0x7E0) >>  5) + 31) / 63;
*(MyDisplay++) = (255 * ((pixel & 0x01F)      ) + 15) / 31;

RGB555 -> RGB888:

Code: Select all

*(MyDisplay++) = (255 * ((pixel        ) >> 10) + 15) / 31;
*(MyDisplay++) = (255 * ((pixel & 0x3E0) >>  5) + 15) / 31;
*(MyDisplay++) = (255 * ((pixel & 0x01F)      ) + 15) / 31;

[mudlord]

If all you're asking for is the correct colour conversion, this was discussed at length in the old monster bsnes topic. RGB565 -> RGB888, right?

Yeah, I am asking for the correct colour conversion of 16-bit RGB to 24-bit RGB colour. Then in my glTexSubImage2D, I use GL_UNSIGNED_BYTE and GL_RGB (at least, that is what I am using.)

I will test your code out and see how I fare.

Thanks for helping by the way!

[Verdauga Greeneyes]

Not a problem; thank blargg for the integer rounding Also, there's another way to do this that gets an even spread of 'peaks' in differences between adjacent colours. The difference is minimal of course and I'm still convinced that the method I posted is slightly better, but it avoids the division.

[krom]

Yes, I couldn't get any of them working on Linux (well, I noticed slight color shifts on some, but the actual pixels were always the same)

Ah, that is a real shame, I have tested on a gforce 6800 in ubuntu 7 linux/windows xp, and an 8800 in windows xp... oh well back to the drawing board!

[mudlord]

Yay! My test code WORKED!

I owe you one Verdauga!

[Verdauga Greeneyes]

Yay! My test code WORKED!

I owe you one Verdauga!

Hehe, that looks cool; glad I could help.

[krom]

Heya byuu,
Just an update to my above post.
I upgraded ubuntu to 8.04 and tried running my bsnes opengl 2.0 driver with visual effects set to normal and extra, and it did not work, It just showed me a white screen!
I have to set my visual effects to none in ubuntu by going to the: System/Preferences/Appearance/Visual Effects menu to get the shaders to run.
So if you are running your visual effects on anything other than none, it will not work correctly...

mudlord I like what you have done with mario and a cube!

[mudlord]

Pack updated again.

[creaothceann]

Code: Select all

void NESCore_Callback_OutputFrame(word *WorkFrame) {
        register int x;
        register int y;

        byte *MyDisplay = (byte*)GLTexture;

        for (y = 0; y < NES_DISP_HEIGHT; y++)
        {
            for (x = 0; x < NES_DISP_WIDTH; x++)
            {
                word pixel = WorkFrame[( y << 8 ) + x];
                *(MyDisplay++) = ( ( pixel & 0x7c00 ) >> 7 );
                *(MyDisplay++) = ( ( pixel & 0x03e0 ) >> 2 );
                *(MyDisplay++) = ( ( pixel & 0x001f ) << 3 );
            }
        }
    }

You could use a buffer of 2^16 items to store the final 24-bit values.

[grinvader]

2^16

64k

way less intimidating

[byuu]

way less intimidating

Please. What self-respecting programmer hasn't memorized up to at least 2^20 in their head? :)

Invaluable for those bit-shift operations ...