Snes9x 1.55 official release

High resolution mode 7 is unlikely to be implemented in Snes9x, as it requires deferred rendering which Snes9x doesn't do. bsnes is able to do it because of the new high-speed parallel renderer byuu created when he resurrected bsnes as a standalone project. While there's no reason Snes9x couldn't add something similar, it would require a huge rewrite of the entire PPU emulation, especially if we ever wanted to achieve playable speeds at higher scalars

Ok, I understand that then, So snes9x would have to be re coded from the ground up to be able to do it. That would also include the libretro core of it as well. Can the bsnes libretro core be able to do this with a source code update?

Is that why between bsnes and snes9x one feels better on the computers resources. When I play sne9x the controls fell very tight and it kinda plays slug est a bit. Bsnes on the other hand feels light and seems to play smoother, and the control feels just right.

Polargames wrote:snes9x would have to be re coded from the ground up to be able to do it.

Only the Picture Processing Unit emulation... though that's STILL a huge chunk of code.  

Can the bsnes libretro core be able to do this with a source code update?

Yes it could, but the retroarch team or any other contributor would have to port newest bsnes builds to the libretro API, or maybe backport its new parallel renderer if it hasn't significantly changed the bsnes core.

Is that why between bsnes and snes9x one feels better on the computers resources.

Not really. Given byuu came up with the parallel renderer just recently, it's likely you're using any of the various old bsnes' performance profiles, which cripple accuracy entirely in the name of speed, while Snes9x has been doing the other way around, and prioritizing accurate emulation.

Wow, this is a lot of code. Would a good guess be that makes up about 3/4 of snes9x? If so, darn, that would be a nightmare.

O ok I see, Would that be a hard thing to do though? And also would retro pie users be able to handle bsnes mode 7 on there raspberry pi's at all?

I see, I did not know that. Is that why there so many versions of snes9x 2002, 05,10,16 etc on the libretro side?

Thank you for your post Colines, especialy the PPU and the computer resources. :-D

Polargames wrote:Wow, this is a lot of code. Would a good guess be that makes up about 3/4 of snes9x?

Not even close but it's really *complicated* code.
https://github.com/snes9xgit/snes9x/blob/master/ppu.cpp

Colines wrote:bsnes' performance profiles, which cripple accuracy entirely in the name of speed, while Snes9x has been doing the other way around, and prioritizing accurate emulation.

You have that backwards, bsnes has always prioritized accuracy, but eventually byuu added the other, faster cores as a slight compromise in the name of speed. Snes9x has always been far less accurate than bsnes, but is working to become moreso.

Sorry, I wasn't being clear. I meant the bsnes performance cores (particularly AWJ's classic fork) are an attempt to sacrifice accuracy or compromise code readability to gain speed, while Snes9x has been doing a great job recently looking out for accurate emulation.

That might explain why Snes9x isn't performing as smooth as old bsnes forks anymore.

Is that why there so many versions of snes9x 2002, 05,10,16 etc on the libretro side?

Yes, they are pretty much forked builds with several speed hacks/code optimizations added to help lessen system requirements on weak machines.

@qwertymodo thank you for letting me know that I was not close, but for what I could understand from the link you posted, Its like a nightmare for me. So thank you very much again. :-) Colines thank you for your info as well and also why snes9x has so many version, It all makes sense now. @qwertymodo and @Colines or any one else also, Why are there so many different emulators for snes? Is the system that complex in that area. I have only dabbled in snes emulators not long, and that qusten always baffled me.

People just like to write emulators

Also, more options to choose from is always good. As you can see from all these forks, there are different use cases for varied purposes.

Aside from personal realization which plays a big role (learning how SNES works, gaining programming skills, etc), we can have more features which other developers can't support at the moment like debugging, and more eyes to verify and study the hardware for better emulation in general.

Sweet. Thank you very much for your info. I have learned alot. :-) I hoped one day that the N64 could reach that point like the snes because that would be awesome. :-)