Some nerds on assemblergames figured out some GameShark code

>>3094257
>it's still enabled for most, if not all commercial games. Guess Nintendo forced developers to leave it on.

In other news, grass is green.

>>3094257
>Some nerds on assemblergames

Then you can be sure that it is a scam.

>>3094261
I always thought it was caused by a shitty video output or some hardware quirk desu

Looks like shit.

Seems to have tons of bugs and graphical defects that comes with it to.

>>3094257
>having a significant performance impact with questionable result

Got any frame rate test proof to back that up kiddo? N64 used HARDWARE anti-aliasing, disabling it should have no impact on frame rate.

>>3094267
The same Nintendo that hoarded secret microcodes that could disable stuff like Z-buffering, perspective correct textures and any other bloated feature that drastically reduced number of polygons per sec, that forced competent developer like Rare and Factor 5 to reverse engineer the hardware and come up with their own microcodes? Nah, it was totally intentional. Reason being "muh competishn". Doesn't help that N64 was basically the PS3 of its time, that adopted Yamauchi's "unskilled developers make bad games so we're going to purposely make the system hard to program for" mentality.

I played several of these no-AA patches and I saw no performance difference. Like another anon said, N64 does it on the hardware side, so it shouldn't make any difference performance-wise. The reason almost every game had it turned on is because the effect was essentially 'free' to use and didn't use up any extra graphical power.

The patched games also looked WORSE in many games, at least to me. Games with bright, contrasting colors just look like a pixelated mess now with hard stair-step edges everywhere. Games with darker colors and a lot of detail might look a little better with the 'haze' lifted, but the difference isn't huge. This was all on a CRT with S-video, by the way. Maybe it helps improve clarity over composite, but over S-video it just makes everything way too sharp.

>>3094285
I can imagine someone saying "Back in the 90s the N64 was hard to develop for to keep the noob casual developers out", unironically.

File: 1382295154261.gif (646KB, 300x310px) Image search: [Google]

646KB, 300x310px

>>3094272
>N64 used HARDWARE anti-aliasing, disabling it should have no impact on frame rate.

>>3094267
N64's undeserved shitty image quality was a mix of composite and vaseline, then texture filtering was like fanning the flames. Poor N64.

>>3094257
>disabling the ``Anti-aliasing'' (ie. vaseline filter) on N64 games.

This doesn't disable the internal anti-aliasing, but the VI filter (aka the external post-process anti-aliasing). The N64 still does a stage of anti-aliasing in its GPU's blender unit, but nobody has yet worked out how to disable it in ROMs. Some of these GameShark codes also disable things like dither filtering and alpha filtering, but turning those things off is stupid for the most part.

>Guess Nintendo forced developers to leave it on.
No, they didn't force developers to leave it on. There are a handful of third party games on the system that have no anti-aliasing whatsoever, like World Driver Championship.

>>3094272
>N64 used HARDWARE anti-aliasing, disabling it should have no impact on frame rate.

You are right in the sense that the GPU itself won't be negatively impacted, however AA involves a large increase of reads and writes to the RAM. So turning AA off in theory should open up the RAM bandwidth improving performance in RAM limited situations (most of the time I'd say).

>>3094285
I always get a feeling from posts like this a unwarranted sense of superiority, that you feel that Nintendo were dumb as fuck or something and that you'd know better.

The reason the default microcode was provided is because it was extremely general and was suitable for any kind of genre of game you wanted to make due to its rich feature set and support for large polygons.

Also the reason so many N64 games use anti-aliasing is because composite (what every game was designed for) looks like GARBAGE with AA off. No, seriously. Try running these codes on a CRT through composite. It looks like shit.

Yes, it can look nicer when you're using a PVM with RGB, but the games weren't aimed at modders 15 years in the future.

>>3094326
>Try running these codes on a CRT through composite

I'd really like to see this fabled composite garbage. Would you gladly post a picture? OP's too scaled down to see anything.

>>3094343
Taking a photo of a CRT image never goes well.

Just try it yourself?

>>3094372
I don't even have half of the stuff required to make said pics. You can also use an LCD, the signal won't just magically change, if anything it'll be more accurate.

>>3094391
>if anything it'll be more accurate.

By definition it can't be more accurate if it has to get linedoubled.

N64's anti-aliasing was designed with two premises:

1) the display would be natively interlaced
2) the output would be suffering from composite artifacts

>>3094285
That's kind of dumb considering Nintendo owned Rare at the time (well, 49% of them).

