Posts for Warp


Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
I think that sometimes it wouldn't even be a question of whether the game shows more or less explicit sexual content, but whether the speedrun shows that part of the game. For example, in most GTA games you can go to a strip bar and get a lap dance. However, AFAIK in none of the games is this part of the mandatory storyline; it's completely optional. A speedrun would naturally not show this. Thus would GTA games be acceptable for publication, as long as the speedrun skips any of those more explicit parts? Moreover, if getting a lap dance were part of some kind of category (eg. some kind of 100% completion), would it be rejected?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
By the way, a couple of questions I thought of, for your consideration: 1) If the site were redesigned to be more like speedrun.com, as I suggested earlier, with each game having its own page, with all the TASes of said game being neatly and clearly listed or tabulated there, would you agree that this would perhaps allow loosening the principle of keeping the number of branches/categories for a single game minimal (since perceived clutter wouldn't be a problem anymore)? 2) If you answered the previous in the positive, do you think it would be a silly idea to start the loosening of that principle now, even prior to such a potential site redesign? Should we just wait for the redesign to happen before we start accepting more categories for games?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Nach wrote:
Beyond that we have different versions of games where input will never sync between the two, not even in limited (but complete) segments. For those, I don't see any parity between the games anymore, despite a similar look and feel, and it being common knowledge that the two are supposedly the same.
That's a very interesting possible approach at the question of "should these versions of the game be considered the same game?" If the exact same optimal TAS input works for both (or at least in the actual playable parts of both), they would be considered the same game, but if an optimal TAS input for one would never sync with the other (even with possible delays added or removed from the input), then they could be technically considered different games. (That still wouldn't mean that both should be automatically accepted. There still ought to be some notable differences between the two that justifies publishing both. But the minimum requirement of "it's a different game" would at least have been fulfilled by this.)
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Your approach is interesting (and different from the usual method). However, I'm not exactly sure how you deduce that the angle between AB and AC is 36°, and that the angle between CB and CF is half of that. Also, I'm not sure how you deduce that ABG is isosceles.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
r57shell wrote:
Save, move, test collision, and restore - should take in single frame, so it will not glitchy bounce in/out.
If you simply test if the moving object would overlap with an obstacle in the next frame, and just keep the object in its current position, it will often stop before visually touching the wall. It will only work ok if in the current frame it's perfectly adjacent to the wall.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
No offense, but dude, I don't think many people are going to read that wall of text. Try to summarize, please?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
So Spyro can't do pretty much anything to baby-Spike, but when he grows to kaiju size, suddenly Spyro can beat him easily. That makes sense.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
OmnipotentEntity wrote:
Hint, if you follow the same procedure as rpbp you get a 18-72-90 right triangle. But the problem is you need the side that represents the cosine of 18°. 🤔
I tried with a triangle with angles 18°, 81° and 81°, and trying to find similar triangles within it, but I couldn't figure anything out. There was always one side too many with an unknown length. I might have missed something obvious, though. I didn't try with a 18°, 72° and 90° triangle. The hypotenuse has length 1. The shorter cathetus has a length of sin(18°), which exact value we know from the previous problem. The longer cathetus can be calculated using Pythagoras. But then what? One idea would be to halve the 18° angle, getting a new triangle. However, while we know the length of the longer cathetus (ie. it's the same as above), we don't know the length of the hypotenuse nor the shorter cathetus (I don't think it's just sin(18°)/2, even though one's tempted to think so). I can't think of any similar triangles that could be formed either, which would give us any more information...
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
The moving object bouncing like that from the wall is one possible solution, but doesn't look&feel very good and polished. Just an opinion. But I understand perfectly why it's such a difficult problem, as I described in great length.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Swordless Link wrote:
This is a speedrun. The version that saves the most time should be published.
It's a speedrun of a different game. As in, the games are not identical. The difference in speed is not because one run is more optimized than the other, but because one is using a different game, with functional differences, than the other. Personally I find it a bit silly to argue "this TAS is faster than that other TAS, therefore it should obsolete the latter", when the TASes aren't even running the same game binary. Because they are not bit-by-bit the same game, if both deserve publication, they should be published side-by-side.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
As said, it depends on how accurate you want the collision to look, and how you want the moving object to behave when it collides. The easiest situation is if the moving object simply stops moving when it collides with an obstacle. However, as a game mechanic this is usually also one of the worst possible solutions (with the possible exception of certain games). When the object just stops dead, it feels clunky to the player. Most often you would want the moving object to eg. slide alongside the obstacle, or possibly bounce from it. But even when it's enough for the object to just stop at the collision point, you need to calculate this point. You could try an iterative process, using what effectively amounts to a binary search (ie. see if the object at half-way between its previous position and its new position overlaps with any obstacle, and depending on whether it does or not, look at one quarter way to either direction, and so on, up until the desired accuracy). Or you could use an exact formula (which would require essentially calculating intersection points between lines and rectangles).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
OmnipotentEntity wrote:
It's also possible to calculate the sin(9°) through a similar technique to the one used by blackpenredpen to calculate sin(18°). Why not give it a shot Warp. ;D
I tried it, I couldn't figure anything out.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Even if you don't care if the moving object may go through obstacles (because it makes too large of a jump from frame to frame), you still have the problem of what should be done when in the next frame the moving object is partially inside the obstacle. Where do you put it? If the moving object should never go inside obstacles, you still need to calculate the point of collision, even if roughly.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
That video reminded me that I forgot to mention in my previous post that even with one single moving object and a bunch of static obstacles, you can furthermore run into the problem of what happens if the moving object collides with more than one obstacle at the same time. This is especially problematic if you go the route of accurately calculating the new direction of movement based on the sub-frame time of collision, as I described. (In other words, if you calculate that at t=0.32 it collides with obstacle A and you proceed to calculate where it will move from there when t=1, you might find that it collides with another obstacle eg. at t=0.74. If you then proceed recursively from there you might find that it collides again before t=1, perhaps even with that first obstacle, and so on and so forth.) The moving object may even collide with two obstacles at the exact same time (eg. the inside of a corner). In a tight axis-aligned grid-based system of obstacles this might even become likely. So yeah, it's not a trivial thing. All physics engines need to deal with this, and it's not at all easy. (Especially in older ones you often encountered unrealistic behavior, like an object on the ground constantly moving back and forth, because the physics engine is unable to find the equilibrium point, as the object is constantly colliding with an uneven ground.)
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Nach wrote:
On a side note, adelikat brought up an argument asking how would we view a hack which changed some the parameters to the game engine similar to how PAL does to NTSC here, and creates some new game-play opportunities. Would we consider that for publication as a new branch/variant that our players could compete to get the best score? If we accepted PAL should we accept that too? Once you start questioning things from the hack angle, my point B above is kind of demolished.
I think it's completely justified to judge the validity of official versions of a game with rather different (ie. less strict) standards than unofficial third-party hacks. (The latter would require, at the very least, significant notoriety and popularity.)
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Collision detection can be surprisingly complicated, even in extremely simple scenarios (such as having all obstacles be axis-aligned squares in shape, and positioned in a regular grid, and even if the moving object is itself also an axis-aligned square or rectangle). One thing that makes it complicated is that in a computer program objects move, by necessity, in nonzero-sized steps. Thus if you were you just check for an overlap of the moving object with obstacles, the moving object may miss some of them (even though they should have collided if the object had moved contiguously). For example, if one corner of the moving object would have just barely touched a corner of the obstacle, it could easily skip over it, with this kind of overlap check. If you need an accurate collision detection, you need to actually calculate whether the entire polygon formed by moving the object over its path from its position in the previous frame to its position in the next frame, overlaps with an obstacle. The problems don't end there. Even if you do implement this, and get an accurate point of collision (and thus the distance that the object moves before it collides, ie. the exact sub-frame in which the collision happens), you then need to decide how the object should behave. Let's say that the object is moving diagonally, and let's mark the first frame as having a t=0 and the second frame as t=1, and the collision having been calculated to happen at t=0.32, where should the object end? If the object should just stop at the point of collision, then the answer is of course trivial: At the point of collision (duh). But what if you want it to eg. slide along the obstacle, when it collides with it, for instance? Or what if you want it to bounce, as if it had been a billiard ball hitting a wall? You would need to calculate its path from t=0.32 to t=1, taking into account the collision that happened at the former (and thus the new direction that the object takes). (A simplistic approach would be to simply stop the object at the collision point for the remaining of the frame, and then start moving it in the proper direction for the next frame. This is much easier to do, and might work with simpler simulations.) And heaven forbid you have several moving objects, colliding with each other. That's a huge, huge can of worms. So it's not an easy question in any way.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
BrunoVisnadi wrote:
That is, we can write sin(18º) as (1 + sqrt(5))/4, as this number squared also gives us (3 - sqrt(5))/8
You missed a minus sign there. But yeah, sqrt((3 - sqrt(5))/8) seems to indeed be equal to the more simplified answer (-1 + sqrt(5))/4.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Bobo the King wrote:
sin(18) = sqrt(3 - sqrt(5))/8
That doesn't seem to be correct. Note that sin(18°) is approximately 0.309, while your result is approximately 0.109.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
sin(18°) is famous in that its precise value can be calculated geometrically. If somebody hasn't seen or done it before, perhaps they could give a try.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
jlun2 wrote:
if you let any arbitrary category be accepted
I never wanted to imply that anything anybody comes up with should be automatically accepted. Obviously categories should be sensible, reasonable, and entertaining. There should be a good reason why a particular set of goals in a particular run ought to be accepted as a valid category. It shouldn't be completely arbitrary.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
I posted a site redesign suggestion to the recent NTSC vs. PAL thread, and that suggestion would fit much more perfectly here. (Although it's also quite relevant there because it's a solution to the problem of perceived clutter if we start to accept copious amounts of TASing categories for each game.) Someone mentioned earlier that they don't like the speedrun.com site redesign. I don't know if they were talking about its current design, but I think it's currently really good, and would fit tasvideos.org perfectly. If you go to http://www.speedrun.com/ and write the name of a game in the search bar on the top, such as "super mario", you get suggestions starting with "Super Mario" as a series, and then individual games in that series. If you select "more..." from the list, you get a page listing all the games in the series (for which there are speedruns): http://www.speedrun.com/games#Name=super_mario If you select one of the games (either from the search box suggestions or that page), such as "super mario bros", you get a nice page dedicated to that particular game: http://www.speedrun.com/smb1 It has the game's cover art, and some basic info (such as publication date), and links to resources (such as guides, forum, statistics...). On the right hand side different speedrunning categories are arranged neatly into tabs. This allows for large amounts of categories. For example Ocarina of Time has a whopping 13 categories: http://www.speedrun.com/oot If tasvideos.org used a similar design, then there could be two possibilities: One possibility would be to not use tabs, and instead list all the TASes for that game as a list (in a reasonable order, starting with "any%", followed by "100%" if it has one, and so on). The other possibility would be to use tabs for each category, and show the entire publication history of that category in its tab. This kind of design would easily allow us to get rid of the principle of keeping the number of categories for a single game minimal (which I think is rather unnecessary).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Radiant wrote:
They play the same roms (without requiring emulation and discounting region lockout) therefore they are the same console.
I'm not sure that's enough of a criterion. The Nintendo DS can play GBA games, but that doesn't make them equal. If I understand correctly, there are quite significant differences between the Famicom and the NES, most prominently in their sound chips, and probably other parts (such as the Famicom controller having a microphone, and a different expansion port).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
This whole discussion made me thinking about something that might be relevant: On what basis it is determined that two consoles are the "same" console? On what basis it is determined that two games are the "same" game? Are the NTSC and PAL versions of the NES the "same" console? They are not identical, as there are differences in the hardware. Even the CPU's and PPU's aren't identical (as seen eg. here). They may be very similar, but not completely identical. Eg. their clockrates are different, among other things. Is the Famicom the "same" console as the NES? If not, where do you draw the line? Is the NTSC version of Super Mario Bros the "same" game as the PAL version? If I understand correctly, the two versions are not bit-by-bit identical, as there are changes in the executable binary. If you consider the the "same" game, on what basis do you assert this, and where do you draw the line? Is the Sega 32X version of Doom the "same" game as the PC version? How about Doom64?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Mothrayas wrote:
I am aware of the speedrun.com verification process. I don't see how what you wrote here counters anything I posted.
You made it sound like publishing runs at speedrun.com requires significantly less work than at tasvideos.org, and that's one of the reasons why comparing the two is not valid. I questioned your reasoning. You made it sound like (although you didn't directly state that) speedrun.com just publishes runs without much work being put into it, which is why they can afford having so many categories. This may be a completely unfair assessment of them.
Mothrayas wrote:
andypanther wrote:
The idea of a design with game pages is something I always supported, you should really look into that!
We have, for years already. I'll grant that more should be done with it, but that's where the technical and practical hurdles come in.
It's just that it would be nicer if we had actual pages for each game, just like at speedrun.com. For example if you search there for, like, "super mario bros" and select said game from the drop-down list, you get a nice page with cover art, some basic info (like date of publication) and different speedrunning categories in different tabs. Of course at tasvideos.org we wouldn't probably use tabs for different categories, but simply list all the runs in a reasonable order (with "any%" first, and so on). Or if we would use tabs, perhaps each tab would show the entire publication history for that category. Either way, it would allow for us to be much more liberal in terms of number of categories, without the site becoming cluttered. But I do completely understand that this kind of redesign would mean a very significant amount of work, so I'm fully aware of how difficult and laborious it would be. I'm just dreaming of what could be, if we had enough resources to do it.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Habreno wrote:
So once again. I request rejudgdement based on fatal flaws in judgement issuance reasoning. 8-2 is misappropriated and even assuming that is explainable none of it should be factored in in the first place since region change does not care about anything but language change and title screen differences. These errors in the judgement issued are absurd and go against current site rules.
Since you are responding to my post, I should state that personally I don't have an argument for the judgment being wrong (as per the current rules and principles of tasvideos.org). I'm just disappointed that this was rejected, rather than published alongside the NTSC version. If the only problem with publishing this is the site rules, then perhaps those rules would benefit from some revision (but that discussion is already taking place in the proper thread, so there's no need to have it here.)