Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
Dyshonest wrote:
Sounds about right, but again, you're still basically deciding that [x] glitch/variant of [x] glitch is okay because it doesn't skip as much. as [y] glitch.
No. You're wording it in an intentionally deceiving way, or clearly don't have any idea of the glitches. The distinction of orb and cloud is that one relies on actively manipulating memory in order to allow the executing code to get a good result (it's ACE), whereas the other doesn't require that at all (not ACE). In the orb the code follows the same path every time, but with cloud, the results are unpredictable without heavy manipulation. They may be similar in appearance but I assure you they're entirely different, and there's therefore a clear distinction between the glitched and warped runs.
And please have some respect for our run. Calling out to obsolete our run because you don't understand the glitches used is insulting.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
For those who don't know this started as an improvement regarding smw warps (the non-ACE run) - Mister pointed us to a Nicovideo movie of a freerun where the player gets a cloud in their reserve box. We were very excited, as this would save a lot of time in Bowser (see Mister's post). Unfortunately after some research and many failures to replicate it, it seemed to be some form of ACE rather than a straight-forward item... Seems like it is both, as is explained in the description. Well, I guess smw warps suffers here. :p
Good job Masterjun even though I know you aren't entirely happy with this work.
Yes vote.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
It's such a shame - one of the most common items in the game, the P-Switch, will spawn a horizontal fish when stunned. However, I don't think there's a way to set the stun timer of the fish without it being in water. I'd love for someone to prove me wrong as I'm somewhat of a fish out of water when it comes to this bug hueheueHEUEEHEUeheue
(Edit: Just noticed BrunoVisnadi already mentioned this in his post but I'm keeping it here for the joke)
But really, is there some way to force the stun timer of some sprite?
We could theoretically break any level that contains a P-Switch, then...
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
CoolKirby wrote:
Which of these sounds best to you? Branch names aren't permanent; they can always be changed. If you have a suggestion that solves the situation we've been trying to solve for weeks now, then please post it here so I can fix the SMW and YI branch names for you.
I've asked a couple of SMW TASers and we agree 11-exit seems most appropriate. That is, if you insist on having the credits glitch run as the any%. I haven't seen this discussion until earlier otherwise I would have weighed in sooner. I don't know what is best for YI, I know very little about that game.
Edit: Oh, and the Japanese SMW TASers call it "smw11" too, as far as I know.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
CoolKirby wrote:
The problem with something like "less glitched" is that it's too arbitrary.
It's less arbitrary than "no stun bug, no null-spit" for sure.
(This post will be only about smw as I only know about that game).
I don't see what the issue is with giving the title "arbitrary code execution" to glitched branches. Arbitrary code execution isn't a subjective term, it's a well known bug in software. You gain control of the program. There isn't a single glitch in SMW that could be described this way except for the credits bug. If arbitrary code execution runs must be the new any%, then "does not execute arbitrary code" could be for non-glitched one.
But here's my main concern with the new branch: We can jump the credits without using either the stun bug or null-spit. This can be achieved by eating a chuck with a certain powerup status. Well, you say, "I'll add no eat-chuck to the branch too!" but the current run eats a chuck anyway to get the orb. Furthermore, the 96-exit run does use both of these bugs, so is that now a glitched run too? Can another 96-exit run be submitted that doesn't use either of these?
Another issue: What the hell does "No stun bug, no null-spit" even mean? That title is impossible to understand unless you follow SMW TASing closely. A newcomer to this site may see that branch and think, "what"? It means nothing unless you know the game well. If you want to keep the credits-glitch run as any%, that's fine. Maybe consulting SMW TASers would have been a better idea so we could have told you these problems and suggested something rational and understandable like "11-exit", "No credits glitch", "beats Bowser", "does not execute arbitrary code" etc.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
Let's say I have a simple lua HUD:
Language: lua
local last_x = 0
function display()
local x = memory.readdword(0x1B90B4)
local dx = math.abs(last_x - x)
gui.text(0, 0, string.format("%04dx, %04ddx", x, dx))
last_x = x
end
gui.register(display)
The value dx behaves correctly except when I'm using frame advance. In that case, the value is always 0. How do I make the value update correctly in that scenario?
Thanks.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
gbreeze wrote:
bahamete wrote:
Post.
Well, if I redo this run, should I do it on the Japanese version?
If that question was directed at me, maybe you should actually read my post. I don't think this movie should be rejected based on version differences, only because of known improvements. By the way, maziari is working on improvement to this run, he has saved 13 frames up to dp1 (I hope he won't mind me saying) - maybe you could contact him and work together rather than 2 separate runs being created. I look forward to an optimal one. :)
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
No due to improvements some of which have been known for many years.
I comment only to mention as to why using USA version is a reason to reject when J or EU version is faster. In SNES SMW, in the E version, Mario runs/flies faster and Door #5 in BACK DOOR can be skipped without waiting for any spikes at all. I have a bad encode of the trick here: SMW - Door 5 break (I originally intended as April Fool's joke). Plus, this version has much less lag and might be faster for the TAS by several seconds. The J version on the other hand is faster due to text on save dialog and switch palaces so either of these versions would be better. Our SNES SMW runs aren't rejected for version difference so I don't know why it should apply here. Maybe I just misunderstand, I don't know.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
Tangent wrote:
adding the author of resync to the current movie author
What's the reasoning for this? "They did something and must be acknowledged for it."? While I'm sure it's not trivial to resync a movie, it's a lot easier than making an original one.
Since when do we judge movies based on how easy they would be to perform, and how exactly do you quantify how easy a movie is to make or 'sync'? Furthermore, why would we not want to credit authors of even trivial movies?
I think including the newer emulator movie alongside the old one a decent compromise above obsoleting older movies with no improvements (which I agree is a very grey area - we must not ignore the efforts of the runners of older movies). For example, I'd certainly be happy for someone who resynced smw any% to be credited alongside us, though.
My reasoning.
Case 1: The new movie is more or less identical, perhaps different only due to emulator differences (faster or slower) but shows the same technical ability. Publish alongside old run.
Case 2: The new movie is faster due to genuine improvement. Obsolete old run.
The other alternative is to ignore the efforts of those who bring our movies into a state of being more likely to sync on console (this is what we want, isn't it?) - I don't much like this one.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
Relevant, from our resident SMW TASer SkamastaG:
Link to video
"Uses non-standard controller" is nonsensical. If the hardware recognizes the input there shouldn't be a problem.
As Nach has pointed out there are official controllers that use these additional buttons, so. Our only concern should be whether or not the input will play back on a console, not whether there are peripheral restrictions.
Edit: The issue of cartridge tilting is irrelevant here. With cartridge tilting it requires (subjectively) a slightly "modification" of hardware, something external from input files, which is all TASers deal with as far as I know (besides CD-swapping, etc).
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
boct1584 wrote:
Do our two published SMW hacks have this problem you're telling us about, Patashu?
Just tested TSRPR in lsnes rr2 ß5. Loads fine, played two levels, everything okay. This suggests the rest of the hack will be fine if the same method for custom music is used.
SDW will not suffer from this well-known problem as it does not use custom music.
Neither does Kaizo 3.
I'd think that any hack that does not implement custom music properly (and is not tested on bsnes) would not be of sufficient quality to be exhibited here, regardless.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
Because our fearless leaders have spoken, we must move on from Snes9x. We could stick to Snes9x 1.5x but I think it's just better to move onto a new emulator. Anyway, I've started porting SMWUtils to lsnes and the latest revision will always be here. It currently shows the same information that the old SMWUtils had plus some extras such as sprite numbers, stun timers and misc info, but lacks cheat functions so far.
I would urge all SMW TASers to use lsnes as opposed to Bizhawk, mostly for the reason that SMW TASers compare runs very often and to make this easier, we should all be on the same emulator. Of course you're free to use whichever you want but lsnes seems the better choice because it's cross platform, so we reach a wider audience, and runs noticeably faster (apparently). Anyway, we're starting a new any% on lsnes now and we only have a couple of tiny improvements so don't expect anything huge. :)
EDIT: For an even smoother transition to lsnes, Masterjun has ported the Lua fonts. It should work with this script straight away but I haven't tested.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
We've discovered an improvement which could be 13 frames or more.
Here is the proof of concept. It gets to the overworld after yi1 9 frames sooner than the current run.
Essentially, we use the POW to gain a stock mushroom in yi2 and then in yi1 we no longer need to care about slowing down to double-eat the invisible mushroom as we already have a stock one. In other words, we fill the sprite slots faster. Because I'm lazy, I used input from the current run, and I had to delay yi3 entry by 3 frames and yi1 entry by 1 frame to sync them. yi2 is 3 frames slower but maybe this can be improved (so my demo movie is 9 frames faster, but it is improvable by at least 4 frames by not being lazy). The ending to yi2 was Masterjun; thanks for proving my theory. :p
I think we'd rather discover other improvements before attempting a new any%, I guess...
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
So, just to clarify: Say, theoretically, a new Super Mario World any% run performed on 1.43 is submitted that beats the predecessor, it'll be rejected and TASVideos will keep the (slower) run performed on the same emulator?
Optionally, replace "Super Mario World" and "any%" with any other popular game/branch performed on 1.43.
I'll relent and say that many points about using 1.43 against Bizhawk/lsnes can be refuted (subjectively). But there's one reason in particular that makes me want to keep using 1.43: For such a contested game, we need to compare the runs very closely. With emulator differences it may be tough for us to see how much time is actually saved/lost, particularly since we normally use the comparison script or watch emulators side by side and some improvements are heavily reliant on the game's frame rules or lag differences, which may only apply to Snes9x. Aside from this, we also have many Lua scripts we use that cannot be easily converted.
Not expecting a response from this besides "tough", just mentioning why it seems difficult for some of us to move to those emulators. I've lost all motivation for TASing since the switch, anyway (but not because of it).
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
I'm really excited for a correct run - this is one of the funniest TASes I've ever seen. Not sure if that makes me sadistic. The glitches used really add to the entertainment - one of the most hilarious moments was when Abe was invisible and got on a lift with a slig (Zulag 3, maybe?). I would definitely vote yes on a run that actually _does_ kill all mudokons, so, nice work.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
The shame about SMW freeruns is that it'd have to spread out the glitches over a large area which would make individual levels less entertaining. Thus it'd have to keep the route short but long enough to justify a "glitchfest"-type run. I think the ideal route would be something of involving taking the Vanilla Dome star warp through to special world, then onto Bowser (or completing the run via code execution or crash). A lot of planning would have to be done to ensure the run gets the maximum amount of glitches in the route without repitition. We'd probably want to include things such as arbitrary code execution too, which can be done as far as I know in Yoshi's Island 2 and Yoshi's Island 3. If that glitch is shown off there, the rest of the run may seem dull in comparison.
I'd love to work on such a project with someone (or a group) though. It's a shame my previous glitchfest project failed due to lack of motivation but I think this game is adequate enough for such a run.
Also, neat work here Masterjun, as I said on Skype. It's an interesting little freerun. :)
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
The fact you'd rather an older, slower run performed on the same emulator remain on the site while the faster one gets rejected is fucking ridiculous. Then the site would be stuck with an "inaccurate" but unoptimized run (as opposed to just an inaccurate one) until somebody does it on Bizhawk/lsnes - what if it takes years or never even happens? This is a huge flaw in logic.
Yes vote. I'm unfamiliar with the game but I found it entertaining :)
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
Didn't p4wn3r not list gia as an author even though it was his strategy? Same scenario here I suppose, though I agree they should be put in the submission text indeed. Yes vote.
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
Yes vote of course. It's fun to see the game destroyed and some of the strategies employed I would have never dreamed of.
This game improves the level design of its predecessors severely so I think that quality of level design may not be an issue (though it is not good enough to be the quality of a commercial game, as I would say was the case with SDW and TSRPR). Still this TAS shows some of the best glitches available in SMW put to innovative use. It's highly optimized and really entertaining.
The problem with Snes9x is not a huge one when we realise that the issue with using Snes9x does not apply to SMW as the only glitches used are emulator independent. Thus the only benefit from switching emulator would be changes in lag. Everything in this run is still possible on console, which I think is the only crucial point. Regardless if the issue with too many derivatives comes into play then I'm happy for it to replace 2074M.
So, thanks for a great run (and for the note about parity of sprite slots affecting interaction, that's news to me).
Experienced Forum User, Published Author, Active player
(263)
Joined: 4/15/2010
Posts: 197
Location: England
HappyLee wrote:
Amaraticando wrote:
Stage by stage comments
Coming very soon - we promise!
Did you forget it?
I'm also waiting for stage by stage comments. I hope it would come soon, just like they promised.
It's not good of me to make a promise we can't keep. I'm sorry.
They'll be coming eventually but I guess we're just glad to finish and are taking a rest.