>>3094397
>By definition it can't be more accurate if it has to get linedoubled.

Doesn't really matter since most games are sub 30 fps and interlacing artifacts rarely ever pop up so it's only going to have moving dot crawl as con and the output will look clear enough.

>1) the display would be natively interlaced

Not for most games it wouldn't

>2) the output would be suffering from composite artifacts

Who cares, I wanna see them pics.

>>3094421
>Who cares, I wanna see them pics.

As I said, taking a photo of a CRT using composite isn't going to give you a good image of what it actually looks like.

If you don't want to bother with GameShark codes, you can load up Quake 64. It officially has an option in its menu that allows you to enable or disable the VI filter.

>>3094294
"Hey does anybody know how we could make this game run a bit better?"
"GET GOOD SCRUB!"

>>3094421
>>3094430
I can try to take some photos. What are some good games to compare? Preferably something quick, i.e. something I can boot up and it'll already be showing me a demo mode or something.

>>3094460
Do you have GameShark or flashcarts? If so try Mario 64 in composite.

If not, Quake 64 and Turok have non-hacking ways to turn off the VI filter.

>>3094476
I have an ED64 plus that huge pack of filter-disabling patches. I can try just about any NTSC game in both composite and S-video.

I'll try SM64, just give me a bit.

File: sm64compositecomp.jpg (2MB, 1632x1423px) Image search: [Google]

2MB, 1632x1423px

>>3094476
Alright, here it is. Left side is how the game looks normally, right side has the de-filter patch applied. Both over composite.

>>3094613
Thought so, although the left side does look hella smoother the right side gives crisper details from a distance, and none of that artifact nonsense Anon was talking about over composite.

>>3094626
Well I should mention that my CRT is pretty high-grade (not PVM, but still a very good consumer model), so composite does look better on it than many other TVs. There are still noticeable composite artifacts and haze.

No matter the setup, though, I think filtered vs. unfiltered is entirely a matter of opinion. Unfiltered is certainly sharper no matter what, but the hard-edge jaggies can be distracting. Hazing over the image some more with filters can help make it less distracting and look more smooth overall, especially on a lower-grade TV.

I'm personally conflicted on which looks better. I use S-video myself, so filtered ends up looking grainy while unfiltered is jaggy central. I don't think there's a real sweet spot for N64 display in the modern day; it's going to look low-tech as fuck no matter what you do to it. Emulation is really the only way to make it look better, but I'm a fan of real hardware and I can deal with the low-tech look.

>>3094667
>so composite does look better on it than many other TVs

I don't think it works that way.

>>3094672
How do you think composite is converted to the CRT's internal format? It depends on the quality of the comb filters.

>>3094257
>>3094613
Are there supposed to be differences between the images on the left and the images on the right?

>>3094691
>CRT's internal format?

You mean RGB? By the way, a really cool thing to do would be using a capture card.

>>3094672
Yes it does. Composite has to come through a comb filter, and my TV has a "3D" comb filter which was usually what higher-end TVs used toward the late end of the CRT era. I have a Trinitron KV-27FV310, which had one of the best 3D comb filters Sony ever made. Its composite quality definitely looks better than a majority of other common CRTs.

>>3094713
Left images have an anti-aliasing filter, the right ones do not. If you can't tell the difference, this thread honestly isn't for you.

>>3094748
The other anons were talking specifically about composite on CRT, so that's what I took pictures of.

>>3094626
>still images totally look the same as motion

>>3094626
It wasn't about artifacts but blended colors that composite delivers make jaggies look much worse. Particularly in motion.

N64's AA was specially designed to remove jaggies in the overly color blended environment of composIte as it works through a special color blending algorithm. The result of this algorithm can look like a distorted blend if you use it on something other than composite. I am certain that is the real reason N64 never supported RGB.

File: combover.png (563KB, 599x800px) Image search: [Google]

563KB, 599x800px

>>3094613
THIS. CHANGES. EVERYTHING.

Literally. Look what it did to Samus in SSB here.

>>3094257
those look the exact same: a blurry as fuck photo of a television screen

>>3094257
Does this work with 2D games as well?

>>3094613
show me a comparison that isn't an extreme close-up photograph of a television so that we can actually see the difference between the two, and we'll talk

>>3094257
Rad.

>>3095845
That picture was not meant for you, it was meant for the other anons who were specifically talking about composite on CRT.

Though actually, if you can't already tell the difference in aliasing between those examples, then this filter mod won't do anything for you anyway. The difference in aliasing is pretty obvious even in my shitty photos.

