Posts for amaurea

1 2 3 4 5 6
16 17
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Warp: Yes, I agree. Copyright is completely unbalanced, both as written and even more as practised. That's why I place everything I produce under public domain, and in general try to avoid having anything to do with it. It is also why I don't like it when the TASvideos community contemplates using it as a bludgeon towards others, even when said others are rude and unlikeable. It is a bit scary that copyright keeps being extended without any empirical evidence to show that society would benefit from longer copyright. As far as I know, very little research has been done on the optimal duration of copyright. One paper I've found which appears to be one of the most ambitious ones on this topic, still makes several unrealistic assumptions such as "Works are only produced for monetary gain", "No income is possible from works not covered by copyright", "Enforcing copyright has no cost" and "It does not get harder to produce new works when the public domain gets smaller", which all bias it towards longer copyright. Despite this, it finds an optimal duration of *15 years*, with the current duration being excluded at the 99.999% level or so. Taking into account the biases, the true optimum is probably significantly shorter.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Trying to attack this game with copyright is not a good idea. While I'm not sure what he is doing is fair use, USA fair use is much fuzzier concept than Warp wants it to be. With Warp's definition, none of our encodes would be fair use either, and we would have no defense against lawsuits by Nintendo etc.. But thankfully fair use is a bit broader than that. Here is a guide that helps you sort-of-guess whether a video is fair use or not. Sadly, the only way to be sure seems to be to settle the issue case by case in court, because fair use is basically a set of commonly recognized excuses for breaking copyright, not actual limitations on copyright itself, as it is in some, saner, systems. To summarize the article, factors that matter are:
  • How transformative the work is. His case is probably pretty low on the transformativeness scale, but it does set the TASes into a new context by showing only their ending.
  • Whether it is commercial or non-commercial. Being non-commercial helps. In this case I guess it would help him if he doesn't get advertisement revenue from the videos.
  • How creative the original work was. A collection of statements of facts has less protection. In this case the original was creative enough to qualify, I should think.
  • The amount and importance of the part copied. Only a small part of the video is copied, and an even smaller part of that actually includes TAS input, typically only a few seconds. This would be the strongest fair use point, I think. Most of the video is taken up by the ending, which does not have any creative input from the TASer.
  • The effect of the work on the market of the original. It would be very hard to show that these ending videos make the original TASes any less interesting. In fact, they may have the opposite effect by making people want to see how the rest of the game is played, not just the beginning. This would also be a strong point in favor of fair use.
I am not sure how this would turn out. He has a few points in favor of him, but does not qualify for all of them. You don't need all points for it to be fair use, though. How many do you need? That's up to the court to decide, sadly. Because fair use is so horribly vague. In addition to all this, I think getting worked up about this is small-minded and unproductive. It is flattery that this guy chose your videos rather than other videos that could have served the same purpose, and he is not harming any of you. He is lazy and not very competent - that I agree with - but the copyright angle is not worth getting angry about here. I think the biggest issue with his videos is, like FerretWarlord points out, that they often fail to show what a typical last boss battle is supposed to look like because he doesn't know the game well enough to choose appropriate videos.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I agree. I think restarts due to new tricks should mostly be avoided, because:
  • It burns people out
  • You might not be the only person interested in doing that game, and having a good, if improvable, TAS published gives others something to compare with
  • A published TAS may increase interest in the game, and inspire others to try to improve it.
