FAQ

From Ukikipedia
Revision as of 13:28, 19 July 2018 by MMMMMMMMMMMMM (talk | contribs) (→‎How many A presses are left?: Fixed ridiculous mistake)
Jump to navigation Jump to search

FAQ (Frequently Asked Questions)

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-rr. The other emulator you can use is 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.

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.

What is STROOP?

STROOP (SuperMario64 Technical Runtime Observer and Object Processor) 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?

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.

The Current Version: 0.5.1 (for windows) 0.5 (for Linux) The Current Version (rerecording): 0.5

Where can I get a SM64 rom?

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.

Challenges?

Ukikipedia made a page about 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.

How many A presses are left?

0 A presses for any% with Virtual Console and 1 A press for any% WITHOUT WiiVC 23 A presses for 100% excluding WiiVC

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?

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.

How are you decompiling the game?

"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, J, Shindou, PAL I think

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 he 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

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

- bad boot"

(fix this aswell so it actually looks a bit nicer than it actually is lol)