>>3095874
I can tell the difference. Thanks for the pics. can you do goldeneye s-video?

>>3094446

It wasn't the developers' intention to make the N64 easy to create games on, so suck it up.

>>3095909
I'm in the process of making a little video using my actual capture card + s-video right now. I've honestly never played Goldeneye before, though, so if I show that one off, it's probably going to be embarrassingly bad gameplay.

>>3095926
Actually nevermind, I just booted it up and it has a nice little demo that it shows off by itself. I'll just record that.

You could turn off the anti-aliasing in the menu options in Doom 64. It wasn't forced on developers.

>>3095937
And quake.

File: anti-aliasing.jpg (110KB, 1037x330px) Image search: [Google]

110KB, 1037x330px

This is talking about the internal AA though, not the VI filter

Why would you want to turn off anti aliasing? That's so stupid.

>>3095874
>the difference in aliasing is pretty obvious
no, it isn't. in the op and your image all I see is a blurry television, that makes each side look the exact same.

>>3096160
Yes, it is. Particularly around Mario's nose, where it meets the mustache. Like I said, if you can't tell the difference, these patches probably aren't for you.

Anyway, I've uploaded a video showing a few games with the default AA filter on and then off. Quality's a little messy because my capture card is shit, but it should be more than sufficient enough to show the difference.

https://www.youtube.com/watch?v=HyZx_DaED7k

>>3096304
Yeah, really digging it when it's not enabled and it looks really good even in motion. Now we wait for the 60fps hacks that will run on real hardware.

>>3096304
Gotta say I prefer the anti-aliasing on. It'll take a small increase in blurriness in return for the jaggies and shimmering being purged.

Y'all gotta admit that the AA on the N64 actually does its job.

Turning AA off will only be worth it IMO once people start coming up with the hacks that can significantly improve performance.

>>3096323
I'm conflicted about it, personally. Over S-video on a high-quality CRT, both AA and no-AA look kinda poor. AA mode looks grainy and no-AA has that jaggy shimmer. AA mode does look smoother, but no-AA makes distant objects clearer. Each has a trade-off, and thus each is up to preference. But I still don't know which one I want.

I think no-AA looks alright for bright, colorful games where things are cartoony and defined anyway. AA on helps a lot for darker games with more detailed models and textures. You can REALLY tell in the Majora's Mask footage there. I tried to get some footage of Goldeneye too, but for some reason the patch wasn't working. I think it's safe to say that Goldeneye probably looks best the way it is, though.

>>3096304
thanks for the vid anon, quality post

File: jaggy.jpg (24KB, 418x354px) Image search: [Google]

24KB, 418x354px

>>3096341
>All the other consoles don't have any AA filter whatsoever and that's precisely how I like it

Eh Dreamcast has much the same thing, and I remember the eternal bitching when PS2 came out and had a complete lack of AA in its earlier games.

>but don't act like it makes all the difference or anything.
Makes a pretty obvious difference to me

>>3096304
Y'know what, I apologize.
I had my wires crossed and I (for whatever reason) was thinking that AA was the texture blurring that N64 does.
Please excuse my rude posts.

File: dsmario.jpg (25KB, 480x360px) Image search: [Google]

25KB, 480x360px

>>3096304
look like mario 64 for ds now

>>3094267
That shitty, blurry look N64 games all had is one of the main reasons I never bought one. It had a few cool games, but so many were 3D and just looked awful to me. They still do, though this actually looks a little better.

File: DSCN0237[1].jpg (456KB, 1600x1200px) Image search: [Google]

456KB, 1600x1200px

how I hoped the n64 looked on a flatscreen.

File: DSCN0230[1].jpg (457KB, 1600x1200px) Image search: [Google]

457KB, 1600x1200px

>>3097051
how it actually looks

>>3097054
Get a tripod you silly billy.

>>3094613
left one looks better and more high-res.

>>3097065
>more high-res.
You need your eyes checked.

>>3097084
no, i'm fine. you're autistic.

>>3097089
If you think the image on the left looks higher resolution then you're not.

File: giphy (1).gif (2MB, 534x300px) Image search: [Google]

2MB, 534x300px

>>3097092
>autism intensifies

>>3097065
They're literally the same resolution.

>>3097051
>>3097054
>stretched aspect ratio

Why are you even here?

File: mgs.png (176KB, 350x240px) Image search: [Google]

176KB, 350x240px

>>3097065
Such high-res, much increased detail.