Publish early, publish often. By the time your re-re-re-restarted TAS would be finished, you could have have a v3 TAS published in stead. And since that would have gotten more feedback (and possibly competition!), it would probably be better, too.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I'm not experienced with this, but what you say makes sense, Derakon. I think you will have to avoid lambdas if you want the kind of automatic serialization you are thinking of. Of course, if you do things the old fasihoned way, with manual serialization and deserialization, you can use as many lambdas as you want, but instead have to spend lots of maintenance time making sure all relevant variables are being saved and restored correctly. By the way, your problem with "<" is probably due to not checking "Disable HTML code in this post".
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Let us not add any legitimacy to the youtube automatic takedown system by using it ourselves. At least he doesn't seem to be claiming to have made these TASes himself, so he probably isn't plagiarizing on purpose. He might just be lazy. Giving credit is the right thing to do, and it would be polite of him to do so. But by not doing so, he is just being rude - he isn't actually hurting any of us. So I don't think we need to work ourselves up into a froth about this.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Bismuth wrote:
He definitely is, though I think it's mostly for notes out of his register.
Do you have any evidence for this? I think it would definitely make it less cool, but I haven't seen any reason to think he's doing so.
Post subject: Damage, criticals and random numbers
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Ok, I've finally tracked down the criticals. For each strike, you get a critical if the low byte of the RNG is less than your crit chance C, which is the sum of the crit stats from all your equipment and is calculated when the battle starts. Each item piece of is described by 35-byte records in a table at 0xc89ba1 (i.e. offset 0x89ba1 in the rom), and the 13th byte in this table is the crit stat. If you know the id of an object, its info starts at 0xc89ba1+(id-1)*35. I have dumped the object table here, though it does not come with object names. Hopefully the other stats of the objects will help you determine which they are. The IDs of Cless' equipment is stored in 7 words (i.e. 2 byte numbers) starting at 0x7e6b0c, in the same order as shown on the equipment screen. The number on the left margin of the object table corresponds to these IDs. When you strike a monster, this happens: 1. if you face the same way as the monster, you will hit. Otherwise, you will hit if rng()&0xff >= evade+agility/4-hit 2. if rng()&0xff < C, it will be a crit 3. Compute damage. Starting from atk which depends on your weapon and attack type (for a normal strike this would just be your attack stat), compute dam = cap(cap(atk-4*def)*mul), where mul is the elemental modifier, as described previously. 4. If rng()>=55000, bonus = dam/8. Otherwise, if rng() >= 45000, bonus = dam/16. Otherwise, bonus = dam/32. Then, dam += bonus. 5. If this is a crit, dam += dam/2 6. dam = cap(dam) So this should show pretty clearly what random numbers are used. It will be between 2 and 4 for this calculation. Note that the low byte of the rng ranges from 0 to 255, so if C = 100, that does not mean that you will get a 100% crit chance, only 39%. And most weapons have much less than that. The one I tested with, Flamberge, had C=15, giving a 5.86% crit chance. Edit: Fixed the hit vs. crit order. Edit2: This script displays the upcoming random numbers as well as your crit chance.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
It's nice to see somebody working on this - I'll be looking forward to the TAS! I investigated some of the mechanics of the game when I played it half a year ago or so. One of the things I did was to dump the monster information table. Sadly, it seems I didn't dump the associated monster names, but that should be possible to infer based on the stats of the monster. Pherhaps it will come in handy. I didn't figure out what all the columns mean, but I think the two bytes between the Holy and Air resistance are individual spell immunities (one bit per spell). A monster can have 5 possible reactions to an element, indicated by the number in the column for that element:
  0: Normal   damage                                 
  1: Double   damage                   
  2: Half     damage                    
  3: Zero     damage                      
>=4: Negative damage                                                                       
The hit formula seems to be:
  • If attacker and defender face the same way, the attack is a hit (and there is a chance of some extra stuff happening, it seems).
  • Otherwise, the chance of hitting is (hit - evade - agl/4)/256.
