User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
super_mario_64:console_compatibility [2018/03/04 08:20] david [The Project64 problem] |
super_mario_64:console_compatibility [2018/03/04 15:45] david [The problem with N64 emulators] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ======== Console compatibility with SM64 ROM hacks ======== | ======== Console compatibility with SM64 ROM hacks ======== | ||
| - | (add info here) | + | This page lists the problems found over the past few years to help figure out how to get custom SM64 ROM hacks to work on real N64 hardware. Each issue that we have discovered is detailed here, and also includes ways to fix those issues. |
| ===== Issues ===== | ===== Issues ===== | ||
| Line 25: | Line 24: | ||
| To fix this issue, we will have to look through the entire ROM file and adjust every 0x17/0x18/0x1A level script commands that have odd ROM address values. Thankfully, some people have made tools to do this automatically [[https://smwc.me/1374314|like queueRAM's sm64compress tool]]. | To fix this issue, we will have to look through the entire ROM file and adjust every 0x17/0x18/0x1A level script commands that have odd ROM address values. Thankfully, some people have made tools to do this automatically [[https://smwc.me/1374314|like queueRAM's sm64compress tool]]. | ||
| - | If you want to make your own tool that will implement this fix, then just follow these steps: | + | If you want to make your own tool that will implement this fix, then you can follow these steps: |
| 1.) Look through all of the levels scripts to find 0x17/0x18/0x1A commands | 1.) Look through all of the levels scripts to find 0x17/0x18/0x1A commands | ||
| 2.) Test if either the ROM start address or ROM end address is odd. | 2.) Test if either the ROM start address or ROM end address is odd. | ||
| Line 37: | Line 36: | ||
| ==== Improper use of Fast3D's SetCombine (0xFC) command ==== | ==== Improper use of Fast3D's SetCombine (0xFC) command ==== | ||
| + | {{:super_mario_64:nofog-nofix_zpsgm0vpfw8.gif|}} | ||
| + | |||
| + | In the display lists that draw the level's triangles, you might see a 0xFC command near the top. This is the command that will configure the RDP's color combiner. Like it's name suggests, the color combiner will take in inputs from many different sources and combine them into a single color that affects how the polygons in a model will look. Basically, using a wrong combine value will cause the level to not look the way you want. | ||
| + | |||
| + | The problem with earlier versions of the SM64 Editor is that it only used a single 0xFC command for all of the display lists: '' **FC 12 7F FF FF FF F8 38** ''. This one command was only meant to work with solid RGBA textures in levels that have fog. For levels without fog, all of all the geometry will just flash between different solid colors. (see gif above) | ||
| + | |||
| + | **How to fix it?** | ||
| + | |||
| + | To fix this issue, we need to go through all the Fast3D display lists of every single level and determine if the 0xFC is fine to use or not. If the wrong 0xFC command is being used, then we need to replace it with a correct one. There are 4 0xFC commands that we need to know: | ||
| + | |||
| + | FC 12 7E 24 FF FF F9 FC = Solid RGBA texture (No fog) | ||
| + | FC 12 18 24 FF 33 FF FF = Alpha RGBA texture (No fog) | ||
| + | FC 12 7F FF FF FF F8 38 = Solid RGBA texture (With fog) | ||
| + | FC FF FF FF FF FC F2 38 = Alpha RGBA texture (With fog) | ||
| + | |||
| + | We don't need to worry about other texture formats, since every single version of the SM64 Editor has only ever used RGBA16 textures. | ||
| + | |||
| + | To figure out if a level has fog or not, you will have to look at any [[super_mario_64:fast3d_display_list_commands#b7f3d_setgeometrymode|0xB7 (F3D_SETGEOMETRYMODE)]] commands that you see before a 0xFC command occurs. If the parameters contain a 0x10000 flag, then fog will be enabled in the level. | ||
| + | |||
| - | (add info here) | ||
| ---- | ---- | ||
| Line 46: | Line 63: | ||
| {{youtube>SoHqFRqnwGw?small&start=125}} | {{youtube>SoHqFRqnwGw?small&start=125}} | ||
| - | Some versions of the SM64 Editor, like v1.9.3S, will have warping polygons when the player is moving around the level. This issue was caused by Skelux setting the camera frustum's far value to be a negative number (0x9696 = -26,986) in the [[super_mario_64:geometry_layout_commands#aset_camera_frustum|Geometry Layout Command 0xA (Set Camera Frustum)]]. | + | Some versions of the SM64 Editor, like v1.9.3S, will have warping polygons when the player is moving around the level. This issue was caused by setting the camera frustum's far value to be a negative number (0x9696 = -26,986) in the [[super_mario_64:geometry_layout_commands#aset_camera_frustum|Geometry Layout Command 0xA (Set Camera Frustum)]]. |
| **How to fix it?** | **How to fix it?** | ||
| - | This issue can be fixed by changing the camera's far value back to being a positive number. The largest possible positive number is 0x7FFF (32767). | + | This issue can be fixed by changing the camera's far value back to being a positive number. The largest possible positive number is 0x7FFF (32767). A simple way to fix this problem is to look through all the bytes in the ROM file and find a specific pattern of bytes: |
| + | |||
| + | 1.) Find all occurrences of: 0A 01 00 2D 00 64 96 96 80 29 AA 3C | ||
| + | 2.) Replace occurrence with: 0A 01 00 2D 00 64 7F 7F 80 29 AA 3C | ||
| ---- | ---- | ||
| Line 62: | Line 82: | ||
| **How to fix it?** | **How to fix it?** | ||
| - | To fix this issue, you only need to revert the two bytes back to normal. Just change the two bytes at ROM offset 0xF00C2 to '' **02 0D** ''. | + | To fix this issue, you only need to revert the two bytes back to normal. Just change the two bytes at ROM offset 0xF00C2 to '' **02 0D** ''. Once that is done, make sure to use a program like //n64crc.exe// to recalculate the ROM's checksum. |
| ---- | ---- | ||
| Line 76: | Line 96: | ||
| ---- | ---- | ||
| - | ===== The Project64 problem ===== | + | ===== The problem with N64 emulators ===== |
| + | |||
| + | As we all know, Nintendo 64 emulation has never been perfect in the 20+ years since the console's release. This is mainly due to the architecture that was created by Silicon Graphics back in the mid 1990's. The console truly was a unique piece of hardware. While most N64 emulators do a good enough job for casual players who want to only play games, there are some inaccuracies that can create problems for ROM hackers. | ||
| - | Project64 is a popular, and performance friendly, Nintendo 64 emulator that was initially created back in 2001. While it is highly compatible with most of the N64 library when it comes to casual players, it is not cycle accurate and depends on plugins for graphics and audio. This fact makes it easy for us, as ROM hackers using the emulator, to unknowingly create the issues seen above. It is not so much the emulator itself that is the main problem, but rather the fact that most SM64 hackers will only use Project64 that creates these problems. | ||
| ===== See Also ===== | ===== See Also ===== | ||
| [[super_mario_64:list_of_console_compatible_hacks|List of console compatible ROM hacks]] | [[super_mario_64:list_of_console_compatible_hacks|List of console compatible ROM hacks]] | ||
