And theoretically, I'm working on a non-glitch Rockman TAS.
What do you classify as a glitch in Rockman?
I'm guessing this means 1. no through-the-wall (including ceiling zipping) 2. no screenwrap ladder grabbing 3. no pausing to reset vulnerability... the rest of it doesn't cause route changes or obvious gameplay changes or is impossible without doing one of those I believe (like grabbing ladders early, that's almost unnoticable).
I think it would be a good idea to make a concrete list of tricks which cannot be used in the "no-glitch" version of the TAS, all of them with a rational basis, and if the movie is published, this list should be put in the movie description (alongside the reason why they are considered "glitches" not to be used in such run). Else it may feel a bit arbitrary why something is used and something else isn't.
Reading http://tasvideos.org/SuperMetroidTricks.html it becomes quite clear that making a high-quality Super Metroid TAS is really laborious and requires minute attention to detail. I must admire the amount of effort put into it, especially taking into account that we are talking about 1-hour long videos...
And then some people diss TASes because they are "too easy" to make.
I just watched all the four Super Metroid TASes in a row (100%, any%, the "semi-published" any% aiming for the internal timer, and this one).
Is it just me, or is this run not at par with the newer runs anymore, with regard to newer techniques found? Somehow the running in the newer TASes looks smoother, with less delays and overall faster, especially at parts which are equal in all the runs. I suppose that many of the techniques and tricks used in the newer runs were not known when Terimakasih made this one.
Is anyone planning an improvement?
And theoretically, I'm working on a non-glitch Rockman TAS. However, I'll gladly resign that project for someone else who's willing.
What do you classify as a glitch in Rockman? Should there be a specific list of glitches which cannot be used? (Who decides what is and isn't a glitch?)
Do you think there are other forms of life in space? Why?
I think it is possible. It would be religious to say that there aren't, considering no proof is given either way. In this aspect, I believe in the scientists.
While I have the utmost respect for science and the scientific community (I consider myself a skeptic with regard to pseudoscience, which I detest), I think this is one thing where the majority of scientists are a bit biased. The logic goes like this:
- There's no scientific evidence that life on Earth was created instead of having appeared by natural causes. I completely understand and respect this as a scientific fact.
- Thus it follows that natural phenomena must be so that they can produce life.
- Thus given the right conditions it must be so that forming life by natural means becomes possible.
- Not only that, but given certain conditions forming life must be quite probable.
- Since there's a staggering amount of different planetary systems in the universe, the amount of planets with these conditions must also be high, so the probability of some of them having life is also quite high.
Personally I see somewhat of a circular deduction somewhere in this deduction chain. Because there's life in Earth, it must be possible for life to form by natural causes. Given the proper natural conditions, forming life must be possible, because there is life in Earth, after all, where life was formed by natural causes. It just feels like the phenomenon is explained by the phenomenon itself: It must be possible for life to spawn by natural causes because life exists on Earth, and life exists on earth because life can spawn by natural causes.
Moreover, it must be more or less "easy" and "probable" that life forms given the right conditions (or else there wouldn't be life on Earth). This is so ingrained in the scientific belief that even the mere presence of water seems to make the probability of presence of life quite high. Personally I find it amusing that they almost expect to find signs of life in Mars if they find signs of water in Mars. As if water made the probability of life something like 50% or something.
(Quite curiously, it is actually possible that there has been some life in Mars, but from Earth! It has been scientifically argumented that it would theoretically possible for mold spores to be carried by air currents to the upper layers of the atmosphere, grabbed there by solar winds and carried all the way to Mars. Mold spores are incredibly resistant to all kinds of radiation. It has been estimated that some mold spores could survive even a thousand years of outer space radiation and still spawn if they arrive to the right conditions. If some mold spores from Earth have been transported to Mars during the past millions of years and there has ever been water and even the slightest of proper atmospheric conditions, it's theoretically possible that mold from Earth has grown in Mars at some point.)
For once the nesvideoagent's "beauty" algorithm caught the essence of beauty spot-on with its third proposed screenshot.
Btw, I notice that in this metroid run, in the same way as in the others, bomb-jumping is used a lot to access places which don't seem to be accessible otherwise (at least not at that point of the game). I was wondering if this is indeed the original way intended by the developers to access those places, or if this is just a trick not supposed to be possible (but instead you need to find some object which allows you to access those places).
My very first intuition was Fullmetal Alchemist, but looking at the image more closely it doesn't really look like it after all. So no price for me, I suppose.
I think a bit stream is related to some other things, not really relevant to this issue. Perhaps "bit sequence" is more the term you were looking for.
can be written in terms of 2^X = Y (in this example x = 4 and y = 16).
Hmm, "1001" cannot be "written as 2^4 = 16". What 2^4 is telling you is the amount of different bit combinations that can be achieved with 4 bits (ie. 16 different combinations). "1001" is simply one of those possible combinations.
In order to know which decimal value does "1001" (which is a base-2 number) correspond, you can do it with the formula: 2^0 + 2^3 = 1 + 8 = 9. The first term is for the least-significant bit (the "zeroth bit") which is on, and the second term is for the fourth least-significant bit (the "third bit").
Likewise "1111" would be 2^0 + 2^1 + 2^2 + 2^3 = 15. (You can also think of "1001" as being 1*2^0 + 0*2^1 + 0*2^2 + 1*2^3 if you like.)
The way I refer to X and Y (when thinking about it myself, not to other people) not is that X represents the number of bits while Y represents the state space of those bits. Since I have seen the word "bits" used to refer to both X and Y I am not sure which one is supposed to be refered to as a bit.
I have never seen the maximum range representable by a certain amount of bits being referred to as "bits". I think you are confused. "Bits" is always used to describe the amount of bits in a certain value, nothing more.
Each pixel is made up of the RGB color model
Not necessarily. RGB is just *one* way of representing images. Another very used representation is a paletted image (used eg. in GIFs and 8-bit PNGs), where each pixel is just an index value to a palette table, instead of being the color itself. Thus from the pixel value alone it's impossible to tell the color of the pixel. You have to look at the correspondent color in the palette table instead.
There are other color representations used in image formats besides RGB, but they are much more rarely used. (Mainly they are used in very specialized industries.)
In the vast majority of image formats, however, the rule of thumb is that if it's an "8 bits per pixel" image, it's paletted, and if it has more bits per pixel, it uses the RGB model (although in some cases it could also be BGR, which is just a case of ordering of the color components inside each pixel).
so since there are 3 variables in this color model (red, green, blue) I took the number of bits per pixel and multiplied this number by itself 3 times (in other words cubed it).
No, bits per pixel means exactly that: The number of bits used per pixel. How these bits are divided into the different color components is another thing, but one pixel uses that amount of bits, period.
For example in an image with 16 bits per pixel you would have 16 bits for red x 16 bits for green x 16 bits for blue.
That would not be 16 bits per pixel. That would be 48 bits per pixel, which is a completely different thing. If an image has 16 bits per pixel, then it has 16 bits per pixel, not a bit more. (Usually this kind of image will have 5 bits for the red component, 6 bits for the green component and 5 bits for the blue component, but that's mostly irrelevant.)
The reason you need 16 bits for each color is because you need to represent the level of intensity of red, green, and blue. For example the lowest intensity would be 0000 while the highest intensity would be 1111.
"0000" and "1111" are 4-bit values, not 16-bit.
If you had 4 bits per color component, and it's an rgb image, then the pixel would have 12 bits, iow. it would be a 12-bits-per-pixel image.
So you take the bits per pixel number a cube it right.
I don't really understand where you are getting that cube from. There's no cube. It's just the resolution (in pixels) times the bits. Basic math.
DeHackEd wrote:
For 16 bit mode, 1 extra bit for green.
Btw, the reason why the extra bit is added precisely to the green component and not the others is because the human eye perceives green shades more accurately than red or blue shades. (That's also the reason why the correct way of transforming an image to grayscale is not to the take average of the color components, but you have to weight them, and the green component has a considerably larger weight than the others.)
Is the constant sideways walking faster than normal travel?
In many 3D games you can walk forward at a certain maximum speed, as well as sideways at the same speed. Usually you can also do both at the same time (ie. press forward *and* sideways at the same time). Due to programmer lazyness they simply add the two movement vectors together to get the resulting diagonal movement vector. Naturally since adding two perpendicular movement vectors like this makes the resulting vector longer than either of the original ones (by a factor of sqrt(length(forward)^2+length(sideways)^2), which is > 1) this means that walking in diagonal is faster than walking forwards or sideways alone.
There are a few 3D games where they actually saw the trouble of making diagonal walking equally fast as forward walking (Quake being a prominent example).
How many people download every single AVI published here even though they don't *watch* every single one?
I can count myself as one. I download every single one, but there are a few I have not watched. (These are some RPGs which I don't want to spoil myself about, because I might want to play them some time and then watch the TAS.)
(Why download something you are not going to watch? Why not wait until you are ready to watch it? To help seeding it. And it's faster to download when it's freshly published.)
So for example if you look up an images properties and see it has 32 bits per pixel that means that each pixel can display 32 different colors right.
I find your misconception rather interesting.
It would be interesting to know if you know what "bit" means, and that if you understand what it means that, for example, one byte consists of 8 bits or that one pixel consists of 24 bits.
I suppose that, in a way, the misconception might be logical. If a pixel consists, for example, of 8 bits, in other words, 8 elements which can be either 0 or 1, one might think that each of these elements represents one color and that the chosen color is marked with a 1 while the other bits are 0.
If you think about it a bit more, I'm sure you'll understand that that would be a huge waste of resources. Think about this: Couldn't we optimize and say that, besides those 8 colors, if the first *two* bits are 1, then we choose a 9th color? And of course if the second and third bits are 1, we could choose a 10th color, and so on? And if *three* bits are 1, we can still chose more colors, etc. Just this way we get a lot more colors that can be represented with 8 bits.
However, that's still not the optimal way of using the bits.
Each bit combination can be assigned a unique number, for example like this:
00000000 = 0
00000001 = 1
00000010 = 2
00000011 = 3
00000100 = 4
00000101 = 5
etc.
These combinations are unique, and each one can be mapped to a number. With 8 bits we get 256 different combinations. With 16 bits we get 65536 different combinations. In general, the number of possible combinations is 2^bits.
That's why, for example, a pixel of 8 bits can represent a total of 256 colors, pixel of 16 bits can represent a total of 65536 colors, and a pixel of 24 bits can represent a total of 16777216 colors.
In theory a pixel with 32 bits could represent 4294967296 different colors. However, in practice only the 24 first bits of that value is used for the color information (giving the 16777216 possible colors). This is because it's handy to have one byte (ie. 8 bits) per color channel (ie. 8 bits for the red component of the color, 8 bits for the green component and 8 bits for the blue component).
Usually if you have a 32bpp image, the last 8 bits are used for the alpha channel (although in some cases it may simply be unused, and 32 bits are used, with the last 8 bits "wasted" for other reasons, such as memory alignment, etc). The alpha channel tells the transparency of the pixel.
I would like to bring your attention again to my suggestion at http://tasvideos.org/forum/viewtopic.php?p=144974#144974
If there was a semi-automatic "world record" category (alongside the other categories) then there would be less controversy about this subject.
Unless the statistics are restored from backups the "Bittorrent data" section of MovieStatistics became obsolete with this global reset, so it could as well be removed.
Just wondering, is that plane supposed to be a big black box or is that an emulation error?
I don't think it can possibly be an emulation error. I think it is more likely that the distance from which the plane is normally supposed to be observed, through fog, makes it impossible to notice the actual crude shape of the plane.
I have the strong feeling that there is a glitch there. The parts of the plane which are visible (wings, part of the hull) are very detailed. It would seem illogical to put so much detail there but then just put a black box as the main body. Maybe it's a case of missing textures or something (either in the original game itself, or the emulator).
If you have some video editing software what could be cool is a video presenting the top10, like those "top 10 best weapons" and other such clips aired in some gaming tv shows etc. :P
32 px/f:
Vinnie — Biker Mice From Mars (SNES, 1994)
(etc)
This would make a superb "top 10 fastest game characters" page, with a clear introduction and the list in increasing order of speed (the last one being the winner).
Edit: With some short demo videos too!