The hit chance is capped to [0:1], like any probability should be. The melee damage formula seems to be
x = (attack - def*4)*mul*33/32
Here, mul is the element multiplier as described above, with the first element of the weapon that is something else than normal being used, if any. I don't see the point of the multiplication by 33/32, but that seems to be what the game does. I haven't tested this formula, though. It is unsual that it doesn't seem to include any element of randomness, for example. So I may be missing something. Damage is capped to [-9999:9999], and def cannot reduce damage below 0. I haven't checked how def is applied for negative damage, but it would make sense that it isn't applied in this case. The damage formula shows that one strong attack is much better than many weak ones. This is also my experience in the game. This means that attacks like shinkuuhazan (the one with the long delay, but 3 times normal damage, and long reach) can do much more damage than other attacks when you are weak. This meshes with my experience. I have sometimes done 0 damage with my normal attacks, but more than 1000 with shinkuuhazan. On the other hand, when you are strong enough to easily penetrate the enemy's defense, it is better to have 2 hits at double damage than 1 slow hit at triple damage. There is some partially commented assembly here, but I'm not sure how useful it will be - it was written at various stages in my investigation, and may contain incorrect or contradictory hypotheses. Edit: While doing this, I found some RNG code too, though I don't know if this the only RNG or not. The RNG code is at C3E793. I didn't fully disassemble it, only trace it, so I don't have all its code paths
rng = table[((state++)&0xff)<<1]
if(state >= 0x38) do something
where state is the byte at address 0x85 and the table is at address 0x10740x103c (in ram, so it is probably getting overwritten in the "do something" branch. I don't have the rom and emulator at hand at the moment (I'm using my work computer now), but perhaps somebody else can disassemble the funciton now that its location is known. Edit2: I have now disassembled the whole RNG. Here is a C equivalent of what it does (word here means 2 bytes. Remember that indexing an array of N byte data types increases the address by N times the offset. So this is equivalent to the disassembly below):
byte * state = 0x85;
word * table = 0x103c;
word rng() {
  if(++*state >= 0x38) {
    word x;
    for(x=0;x!=0x19;x++)
      table[x] -= table[x+0x1f];
    for(;x!=0x38;x++)
      table[x] -= table[x-0x18];
    *state = 1;
  }
  return table[state];
}
The disassembly itself is here:
rng:
$C3/E793 08          PHP                     P:...Mx....
$C3/E794 8B          PHB                     P:...Mx....
$C3/E795 DA          PHX                     P:...Mx....
8 bit mode;
if(++$85 >= 38) {
  shuffle();
  $85 = 1;
}
$C3/E796 E2 20       SEP #$20                P:...Mx....
$C3/E798 A5 85       LDA $85                 P:...Mx....
$C3/E79A 1A          INC A                   P:...Mx....
$C3/E79B 85 85       STA $85                 P:...Mx....
$C3/E79D C9 38       CMP #$38                P:...Mx....
$C3/E79F 90 07       BCC $07    [$E7A8]      P:...Mx....
$C3/E7A1 20 B7 E7    JSR $E7B7  [$C3:E7B7]   P:...Mx....
$C3/E7A4 A9 01       LDA #$01                P:...Mx....
$C3/E7A6 85 85       STA $85                 P:...Mx....
16 bit mode;
return $103c[($85&0xff)<<1];
$C3/E7A8 C2 20       REP #$20                P:...Mx....
$C3/E7AA 29 FF 00    AND #$00FF              P:...mx....
$C3/E7AD 0A          ASL A                   P:...mx....
$C3/E7AE AA          TAX                     P:...mx....
$C3/E7AF BF 3C 10 00 LDA $00103C,x           P:...mx....
$C3/E7B3 FA          PLX                     P:...mx....
$C3/E7B4 AB          PLB                     P:...mx....
$C3/E7B5 28          PLP                     P:...mx....
$C3/E7B6 6B          RTL                     P:...mx....

shuffle:
16 bit mode;
for(x=0;x!=32;x+=2)
  $103c[x] -= $103c[x+3e];
$C3/E7B7 C2 20       REP #$20                P:...mx....
$C3/E7B9 A2 00 00    LDX #$0000              P:...mx....
$C3/E7BC BF 3C 10 00 LDA $00103C,x           P:...mx....
$C3/E7C0 38          SEC                     P:...mx....
$C3/E7C1 FF 7A 10 00 SBC $00107A,x           P:...mx....
$C3/E7C5 9F 3C 10 00 STA $00103C,x           P:...mx....
$C3/E7C9 E8          INX                     P:...mx....
$C3/E7CA E8          INX                     P:...mx....
$C3/E7CB E0 32 00    CPX #$0032              P:...mx....
$C3/E7CE D0 EC       BNE $EC    [$E7BC]      P:...mx....
for(x=32;x!=70;x+=2)
  $103c[x] -= $103c[x-30];
