Is it possible to disable anti-aliasing in N64 games via GameShark cheats?

Discussion in 'Nintendo Game Development' started by mdmx, Feb 4, 2016.

  1. Poregon

    Poregon Member

    Joined:
    Feb 17, 2016
    Messages:
    16
    Likes Received:
    10
    Goldeneye works fine for me and is hideous with AA off, like the other Rare games... but does not crash when the watch comes up/goes down. Your patch must have done something screwy. Use the IPS files I linked.
     
  2. S3M

    S3M Rising Member

    Joined:
    Sep 20, 2011
    Messages:
    56
    Likes Received:
    4
    It's great to see what you guys are doing here as the N64 fog is the bane of the system. To think it was just some crappy filter Nintendo had the N64 output much like the original Xbox. Tempted to test this out on a few games myself.

    As a UK member will these codes work with an Action Replay for the system or only a Gameshark? The reason I ask this is that looking at amazon and ebay here in the UK the Action Replay is cheap and easy to find where as the Gameshark is rather hard and pricey much more common in the USA. That said looking at the N64 AR and GS I'm wondering if they are the same device and it's just that AR was the European branding and GS was the USA.
     
  3. rso

    rso Not a member. You're imagining things.

    Joined:
    Mar 26, 2010
    Messages:
    2,125
    Likes Received:
    413
    Same devices under different branding afaik.
     
  4. Try4ce

    Try4ce Member

    Joined:
    Feb 26, 2016
    Messages:
    7
    Likes Received:
    7
    Hey everyone. This is Try from My Life in Gaming. I don't know if any of you are familiar with our videos, but we do a series on getting the best picture quality out of retro consoles. We were lucky enough to have an opportunity to include the Ultra HDMI in our N64 episode ahead of its release:


    We've been getting a lot of comments about what you all have going on here, and it's something our audience would definitely like to see addressed. There seems to be a misconception that this is an alternative to the Ultra HDMI's de-blur effect, but as far as I can tell, they're actually two completely different things (I bought my own Ultra HDMI in December). I tested the Mario Kart 64 code last night with my very outdated GameShark 1.06, and the result was exactly what I expected.

    Here's Ultra HDMI, no de-blur, no GameShark:
    [​IMG]

    Turning on the de-blur effect gives us this, which has VERY clean HUD elements:
    [​IMG]

    OK, so let's turn the de-blur off again, but add the GameShark code. As I expected, this does NOT improve 2D elements:
    [​IMG]

    Combining the power of the Ultra HDMI de-blur with the GameShark code, we get this:
    [​IMG]

    Please correct me if I'm wrong, but as far as I know, the N64's "blur" is essentially a two-step process.

    1. There's the basic anti-aliasing, which is completely outside the scope of the Ultra HDMI's capability to "fix." This is what the GameShark can change.

    2. Then there's an additional horizontal blur added before the final video output. Through whatever witchcraft, the Ultra HDMI is able to restore the image to a much cleaner state in its final output. I suspect this process happens past the point where the GameShark could have any influence, but again, correct me if I'm wrong.

    If I were to throw in my personal opinion, I don't think I'm too into the GameShark anti-aliasing removal, but I LOVE the Ultra HDMI's de-blur. I love seeing the sprites in the way they were originally drawn, and it improves the clarity of the overall scene as well. While I am certainly a fan of the PlayStation look as well, I feel like the N64's basic anti-aliasing, combined with the de-blur, makes a nice middle-ground, and that the complete removal of anti-aliasing isn't necessary. But since my GameShark is so old, there's not a ton of games that I can test, so I'd need to see more games to really form an opinion (I think GoldenEye is the "newest" game that mine works with).

    Regardless, this is pretty fascinating stuff, and we'd love to address it in a shorter video on our channel. If anyone would like to collaborate to help us come to a better understanding of what's going on here, how to explain to people how they could generate their own codes (you're figuring this out with some sort of software?), and help us come up with more codes to feature, that would be great! I'm in the US, and Mario Kart 64 was the only code I could find in this thread that was for a game old enough to work on my GameShark. We would also like to be able to point people to an easy-to-browse resource that includes the codes... is anyone planning to make one?

    To be honest, most of the talk in here flies over my head... flipping the flags, generating the codes, etc. We always like to break things down in such a way so that people who, like us, aren't modders and hackers, can enjoy the results. So any help that could be provided to clarify things would be much appreciated!
     
    sa1 likes this.
  5. saturnu

    saturnu Spirited Member

    Joined:
    Dec 8, 2011
    Messages:
    143
    Likes Received:
    27
    Hm lets try to explain this a bit more, feel free guys to correct me. ^^
    I don't think i get all this stuff correctly written down. ^^



    GS-Codes
    8102316C 0000
    8102316E 3216



    The GS-Code 81XXXXXX YYYY means, that 16Bit (2Byte) at addr 0xXXXXXX are continuously written to this memory location.
    This example code writes at 0x2316C the value 0x00003216 to one of the mostly two buffered
    VI_STATUS_REG settings for each framebuffer?
    i think it's read, bufferd, altered and written back by the vi_register.


    binary translation:
    0x00 0x00 0x32 0x16

    MSB->
    00000000 00000000 00110010 00010110 <-LSB
    (a byte mostly has 8 Bit, the bytes here are filled up with zeros to the left)


    The LSB (least significant byte) is right and you read it to the left side.

    In the following description the first number is the posituon in decimal from the right to the left. counting starts at 0 e.g. like it's done on an c array.
    the functions are disabled with 0 or enabled with 1, if there is more than one bit you have to convert the dec value to binary. e.g. 3d to 11b


    0x04400000 - VI_STATUS_REG or VI_CONTROL_REG - VI status/control (Read/Write)
    Bit Expl.
    0-1 Type (Pixel Size) (0-3, see below)
    >>> 0 = blank (no data, no sync)
    >>> 1 = reserved

    >>> 2 = 5/5/5/3 ("16" bit)
    >>> 3 = 8/8/8/8 (32 bit)
    2 Gamma Dither Enable (normally on, unless "special effect") adds noise to lsbs of the pixels
    3 Gamma Enable (normally on, unless MGEG/JPEG)
    4 DIVOT Enable (normally on if antialiased unless decal lines) this is part of the aa algo and adds in some median valued pixels around outlines

    5 reserved - always off <- don't turn this on, hardware damage can be a result
    6 serrate (always on if interlaced, off if not)
    7 reserved - diagnostics only

    8-9 anti-alias (aa) mode
    >>> 0 = aa & resamp (always fetch extra lines)
    >>> 1 = aa & resamp (fetch extra lines if needed)

    >>> 2 = resamp only (treat as all fully covered)
    >>> 3 = neither (replicate pixels, no interpolate)
    10 <- reserved

    11 reserved - diagnostics only
    12-15 reserved -> this should always be 3
    Extra: 16 dither filter enabled: this bit is in the next byte and the next gs-code (the third one)
    you have to clear this to get rid of AA?
    what this does is reversing the dither filtering and leave it to the rdp, it's used on 16bit mode but not on 32bit mode.

    Here is a normal low res vi_status_reg setting, look how the "dither filter" is enabled in the 3rd byte.
    0x0001311e

    if all bits are set, you can convert these binary numbers back to hexadecimal

    n64.icequake.net/mirror/www.ji…N64TEK.htm#videointerface
     
    Last edited: Feb 26, 2016
    Poregon likes this.
  6. AtomizerZero

    AtomizerZero Enthusiastic Member

    Joined:
    Aug 13, 2013
    Messages:
    588
    Likes Received:
    112
    I thought there was no text in your post, but it turns out you're using white. I'm using the white/blue theme, so I can't see your text without highlighting it first.. minor annoyance, but thought i'd let you know.

    To be honest, the website should have something in place to stop this from occurring (like, If using XTHEME -> White text = Black, or something like that). Yellow is hard to see on white too, as well as lime green.. Maybe I should make a suggestion post about this.
     
  7. Try4ce

    Try4ce Member

    Joined:
    Feb 26, 2016
    Messages:
    7
    Likes Received:
    7
    Thanks for the info! I have to admit that it doesn't make much sense to me, but I showed it to a friend who understands coding stuff, and I'm kinda starting to understand.

    So each game is going to have different codes, different memory addresses to tweak, right? What are you using to analyze the game to determine what address to tweak? How are people figuring these out? Is there trial and error involved, or is it easy to find, for people who are used to this? I would definitely like to see more US codes to test out!

    Sorry to ask questions like these, I'm just trying to figure out how to translate this stuff into layman's terms for our video.
     
  8. xdaniel

    xdaniel Robust Member

    Joined:
    Feb 14, 2011
    Messages:
    213
    Likes Received:
    16
    I can try to help a bit with the "how to generate your own codes" part. There's two ways to create the GameShark codes I know of: the first would be using an emulator with memory viewing/editing capabilities (ex. Nemu64) and ROMs of the games, while the second would be using a GameShark capable of linking up to a PC for code generation.

    The first way, via emulation, is probably the easiest as it just requires a copy of Nemu64 v0.8 and the game's ROM image. Leaving the matter of acquiring the ROM aside, it's quite simple. Boot up the game in Nemu, then go into the "Plugins" menu, then select "Debugger: Memory..." to open up the Memory window. There, use the "Address" textbox to go to address A4400000, which is the system's VI_STATUS register, and take note of the 4-byte/32-bit value there - in Mario Kart 64's case, it's 00013016. Now, click the "Search..." button, put that value into the "Search value" textbox (making sure "Hex" is checked and "32 bits (aligned)" selected to the right of it) and click "Search". You'll hopefully wind up with only two possible results, both exactly 0x30 hexadecimal (48 decimal) bytes apart. Make note of both addresses. If you want, you can also double-click them to go to the address in question in the memory editor. For MK64, the two results are 000EB3DC and 000EB40C. I'll get to what to do with these two addresses after describing the alternate way.

    Screenshots:
    [​IMG]
    [​IMG]
    [​IMG]
    [​IMG]

    The second way is more involved, as it requires some hardware, as stated before: namely an N64 (obviously), a GameShark Pro with a functioning parallel port on the back, a PC with a parallel port (I believe USB adapters for connecting printers won't work), the game you want to find codes for, and, if the game requires a GS keycode to boot (Zelda, F-Zero, etc.), another game like Super Mario 64, Mario Kart 64 and most others to boot the system, to select the correct keycode, then turn the system off again, swap in the cart that needs the keycode, and then turning everything back on. I should note that the whole procedure can be quite unstable regardless of the setup, and I, personally, have had the best luck using a Windows 98 setup on an old laptop, although at least the "Game Software Code Creator" tool, GSCC for sort, is supposed to also work under Windows XP, at least. See the Kodewerx EnHacklopedia for more details about the PC connection.

    With the N64 booted up and on the GameShark's main menu screen, have the GSCC software on the PC detect the proper settings for communication in its configuration screen, then start the game on the N64 with the Code Generator turned ON. Once somewhere in-game, go to GSCC's RAM editor via the menu "Ram Edit", then "Open Window". Once there, click the "Goto Address" button, then enter "0xA4400000" as the address and click "Goto". The main editor window will now show the memory starting at address A4400000, where you should find the same values as with the Nemu64 method, i.e. 00013016 for MK64. Now, press the "Find Memory" button next to Goto Address, put the value into the "Find What" textbox, make sure "Hex" is selected for "Value" and press "Find Now". This'll freeze the game until the value has been found in memory, so don't be alarmed. Once the value has been found, the game resumes and the RAM editor jumps to the value's location, in this case, again, 000EB3DC (or rather 000EB3D0, as that's how the display works, but the result is in fact at 000EB3DC). Once again, there's another copy of the same value 0x30 bytes away.

    Screenshots:
    Sorry it's only two, as I mentioned this setup can be kinda unstable, plus that old laptop isn't the fastest, etc.

    [​IMG]
    [​IMG]

    Now, what values to write to these addresses, and how to turn them into GameShark codes. My codes so far have done two things: one, disable the dither filter (which removes dithering in 16bpp display modes), and two, change the anti-aliasing mode to only resample, not anti-alias. What exactly the four AA modes do I honestly can't say for certain; other people like saturnu or Zoinkity know much more about the N64 hardware than I do. Also, this'll be a very simplified breakdown, so you might want to refer to saturnu's post above for more details about the bits in the register, etc.

    First, let's remove the anti-aliasing. The AA mode is encoded in bits 8 and 9 of the VI_STATUS value, which in MK64's case are set to 0, 00013016. Note that this digit could theoretically be something higher than 3, in which case you'd need to do some math to modify only the bits you need. Changing this to 00013216 will disable AA while keeping resampling enabled. I'm not sure if this is an issue on my end, but if I set this to 3, i.e. 00013316, I tend to get scrambled video output on my NTSC system and some distortion on my PAL machine (see the comparison photos below and this previous post of mine).

    [​IMG]
    [​IMG]

    Next, removing the dither filtering. Bit 16 in the VI_STATUS value controls this, which is set to 1 in our MK64 example, 00013016. Thus, disabling the filter is as simple as changing 00013016 to 00003016, and putting the two together, we turn 00013016 into 00003216.

    Finally, the easiest way to turn this into a GameShark code is by turning it into two 16-bit writes. Split the changed value of 00003216 into two, i.e. 0000 and 3216. 16-bit writes are prefixed with 81 before the address, so the addresses we've written down, 000EB3DC and 000EB40C, become 810EB3DC and 810EB40C, and because we need to use two writes per location, we'll need four codes in total, 810EB3DC, 810EB3DE, 810EB40C and 810EB40E. Thus, the final codes are 810EB3DC 0000, 810EB3DE 3216, 810EB40C 0000 and 810EB40E 3216.

    I hope this is in any way useful, no matter to whom. If there's anything wrong with my explanations, feel free to correct me, or if there's any questions, I'll try to answer them.

    (Edit: fixed some minor errors)
     
    Last edited: Feb 26, 2016
    Poregon likes this.
  9. saturnu

    saturnu Spirited Member

    Joined:
    Dec 8, 2011
    Messages:
    143
    Likes Received:
    27
    i would like to add, that so called master codes or enable codes are often needed in addition to get the aa codes working.
    if you are using roms to create the codes you should keep in mind, that games - beside the obvious region can have different internal game versions. this can result in different memory locations for the same game.

    i'm using a modifed version of mupen64plus with a 2.5 debugging core to create codes.
    it plays a lot of games but it's not very userfriendly. ^^
     
    xdaniel likes this.
  10. xdaniel

    xdaniel Robust Member

    Joined:
    Feb 14, 2011
    Messages:
    213
    Likes Received:
    16
    Right, I forgot to mention the Master codes and game revisions. If the game in question already has codes stored in the GameShark's default code list, then it'll already have its master code stored (listed as "(M)" codes on my GS Pro v3.3) if one is required, otherwise no codes would work. If the game's not already on the list and the codes won't work when you try them without a master code, you'll have to look up the proper code on the internet. I did have some issues finding the proper one for my PAL copy of Smash Bros., but you should be able to find the right codes (by trial and error, if need be) for most games online.

    Some games, like Zelda: Ocarina of Time, have had multiple revisions - NTSC had three, PAL had two - so you'll have to make sure to use the ROM corresponding to your cartridge's version, as there can be (and in OoT's case, there are) memory location differences, as saturnu said.

    Also, I forgot to mention that I used the US NTSC version of Mario Kart 64 in my example above, just to make that clear.
     
  11. DoctorPain99

    DoctorPain99 Newly Registered

    Joined:
    Feb 26, 2016
    Messages:
    1
    Likes Received:
    0
    Found a couple of codes that I would like to share:

    Majora's Mask (USA):
    8109806C 0000
    8109806E 3216
    8109809C 0000
    8109809E 3216

    Ocarina of Time 1.1 (USA/JP):
    8100646C 0000
    8100646E 3216
    8100649C 0000
    8100649E 3216

    Donkey Kong 64 (USA):
    8101013C 0000
    8101013E 3216
    8101016C 0000
    8101016E 3216

    I'm not a big fan of how DK64 looks with the code on; it just seems to make the kongs have more jagged edges, as would make sense with disabling anti-aliasing. Majora's Mask certainly looks somewhat clearer with the code on, imo it has a bit of a washed out look with the code off. Enabling the code highlights flaws in the graphics more prominently though, so pick your poison. I couldn't even notice a difference with the OoT code. I'm not convinced it's working, but it should be the right code. Maybe someone else will have more luck.
     
  12. Try4ce

    Try4ce Member

    Joined:
    Feb 26, 2016
    Messages:
    7
    Likes Received:
    7
    Thanks for the additional info! While I don't think I'll be making my own codes anytime soon, it helps me understand what the process is.

    Is the main thing going on here just turning off anti-aliasing and dither? Are there other graphics features that the codes are disabling? Do those functions need to be turned off together to work correctly? What if someone wanted to turn off dithering, but keep anti-aliasing, for example, or vice-versa?
     
  13. xdaniel

    xdaniel Robust Member

    Joined:
    Feb 14, 2011
    Messages:
    213
    Likes Received:
    16
    Yep, the main thing the codes do is disable anti-aliasing and disable the dither filter, i.e. we basically "enable" the dithering that appears in 16bpp display modes (which is was the majority(?) of games run in) by disabling the filter that otherwise removes it. These are the only two features the codes in the thread toggle, but there's a few other bits in the register that one could experiment with, although I'm not sure if they'd change the image dramatically.

    The features can be toggled separately, although you probably won't see much of an effect if you just disable the dither filter. Also, I have run into some visual glitches before if I just change the AA mode and leave dithering untouched, but YMMV. So, the order of importance would in my opinion be, first the anti-aliasing, second the dither filter. To disable only one of the two, you just have to leave off the corresponding codes, which is easy in this case, as it just so happens that one of the two codes (the one with the lower address) toggles the dither filter, while the other (with the higher address) changes the AA mode.

    Let's have another look at the Mario Kart 64 (US) codes:
    810EB3DC 0000 and 810EB40C 0000 = disable the dither filter (original value was 0001, filter enabled)
    810EB3DE 3216 and 810EB40E 3216 = change the AA mode to resample only (original value was 3016, AA and resample)

    Thus, if you only activate the first two codes above, it'll only disable the dither filter, and if you only activate the last two, it'll only disable AA.
     
  14. SonicIce1

    SonicIce1 Newly Registered

    Joined:
    Feb 29, 2016
    Messages:
    1
    Likes Received:
    1
    Here's a bunch of old Vram dumps from the Gameshark I had.
    http://jord.altervista.org/n64.zip
    I guess the image is captured before the filtering/AA is applied. Weird how some of them like Goldeneye's menus are cropped off.
    Also did anyone ever notice that when pausing Mario Kart 64, the AA becomes disabled?

    Here's a shot of regular, and with the Gameshark codes posted. Taken through S-video into a capture card. You can clearly see how much sharper the rocks are, and also the Mario sprite.

    [​IMG]
    You know what's funny. The devs put so much work into adding this AA/filtering, and here we are trying to get rid of it.
     
    Last edited by a moderator: Jul 6, 2017
    BLUamnEsiac likes this.
  15. rso

    rso Not a member. You're imagining things.

    Joined:
    Mar 26, 2010
    Messages:
    2,125
    Likes Received:
    413
    "The devs" also put much work in not having RGB output (at least not for long)... Not all decisions made are necessarily good decisions.
     
    xdaniel likes this.
  16. xadox

    xadox Member

    Joined:
    Jan 18, 2016
    Messages:
    5
    Likes Received:
    0
    After testing some games with AA/dithering disabled I must say that I prefere the muddy AA look :)
     
  17. rso

    rso Not a member. You're imagining things.

    Joined:
    Mar 26, 2010
    Messages:
    2,125
    Likes Received:
    413
    If you don't mind me asking, what signal are you using? Composhite, S-Video, RGB, HDMI?
     
  18. Poregon

    Poregon Member

    Joined:
    Feb 17, 2016
    Messages:
    16
    Likes Received:
    10
    From personal experience using RGB (all just opinions):
    - All Rare games look better with it off.
    - Zelda titles look better off.
    - Mario games with blocky simplistic polygons and textures look fantastic. You can see more detail on Mario Kart/SM64/Golf.
    - If you add scanlines, it really adds to the benefit.
    - Gauntlet Legends looks much much better.
    - All 2D games like Magical Tetris/Dr. Mario look much much better.
    - Duke Nukem 3D is the best representative of this feature -- It clears the screen up significantly.
     
  19. brainpann

    brainpann <B>Site Supporter 2012</B><BR><B>Site Supporter 20

    Joined:
    May 1, 2011
    Messages:
    402
    Likes Received:
    6
    Has anyone tried Starfox 64? I feel like the AA was cranked up to 11 on tgat game.
     
  20. xadox

    xadox Member

    Joined:
    Jan 18, 2016
    Messages:
    5
    Likes Received:
    0
    RGB on 20" Sony PVM.
     

Share This Page