Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
It sounds like you're proposing a "Borda count" method, and also thinking about the best theoretical way to elect a winner according to voters' preferences. If that's true, you might prefer reading about well-researched systems (e.g. the Schulze method or other Condorcet systems) rather than reinventing them. There are lots of interesting concerns that they address...
Luckily, the voting is over whom to give a pat on the back for TASing excellence in the past year... voters probably aren't losing sleep over how much they can influence the outcome. :) The most important feature of this voting system is that anyone can post supportive or congratulatory messages along with the vote.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Why assume one frame would be final? :) Those posts would almost bolster Saturn's reasons for secrecy, if this pursuit fit into the goal of anybody else's current runs...
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Yes vote. Even though the SDW-120 one had shown a lot of these already, I thought this was gave a very charming and accessible presentation. I think it's definitely possible in principle to obsolete (which is good): specifically, somebody could drop the "Forest of Illusion 3" bonus game's lag, and add some of the fish-creation tricks that everybody loves. :)
I don't know what it is about this run, but it caught my imagination in a way that felt a lot like the first TAS I watched.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Sorry, long post. And sorry if the technical details took the fun out of the problem. :)
HHS has me convinced, and also anticipated the problem with Kuwaga's answer: if you find factors of 2, 3, 4, 5, 6, and 7 (separately) in the product, you have to make sure you didn't double-count any factors: 350 is a multiple of all of them, but not of 7!. (Mathematicians aren't picky about the "form" of a proof as long as it explains any potentially tricky issues.)
Here's the "proof by allusion" with details filled in: Assuming c,k>0, and letting n=c+k-1, you need to show n!/(k!(n-k)!) is an integer. That formula actually gives the number of ways to choose k objects from a collection of n objects (which would obviously be an integer). That's a standard fact, proved as follows: on one hand there are n! ways to line up the whole collection in some order (one of the n objects comes first, followed by one of the remaining (n-1), etc.); on the other hand there are (n choose k)*k!*(n-k)! ways, since you can pick which k of the objects come first, then arrange the first k & last (n-k) objects. So (n choose k)=n!/(k!(n-k)!). Actually, the "binomial coefficients" (n choose k) work when n isn't a positive integer, but not for the reasons above. (Wikipedia can explain the name and why they'd ever make sense for negative n.) Alternatively, split into two cases (if there's a 0 factor, 0 is divisible by anything; if not, collect the minus signs and you're left with a product of consecutive positive integers). Or you can work modulo k!, if you know what that means.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Hm. Randil's formulas are correct, but I can't tell whether they're just a restatement of what needs to be proved or an allusion to (censored by font color:) the formula for the binomial coefficients.
HHS, I'm not sure I understood your number-theoretic proof. But you're right that any integer l appears as a factor in at least as many integers in the range n..n+k-1 as in the range 1..k. If you let l range over the powers of a given prime p, you should be able to conclude that the number of p-factors of (n)*..*(n+k-1) is no smaller than the number of p-factors of (1)*..*(k). But the step with the prime powers is crucial.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Along those lines, prove the product of k consecutive integers is divisible by k!. (No shame in restricting to the case where they're all positive, but it's true in general.)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Probably adelikat being lazy and selfish enough to publish only four movies in the last 24 hours (and before that, waiting an entire four and a half hours since co-submitting two runs). What a fucking, shitty travesty. If he'd pre-empted DeHackEd instead (and had better luck syncing the video) this never would have happened.
Edit: five now.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
The "fastest time" thing looks like just a mistake in wording his post. The google video's description does not say "aims for fastest time"; instead, it has the usual boilerplate which says "It's meant to show the game pushed to its limits."
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Yikes, I don't see why such a hostile response was necessary. Certainly, aznxknight, you'll have to do more homework than you realized (the aforementioned thread lists several tremendous discoveries made since this run's publication). If you get caught up, and it still looks like you're aware of new tricks that will apply to Inichi's effort, please also choose your words more carefully to avoid miscommunications.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
mmbossman wrote:
I found an address that determines whether Turok is moving or not (a simple 1 or 0), and thought I had found an address for speed, but it wasn't quite fitting right for me. Strafing left had a value of 128, right was 256, backwards was 1024, and forwards was 2056 (suspicious, huh?). The funny thing was, when buttons are pressed together, the values simply add together. So that means strafing to the right and forwards was 128 units faster than strafing to the left and forwards, which I don't actually think occurs.
You've just met your first bitmask! :-) The numbers in binary are just
L =00000000 10000000
B=00000100 00000000
L+B=00000100 10000000
etc., so this is an easy way for a computer to store a bunch of "true or false" values in one place. (Your forward was probably a combination, 2048+8=2^11 + 2^3.)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Warp wrote:
Why are so many atheists so obsessed in insulting and making fun of other people's beliefs? Is respecting other people really so hard to do? What does that tell of atheism? At least it seems that atheism is *not* about respecting other people but about making fun of and insulting them just because they happen to believe differently.
I don't appreciate this generalization. As an atheist who hasn't been insulting the religious members here (thus probably passing under your radar), I feel a little insulted myself. Of course it's valid to ask whether atheists form a group that makes fun of "outsiders" more than other groups. But a few responses to your exact words: First, making fun of "outsiders" can lead to feelings of amusement and closeness among members of any group; even several isolated instances of this behavior needn't indict a particular group. Second, it's unfair to transfer the argument to the idea of atheism, which is rarely the only thing which unites atheists. Third, how can you conclude atheism is defined by disrespect if not by respect? By definition, it's defined by a belief in a world without God--nothing more.
For you, http://tasvideos.org/Movies-214up-Obs.html.
Remove the "-Obs" to show only your non-obsoleted movies.
You can find the magic number (214) by clicking "players" on the main page...
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
I haven't looked at the 1.43+ code in detail, but it's probably caused by snes9x polling controller input once per frame. Keypresses, on the other hand, are caught in an event loop, so their timing isn't as important. It's almost surely not a problem with your hardware or drivers if the joypad works for normal play.
Try (1) holding the controller buttons while hitting the frame advance key and (2) looking for software ("JoyToKey"?) which will convert joypad button presses to correctly handled key presses.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
I'd hate to be the grue locked in a cage with this run. I found it very impressive, and I think the game's edit-unfriendliness (especially in terms of preserving lag management) has been underestimated.
Yes vote.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
It doesn't sound risky because that check doesn't do much. If you're in read-only mode, the input already gets checked for consistency. If not, loading a savestate will clobber all of your hex-editing work anyway. :)
If you grab my modified snes9x (not desyncless, but available in the "desyncless 1.51" thread) you can get a "fast forward to frame" feature. That might even be nicer because you can skip right to where you started making changes. (This assumes you're using Windows. If you're on Linux, snes9x can do that already. :))
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Agreed.
Most suspicious objects I've seen are PPU.RangeTimeOver and some sound-related things. But I certainly don't understand them well enough yet to blame them.
I've found a (very long) save-reload sequence that can get a few bytes of RAM and CPU.Cycles out of sync (i.e., doing 2 sequences of save/reload with the same read-only movie and freezing the result on the same frame gives you different values in those fields). At that point I assume you're fucked, so I'll try shortening the sequence and then tracking how the static data diverges.
BTW, the SoundData struct should be irrelevant now that the fake mute fix is always used, right?
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Yeah, thanks Nach. This has been... fun. Sorry if I'm making you cringe with my mistakes... :) I did figure out minGW cross-compilation. And there's more going on here than I realized, but I'm still sure this whole "skipping states" idea is broken beyond repair. :)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Now you tell me you had it turned off!! ;)
You are right: this proves there is another desync-causing bug, which I haven't found. May I waste your time asking questions (instead of wasting your time with a "desync fix" that doesn't work)? You are much more successful at triggering this bug than I am.
OK, here goes.
* Just to be sure: had you never set the option to TRUE before?
* Are you still (90%) sure the problem only happens if you use savestates during fadeout?
* Is it easy for you to reproduce the desync with clean savestates?
That last point is key, because that's what I have to do before I can figure out what is going on. Your SCV4_desync.zip, for instance, was helpful but not enough information to make a diagnosis. The out-of-sync savestate took 984 rerecords to make, and without all those steps I can only make savestates that stay in sync.
Anyway, I'll keep looking. If you can help, great. If you only run into the bug doing complicated stuff, I can make a "spying" version of snes9x which records every little thing you do. Maybe that would help?
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
http://www.fileden.com/files/2007/9/22/1451488/snes9x-1.51-nitsujrehtona-v1.zip
Includes source-code diffs from vanilla 1.51.
"Fast Forward to Frame" is under the file menu.
Please back up your work (or play?) before using it. Please expect desyncs if you load a savestate created with the unmodified 1.51.
In general I'd like to know if this holds up better than the unmodified 1.51. I'd appreciate it if people could try abusing it in these specific ways:
1. Go into frame advance (with--not to get too repetitive--[Settings\Win]FrameAdvanceSkipsNonInput = TRUE), hit the button to create a savestate, and (ignoring the "Action deferred" message) close the program.
Tell me what happens (including whether it's able to save the file).
2. If you TAS with this, keep an eye out for one-frame "seams" in rerecords or reset-records. The nature of the workaround makes the emulator less responsive to some things you'll want to do.
Thanks for testing. :)
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Works for me with wine-0.9.45. In fact the graphical problems I'd had running 1.43+ v10 seem to be gone! I am also building 1.51 with MinGW. But if I weren't trying to work on a fixed Windows version I'd definitely be using a native Linux build.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
The main use of this version will be to answer exactly your question. Like I've said, going back to 1.5/1.501 or 1.4x style frame advance--and re-creating your savestates--completely avoids the bug I'm fixing. And you can even get 1-frame-late notification about ignored frames under 1.51, so for instance during fadeout lag you could hit save-advance-save-advance... and know exactly when to reload and resume input.
Which reminds me, if you hit save-reload-save-reload (nothing else) in "desyncless v1", it will advance one frame each time because of how the workaround works. Another reason I won't consider the code correct until it's scrapped in favor of rewind.
But I've heard nobody say "wait a minute, I never turned on that setting" to me or "wait a minute, my desyncs aren't related to fadeout lag" to Phil or Hero. So I'm pretty confident about my work!
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
OK, looks like the first release really will be ready this weekend. :) This version doesn't change how "smart" frame advance works, but instead shields it from the situations it mishandles. Obviously I'm not hoping for this to be part of the next official release.
Temporary new feature: "fast forward to frame". That should give you a way to overwrite your savestates with correct ones, other than loading up a movie and hitting frame advance 100,000 times.
I mostly just need to test it more before releasing. The workaround did its job from day 1, but it created several bugs at first.
Goal for v2: replace the "smart" frame advance code (which won't ever work right) with movie rewind support. Then the feature is trivial to add, robustly this time. The frame advance-advance-rewind sequence will probably look stupid, but contrast to how the workaround release has to misbehave:
* You won't be able to record actions like ending a movie's input or recording a reset the way you did before, or they will happen a frame late.
* If you close the window in frame advance, the emulator will have to finish up the frame. Under wine a nasty graphical glitch results (bits of SNES graphics plastered onto my menu bar). I am afraid that it might crash under Windows.
Thanks for your patience phil (and anybody else watching). Let me know if you have any suggestions.
Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA
Phil wrote:
I am interested. I don't trust JXQ. So I will continue using 1.51. Also, you could do it and post in snes9x forum.
Cool, thanks for the interest! Progress updates will go in this TASVideos->Snes9x thread, and I hope my work can help somebody.
About the timing, Phil, I do have a question. (I don't mean this as an argument.) Since JXQ backed up his findings with both a clear recipe for reproducing his results and a reminder of what they didn't prove, I'm not sure what part of his post you don't trust. Maybe it's this sentence?
SNES9x 1.51 adds approximately 10 frames to each door transition, for "more accurate emulation".
But I read that as a half-joking comment about the lag added due to "more accurate emulation". Of course the timing changes were more subtle than just sprinkling lag frames here and there, but that's the main difference you see while playing games that 1.43 already handled well.
In any case, I'd be fascinated if somebody did more thorough timing tests (probably using a variant JXQ's method that makes sense for other games) and posted them on the snes9x.com boards. I'd definitely be doing this myself if my SNES had made it to grad school with me. :)