$C3/E7D0 BF 3C 10 00 LDA $00103C,x           P:...mx....
$C3/E7D4 38          SEC                     P:...mx....
$C3/E7D5 FF 0C 10 00 SBC $00100C,x           P:...mx....
$C3/E7D9 9F 3C 10 00 STA $00103C,x           P:...mx....
$C3/E7DD E8          INX                     P:...mx....
$C3/E7DE E8          INX                     P:...mx....
$C3/E7DF E0 70 00    CPX #$0070              P:...mx....
$C3/E7E2 D0 EC       BNE $EC    [$E7D0]      P:...mx....
8 bit mode;
return;
$C3/E7E4 E2 20       SEP #$20                P:...mx....
$C3/E7E6 60          RTS                     P:...Mx....
Here is a lua script which uses this formula to predict the next few values of the RNG:
emu = snes9x

-- Generate the next N random numbers
function step_rng(state, table)
	state = state+1
	if state >= 0x38 then
		for x = 0, 0x18 do
			table[x] = AND(table[x]-table[x+0x1f],0xffff)
		end
		for x = 0x19, 0x37 do
			table[x] = AND(table[x]-table[x-0x18],0xffff)
		end
		state = 1
	end
	return table[state], state
end

function top_rng(n)
	-- Copy initial rng state
	state = memory.readbyte(0x85)
	tsize = 0x38
	table = {}
	for i = 0, tsize-1 do
		table[i] = memory.readword(0x103c+i*2)
	end
        -- generate the requested number of numbers
	res = {}
	for i = 1, n do
		res[i], state = step_rng(state, table)
	end
	return res
end

gui.register(function()
	nums = top_rng(27)
	for i = 1, #nums do
		gui.text(10,8*i,string.format("%04x",nums[i]))
	end
end)

while true do
	emu.frameadvance()
