SA-1 - Scanline issue with Kirby's Dreamland 3 - slower speed with Jikkyou Oshaberi Parodius - new core about snes9x HOT 5 CLOSED

I believe the 'ugly scanline rasterizer effect' is the correct effect.
http://www.mobygames.com/game/snes/kirbys-dreamland-3/screenshots/gameShotId,27791/ is wrong. Kirby 3 uses pseudo hires mode to draw 'transparent' graphics.
I tested Kirby 3 on the Mac build of 1.52 and current master branch and found no differenes.

from snes9x.

The issue of Primal Rage seems bad timings between CPU and APU, which cannot be treated well within current poor accuracy of snes9x. Timings.APUAllowTimeOverflow will avoid this problem.

from snes9x.

The problem with the pseudo hires effect is that on normal hardware it will produce a transparency effect similar to that screenshot (i.e. the scanlines aren't that noticeable). If you use blargg's NTSC filter you will get the desired effect.
It would be nice to have an optional blending effect like you will get in bsnes, but that is currently not available.

In summary: the kirby effect is not a result of the new SA-1 core, it's been present since (AFAIK) 1.43. Primal Rage is a result of the new APU core, I've already commited a fix - thanks for reporting.

Regarding noticeable improvements: the changes fix various graphical issues in a few games, for example "F-1 Grand Prix", "Sink and Swim" or "Battle Blaze".

from snes9x.

Thanks for the responses. It looks like in the future I will have to make do with manually optimizing the PS3 build to make up for any performance regressions. There are a couple of things I dabbled with yesterday that can definitely improve performance - such as turning the for loops in the SuperFX code (fxemu.cpp) into do while loops and iterating the counter value by 4 so that the PPU is at least kept busy. Even something as trivial as unrolling for loops can have a definite beneficial effect on
performance.

It doesn't help that we have barely any devices to properly profile and debug - Themaister wrote a networked stdio client that allows us to do gcov profiling, but we can't do anything meaningful so far with the profile data other than basically playtesting on the PS3 with the stdio wrapper on, dumping the data to the PC, then letting the compiler compile with the profiling data and hope through some black magic that it will be sped up. There's still no idea on our end as to which parts constitute the 'hot code', or where the Load-Hit-Store penalties might occur. Basically, reading through some PPU optimization documents, it seems every boolean if predicate means a branch and PPU stall, and their solution is basically bitmasks and isel/fsel everywhere.

None of this was an issue up to now because everything ran above 60fps except for two games (Vortex and Star Fox 2 - although they're getting there now as well) that sometimes dipped below 60fps. I guess sticking as closely to the original codebase as possible isn't an option anymore and I will have to start with optimising for PPC in-order aggressively.

Overall, SNES9x up to this point seemed to really scale well on an in-order PPC system like PS3 with close to no optimizations - which is something to be proud of, as bSNES by comparison can barely get above 50fps on Themaister's PS3 port.

from snes9x.

squarepusher: If your optimizations have no ill effects, then create a git branch or some patches for them, and we'd be glad to accept them.

from snes9x.