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

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

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


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

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.

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.

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.

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..

Updated shader pack.

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

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!

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

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:


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.

This site appears to have several backups of the source:

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.



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.

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

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!

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.

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!

Yay! My test code WORKED!

I owe you one Verdauga!

Hehe, that looks cool; glad I could help.

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!

Pack updated again.

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

64k

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 ...