end
Edit: Small fitx to C code.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
creaothceann wrote:
amaurea wrote:
Advertisements make your videos more annoying, and is an insult to the viewers.
If you browse the web without Adblock then you almost deserve seeing them. Personally I don't really care about those users.
I use AdBlock, of course, but most people don't. I hate the thought that some of them might think I put the advertisements there myself. I also think that advertisements are a negative influence even on the people who don't block ads, so I would rather not expose them to more than necessary. Everybody should have e-mail spam filters, but that doesn't mean that it's pleasant to have spam being sent in your name.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
It matters if advertisements suddenly are being added where they used not to be. That matters much more than who gets paid for what advertisement might be there. Advertisements make your videos more annoying, and is an insult to the viewers. One of my videos also has advertisements on it, and I am not happy about it.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
AnS wrote:
amaurea wrote:
I think this should be allowed, because it should be possible on all controllers by switching between left and right or up and down in the middle of a controller poll.
Stop repeating this nonsense. This is not how joypad controllers work. http://www.ni.com/white-paper/11965/en
OK, thanks for the correction. I don't think it was nonsense, but it was certainly wrong.
Post subject: Re: Debate: allowed or not?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
SmashManiac wrote:
- Pressing Up+Down or Left+Right on controllers that don't normally allow it
I think this should be allowed, because it should be possible on all controllers by switching between left and right or up and down in the middle of a controller poll. I.e. it is just a question of speed and timing.
- Pressing buttons that don't exist on normal controllers but that are still read through the controller port
I don't like this one. I think the interface to the console should be at the outside of the controller, not at the level of the wires leading into the console. Or at least that runs that stick with physical controllers should be in a different category than those that do not.
- Streaming arbitrary data through an external port
I guess from my answer to the previous question I should say no to this too, but I'm not sure. I think it depends on the external port. If that port is a network port, then streaming arbitrary data there may be the only practical way to TAS a network game. Though ideally a network game should provide input files for all the players taking part in that game, and let the network port input be generated that way. I think this question will have to be settled on a case by case basis, but the answer will mostly be no.
- Partially disconnecting a cartridge
This is a special case of the previous question. I think the answer should be no in this case. "How fast can a game corrupted through a poor cartridge connection be conmpleted" is not an interesting question. If it were allowed, it should be clearly marked in the category.
- Swapping discs when not prompted
Not sure about this one
- Swapping discs with a completely different game
Well, if this results in an interesting, novel result, then I guess it would be OK, but it should not be filed under any of the individual games, and be treated like a hack.
- Witnessing the ending without completing the normal game's objective
This should be allowed. But categories that do complete the game's oy.bjective should also be allowed to coexist for the same game.
- Getting a game beaten state in memory but without witnessing the normal ending
I think this is OK as long as at least part of the ending plays out (such as the "The End" screen in super mario world). Simply setting a "game completed" bit in memory while the game continues as normal is too obscure. But I guess a "set bit X in memory as fast as possible" could potentially be an interesting category, for which this would be OK.
- Resetting during a save operation
I think this should always be in its own category (save corruption). I like the results, and it is technically interesting. But most watchers will feel cheated when they find out how it works, and I think it feels a bit dirty myself. So I don't think it should be allowed in "any%", only in a dedicated branch.
- Starting a run with dirty memory (excluding save data)
Well, if you can start with any memory content you want, then that wouldn't be very interesting, would it? You could just start at the ending sequence and get 0 frame input for every game. It would also allow you to trivially hijack the logic of the game and do anything, including replacing the game main loop with something of your choosing. So starting with arbitrary memory should not be allowed. Starting with plausibly possible ram (as generated by a proof movie which starts from a clean state) should be OK, but would still require some judgement (again, starting the run after the final blow has been landed to the last boss would make for a boring TAS, I think). In general, I think that much controversy can be avoided by proper labeling and use of categories.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I don't think categories and time-entertainment tradeoffs should be equated. Usually the former follows a few, simple, well-defined rules, while the latter is vaguer and more subjective. For example, people would usually think that calling 100% vs. any% a time-entertainment tradeoff. And I think the same should apply to pacifist. A typical time-entertainment tradeoff would be "does not use jitterwalk while the spear is equipped due to the horrible flickering it induces", or "does not use pause screens to manipulate luck". Sure, it would be possible to express those as a categories, but that would be pretty different from the categories we're used to. I think any reasonable category should be able to go into the vault, not just any% and 100%. As feos says, the purpose of the vault is record keeping, and we now have a data point for how fast the Smurfs pacifist category can be completed. I am aware that that isn't how the rules work now, and I'm not asking feos to make an exception here. But I think this TAS gives an example of how our vault-rules are suboptimal.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
What's the point of going via the string when you end up with a double in the end? Just return a double to lua to begin with.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Personman wrote:
This is an amazing idea and I hope it makes it into mainline BizHawk ASAP.
Thanks, I'm glad you like it!
Personman wrote:
One thing I don't quite understand is if playback works out of the box: if I take the .hist you describe and run it in snes9x, do I get to watch the full TAS process? It seems unlikely - I don't really know what the "FEFF as input for player one" thing is doing, but it doesn't sound like something that snes9x would play back in the desired manner. So while all the input could be recovered by a dedicated researcher, it seems like there would be some more dev work needed to make it truly awesome for the everyday-TASer/viewer, no?
You're right that the proposal above only includes recording, not playback. That doesn't mean that playback needs to be hard, though. The simplest way of adding playback support is simply to scan through the .hist file once, looking for loadstate markers, and making a list of which frames need to be loadstate-able. Then run through it again, making savestates when reaching those states, which can then be loadstated when a loadstate marker is encountered. This implementation is not the most efficient, though, as it stores more concurrent savestates on disk at the same time than needed, and savestates are relatively large. A more intelligent approach would delete savestates after they are no longer needed. But the main point of this proposal was to make something super-simple to implement that still contains all the necessary information. Once that is in place, it can be expanded on to make it into some awesome multi-track non-linear editing system or something, but requiring that from the beginning would reduce the chances of having it implemented in emulators, I think.
jlun2 wrote:
How would this work for runs that might get heavily botted, causing it to have hundreds of thousands of rerecords?
For 100000 rerecords of average length 1000 frames, such a file would contain 100,000,000 input records, and be about 200-500 MB large uncompressed. That is starting to be relatively large, but still manageable. But there should probably be an option for avoiding this. One simple way would be a checkbox to disable full history recording when starting a movie. Another, more flexible option would be to make use of the emulua savestate option for indicating that a loadstate should not count towards the rerecord count. It would be easy to make the full-history behave like a normal movie (i.e. truncate on loadstate) when that flag is set.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This isn't the same as the TAS comparison stuff. That one compares one TAS against another. With the full history stuff, you would be able to compare one TAS against all the stuff that was recorded over in the same TAS. I think the video above shows that quite nicely, but imagine that when TASing Sonic or something, you're not sure if jumping on an enemy or rolling through it will be fastest, so you try both. In the normal movie file, you will only be able to see the alternative that turned out to be fastest, but with a full history movie, you would be able to see both. It would be a bit like a "making of" movie or a "bloopers" movie. Are you trying to make a comparison video, but find the instructions too difficult? Where are you getting stuck?
Post subject: Save the full input history
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
During the making of a TAS, a large tree of possible inputs is explored, but in the end only one path through that tree is retained as the input movie. The other inputs are currently irrevocably lost, with the only trace of them being the rerecord count. While the final TAS is definitely the most interesting branch of that tree a-priori, I still think it is a bit tragical that all the rest is discarded. Here are some examples of what could be done if the full set of inputs were available:
  • "Many Worlds"-type videos like this one: Link to video
  • Showing the rerecord density as a function of time, identifying which regions are the most challenging/optimized
  • Finding the average length of each rerecord
  • Documenting what other approaches where tried, not just the number of things tried
  • Recover lost input in the case of a mistaken loadstate during recording mode
