It is true that choosing the hardest difficulty also increases the enemies' HP. However, as I said, it also increases the amount of bullets shot by the enemies and also increases the movement of many enemies by a lot. From my testing, the distinction in difficulty is as pronounced on PAL timing as on NTSC timing (as in, I noticed more enemy bullets being shot and increased movement speed of at least the bat-like creatures on both timings).
Oh, by the way, this run isn't even on the hardest difficulty (Skill 4 in the options), nor is the previous publication.
The manual (in German) even says Skill 4 is for very good players. Note that when the game boots up, it's at skill level 2 (average player) by default.
The enemies shoot a lot more projectiles and many enemies move a lot faster on Skill 4, which I believe should make for a more interesting TAS.
EDIT:
Link to video
This is just a taste of what the hardest difficulty has to offer.
Actually there seem to be 4 speeds to run the game at depending on how I set the emulator.
(E) - with PAL emulation
(E) - without PAL
(USA) - without PAL
(USA) -with PAL
The first and third are pretty close, but the other 2 are way different, weird.
The second and fourth (bolded) happen because you change the timing while the game is actually running, and thus whatever the game does to compensate is not in effect until you perform a hard reset (NES -> Power in FCEUX).
To me, because the game (NES version, at least) was only released in Europe, the game is supposed to run on PAL timing, so I'd much rather see a run done on PAL timing than on NTSC timing.
Might be something worth checking out in Bizhawk too?
This is BizHawk's dump status report when I boot up the game (NesHawk):
------
BEGIN NES rom analysis:
Found iNES header:
pr=128,ch=128,wr=8,vr=0,ba=0,pa=0|1,brd=MAPPER004,sys=
Since this is iNES we can (somewhat) confidently parse PRG/CHR banks to hash.
headerless rom hash: sha1:33487D9A013F81F434323960203E564434F8D2F8
headerless rom hash: md5:EAF108F829CF64FFA7F944E5AE420676
Could not locate game in bizhawk gamedb
Chose board from nescartdb:
pr=128,ch=128,wr=8,vr=0,ba=0,pa=0|0,brd=NES-TSROM,sys=NES-PAL-B
Final game detection results:
pr=128,ch=128,wr=8,vr=0,ba=0,pa=0|0,brd=NES-TSROM,sys=NES-PAL-B
"Super Turrican"
Implemented by: class TxROM
END NES rom analysis
------
(relevant parts bolded)
To me, it clearly indicates it's supposed to run on PAL timing (NesHawk does, anyway). Of note that QuickNES does not support PAL emulation as of present (akin to a certain terrible NES emulator called Famtasia), so it shouldn't be used for PAL games.
Alyosha wrote:
If you rename the rom with a (USA) tag and then run it, it does indeed run in NTSC mode with the same speed as the original (EUROPE) rom runs in PAL.
Again, the game runs faster on NTSC timing than on PAL timing.
Here's a waveform of the title screen music on both PAL (top, intended) and NTSC (bottom) timings. As you can see, the title screen music ends slightly earlier on NTSC timing than on PAL timing (note: both WAV files start from console boot-up). For the record, the music is also slightly higher pitched on NTSC timing than on PAL timing.
The fact that renaming the ROM filename to omit (E) or (Europe) makes the game run on NTSC timing is just something FCEU(X) does. It's not a glitch or anything in particular.
For me, the timings are different enough that the game is supposed to be run on PAL timing and not NTSC.
However it is true that the game can recognize the region setting, (I did put this in my submission comments) so NTSC is proper.
No, it isn't.
As you can see, the game runs a bit too fast on NTSC timing than on the intended PAL timing. Therefore, I myself am very iffy about this run being on NTSC timing rather than PAL timing.
Sometimes, the video feed just seems to freeze for a couple of seconds, with the sound still going. I don't recall this happening in 0.2 or pre-0.3 nightly builds. I'm using the OpenGL backend on Windows 7 x64, by the way.
EDIT: It doesn't appear to happen when I use the software renderer.
Anyway, coming back to this:
fsvgm777 wrote:
Another thing I noticed in mGBA in this particular game is that sometimes, a sound effect doesn't play at all (unless it's a side effect of the sound restoration patch that I used, but it doesn't seem to happen in the both VBA flavours I tested, though I'll test on the regular version to confirm). I have a recording ready, if you need it (which, by the way, works pretty well now).
I've now had this happen on the unpatched European release (that is, without the sound restoration patch)...though, upon closer listening, it seems like a specific sound channel doesn't play at all at random. Unfortunately, I don't have a recording ready yet.
EDIT 2: Here are two recordings showcasing the sound issue. (yes, the game is in French (I chose for it to be in French), but that's beside the point)
After mucking around a bit, it seems the issue is with sound channel 4. Note that sound channel 4 was enabled at all times in these two recordings.
I got caught off-guard when the game suddenly cut back to the intro scene after the movie finished....but then it proceeded to the ending anyway.
This new ending has a lot more Terra in it, and the portraits of the many characters that weren't recruited glitch up a bit when "Terra" is off-screen, it seems.
Anyway, from a technical standpoint, this is pretty impressive. However, seeing so many game overs in a row hurts the entertainment quite a bit. I'm going to vote Meh.
Link to video
This guy seems to have found an improvement in Bowser's Castle, though I don't know if it's WiiU VC-specific or not, since he used the WiiU VC release.
I myself am not too certain about the game version used, seeing as this is not the de facto official version of the game (the one that's 4 stages long). The way I see it, is that the version used in this run is an unofficial version that has 4 additional stages.
I'm not voting (seeing as the run desyncs on me anyway, though while it syncs on an XP VM, it has graphical glitches probably due to using a VM).
What are the contents of the 61-100 floors that warrant them not being played through?
They're "special floors" that are only available after beating the regular game, which ends at Floor 60. There are warps in the special floors; however, they actually take you back to the regular game (with the notable exception of the Floor 61 warp, which takes you to the same floor). Beating these special floors triggers a completely different ending. After asking Mothrayas, he suggested that if these floors were to be shown off, a full warpless run should be made (100 floors in total), which would take a long time until it's done.
For the record, the ending you get at Floor 60 directly leads to the events in The Tower of Druaga, so it's the de facto "canon" ending.
Zarmakuizz wrote:
Maybe add in the description why you are able to fly ? I got the answer on the Wikipedia page, but you can't fly in most platformers.
Yeah, it's part of the game. Will add it to the description.
£e Nécroyeur wrote:
This is quality work. I am happy to see you have graduated beyond April Fools' Day submissions. :)
As it turns out, the ROM version that was used in this TAS is, in fact, the German "Classic Serie" release, which was released in 1993.
The regular NES Mario Bros was released in Europe in 1986 (complete with slowed down gameplay, as was usual back then).
See for yourselves.
I noticed a visual bug in Final Fantasy VI Advance during the transition to the battle. This is what happens in mGBA (I used the nightly build from June 13th):
And this is what happens in VBA-M 2.0 beta and VBA-Next, respectively:
Another thing I noticed in mGBA in this particular game is that sometimes, a sound effect doesn't play at all (unless it's a side effect of the sound restoration patch that I used, but it doesn't seem to happen in the both VBA flavours I tested, though I'll test on the regular version to confirm). I have a recording ready, if you need it (which, by the way, works pretty well now).
The Nicovideo TAS rankings for April 2015 are out:
Link to video
I'll post the ranking in full detail tomorrow (probably going to edit this very post).
As you can see, the game runs a bit too fast on NTSC timing than on the intended PAL timing. Therefore, I myself am very iffy about this run being on NTSC timing rather than PAL timing.
And this is what happens in VBA-M 2.0 beta and VBA-Next, respectively:
Another thing I noticed in mGBA in this particular game is that sometimes, a sound effect doesn't play at all (unless it's a side effect of the sound restoration patch that I used, but it doesn't seem to happen in the both VBA flavours I tested, though I'll test on the regular version to confirm). I have a recording ready, if you need it (which, by the way, works pretty well now).