|
|
| Line 3: |
Line 3: |
| ==How do I TAS?== | | ==How do I TAS?== |
|
| |
|
| [[TAS]] (otherwise known as Tool Assisted Speedrun or Superplay) is most commonly done with frame-perfect inputs and a number of glitches that the developers never knew existed. While regularly playing the game, you get to experience the whole environment they dedicated a long time developing on. While speedrunning a game, you make up your own rules and try to beat the game as quickly as possible. A TAS in it's typical natural is a special category where you once again appose a new set of rules on your game of choice, but instead of looking what is humanly possible, displays of what the run would look like if a human can be 100% accurate with their input on the controller on every single frame. To make a TAS, you need 3 features on an emulator: Save-States, Slow-down, Frame Advance. These are most common features used to make a TAS video. TASing doesn't require 5 minutes of work, it requires more than 2 hours to make up a run, and a single TAS that last 2 minutes could take weeks to optimize and make the run look perfect. In order to TAS, you would need an emulator, most people use [[Mupen64|mupen64-rr]]. The other emulator you can use is [[Emulators|Bizhawk]] but Bizhawk has inaccurate emulation, Mupen64 is more preferred than Bizhawk. There's also Memory Watch, which is optionally used to optimize frame perfect inputs. Most common is the mupen64-rr Memory Watch, or [[STROOP]]. | | [[Basic Mupen64 TAS Tutorial]] |
|
| |
|
| ===Why Mupen over Bizhawk?===
| | ==Why Mupen over Bizhawk?== |
|
| |
|
| Mupen64 is more better than Bizhawk because Mupen64 is much more better in terms of emulation and is simple to use. Bizhawk does have multi-console emulation, but if you make a Bizhawk recording and try to play it back on mupen, it will not work. TASVideos in 2016 announced that they will reject any TASes that have been recorded via mupen64, which means any TAS video that has been made with Mupen, will be rejected. | | Most TASes of Super Mario 64 are done on [[Mupen64]]. This is for two reasons, one, the M64 file can be played back on console, known as [[Console Verification]] and two, Bizhawk polls inputs on lag frames as opposed to Mupen64, which doesn't. BK2 files (Bizhawk movie files) can still be converted to M64 files however. |
|
| |
|
| ===What is STROOP?===
| | ==What is STROOP?== |
|
| |
|
| [[STROOP]] ('''S'''uperMario64 '''T'''echnical '''R'''untime '''O'''bserver and '''O'''bject '''P'''rocessor) is a diagnostic tool for Super Mario 64 which displays and allows for simple editing of various game values and information. It can connect to a running emulator and update values in real time. Some core features include views of loaded/unloaded objects, Mario structure variables, camera + HUD values, an overhead map display, and many more. | | [[STROOP]] ('''S'''uperMario64 '''T'''echnical '''R'''untime '''O'''bserver and '''O'''bject '''P'''rocessor) is a diagnostic tool for Super Mario 64 which displays and allows for simple editing of various game values and information. It can connect to a running emulator and update values in real time. Some core features include views of loaded/unloaded objects, Mario structure variables, camera + HUD values, an overhead map display, and many more. |
|
| |
|
| ===What is Mupen?===
| | ==What is Mupen?== |
|
| |
|
| Mupen (otherwise known as mupen64) is an emulator used for n64 games and super mario 64. The emulator was first released as a public version in 2001-12-10, the emulator is able to do slow-downs, rerecords and savestates if using mupen64-rr. | | Mupen (otherwise known as Mupen64) is an emulator used for N64 games and Super Mario 64 that is most commonly used for TASing |
|
| |
|
| The Current Version: 0.5.1 (for windows) 0.5 (for Linux)
| | ==Where can I get a SM64 rom?== |
| The Current Version (rerecording): 0.5
| |
|
| |
|
| ===Where can I get a SM64 rom?===
| | A quick google search can help you with that. Unfortunately we cannot provide links here because of copyright. |
|
| |
|
| You can get the SM64 rom from a quick google search, we cannot provide the links here because of copyright. We will not include any links (except screenshots) for any ROM hacks.
| | ==How many Challenges do we have?== |
| | |
| ===Challenges?===
| |
| | |
| Ukikipedia made a page about [[Challenge|challenges]], which features restricting button presses, joystick movement, not using any cannons aswell as caps.
| |
| | |
| ===How many Challenges do we have?===
| |
|
| |
|
| As of right now, we currently have 11 challenges. | | As of right now, we currently have 11 challenges. |
| Line 44: |
Line 37: |
| *[[The Floor is Lava Challenge]] | | *[[The Floor is Lava Challenge]] |
|
| |
|
| ===How many A presses are left?===
| | ==How many A presses are left?== |
|
| |
|
| 0 A presses for any% with Virtual Console and 1 A press for any% WITHOUT WiiVC | | 0 A presses for any% with Virtual Console and 1 A press for any% WITHOUT WiiVC |
| Line 50: |
Line 43: |
| 23 A presses for 100% excluding WiiVC | | 23 A presses for 100% excluding WiiVC |
|
| |
|
| ===Is a 70 Star 0 A press run being developed?===
| | ==Is a 70 Star 0 A press run being developed?== |
| | |
| On the n64 side, yes. On the WiiVC side, no.
| |
| | |
| The WiiVC TAS is not being developed because we can't use a m64 file and execute it on the WiiVC because the movement gets desynced over time.
| |
| | |
| (needs correction lol)
| |
|
| |
|
| ===What's the next A press save going to be?===
| | No. |
|
| |
|
| We do not know. We are always attempting new ideas and new methods in order to make another save, but ultimately we are never absolutely certain that what we try out will achieve one. The current progress has been on Tick Tock Clock as of recent, which has managed to save 2 A presses.
| | A WiiVC TAS is not being developed because there is no way to console verify a TAS on WiiVC at the moment and even if there was, WiiVC polls inputs on lag frames, meaning that the TAS would become desynced over time. |
|
| |
|
| ===How are you decompiling the game?=== | | ==What's the next A press save going to be?== |
|
| |
|
| "It turned out that the reason we couldn't figure it out for so long was because the devs used the "-g" flag in the final version of the game, It's the same compiler for US, PAL(?), J, Shindou. The -g flag is for debugging, it basically disables a bunch of optimizations. You're not supposed to ship games with that kind of flag, even Nintendo told developers to be careful not to but they did. And that's really, really good for us since lack of optimization simplifies decompilation a ton. But they removed it in the Shindou version, which is why the game runs faster. Once you have the decompiler, you just start writing C code based on the assembly code, which we've been doing for a long time, but then you have to make the code match, meaning it compiles into the same assembly code and that is sort of trial and error, but once you learn how the compiler works, it becomes pretty routine.
| | The short answer is we don't know. We are always attempting new ideas and new methods in order to make another save, but ultimately we are never absolutely certain that what we try out will achieve one. The current progress has been on Tick Tock Clock as of recent, which has managed to save 2 A presses. |
|
| |
|
| We get the assembly code from the rom. We used a hacking tool to help split it into assembly and assets, and to do some preprocessing on the assembly code. Worth noting for anyone who doesn't know much coding, when the stuff is decomped it loses nearly all labels, comments, etc. So getting back the logic and formulas is only part of the battle, you still have to go through and make the code readable."
| | ==How are you decompiling the game?== |
|
| |
|
| - bad boot
| | Essentially, we've figured out the compiler that Nintendo used for Super Mario 64 and then we get the raw assembly from the rom, and see what C code compiles into that. This is a long and tedious process but many prominent members of the community have made excellent progress so far. |