Posts for Warp


Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Randil wrote:
Well, by looking at the formula, it seems that for movies with few votes the rating lies closer to the mean for all movies. The more votes a movie gets, the closer this weighted rating gets to the arithmetic mean.
I think there's a confusion of terminology here, and I honestly can't understand what you are trying to say. "Mean", when used all by itself, is synonymous with "arithmetic mean", which is colloquially called just "average" (in other words, the sum of all the values divided by the amount of values). You probably meant something else with either term, or both.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Randil wrote:
Instead of using the arithmetic mean, how about using a weighted rating similiar to the top 250 rating system in IMDB, defined as (taken from the bottom of the top 250 page): "The formula for calculating the Top Rated 250 Titles gives a true Bayesian estimate: weighted rating (WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C where: * R = average for the movie (mean) = (Rating) * v = number of votes for the movie = (votes) * m = minimum votes required to be listed in the Top 250 (currently 3000) * C = the mean vote across the whole report (currently 6.9)"
Interesting suggestion, but it would also be interesting to know a bit more about how it would change the results if it were implemented, before making a decision one way or another. Can you give some actual examples (eg. from some actual TASes and their ratings) how that formula would change the rating value compared to the current formula?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
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. There are many runs which I personally don't find extremely entertaining, but which I understand very well how the average gamer would find quite interesting. This poses a dilemma when rating: Should I rate it according to my feelings, or should I rate it according to what I know about the sentiments the average gamers and TASers have towards the game/run? Of course the dilemma is even harder in the opposite case: In other words, when I personally like a run a lot, but I know that it's not very popular in average.
Post subject: Re: encoding on linux server
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Ilari wrote:
Install schedtool (its in package repostiories), and then to encode, run 'schedtool -D -e <rest of encode command>'.
What's the difference between 'schedtool' and 'nice' (except that the latter is a standard builtin command in all unix shells)?
Post subject: Re: RGB and YUV conversions
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
rhebus wrote:
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.
Even if that's so, there are probably no practical consequences once you get to brightnesses rivaling that of the core of the Sun (which is probably achievable by colorspaces which use floating point).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
There's a scene in this game which is just... ****ed up, I say. Namely, this: Leonardo (blue mask) is just terrified. The expression on April's face doesn't make the situation any better. And what's with Michelangelo's (yellow mask) pose there? It's just wrong.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Aktan wrote:
320x240
I hope the publication will be in 640x480, as voted in the poll.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Note that skipping forward during a "playback" of a recorded movie is technically impossible because the record file is basically "playing" the game (by providing the game with pre-recorded input). Hence it's obviously impossible to directly jump forward, skipping part of the playback. The only thing an emulator can do is "fast-forward", in other words, basically emulate the game (and applying the keypresses in the record file) at high speed. Once you get the playback to a certain point, you can take a "snapshot" of the entire state of the game, in the form of a savestate. These savestates are designed (in most modern emulators) so that the playback of a record file can then continue from that point forward. However, as said, there's no way to "skip" forward for the first time, without any savestate information. The most you can do is "fast-forward" (by making the emulator emulate the game at high speed).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
I suppose this could be fake, but I'd like to think it's the real thing. Some research could give it credibility, but I'm too lazy right now to do any googlefu on it. http://www.youtube.com/watch?v=16oaGSltUPE
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Is this a record for the highest amount of "no" votes ever, both in absolute value and relative to the total amount of votes? Sadly, the run itself is not bad, it's just a poor game/goal choice combination...
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Kuwaga wrote:
I thought I had dropped enough hints, but now I can't tell if you didn't take at least part of the post too seriously. That's just my kind of humor, I'm sorry.
Ok, I didn't fully catch your original intent with your post.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Kuwaga wrote:
Discuss.
I don't think there's much to discuss. It has become clear that the wording of the rule is ambiguous and doesn't cover special cases. Trying to "discuss" what this ambiguous wording might mean according to people's personal opinions is rather moot. That's not the important issue. What would be more important is to reword the rule to make it less ambiguous and clearer. I made such a request in the 'general' group, to no significant response. (It almost feels like people are more eager to fight over what their personal interpretation of the vaguely worded rule is than making the rule less ambiguous.)
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Scepheo wrote:
Going into FCEUX, running the game and disabling the background, I found the even then Shadax can go behind it (as he's only half visible behind some blackness). So, it seems that the game does indeed draw some tiles, then some sprites, then some tiles.
Since the visual obstacles have diagonal edges, it would mean that it would have to draw part of a tile first, then the sprites, then the rest of the tile, which is obviously impossible. AFAIK, you can't even draw one full tile first, then a sprite, then another adjacent tile. All the tiles are drawn in one single step. The sprites are drawn either before any of the tiles are, or after all of them have been drawn. A sprite cannot be in-between two tiles. What you describe sounds more like the game is modifying the sprites themselves (by modifying their pixel data), rather than doing anything with drawing order.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
zem wrote:
you know what would be the best. if encodes of this and all zelda games were made with a hack that removes the low-health warning bleep, like how megaman 1 is encoded with visible magnet beams or whatever.
What next? Remove the endearing "hey, listen!"? ;)
Post subject: Re: RGB and YUV conversions
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Bisqwit wrote:
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: YUV can express colors that are not possible to express in RGB which uses a limited gamut. The problem is not RGB per se, but the limited accuracy of its representation in most image formats and display systems. Namely, most of these formats use a linear mapping between color components and (typically) a 8-bit or 16-bit integer. This not only limits the maximum (and obviously minimum) value of each component, but also introduces aliasing (which can sometimes be even visible, eg. in slow grayscale gradients). There are RGB-based color spaces which have no such limitations, typically using either larger integers or floating point numbers for each color component, and which can go far beyond the upper (and lower) limits of the traditional RGB-based image formats. scRGB is one example of such a color space. Of course this is completely theoretical stuff in this context because we have to limit ourselves to the traditional limited-gamut RGB when encoding and viewing videos.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
NitroGenesis wrote:
This was funny.
Netsplits happen. What's so funny about it?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Does "users with published movies" include users who had published movies in the past, but all of them currently being obsoleted (iow. "former players")?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Scepheo wrote:
All the other things can be solved by using a clever drawing order. Which is usually from the bottom to the top.
Drawing order of what? You can't make the NES draw some tiles first, then some sprites, and then the rest of the tiles. Moreover, you can't draw two tiles at the same place (remember, it's just a grid of adjacent tiles, one tile per slot). In theory you could have all the geometry which can be either in front or behind the moving objects as sprites, because the drawing order of sprites can be defined. However, I think the problem with that is that there aren't enough sprites for all such edges, plus you can only draw a maximum of 8 sprites per scanline at one time (the hardware won't draw any more). Maybe they are sprites and they got around these limitations with clever level design, but I'm interested in knowing exactly how. Or if they used something else completely.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Does anyone know how the isometric projection in Solstice was implemented? For those who don't know about the technical details of the NES, let me explain why Solstice is technically such a challenging game to make for that platform, and why its implementation is so ingenious (this info is self-evident to anybody who knows even a bit about how the NES graphics work, but many people might not be fully aware). Please correct me if I get any of this info wrong. The graphics of the NES are tile- and sprite-based, both of which are 8x8 pixels (and 4 colors can be used in each tile and sprite, with some additional limitations). Simplifying, the screen is a grid of adjacent square tiles which can be scrolled (iow. the location of each tile is fixed with respect to the other tiles). There's a limited number of sprites which can be drawn anywhere on screen (although with some limitations on how many sprites can be drawn on one horizontal line of screen pixels). Obviously tiles are usually used for static backgrounds and sprites for moving objects (such as the playable character). A sprite can be drawn either in front of the tiles, or behind them (both tiles and sprites can have fully transparent pixels to make whatever is behind them visible). However, you can't draw a sprite which is partially behind a tile while the rest of it is in front of it. The technical challenge with an isometric projection like the one used in Solstice is that moving objects (such as the playable character) need to sometimes be both behind some part of the scenery (eg. a box) and in front of other scenery (eg. the floor behind the box). What makes this even more challenging is that the edges of the geometry are often diagonal (due to the isometric projection) and even free-shaped, and thus don't conform to the strictly square tiles and sprites. To the modern player (and even to most players of the time) the playable character moving partially behind a box or a staircase (with diagonal edges) may not seem like a big deal, but to anyone who knows how the graphics in the NES work it's a really ingenious feat from the part of the game developers. If I'm not mistaken, that was actually one of the biggest hurdles the developers had to overcome when they made the game. So, does anyone know how exactly Solstice does this?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Slowking wrote:
Well runs can be submitted as much as they want. But when a run gets published the rom it was made on becomes the default (if the rom is clearly faster). It doesn't matter how the submission came to be. I mean really, this site has rules and if you are not going to honor them on a whim, you might as well not have them. That's what pisses me off about the whole thing.
You are arguing that you know the intent of the written rules better than the people who wrote those rules. Just because a rule may be ambiguous doesn't mean it has to be taken literally and contrary to its original intent. It means that the rule should be reworded to be less ambiguous and reflect better the intended meaning. You are, however, arguing that your interpretation of the rule must be followed because it has been written in such way. I have already said that it's the intent of the rule (ie. its spirit) that matters, not its letter. The people who wrote and impose the rules ought to know what they meant when the wrote them. There's a term for people who insist in imposing literal (but wrong) meanings of rulesets, but I would be invoking Godwin's law if I wrote it out, so I'll skip it.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Slowking wrote:
Uh how one can make up "spirits" so randomly. Nowhere in the rules does it even hint to that "spirit".
By reading the context. The section starts with "you should prefer the (U) ROM unless you have a good reason to use something else". Then immediately after it states that the same ROM should be used for subsequent runs. Why? Well, because if the non-(U) ROM was accepted previously, there are good reasons for that, and the same reasons apply to the new run as well. In other words, the same reasons of ROM choice apply to both, the existing run and the new submitted run. But this particular case was exceptional: The (U) run was accepted because of special circumstances. You would have to argue the same special circumstances for a new (U) run. Can you? No, you can't. Hence there is a better reason to switch back to (U): Namely, because the rules say so (iow. the (U) version should be preferred).
I'm sure the spirit was to keep roms consistent so you can compare runs better.
You refuse to accept the concept of "exceptional case". Accepting the (J) run was an exception to the rules.
With acepting the J run tasvideos fucked themselfs into making the J standart, since it's the fastest rom to use.
Maybe in your mind.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Slowking wrote:
If there already is a published video, do not use a different ROM than what it uses, unless the new ROM is obviously better, and you can show how it should be compared to the existing movie.
Pretty clear isn't it? English is prefered in general, but you should use the same rom the last published run used unless there is a good reason not to. And there really isn't. And yeah that is not only the letter of the rule, but also the spirit. Just because people don't like a japanese OoT run doesn't make it any less true that this run should have been in japanese.
The "spirit" of the rule is that the previous run was accepted with a non-(U) ROM for a good reason (the ones listed in the rules), and that a new run should stick to that ROM for the same reasons, unless there are better reasons to change it. That means that you would have to argue that a new (J) run should be published for the same reasons as the previous one. Remember what the reasons for publishing the previous one was. Can you claim the same reasons for a new (J) run made specifically for tasvideos.org? No? Then you are breaking the spirit of the rule. The (J) run was not accepted because the ROM is better than the (U) ROM. It was an exceptional circumstance. You can't use the same reason for a new (J) run.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Scepheo wrote:
Warp wrote:
Care to give a reference to that?
In the rules, under the title "Use the correct version", it says:
Rules wrote:
If there already is a published video, do not use a different ROM than what it uses, unless the new ROM is obviously better, and you can show how it should be compared to the existing movie.
Ok, I admit that that rule, in its context (especially in its context), could be interpreted to mean that the (J) ROM is a valid choice if it has been accepted once. I made a request in 'general' for clarification of the rules on that (without taking a stance on either side of the argument).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Patashu wrote:
-Doesn't exit the field of view
That feels too game-specific. A "category" that was created for a Sonic game, and basically can only be applied to that Sonic game (it could be theoretically applied to some other games as well, but there's no rational reason to apply it to them because momentarily exiting the view isn't as "bothersome" than with that Sonic game). Plus it doesn't stop the TASer from glitching its way through the levels with Sonic being most of the time behind the scenery anyways.
Post subject: A clarification to the rules might be in place
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
The "Use the correct version" of the rules could perhaps use some rewording to make it less ambiguous. Currently it states: "Use the (U) version of a ROM unless there is a good reason not to (as an example a shortcut/trick which only works in a different version, or superior music), or the version does not exist." and then, seemingly referring to the previous point: "If there already is a published video, do not use a different ROM than what it uses, unless the new ROM is obviously better, and you can show how it should be compared to the existing movie." It has been argued (and I suppose it's a fair assessment) that the latter statement implies that if a run using something else than a (U) ROM is accepted and published, then subsequent submissions can (if not even should) use that same ROM. In a way, it seems like the latter rule is giving a valid exception to the former rule (ie. that the (U) ROM should be preferred), if not outright contradicting it. More importantly, if a rare exception is made to the first rule (by accepting a non-(U) ROM as a one-time event because of exceptional circumstances), the second rule would seem to open the doors to bypass the first rule with impunity. The second rule also doesn't make it clear whether it's talking about different versions of the game published in different continents, or whether it's perhaps talking about different ROM dumps of the exact same game cartridge (as it's quite common of the same game to have different ROM dumps made by different people in different ways). I think that the rules could use some clarification on this regard, to better express the actual intention. (Note that I'm not taking any kind of stance onto which side of the argument the rules should be clarified towards. I'm not a judge. I'm just arguing that they should be made more explicit and less ambiguous in this regard, to avoid future controversy.) Also a clear stance on exceptions made in special circumstances (and those exceptions not invalidating the rules) should be made in the rules, so that they can be referred to in the future.