shmups.system11.org

Is there any interest in a little kit to produce sharp RGB output that has the horizontal blurring of 240p games removed? It's my favorite feature of the HDMI kit and I think it'd be neat to have for regular RGB. I implemented it on my FPGA dev board and the difference is pretty clear on my PVM, and also my RGB Trinitron TV. I will take a picture later.

Yeah.. that would be awesome! Maybe have the RGB amp implemented in the kit as well!!

Cost and easy install is everything. People are not willing to pay $$$ for this feature as they are with NESRGB for instance. Not as much love out there for N64 as NES/SNES at this time.

1. Very interested
2. Pictures please

If you have a flashcard, I would just go with the no anti-aliasing patches. The end result is more effective.

I would be curious to see how it compares to the gameshark codes for disabling the filter. This is basically like post-processing, right?

I'd be really interested in such a device myself.
Probably would go about skipping the hdmi mod altogether if you were to make an n64 rgb mod with the de-blur option.

Sign me up for the pre-order!

Yeah, I'd definitely be interested in that.

Would it be implemented in a way that would allow you to toggle it?

I wonder if viletim could make a new revision of his N64RGB that implements a VI de-blur! Just a matter of interest on his part and whether or not he could implement it on the MAX II CPLD used by the N64RGB (and make a FFC for easier installation ).

I'd rather disable it before it happens vs trying to remove it from the signal after it is already applied

Why not just take the RGB lines before the blur filter?

Because the antialiasing is part of the graphics pipeline, not something that's done on a separate chip?

It depends on how the de-blur is achieved, if done right I would be interested.

There's no such thing. The blur is how the image comes out of the Nintendo 64 digitally.

The blur is not just anti-aliasing. It's a horizontal 50% blur. The N64 outputs a 640 pixel wide image, even if the backbuffer is 320 pixels wide, and it doubles the backbuffer's width to fill the line. The appearance is an "off by half pixel" blur done horizontally. Correcting it produces a sharp 320px wide image. The scene's rendering and use of AA shouldn't affect it.

Because the blur is exactly 50% "between pixels", that means every other column is a 100% intact part of the original 320px image. So, if we simply drop the blurred columns (odd columns) and re-use the good columns (even columns) we have a restored 320 pixel image. Naturally there is zero lag in this technique.

Here is a before and after comparison, with Super Smash Bros - a game which uses AA. Patched games are an expensive option because all the flash carts are pricy, and not all games have patches.

Capturing a picture of a CRT is very challenging, so please forgive my moire patterns. Colors changing or losing saturation is an artifact of the camera and not the de-blur.





http://i.imgur.com/yvMHAOv.jpg http://i.imgur.com/H7EMDMq.jpg
http://i.imgur.com/Vnfc7Fa.jpg http://i.imgur.com/xgsp7MN.jpg

This can definitely be implemented on Tim's RGB board. Right now I don't have any fancy heuristic to determine whether or not it's appropriate to use, I just have a switch wired.

I'll be following this, very interested. My RGB modded n64 has seen a lot of use. Anything to improve the image quality again would be great. I also don't have a flash cart, so I like this.

This is not a big deal.
Actually, my N64 is running on my own custom firmware as I was experimenting with the deblur as described here (among some other things). I also implemented a logic which detects 480i mode of the N64 to deactivate this feature in 480i mode.
The MAX II has enough free pins in case somebody wants to use a pin to globally deactivate the feature

Unfortunately, I have hardly seen a difference on my LCD TV. So I put it aside. Now with the OSSC at home, I guess I might 'reactivate' testing.

I'll take a look at it. The N64RGB is due for new a board revision anyway, to make it compatible with the component video add-on board.

Awesome. Thanks, Tim.

Does it go in before or after the rgb amp, or does it not matter?

The RGB amp and original DAC are all bypassed; my FPGA is taking the digital data from the RCP. That's how Tim's board works too.

Is 320x240 the most common internal resolution? Was 256x240 ever used?

Is this effect the same as the one that the de-blur gameshark codes are switching off?

I do not know since I haven't seen it. From what I've read those change the AA or filtering model the game uses, which may or may not remove the blurring by coincidence. This will not affect the game's generated image at all, and more importantly won't require a gameshark code being made for each game or for a game to be modded.

I've never seen a game with a 256x240 internal resolution.

My guess is that it's different, mainly because when I read that assemblergames thread it didn't really seem like people knew what they were doing. It was sort of a trial-and-error "I changed this and my N64 looks sharper!" sort of thing. Games were crashing a lot too.

That said the effects may look very similar, and things may be better understood since I last looked at the thread. Considering the inconvenience of using real carts with the Gameshark codes I'd be fine with a simpler solution just built into the RGB amp, but that's just me.

Yes that's exactly the impression I got - the gameshark codes are at an early stage and compatibility is low and it's inconvenient. Still, it would be very interesting to know if they are two ends of the same stick.

I think that Mike's saying that this isn't disabling AA like the Gameshark hack, but just removing the horizontal blur filter - which would produce a different style image. This would be an ideal scenario for me, I think - removing some blur without going to the extent of removing AA.

I got the Gameshark thing up and running, but to me the resulting image just looked overpixelated & 'downgraded' somehow. I'm hoping Mike's approach would produce an image that's clearer than stock but not overly pixelated...

Either way, I would definitely buy this just to have the option.

Mike: I don't suppose it would be possible to have a couple more CRT comparison images of actual in-game 3D graphics?

Apologies for double post but is this project still a possibility? I would buy this in an instant..

this

I'm pretty sure the latter creates input lag.

The process described above discards extra pixels from the picture, using only original non-blurred pixels, with no creation of new elements. The blur is extraneous and not a transformation, so there's no "reversal" of an effect, just ignoring extra data.

Would it even require a framebuffer?

It sure wouldn't.

I think the issue remains kind of misunderstood. We either need to learn more or somebody needs to summarize what we know nicely.

There are talks of both a horizontal blur and hardware-based AA filtering. If the horizontal blur is really as simple as extra averaged pixels, then just throwing them out shouldn't be any different than stopping the console from generating them. An external solution can't remove in-game AA though of course, and that's what I've seen people talking more about recently.

I guess the main questions are:
-Is the horizontal blur universally applied to the console output no matter what? Removing it seems to already be proven as a very simple process- is it always there and the same for all games?
-Is in-game AA (which people have been disabling with Gamesharks with recently-developed techniques) universally or near-universally applied as well and is it really what makes the N64 look so blurry? The only game I know of where AA can be turned off is Quake, as far as I know at least 90% of the library uses it.

I don't think there would be any confusion if Gameshark codes for "de-blurring" games hadn't just started coming out. But I wouldn't mind clearing up some of the confusion.

Hell I don't know maybe I needed to re-read the whole thread again before I typed this, it's been a while.