Cx4 SNES Special Chip Image Download

Since byuu added low-level emulation support for the various special chips found in SNES games into bsnes/higan, anyone wanting to play those games has needed an image of the chips to go along with their ROMs. Most of the common SNES special chip images are available from caitsith2's SNES hardware page, except for the Cx4 image used in Mega Man X 2 and 3. Byuu is confident that the contents of the Cx4 image are non-copyrightable (it's just math tables) and hosted a copy of it on his own site for some time but that seems to be either down or missing since his various website overhauls, so I figured I'd host it here, from my mediafire account:

http://www.mediafire.com/download/9747o707ciq4lh8/cx4.rom

A Brief Look at x265 vs x264

The next-gen open-source video codec known as x265 (h.265 / HEVC) is starting to gain some traction, since it is now included in the popular FFmpeg utility and its various derivatives, so I figured I'd do some poking around and see how it compares with the ubiquitous x264 (h.264 / AVC). NOTE: x265 is still extremely new and unoptimized, while x264 is mature and stable, so this isn't really a fair fight just yet.

For this comparison, I downscaled a 720p video to 480p with both codecs. For x264, I used a CRF value of 21, high profile, 'medium' quality preset with a 'film' tuning (these settings were chose for simplicity rather than quality). For x265, I used an RF value of 21, 'medium' quality preset with 'ssim' tuning.

During the encoding, x264 used all 8 of my AMD Bulldozer cores at approximately 95% utilization, with an average encoding speed of ~75 fps. In comparison, x265 reached only approx. 65% CPU utilization, with an average encoding speed of just 12 fps.

As expected, the videos were comparable in quality, with a slight edge going to x264 (maybe related to differences in my settings, or maybe differences in the codecs, themselves; I'm not sure and didn't delve deep enough to find out), as you can see in these sample shots (click for full size, which is still pretty small):

x264

x265

x264

x265

However, underlying that slightly better quality, x264 used roughly 47% more bits per second to encode. That is, x265 had a final bitrate of 624 kbps vs x264's 919 kbps.

So, x265 already produces a significantly more efficient encoding than x264 but the processing power required for that encoding is much greater (roughly one-sixth the framerate). Moreover, decoding is all done on the CPU right now, as no GPUs have built-in decoder chips for h.265, so that means greater power usage and shorter battery life when viewing.

x265 is already impressive in efficiency but the drawbacks of increased computational costs in both encoding and decoding and drastically slower encoding speeds make it currently unattractive to me. I'll be keeping a close eye on development, though, since it's only a matter of time before the tradeoffs are corrected (improvements in the codec), negated (implementation of hardware encoding/decoding) or rendered moot (improvements in general computation power). After all, it wasn't so long ago that x264 was considered immature, unoptimized and poorly supported in hardware vs xvid / ASP. ;)

Interlacing Shader for CRTs

In the comments of my TVs and Retro Gaming post, GPDP and Monroe88 mentioned the need for a shader that would take a 480p signal from an emulator and either add 100% black scanlines on "240p" content or blank alternating fields each frame. In other words, they needed a shader that would interlace the default progressive signal, which would allow them to run their displays at 480p for all retro console emulation instead of having to switch back and forth between 320x240 (most games for NES, SNES, Genesis/Mega Drive etc.) and 640x480 (for games that utilized the added lines of resolution that interlacing provided, such as 2-player mode in Sonic 2, SNES' R.P.M. Racing, and tons of PSX games).

So, here's the shader in RetroArch-compatible Cg format:

/* COMPATIBILITY
- HLSL compilers
- Cg compilers
*/
/*
Interlacing
Author: hunterk
License: Public domain
*/
struct input
{
float2 video_size;
float2 texture_size;
float2 output_size;
float frame_count;
float frame_direction;
float frame_rotation;
sampler2D texture : TEXUNIT0;
};
void main_vertex
(
float4 position : POSITION,
out float4 oPosition : POSITION,
uniform float4x4 modelViewProj,
float4 color : COLOR,
out float4 oColor : COLOR,
float2 texCoord : TEXCOORD,
out float2 oTexCoord : TEXCOORD,
uniform input IN
)
{
oPosition = mul(modelViewProj, position);
oColor = color;
oTexCoord = texCoord;
}
float4 main_fragment (in float2 texCoord : TEXCOORD, uniform input IN) : COLOR
{
float4 res = tex2D(IN.texture, texCoord);
float y = 0.0;
// assume anything with a vertical resolution greater than 400 lines is interlaced
if (IN.video_size.y > 400.0) y = IN.texture_size.y * texCoord.y + IN.frame_count;
else
y = 2.0 * IN.texture_size.y * texCoord.y;
if (fmod(y, 2.0) > 0.99999) return res;
else
return float4(0.0);
}

It has two branching 'if' statements, which is horrible for performance in shaders, but this one is simple enough--and only needs to run at 2x--that it shouldn't matter.

UPDATE: In the comments, Monroe88 mentioned another very useful shader for use with 31 kHz CRT monitors: aliaspider's TVoutTweaks, which lets you add some nice effects, such as composite color correction and horizontal bandwidth (blends things like SNES' pseudo-hires transparency and other dithering effects), which will make the image a little closer to a 15 kHz TV. See Monroe88's comment below for more info and a pic.