>>3097109
He might be using the wide-screen code with it. Seems like the button overlay is stretched, but the graphics aren't.

>>3097103
but the anti-aliasing makes it look more high-res. that is the whole purpose of why it was implemented. kek

>>3097126
Good point. Maybe I spoke too soon.

Speaking of which, where can I find more N64 widescreen codes? That Assembler thread had someone talking about MK64 in widescreen, but are there others?

>>3097127
>but the anti-aliasing makes it look more high-res.

There's actually some truth to this. Filters can actually give the impression of a higher color depth.

See; 3dfx Voodoo 3

>>3097137
It will different for every game and harder to find general patches for, since it involves changing the viewport scaling (which could be really hard to get to unlike VI regs)

Actual n64 dev here, let me explain.

Antialiasing on N64 is happening in 2 seperate places at 2 separate times.

Case 1.
When multiple triangles/fragments are exactly adjacent to another, most of the time they will share an edge inside a single pixel. The blender inside the RDP shades the overall pixel based on what proportion of each fragment is showing. In order to do a blend, it has to read the pixels from the surrounding area out of RDRAM, modify it, and then write it back. This is called a RMW (read modify write) process and it has a deleterious effect on RAM bandwidth.
Whether this happens or not is specified by the RDP render mode which is most commonly an instruction in a display list that the RDP is executing. This displaylist could be dynamically generated by the CPU at runtime, or it could be a static blob that is loaded from cart, either uncompressed or compressed/encoded. (Most games at least compress their display assets).
So to disable or enable this, you'd need to patch all displaylists that set the AA_EN blender bit. A very tedious process that would be different for each game engine - basically extracting all the displaylists, then injecting back into the ROM and hoping it works. Very possible but very tedious.

But wait, we're not done yet - when this option is enabled, as it is most of the time, the blender ALSO saves "coverage information" alongside the visual data. This is crucial data for the other second case of doing AA, and yet again consumes precious RAM bandwidth. Fun fact: This is the only place the 9th bit of RDRAM is ever used.

The AA patches so far do not disable this first operation being done by the blender. As a result, interior polygon edges are still antialiased, and there is still a performance penalty.

Case 2.
When a polygon is rendered against an existing part of the background. The blender can't know how to blend the edges since it doesn't have a complete picture of what the result'll look like, and you can't just go blending willy nilly. So, the second stage is basically reading the coverage information the blender previously generated while drawing, and blending pixels at the time they are sent to the TV.
The VI (video interface) is the part of the RCP that does this - it generates the TV sync timings and does gamma boost, noise dithering, etc. As it pushes out the image to the screen, it's also looking at the coverage bits and blending pixels according to how the triangles were marked to overlap.
To blend, it must read out adjacent pixels from the buffer, then write the result back - another RMW cycle. Again, this kills ram bandwidth.
However, unlike Case 1, it's much easier to tell the VI to bypass this process - don't blend, and just output what is already in memory. This is what the Gameshark patches are doing - patching writes to the VI mode register to disable case 2 AA processing.

Performance.
Each step incurs a penalty on RAM bandwidth. Because the N64 uses a unified memory system, literally everything bangs on RDRAM constantly - CPU code, microcode, video rendering, texture fetching, video output, audio output... I believe that the single-channel Rambus system is probably the worst weak point of the N64 besides the tiny texture cache.
Every time the rambus controller has to service a new request, it has to drop what it's doing, service, and resume something else. As we all know Rambus has very good peak throughput (0.5 gigabyte/second on N64, which was very good at the time), but terrible latency. It's like using a Ferrari to drive around cramped city streets - it works, but not very well, and to really fly you have to go in a straight line without stopping.
Since many subsystems are hammering on the RAC, you want to minimize whatever you can. Disabling both steps of AA can have significant gains. Some other systems that cause problems are the RMWs incurred by using the Z-buffer (should be minimized), the divot filter, and the dither filter.

I tested with my MGC demo and found that with 640x340 framebuffers, turning on Case 1 halves throughput. Turning on Case 2 halves throughput yet again. So, in high-res with triple buffering, full AA can have a 4x speed penalty.
Many games only use double-buffering and the render time is quantized to the nearest Vsync (10hz, 15hz, 20hz, 30hz, 60hz etc) but disabling both AA cases would prevent slowdown in many games - but very difficult to implement.