I've discussed this previously with Ilari, but we always ended up with rather complicated setups. This time I have a suggestion which I hope is simple enough that it will be trivial to include it in rerecording emulators: The full history movie is simply a normal movie file which is never truncated. Instead, every time a loadstate happens, a token indicating the frame the loadstate jumped to is inserted. That's it. A simple way of implementing this is:
  • Every time a new movie "a.lsmv" is created, also create another file, "a.lsmv.hist" say, for the full history, and initialize it the same way as normal.
  • When an existing movie is loaded, look for a corresponding history file, and open it for appending too.
  • Every time input would be added the normal movie, also add it to the full history file.
  • Every time the normal movie would be truncated, add a loadstate token to the history file, but do not truncate it.
I added this to my own copy of snes9x, and it only required a few lines of code spread over 3 functions in a single file, so pretty simple. Hopefully it will be as simple for other emulators. For the loadstate token, I used a frame with FEFF as input for player one, follwed by a 4 byte number indicating the frame of the state that was loaded, but this will change from format to format. The resulting file will be a few times larger than a normal movie, but will still be a small file. Of course, for this to be useful for more than just the TASer himself, it should be possible (dare I say encouraged) to submit the history files together with the normal movie file when submitting a TAS to tasvideos.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Let's look at the simple case of a horizontal hose connected to a faucet on one side, and open to the air on the other side. The water provider ensures that the faucet end has high pressure, while the open end has normal air pressure, which is much lower. So inside the pipe, the pressure is changing from high on one side, to low on the other. This pressure gradient accelerates the water towards the low-pressure end. For a constant cross-section hose, it doesn't really work to have water move at different speeds at different points: Water would have to pile up or be stretched thin in this case, and water is almost impossible to compress. Hence, the water can only accelerate or decelerate if the cross-section of the hose changes. It follows that the pressure gradient is zero for sections of constant cross section, and nonzero when the cross-section changes. So for a constant cross-section hose, the whole pressure drop happens at its exit. If the cross-section in parts of a hose shrinks, this will obstruct some of the water, letting less through the constricted section. This cases the pressure on the exit side of the constriction to fall, and this pressure gradient accelerates the water, causing it to move more quickly in the constricted section. The opposite applies to expanded sections of the hose. When you hold you thumb in front of the exit of the hose, the water accelerates for this reason. Your thumb reduces the cross-section of the water flow, which lets less water through, which causes pressure to fall on the other side of your thumb, which sets up a pressure gradient, which accelerates the water until the same flow rate is achieved. As long as we ignore friction, this will always happen. The equilibrium flow speed in volume/s ends up being constant no matter how the cross-section changes along the way, because the flow ultimately is driven by the pressure change between the two ends, and changes in the radius of the tube only change where that pressure change happens, not how large it is in total. As I said, though, this is only as long as friction is ignored. For a very long pipe, or for a severe constriction, friction against the walls will be considerable. If you pinched the exit of your hose to a millimeter in radius, the water should ideally be shooting through it at more than 10000 km/h, but long before it gets that fast, it is slowed to a trickle by friction. This is why the water stops getting faster once you close the opening too much.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
HappyLee wrote:
By the way, I'm a big fan of this game, and I'd like to make an 100% (all Shiny Trinkets) run this year if no one else wants to do it. One of the things that stopped me last year is the version issue. Using suicide in 2.0 can save plenty of time in the 100% run, but I'm not sure if anyone would like to see it happens.
Won't that be a non-issue if you just make it a 100% run in no-death mode, with the current movie as a verification movie?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This may be a bit late, but here's a video comparing this TAS with previous, incomplete ones: Link to video The ones being compared are the ones mentioned in the submission text, minus the one for which no smv file is available. The comparison might sometimes drop out for the Zvsp comparison, as he used a different version of the rom, but I have tried to compensate for this. See the video description for more details. Edit: A non-youtube encode of the same thing.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Ilari wrote:
Sounds similar to my earlier "Multirecording" ideas. There are some subtle issues with things like sharing progress. Oh, the thing corresponding to rerecord count would be branch count (number of segments minus number of branching points).
Yes, I remember that we discussed these ideas a while ago. Something like this has potential to make the TASing process more efficient, if the tree is exposed in the emulator GUI, allowing one to direclty jump between various alternative branches. It all depends on how much effort one is willing to spend implementing it. But I actually think that the very simplest, minimal implementation you get by just storing a copy of the movie every time a state is loaded in write mode, would already be quite useful. And making it that simple would greatly lower the barrier for having it added to emulators.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
It would be nice if rerecording did not discard the part of the movie that is being revised, but instead kept all the input in a tree of histories, much like the full undo history in text editors like vim. This would make it much easier to make videos like this: https://www.youtube.com/watch?v=T2OytHzZ72Y. These alternative histories generalize the concept of the number of rerecords from a single number to full temporal information about when they happened and what approaches were explored. Implementing this does not need to be very difficult. The easiest (but least efficient) approach is to simply store a copy of the current movie every time it is about to be rerecorded. The result would be a large number of partial movies with large overlaps, which would compress very well. Smarter approaches would involve modelling the input as a branching graph, and only storing each edge once. I don't think the overhead of doing this for every non-bot loadstate would be onerous, so perhaps this could be made the default behavior in our emulators? It would as a side effect provide automatic backups of the movies, so it would be useful for TASers too, not just viewers.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I have a modified version of snes9x which identifies unique sprites, turns them into png images, and dumps their position and orientation on the screen for every frame. This was supposed to be the beginning of a sprite-based video codec that could be dumped directly from the emulator, but I got a bit too ambitious with the backgrounds (wanting to compose the segments of background that are in vram at any given time into the large, continuous background they represent), and the project was not completed (also, this would not have been able to handle any of the color arithmetic stuff the SNES uses). But it sounds a bit similar to what you are suggesting here, so perhaps some of it might be of use. It would give you both the position and shape of the sprite at any time, letting you identify exactly which pixels need to be changed. To be honest, though. I think a much easier approach (though game dependent) would be to identify what controls the blinking, and simply turning it off. I'm not sure how easy that would be to find, though. Another possibility is to monitor the OAM to look for and eliminate blinking behavior there. Of course, turning off blinking would not be quite as good as replacing it by transparency.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This is one of the most entertaining TASes I've seen in a long time, and does not lose out to any of the super mario world non-hack TASes. The strategies are inventive, the execution is precise, and the dead-time during scrolling levels is well-used for entertainment. There were many places where I had to re-watch it in slow motion to see what was going on. So I vote yes, of course. Aside from the quality of the TAS itself, the hack also looks good, and much more polished than the previous kaizo hacks I've seen. Bowser in particular was very impressive (but as a commenter on Nicovideo said, mario's effortless dodging and relentless onslaught made it seem more like Bowser was the hero, and mario the last boss). I don't know what the people who voted no look for in a TAS, but I found what I look for, at least.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I hope this will be submitted. The hack looks good (I especially liked Bowser), though sadistic, and the TAS was entertaining and used impressive strategies. I think it is publication worthy even if there are potential improvements - there usually is. This was one of the most entertaining TASes I have seen.
1 2 3 4 5 6
16 17