Ontario, CanadaHey all,
So, in light of some runs that were just recently submitted which were done on a Super Retro Trio, the question of what to do with clone systems like these has come up.
First some terminology so we're all on the same page. What we are in this forum thread calling a "clone system" is something like the Retro Trio, which contains a clone of a SNES (among others) implemented in hardware. The system isn't running an OS (such as Android, or whatever else). This is similar in many respects to an Analogue Nt, and many other similar types of clone systems implemented via FPGA's or what have you.
This is not to be confused with something like a RetroN which for lack of a better term, we will call a "emulator system" because it is basically a computer running an OS (commonly a mobile OS like Android) with software emulators pre-installed. The exact same emulator software that you could get on your PC or phone.
Currently for Star Fox, emulators are banned.
However, we have no such existing rules to deal with the hardware clone systems.
After some discussion today, we think that the best option is to allow these runs, but to always ensure that they are clearly marked as a run that was done on a clone system by mentioning it in the run comments (since speedrun.com doesn't give us many other options short of creating all new categories... yuck).
HOWEVER: Runs done on such a hardware clone system are done at the runners own risk. If it is deemed in the future that these runs are "bad" for whatever reason (e.g. some issue with the hardware is uncovered and we realize that the game runs too fast on the clone... or something else like that say) then we may need to remove these runs from the leaderboards. It's quite possible that nothing like this would ever happen, but consider this fair warning!
At any rate, we'd love to get the communities thoughts on this! Are we being too anal about it? Does someone have a better idea on how to handle it? Does this not even matter at all, and hey, let's just get back to playing Star Fox?
Let's talk about it!
Agree that this would be a great addition. I'd personally be fine with any reset point between routes so long as it's after the score is shown. As has been suggested already, perhaps either the fade out before the boss montage starts or the fadeout after that or at the first bit of text in the final credits, or whatever really. Not too picky, just the important part is obviously showing the percentage IMHO (in case someone wants to start doing a 100% version of the run, then at least everyone is already in the habit of letting the score being displayed before resetting. :) )
For the 3 asteroids to get into the Black Hole, most people will fly directly into the 3 brown asteroids and only destroy them at the last second. You have to fly through the exact spot that the 3 brown asteroids are at in order to spawn the Black Hole (those positions are like "trigger" points). Be sure that you don't just destroy the asteroids and fly away... once you shoot them keep flying through and then go on to the next one, etc. Hope that makes sense!
Ok good to know, thanks for confirming that you were just intending to use the Action Replay as a cart converter. :) Won't ever be a problem as long as no cheats are ever used.
Regarding modding a PAL SNES to 60hz. I don't see a problem with this for the purposes of running Star Fox, but you should know that a 60hz modded PAL SNES actually ends up running slightly slower than a real NTSC SNES (PAL 60hz mod = 59.56hz, real NTSC SNES = 60.10hz). If you're intending to do more speedrunning in the future with your SNES, I would recommend picking up a real NTSC console instead of doing a 60hz mod. But if you do decide to go ahead with the mod I think it would be fine.
Actually I dunno what I was thinking, even with our video submission requirements anyone could technically edit their video to remove Action Replay bits if they really wanted. We'd just have to catch them by actually looking at their video and noticing if they were doing anything that's not possible without cheats of some kind.
I assume you want to use the Action Replay 2 for the NTSC-J to PAL converter capabilities? I personally think it would be fine as long as you're not using any cheats/codes.
I've never used an Action Replay 2 so I'm not sure if there's any way you could hide usage of codes by e.g. saving codes in it and being able to power on the console and have it boot straight to the game without showing any Action Replay menus/intros but have it still apply saved cheats/codes. That would basically be my only worry with this. But maybe the Action Replay 2 doesn't let you do this kind of thing?
Our video submission requirements do require you to show the console/game boot up. Don't have to use a webcam obviously, but just the game capture. So I guess this would maybe help prevent against this (if it's even possible at all)?
Is your PAL SNES also modded for 60hz? Or would this just end up with the converter and console playing the NTSC-J game at 50hz?
For what it's worth I use a pin converter to play my US NTSC Starfox cart on my Super Famicom (JPN SNES). But it's a simple pass-through converter so no cheats involved.
Also not against mid/low-end runs not requiring video proof.
I also agree with Lylat's suggestion about having runs with times beyond a certain threshold being the determining factor to whether a given run requires video proof or not.
I suppose either way of doing it is fairly arbitrary, but personally I do think when people think about "top-tier" runs for any given game, they usually think about it in terms of "sub-XX" and not "top 10" ... especially once they start learning the game (not to say they don't think about it both ways, but I do hear people say stuff like "sub-XX is a great time" much more often, and having "sub-XX" as a speedrun goal... that kind of thing).
So with this in mind, using a run time as a threshold definitely would be game-specific and need to be determined by the moderators of each game/category individually as Lylat mentioned.
That all being said, I'd be ok with either way (top X on the leaderboard, or sub-X time). Just stating my own thoughts! :)
Thanks for summarizing Lylat. :)
[small]Full disclaimer: I don't currently run SF64. I want to in the very near future, but right now I don't. But I think the emulator discussion is important not just for SF64, but eventually for SF1 as well down the road perhaps.[/small]
Just wanted to also offer my opinion on a suggestion zewing made above -- I think the Console (N64/VC/iQue) vs Emulator separation is enough simply because this is where the real division lies in the community as far as what is acceptable and what is currently banned. Making all platforms their own categories is probably a bit too much as has been said by others already. So far as I know, other then a few lighthearted comments made here and there, there's no real divisions in the community between N64, VC and iQue.
Anyway, moving on....
Repeating a bit of what Lylat said earlier (I think it's important enough to repeat), the whole point of allowing emulator runs to be submitted in any form is to do what we can to help encourage new runners to the game. People who may not already have the hardware to run it on console. e.g. a broke college student living at home, no money to spend, certainly not $100 to get whats needed. But his/her family has a computer and an emulator is free. Telling these people to "just go out and get an n64" is essentially the same as telling them "piss off, you can't run it." :P
At the same time, I don't think any current runners (both those for and against emulator runs) want to really promote emulator speedrunning for Star Fox. Rather (as Lylat said above in one of his posts), we see it as a gateway drug. Getting people interested in the game and eventually getting them to come over to playing it on real hardware. For such a tiny speedrunning community like this, I think our goal should be to remove barriers to entry, not add more.
Keeping emulator runs on a separate, by default hidden (aka. Misc) category does appear to accomplish this idea of not promoting emulator runs nicely. Or as nicely as speedrun.com appears to allow us to do anyway. Putting emulator runs on the same leaderboard as the console runs but hiding them by default is not without problems as Lylat mentioned above.
Other N64 games which allow emulator runs appear to have standardized on Project64 v1.6 or v1.7. We'll of course have to decide as a community what we want to standardize on and what (if any) standard emulator settings should be used.
I can understand the logic behind the idea of not allowing emulators to be used that run significantly faster then iQue, but I would caution that for N64 emulation, we really don't have much choice. It's pretty much Project64 or nothing (I don't think mupen64 is comparable, but it's been quite some time since I last used that one).
I don't think there's a big problem with emulator runs given all this. We just need to very clearly define the requirements for what will be accepted and what will not be. Moderators validating these runs need to do their part and make sure that people aren't trying to slip a cheaty run through the cracks (goes without saying, but there, I said it anyway).
Anyway, just my thoughts on the matter.
EDIT: Also, I feel I should point out that I'm ordinarily quite anti-emulator. I do not run anything on emulators myself and would never do so. I don't play any games casually on emulators either. However, I do recognize that they are some potential new runners only choice for getting into the game.
I did some checking as I was curious why I didn't end up with exactly the same ROM file after applying all 4 patches manually, and discovered that the ROM you guys have picked as the standard one ("Star Fox 2 (Japan) (Proto) (Alt 1) [En+Hack by Aeon Genesis v1.0] [Fix by ManuLoewe] (Final Version)") does not include the third patch "agtp_starfox2v1.0_staffroll_by_manuloewe.ips". This is probably because that patch was released 2 years after the other two patches, so I'm guessing the ROM download was put up on that site before that time.
All this means is that with that ROM, the final credits is still missing this line of text at the start of the sequence:
A speed increase is pretty significant. I find it incredibly unlikely he would neglect to mention that (especially given that he wrote about the changes in some detail... doesn't come across as a person who leaves things out). Also, it's not 1 patch, but 3 separate patch files with descriptive names included in the zip:
- agtp_starfox2v1.0_debriefing_by_manuloewe.ips
- agtp_starfox2v1.0_menufix_by_manuloewe.ips
- agtp_starfox2v1.0_staffroll_by_manuloewe.ips
I still can't fully explain the speed change you're seeing with this ROM (I'm still assuming it's emulator-specific), but it appears to be completely unrelated to these 3 patches at least.
Ah, yeah that's true I didn't see that was already a selection when submitting a run. Seems to solve it nicely.
So in the ROM name mentioned by Literal, I was curious what the "Fix by ManuLoewe" was and found the original patch files here: http://manuloewe.de/kayeneng.htm (at the bottom of the page).
This is a relatively newer patch (I didn't know it existed until just now!) so it's possible that not all reproduction carts will include it (mine doesn't).
In the download are 3 individual patches:
[quote]
- DEBRIEFING FIX (applies to: "debug" & "final" versions)
agtp_starfox2v1.0_debriefing_by_manuloewe.ips will correct the spelling of one of the graphical text strings on the records screen (from "DEBREIFING" to "DEBRIEFING").
You can use this patch with the "debug" and/or with the "final" ver- sion of AGTP's patches as both are affected.
- MENU FIX (applies to: "final" version only)
agtp_starfox2v1.0_menufix_by_manuloewe.ips will correct a bug in the main menu. Note that this bug only affects the "final" version of AGTP's translation!
To see the bug in effect, start the "final" version of the translated game, go to the main menu, select "MISSION" and press B. When the difficulty selection menu appears, press Y. You will be taken back to the main menu. Now, press Up or Down on the Control pad several times. You'll be able to blindly select the test, training, and config menu items, which shouldn't actually be available in the "final" version of the translation.
Make sure ONLY to use this patch with the "final" version of AGTP's patches. If used with the "debug" version, it'll no longer let you select the test, training, and config options in the main menu!
- STAFF ROLL FIX (applies to: "debug" & "final" versions)
agtp_starfox2v1.0_staffroll_by_manuloewe.ips will correct the color of the very first line of the staff roll sequence. It says, "EXECUTING SECURITY CROSS CHECK." In the "debug" version of the translation, the line is actually visible (albeit in the wrong color), but in the "final" version, it was accidentally blacked out completely, resul- ting in no more than a green cursor flickering across the bottom of an otherwise black screen. This patch restores the color the line is displayed in to its original shade of light gray.
You can use this patch with the "debug" and/or with the "final" ver- sion of AGTP's patches as both are affected. [/quote]
The lag fixes mentioned by Literal appear to be fixed by something else, nothing that these patches are fixing (as you can see from the list of fixes above). Guessing that the ROM that was being used before was a bad copy. Can't really explain it, but if this one is faster, then that's awesome for emulator users I guess!
Alrighty, going to post my thoughts on this for whatever that's worth. :P
[small](NOTE: I've updated the info below after seeing Literal's posts. Didn't know that there was a new patch released in 2010 that contained some additional bug fixes and I didn't want this post to contain inaccurate info).[/small]
[big]Regarding ROMs[/big]
For everyone's general info, I'm going to post some information on the ROMs of this game that are floating out there and the patches that are available that everyone should be using (as they fix bugs, remove debug info, and translate the game to english).
First off, here's a very good source of general info and the history of Star Fox 2: http://www.snescentral.com/article.php?id=0077
Anyway, there are basically 2 main leaked ROMs of this game, the "Early Alpha" and "Final Beta." For our purposes the Final Beta is the one we want. However, the unpatched Final Beta ROM also includes Japanese text and debug info / menus littered throughout, not to mention some gameplay bugs.
In 2004 a patch was released by Aeon Genesis which translates the text to English, removes the debug info, and fixes a few bugs (such as Corneria being unable to take damage) making the ROM look like a final release product. This patch is available here: http://agtp.romhack.net/project.php?id=starfox2
In 2010 another set of 3 patches was released ManuLoewe which fixes a couple of text issues and fixes a little bug in the main menu. These patches are available here: http://manuloewe.de/kayeneng.htm
These patches (4 in total) can all be applied (beginning with the Aeon Genesis one), to one of the two main unpatched, untranslated debug ROMS:
Star Fox 2 (Beta TD) CRC: 1fb1cf76 MD5: de70567495c962b15574abf03a0785f4 SHA-1: 60f45d5ca95247294120080359639eb3a7e505c3 SHA-256: 6bbbacdf71026a6596e375f6bad08993368b3576ef360e77c7fc78d0510e1698
Star Fox 2 (Beta TD) (J) [o1] CRC: 1b3bc708 MD5: d078ec303bcd19fbd77d545e6b9617c3 SHA-1: 6669899a6c9c3bb71c41d90c36932ddfc1f4f208 SHA-256: 1d3607ba60504e988c53c9de46a2170ccdc655e921ae0575bfe20c2deb3e7025
However, since not everyone likes applying patches manually, a prepatched ROM can be found on the interwebz:
Star Fox 2 (Japan) (Proto) (Alt 1) [En+Hack by Aeon Genesis v1.0] [Fix by ManuLoewe] (Final Version) CRC: 1e61c986 MD5: cbaf1982688304cd97453032ccfd5cb5 SHA-1: 12de5ce6d07bb1f3b4eaa3652bd985e1504109d5 SHA-256: b86c6113be950337b5cf43c5105f8a442ba897da6fca1cf3af47420d33f76f54
¤¤¤ This ROM is the one that has been decided will be the standard ROM for speedrunning on by LiamPiper and LiteralRathalosPlate. ¤¤¤
For completeness, there is another prepatched ROM floating around out there which includes only the 2004 Aeon Genesis patch. This ROM is worth mentioning because it has been around the longest and is what was used on many reproduction carts (including my own) and by many people who played the game on emulators prior to ManuLoewe's patches being made available sometime in 2010.
Star Fox 2 (Japan) (Proto) (Alt 1) [En+Hack by Aeon Genesis v1.0] (Final Version) CRC: a797f974 MD5: e27fb54db09b3bc1cbb6d05b8f42ddbf SHA-1: e6a66a8e6c929f569c8d3d625a571d8790866b42 SHA-256: be4d3bd755ac6e5ac6061fa1c528f5ff5b1a1b539a44aadf4ee03168e1ff11f9
Ultimately, since ManuLoewe's patches do not include any speed changes (only text fixes and a menu bug fix), this shouldn't change anything for speedrunning, but it is NOT the standard ROM for speedrunning!
[big]Regarding Reproduction Carts[/big]
So, after doing a bunch of research on the history of Star Fox 2 and what versions of the game were leaked... the fact that there's only 1 main patch of the game out there that fixes it up and turns it into something that looks like a final release (and an extra set of 3 smaller patches by ManuLoewe's which only change text and don't affect any actual gameplay).... I'm actually quite a bit less worried about reproduction carts containing "bad" copies of the game. Assuming that the reproduction cart in question was made with a Super FX 2 chip anyway. They all should be, but I'm told apparently some are not... if that's the case, it would stand out like a sore thumb as the game would run ridiculously slow since the Super FX 2 chip has twice the clock speed of the original.
However, since not everyone with a reproduction cart has access to ROM dumping hardware and cannot verify what version of the game they actually have, it's just yet another reason probably to split up emulator vs console run submissions in my opinion.
The main reason to split up emulator vs console runs is that SNES emulators still do not do a great job mimicking the unique performance characteristics of the Super FX chip (Snes9x certainly doesn't, and I think the jury is still even out on whether BSNES/Higan does this).
So definitely seems like a good idea to tag run submissions with the name of the emulator used or whether they were done on the actual console (repro cart). If there's some concern about this, I dunno if it's possible to use tabs / subcategories to separate emulator runs vs console runs into two separate lists (make the emulator category the default one shown since that's the more popular one for sure) or if you think that's too much... ?
Anyway, sorry for the lengthy post!
Nice... looks a lot cleaner then that previous mess of categories on the side navbar. :) Awesome stuff.
That being said, the first thought I had when I looked at this was that since "Any%" for this game can only be done by beating the game via Out Of This Dimension, why not just call it exactly what it is: "Out Of This Dimension" ?
Oh no, as mentioned in the first post you can save anywhere inside a level but only if you pause the game first. There are some caveats mentioned, but it's not that bad. e.g. I had no problems practicing the one cycle for Andross-2's cube with a save state taken at the start of the fight. Sorry I guess the post is really wordy... I tend to write too much.
Going to quickly add that I've now tested that this works with my Game Saver+ with:
- North American Super Nintendo (SHVC-CPU-01) using OEM power supply (aka. original 1990 console revision)
- North American Super Nintendo (1CHIP-02) using OEM power supply (1995 console revision)
- Japanese Super Famicom (1CHIP-01) using third party power supply (9V 2A)
With both v1.0 and v1.2 US NTSC Star Fox carts. Never plugged in the power supply for the Game Saver+, nor used AA batteries.
No issues with any combinations of any of these consoles/carts mentioned.
[big][big][big]Tutorial: Using a Nakitek Game Saver+ With Star Fox[/big][/big][/big]
Also, I made a short video tutorial explaining everything I've written in this post if you'd prefer to watch instead.
[section=Introduction] For those not familiar with a Nakitek Game Saver+, this is a device that was made and sold in the 90's that allows you to use a single hardware save state on your actual SNES console. There are two versions of this device, the plus version and the non-plus version. The major difference between the two is the plus version allows for the use of AA batteries or plugging your SNES's power adapter into it to retain a save state even if the console is turned off. The non-plus version does not have this capability. Also the plus version apparently improves game compatibility somewhat.
Plus Version
Non-Plus Version (Don't get this one! It doesn't seem to work with Star Fox!)
This device is not without it's faults however. For one, it doesn't work with every game out there, and for those it does work with, sometimes you cannot reliably load saved states depending on exactly where you are in the game. Also, due to the hardware architecture of the audio processor in the SNES, when loading save states, you will almost certainly notice audio glitches. This mostly takes the form of background music not restarting or even just outright stopping altogether, or playing the wrong music, etc. This is not the fault of the Game Saver, but a hardware restriction of the SNES (code running off the game cartridge is not able to modify the internal state of the audio processor).
However, even with these issues, this is a super handy device for speed running for those of us accustomed to playing on CRTs with near-zero input lag. But if you're happy using an emulator for save state practice then this guide is probably of no use to you!
[section=Making Star Fox Work] To start off with, if you have the non-plus version of the Game Saver, none of this will work (thanks to DownTheUpstair for confirming this). Apparently the increased compatibility included in the plus version fixes some issues that make it work with Star Fox!
After connecting the Star Fox game cart to the back of the Game Saver and plugging it into your console (make sure to have the game label facing up!) and turning the console on, you should be greeted with a Nakitek logo, and then a Game Saver logo will appear, and then finally you will see a black screen and nothing will happen.
For some reason if you press the Reset button on your SNES here at this black screen Star Fox will finally boot like normal and you can play the game. Weird, but it works.
The Game Saver manual includes a big table of compatibility codes (picture). These codes are supposed to help fix little issues when using a Game Saver with certain games. As you can see in the table, there is a code for Star Fox listed: 41112.
To enter this code, turn the SNES off and then back on. You should see this screen:
Hold down the Select button on this screen until you see this come up:
At this screen you can use the D-pad to move to any of the 4 lines, press A to enter a code on the selected line. Use up/down on the D-pad to select a number/letter and left/right to move to the next space. Press A again when done.
You can and should enter the code 41112 here. If you do not enter this code you will notice little issues when loading save states.
Pressing Start on this screen will boot the game, but you will find that you'll just get a black screen again. You will need to press the Reset button on your console to actually get Star Fox to start up. Don't worry, the code we entered previously will still take effect.
[section=Using Save States] The Nakitek Game Saver+ uses R + Select to create a save state and L + Select to load a previously created save state. When saving/loading a save state the screen will flash black for a second. If you don't see the screen flash black, then saving/loading is not possible at this time for whatever reason (also be sure to try a couple times if it doesn't work at first, I've found it seems to sometimes not recognize the button presses at first but it may just be me).
Anyway, right away you will notice that saving/loading does not seem to work anywhere you try in Star Fox.
From what I've been able to tell, saving/loading states does not work when the Super FX chip is being utilized by the game. So, for Star Fox, this seems to be anytime there are 3D models being rendered and actively animating on screen. So, you won't be able to save/load states from the initial intro sequence, the title screen, the control scheme selection screen, the initial launch sequence (with the Arwings flying through the tunnel after selecting a route), not during a level, and also not during the level end sequence (where the score is shown).
Well, that seems pretty useless right?
Thankfully, it's not that bad. There are two main places where you can save state:
1. On the map screen
And also on the mission briefing text screen:
But note that sometimes when you load a state back to the map screen you may experience some graphical errors:
This seems to be normal and doesn't affect whether you can continue to the next level or not.
2. During a level, only when paused
And yes, you can also save/load at any arbitrary point during a level, but with some limitations. For one, you must pause the game first (using Start). ONLY then can you use the R+Select and L+Select button combos.
You can load a state that was created on a different level, but you should only load a state in this manner when you are at the pause screen of a level (any level), NOT from the map screen. If you have a save state created at some point during a level and try to load it from the map screen, you will get some rather severe graphical issues (also watch the video linked above for a demo of this if you're not exactly sure what I'm referring to):
This limitation on needing to use the Pause screen to save/load states imposes some limitations on boss fights, as with most bosses the instant you kill it the pause functionality is disabled by the game. So, to retry a boss, you may need to go into the next level, pause the game, and then reload the state. Annoying, yes. But much better then having to replay the entire level to retry a boss again!
Alternatively, you can just pause the game just a split second before you kill the boss to reload it to skip having to wait until the next level to reload.
Important Note
As of writing this, I've not yet tested this out on every level in the game. It is entirely possible that some levels may have more issues with save states then others. I make no guarantees!
[section=Audio Issues] As mentioned previously, a common problem with these Game Savers is that when loading states, the audio sometimes becomes messed up. Most notably, any background music that was playing will almost certainly not restore correctly.
This will become noticeable when loading save states created during a level, and even may result in incorrect boss music playing. This is normal behaviour and there is no workaround.
[section=Graphical Issues] Other then the obvious map screen graphics corruption issue noted above, using a Game Saver does introduce some subtle flickering / diagonal lines to your SNES's video output. You can see it in the linked video and in the screenshots above if you look carefully. This is not caused by my recording setup, the same artifacts are visible on the TV I'm using also (which is connected directly to the SNES video output).
This is normal when using a Game Saver and cannot be avoided unfortunately.
Yeah I think that's better. What I was trying to avoid was giving someone a false impression of where they have to aim the bomb at, which may / may not make it harder for someone attempting the strat for the first time have a harder time with it. But I think this sounds a lot better.
(Complete disclosure -- when I do this strat, I don't even think about where I'm aiming the bomb, I just fire and forget, LOL)
Minor nitpick with regards to the Attack Carrier quick kill strat:
"it has to detonate from behind his center for the quick death animation to work"
I disagree with this. I've seen that happen and result in the quick kill, but it's by no means a requirement. In my last two PBs, you can very clearly see the bomb just hits him dead on and kills him the exact frame it collides with him (in other words, it doesn't move through/behind him). Also, for reference, I ¤never¤ detonate the bomb early, I just wait for it to hit him all on it's own.
I just don't like seeing things like this in strategies that imply you have to do it a certain way 100% of the time, which is not the case here. :)
Otherwise, looking great. We definitely needed something like this. Should supplement with some more screenshots / small video clips showing things like nova bomb timing, etc.
Awesome, thank you for mentioning that you counted frames to confirm, I really appreciate it. I hadn't gotten around to it in that video yet and was just coming here to mention it. As I mention at some point in the video, -34 seconds and -33.75 seconds were numbers I pulled out of thin-air but seemed to be pretty accurate. The route 3 change to -33.75 is probably the least important, but definitely the -34 change for route 2 would be good for everyone to do.
And definitely rounding to the nearest 1/4 second makes sense. Since we're talking about timers that have to be started/stopped manually, there's always going to be some inherent human error involved anyway. In the event that there was some real issue with anyone's run time we'd be looking at the entire length of the video and counting frames anyways.
The on-stream/video timer is just a convenience for the runner and viewer, but making these small adjustments to the delayed start timer helps keep those timers that much more accurate. :)
