Did I? All I did was write down the problem in maths. I thought you were after something more, such as a closed-form (non-infinite series) solution, possibly involving logs of some kind.
For X=101, 14 bosses are needed.
What is a good function for calculating how many bosses are needed for any X number of employees?
What? You should show your derivation for that. One of us is confused because f(101)=f(100) unless f(1)=1 (which I don't think is the case, though your statement of the problem is confusing), but even if f(1)=1 then f(101)=12, not 14.
AIUI, given a particular rank N:
If there are 0 or 1 employees at rank N, we need 0 at rank N+1.
Otherwise, we need ceil(N/10) at N+1.
So the derivation is thus:
101 employees of rank 1 need ceil (101/10) = 11 managers
11 managers of rank 2 need ceil (11/10) = 2 managers
2 managers of rank 3 need ceil (2/10) = 1 managers
1 manager of rank 4 doesn't need a manager
total == 14 managers.
The total number of employees can be expressed as the infinite series:
N + floor((N+9)/10) + floor((N+9)/100) + floor((N+9)/1000)...
eventually the rounding error forces the remaining terms to 0. Without the floors, this series is equal to:
-9 + N + 9 + (N+9)/10 + (N+9)/100 + (N+9)/1000 ...
whose limit is -9 + (N+9)*10/9.
We can therefore use (N+9)*10/9-9 as an approximation to our formula, and improve this approximation by studying the systematic error of removing the floor()s. It's difficult to see how to get an exact closed-form formula because of the nonlinearity of the floor function.
Or you could eat the potion or tasty meat you're carrying? You still have both at the end of the Legion fight.
Curse you! I was expecting some minor framegain, but it turns out it was nearly 100 frames faster (I also noticed a minor mistake later on in the same room). So I'm gonna redo from there, which will take about 2-3 days of solid work.
I'm sorry! I didn't mean it! I won't do it again!
Seriously, I really wish I'd noticed this earlier.
Anyways, I'm forced to put the run on temporary hiatus since I got stuff to do in real life, which leaves me in no mood for TASing. I'm going to try to find as much time as possible to TAS and I will most likely finish before 2011; submitting on Christmas would be fun, but only if the run is finished close to that date.
Just before Man-Eater, is it worth taking a hit from a Needles to fall faster? Like this. It looks like 82 damage or so, and I'm not sure how much time it saves.
I actually already knew of the possibility of this trick, but the damage the Needles do + 2 hits from Legion would put me on -14 hp, which obviously is unfavourable. Unless it saves 100+ frames (time it takes to kill a Bomber Armor, and time it takes to switch to Steel Plate), I doubt there is any possibility to see it implemented, unfortunately.
Or you could eat the potion or tasty meat you're carrying? You still have both at the end of the Legion fight.
Just before Man-Eater, is it worth taking a hit from a Needles to fall faster? Like this. It looks like 82 damage or so, and I'm not sure how much time it saves.
You used Medusa Head in the Legion fight last time; how much harder was the Legion fight without the manoeuvrability it provided? Was using Great Armor instead the big win which improved the fight so much or were there other aspects too?
http://bash.org/?3936
It's not just you that finds it difficult to TAS MMF games, it's everyone. If you want to try to pioneer TASing flash games in a consistent, repeatable, verifiable manner, you're welcome to try. But you'd be pioneering, and therefore nobody else could tell you how to do it, because nobody has done it.
Derakon's comment seemed to be a proof of concept that TASing MMF is possible in principle. I doubt he had any particular tools in mind when he made those comments -- only the idea that such tools either exist or can be created.
Are you already a good TASer? If not, I strongly suggest that you TAS a game on an established TASing platform first. Get used to savestate, slowdown, frame advance, luck manipulation, memory search. If you go for IWBTG as your first TAS, you will be trying to learn how to TAS at the same time as trying to develop a new technique for TASing MMF games. IME, it's far easier to focus on one skill at a time, and it will probably save you time in the long run. (An equivalent idea in rock climbing is "never try the limits of your climbing technique and your rope technique at the same time".)
Once you are a good TASer, then you may want to try your hand at pioneering a new platform.
This raises the interesting question of whether one should vote purely with regards to one's personal feelings about the game/run, regardless of whatever possible overwhelming popularity the game/run otherwise has, or whether the rating should reflect how much the voter thinks the average person would enjoy the movie.
I would say it's more desirable to vote how *you* feel, not how you think the average person feels. If voters are expected to know how the average gamer feels, why do we bother collecting and averaging their votes to find out how the average gamer feels? We could just ask one voter.
Alternatively, if we accept that the voters might well get it wrong in their opinion of average gamers, then we get a result of how the average voter estimated the average gamer would consider this run, when what we really want to know is what the average voter thought of the run. This could be substantially different with, for example, a bad game from a big franchise: it might be the case that most people hate it but most people consider that most other people like it. Similar but less extreme effects would affect all runs to some degree.
The point is that we're already taking an average of the votes to get an aggregate result, so we don't need to ask the voters to come up with some aggregate of how they think everyone else feels.
I also support the idea of taking the median rather than the mean to insulate against outliers.
I notice that you do the level 1 glitch, but in level 6 walk right past a key in the open -- at 08:28 in Flygon's encode part 1. Wouldn't it be faster to grab the key in level 6 rather than do the level 1 glitch?
There's also a glitch where you press one of the F-keys (this site suggests F8) which glitches the world map into random sprites, which changes the world map's appearance AND behaviour. You could go pretty much anywhere on the map, enter a level, and when you return to the map it's unglitched again but with keen in a totally different place. You could even get into the space outside mars with this.
Using this glitch could skip all blocking cities. Needless to say i think using this glitch would lower the entertainment value of a run.
It seems unlikely that this feature was unintentional, but it also seems not to have any obvious purpose. Pressing F8 within a level generally kills you by replacing almost all blocks with empty space and letting you fall to your death.
YUV can express colors that are not possible to express in RGB.
This is a complete nitpick because I and everybody else knows perfectly well what you are talking about, but since I love nitpicking, let me correct that statement a bit:
The statement needs no correcting. YUV and RGB are both non-absolute colour spaces, so neither has a defined gamut. YUV is defined in terms of RGB. Any given YUV has a larger gamut than its RGB by definition. If you use a particular absolute implementation of RGB (say, sRGB) then the associated YUV will have a larger gamut.
Actually it seems that you must not use a different ROM to any previous published movie. The only logical interpretation is that any future submission must sync on both (J) and (U) ROMs.
I tried both Imagemagick's -type grayscale and -colorspace gray options, and they both gave the same result, which according to Imagemagick documentation, is calculated with that Y formula (in both cases). -fx (R+G+B)/3 gives the other grayscale result, which was not shown here. So no, that was a good theory, but not the right explanation. The real reason is still unknown.
Thanks for checking this. It looks like you're entirely correct; and it makes sense that my explanation was wrong because it doesn't explain why luma is distorted in some places but not others.
I have another theory: The RGB colour cube is embedded in a larger YUV colour cube. This means that there are YUV values which do not give sensible RGB values -- for example, when you plug the numbers in the formulae, you get negative RGB values. Perhaps this is causing issues?
Let's study your nearest-neighbour example, because it's conceptually the simplest. AIUI, nearest neighbour tries to maintain Y values and to pick one UV-pair and share them between all pixels in a 2x2 block. But that can lead to YUV values out of the RGB range. Looking at the lower-right hand quadrant of the 5-ball, we find that two different pixel values want to share the same 2x2 block: the pink of the 5-ball (228,0,88) and the green of the "felt" (0,68,0). We decide we will take the UV values from the pink, because it's in the top-left, and to leave the Y values as they are. What happens to the green?
(I use the formula in my previous post; Y \in 0..255, U,V \in -128..127 )
My guess is that some hackery maps this "fake" RGB value into the real RGB value that results in the image (190,0,50) in some way which doesn't preserve luma -- and at least one of luma or chroma must be diddled to get back to real RGB values.
So there's my prediction: problems will occur at places where the YUV colour cube doesn't map back to RGB; this happens at extremes of chroma and luma. So it doesn't happen in the shot power bar because the luma is all pretty much bang in the middle of the range there; it doesn't happen at the top-left of the 5-ball because the pink of the 5-ball is of pretty average luma; but it *does* happen at the bottom-right of the 5-ball (and of most other balls) because the high chroma pink of the 5-ball combines with the low luma dark green of the felt.
I am actually surprised of the fact that the grayscale images did not appear to be completely identical. Wasn't the point of these filters to scale the chroma, not the luma? But in retrospect, this is probably an artifact of RGB conversions; there are YUV values that cannot be expressed losslessly in RGB, so additional brightness is "loaned" from other color components by decreasing the saturation. Or something. Waiting for a better explanation.
I suspect your greyscale images are not accurate representations of the luma channel.
Luma usually refers to a weighted average of RGB. In JPEG (more accurately in the JFIF container), luma or Y is:
Y = 0.299 R + 0.587 G + 0.114 B
though other constants are possible. Note 0.299 + 0.587 + 0.114 == 1.
Greyscale usually refers to a simple average of RGB. Using the letter X to represent greyscale:
X = R/3 + G/3 + B/3.
If you simply generated a "greyscale" image, this is what you get in most image editing programs. If the image is optimised to preserve luma, it will not preserve greyscale and vice versa. ie chroma lossage will be noticable in simple greyscale images.
YUV luma uses its weighted average because the rods in our eyes are most sensitive at green wavelengths and least sensitive at blue wavelengths.
EDIT: to answer the obvious followup question "How do I extract the luma channel from a YV12 image?": I don't know, sorry :( I'm just a theory guy, I don't know the tools.
Hmm, I only did 1 year of university physics, so I can't give a full answer, but:
One thing to note here is that by trying to estimate what B sees by making measurements from the point of view of A you are assuming that A and B agree on lengths; you also assume that A and B agree on events which happen simultaneously; however, events which happen at the same time but different locations in A's perspective will happen at different times in B's perspective.
As an example of what I mean, let's assume that A's hull is 1 metre in its own reference frame (and B is 0.5 m in A's reference frame). A can see that after half a second on B's clock, B has moved 0.5 A-metres. At this point in time, two events happen simultaneously from A's perspective: (1) B's bow is halfway along A's hull, and (2) B's stern is in line with A's bow. However, we know that from B's perspective, B is twice the length of A, and that after half a second of B-time A has moved 0.25 B-metres; B's bow is halfway along A's hull but B's stern is 0.75 metres away from A's bow. Event (1) therefore happens before event (2) from B's perspective, and this occurs because A and B disagree on the relative lengths of the two ships. If they disagree on lengths, then A cannot estimate B's observation of speed by combining A-length with B-time, as the example tried to do. B's observations are based on B-length and B-time. I'm struggling to say exactly where the mistake was in the question, but I think I'm on the right lines.
I remember a similar-sounding problem: suppose I have a 2-metre long rod and a 1-metre long slot in a table. I am in the table's reference frame. I accellerate the rod until its apparent length is 1 metre, then I apply a force downwards to push the rod through the hole. Diagram:
force
vvvvvvv
-> ==rod== ->relativistic motion
-table- slot -table-
Because the rod is the same length as the slot, it will fit through.
Now consider things from the rod's inertial frame. The slot is now 0.5 metres long and the rod is 2 metres long. How can the rod fit through the slot? Does the rod go through or not? What precisely do things look like from the rod's inertial frame? [I do remember the answer and will give it; but I'm sure somebody else can give a fuller explanation than I'm capable of.]
As far as I remember if you happen to be engulfed in a vortex or in process for been digested by several other specific monster, you can at least teleport the enemy and still been inside him once teleported. I think I did this once, in the gnomish Mine'End(Version 1: The Mimic of the Mines), but this is long time ago... someone could confirm for the plane?
I think this used to work, but doesn't anymore. teleport.c's u_teleport_mon() code has a check for noteleport and ejects you from the monster:
1278. } else if (level.flags.noteleport && u.uswallow && mtmp == u.ustuck) {
1279. if (give_feedback)
1280. You("are no longer inside %s!", mon_nam(mtmp));
1281. unstuck(mtmp);
so if you try to teleport a monster that teleports you on a notele level, the monster gets teleported but you stay where you are.
Note that covetous monsters' teleport-to-upstairs is different; so if you leave Juiblex alive, you can (with the amulet) arrive at the swamp, get swallowed, get transported to the upstairs, then dispatch (or teleport) juiblex and head upstairs. There aren't any other covetous swallowing monsters (beside quest nemeses) which could also be abused like this are there?
So, Tub's Idea™, anyone?
(Holy hell, it's been almost four years!)
I like this idea very much. It allows a plurality of categories without letting one or two games (Super Metroid, SMW) from taking up half the Movies-<system> pages. It recognises TASes which are awesome but of a nonstandard category by tucking them away in a dark corner of the site where they won't bother anyone who doesn't care about that game. My only worry is Bisqwit's reply:
Bisqwit wrote:
Your idea is intriguing, but I'm afraid there might be too much maintenance in it...
Most notably, the MAJOR_TROUBLE_STUCK_IN_WALL sequence break does not work on the plane of Fire. Amazingly, the NetHack devteam had thought of that; the rescue teleport will always leave you in the same third of the map, meaning that it's not nearly worth the time it would take to set it up. (Also of note is that that sequence break requires you to be surrounded by immobile boulders, thus requiring twice as many boulders as might otherwise be thought necessary; I wonder if it's possible with monsters instead?)
What about TROUBLE_LAVA? It should be pretty easy to get stuck in the lava, similar to drowning on the plane of water. AFAIK it's still subject to the same teleport restrictions, but it should be faster than any other method.
Source suggests that monsters are not enough to block a boulder; the far side either has to be a wall, a boulder or beyond the edge of the map.