Other performance hogs
Z-buffer - as before, reduces pixel fill rate by 2 to 3 times. Can't be turned off easily and most games would break without it.
Divot filter - in the VI, median filter patches 1-pixel holes left over by limitations in the AA. Has to load all adjacent pixel data with about 5-10% effect on performance. Easy to disable and the holes can be overlooked.
Dither filter - in the VI, basically smears the entire output to hide dithering. Similar performance hit. Easy to disable, but some games look downright terrible without it (Starfox)
Deflickered high-res modes - in interlaced mode, single-pixel details will flicker due to missing every other TV field. This mode reduces it by blending the field outputs with adjacent scanlines - again it requires accessing 2 scanlines just to output 1 which has a small performance hit. Easy to disable by patching all Y-scaling coefficients in game VI mode tables.

"Free" features
Gamma boost and dither - Applies nonlinear brightness curve to the output. Because the color output is only 21bits, there is a good reason to also enable gamma dither which has no performance cost - it's almost invisible yet prevents ugly mach banding.
TL;DR: AA on N64 is a multi-step process and so far it's only easy to nix the very last step, but some AA is still being done, and there are real performance gains if you can fix both processes.

>>3094713
Yeah look at the polygon edges. A lot of people think AA is to do with textures. That's mip mapping, I believe. This is smoothing the boundaries of polygons.

>>3097062
using it for my teloscope

>>3097109
its not stretched it's the [gamecube disc] running in progressive scan and zoomed to get rid of pillarboxing. looks burdy gud to me.

>>3094613
Wow, the differences are completely negligible.

>>3099809
>>3099812
>>3099816
>>3099823
Posts like these make /vr/ a great board. Very interesting info, thanks dude.

>>3094713
Look at where the edge of the nose meets the mustache on the giant Mario heads. Look at the edges of the trees and where the grass meets the brown ground in the in-game pictures. The edges with the Anti-Aliasing filter on are smoothed, the ones with the filter off are aliased (jaggy).

It's dangerous to go alone take this!

--{:::::::::::::::::>

>>3099809
>>3099812
>>3099816
>>3099823
thank you marshall you are BASED

so is it actually the dither filter which causes that 'vaseline effect' that so many people bitch about, not the VI AA?

i ask this because as you say at least the VI AA reads the coverage filter which guides it in what it does while the dither filter probably runs across all of the screen pixels

>>3101162
*coverage values

>>3094257
Does this mean Perfect Dark can run at a framerate above 10?

>>3101197
Try playing the Japanese version of Perfect Dark, runs really really well

>>3101162
Marshall? You mean as in B Rogers?

>>3101232
don't think that's the same one

>>3101242
Ah. Well there was a dev who was working on the mutliplayer OoT hack who went by that name. Would have been curious if it were the same guy.

>>3099809
I gotta say I love how N64's RAM has a secret 9th parity bit like servers/workstations.

It means that the 4MB/8MB is actually a little bigger than it seems.

File: ra55e62c28c7e226e8e.png (180KB, 1256x853px) Image search: [Google]

180KB, 1256x853px

>>3101162
Dither filter is a big part of it sure, divot filter also sometimes replaces pixels it thinks are holes but aren't (this occurs when a polygon is almost invisible due to being perpendicular to the screen plane).

If you select AA processing in the VI, but don't have the RDP generate coverage information previously, it still slows down a bit even though it doesn't do anything.


Also, the other part is when the N64 displays a 320x240 game, it actually outputs 640x240 which is twice as wide - it stretches it with a filter. Some games use other horizontal resolutions, like 512 wide or 400 wide. If the internal framebuffer is not 240 high it will be resampled to fit the output.

>>3101252
Not me, that was cendamos or whtaever he calls himself.

>>3094613
Man I have a ED64 plus but it does not have the option to use codes, this de-filther patch can be applied directly to the rom so it can boot if the filter off? Can you provide a link , thanks in advance.

>>3099809
Why is it so difficult for N64 hardware plugins to emulate N64 pixel coverage? It's used for a variety of N64 games for depth checking and also fancy stuff like pen and ink mode.

>>3102934
it requires full LLE and is very annoying.

So it won't even happen for anything higher level.

>>3102910
http://n64.poregon.com/shared/

>>3101930
>lso, the other part is when the N64 displays a 320x240 game, it actually outputs 640x240 which is twice as wide - it stretches it with a filter.

cheers

any reason why it did this? i can imagine this built-in scaling would be a headache for anybody trying to connect their N64 to a modern TV

does the HDMI mod's vi de-blur mode specifically try to counter this scaling? that's what I heard

>>3103235
my flat screen handles it fine. not sure if I left the aspect on full though