Wikipedia defines Joule as "the energy dissipated as heat when an electric current of one ampere passes through a resistance of one ohm for one second."
This seems to imply that a resistor of 1 ohm will always dissipate the exact same amount of heat regardless of what material it's made of. That feels surprising and counter-intuitive.
Or, perhaps, it could be restated as: It seems to imply that there's a tight unique relationship between resistance and heat dissipation, regardless of the material.
From what I can understand, there would be no problems for TASing in general, as it is considerable as a kind of play with its own creative input.
I believe that by "creative input" they mean adding your own content to the video, such as verbal commentary, expressing your opinions, splicing the gameplay footage with other unrelated (preferably original) footage, and so on and so forth.
I doubt that by "creative input" they mean "playing the game in an unusual or special manner". It's not that kind of "input" (ie. button presses used to control the game. I highly, highly doubt they mean that with the word "input".)
They explicitly allow so-called Let's Play videos, but from the context I believe that what they mean is the sort of Let's Play video where the player is speaking and commenting while playing (ie. providing additional original material, in the form of verbal commentary). While it's not 100% clear, I think that it's not a permission to simply post pure gameplay footage with no additional content. (It would be nice if they made that a lot clearer.)
If there was an award for the least entertaining TAS, this might be a major contender. (Of course it's not the author's fault. It's the game's fault. Text-based adventure games, with zero pictures, don't make for entertaining TASes.)
More and more software are starting to give huge-ass warnings when logging in through non-https, including browsers themselves, as well as antivirus/firewall software to an increasing extent.
On that note, sin(x) and cos(x) have a quite clear meaning when the parameter is a real number. However, when the parameter is a complex number, do they have a clear meaning or interpretation? What are they representing?
In one of his latest videos, blackpenredpen calculates the value of sin(i). He uses Euler's formula for this.
But how do we know that Euler's formula is valid for complex values of the angle?
The Wikipedia page says: "Euler's formula states that for any real number x". I don't see a mention (or denial) that it is also valid for complex values of x.
The Wolfram MathWorld page doesn't seem to make any mention one way or the other.
There is, however, a way to get around DRM for plenty of games. Most pirated games either remove the DRM entirely or find a way to disable it.
Putting the legal and ethical questions aside, I would say that the general answer is "not acceptable" for the simple reason that it's a modified version of the original game, and in general we don't allow those (barring extraordinary exceptions).
Of course there can still be other major problematic situations, even when using "recommended specs" or equivalent. A game from the late 90's could, for example, work properly when using a 3dfx Voodoo card but bug out if using an ATI FireGL card. Should the run be allowed to emulate the latter to abuse some glitches that don't happen with the former?
Actually, the more I think about it, the more of an endless rabbit hole this becomes.
Sometimes graphics card drivers have been buggy, and these bugs have been fixed with newer versions of those drivers. If a particular version of a particular graphics card driver would allow a glitch in some game which wouldn't otherwise happen, should it be allowed?
Which version of the operating system should be allowed? Again, some glitch might happen in one version but not in another.
This is an endless swamp...
So just for clarification, does this mean no disc swapping FMV trick in FF7, even though it has been shown to work on emulator exactly as it does on console?
I don't think that something should be allowed merely because it works on the console. A GameGenie works on the console, but that doesn't mean it should be allowed, for instance.
Just like with picking the intended console region or the intended BIOS, we can pick intended conditions the games were supposed to be played in. The easiest way to find them out is reading the official docs on recommended PC specs. If that's not enough or not available, we can use modes the games explicitly supply, for example several pre-defined speed modes. If even that is not enough, we may look at some less public resources like game code and deduce intended settings from that.
If for some reason the game did not come with recommended specs (as might have been the case with many older games from the earlier 90's, and perhaps even some from later), one approach would be to research what was the most typical average gaming PC of the time of publication, and take that as a baseline. Of course even in this case there can be a lot of ambiguity (especially given that in the late 90's and early 2000's there were like 4 or 5 different major GPU manufacturers and at least 3 or 4 major CPU manufacturers, before only the current two on each industry were left), but some kind of baseline could probably still be reached.
Of course there can still be other major problematic situations, even when using "recommended specs" or equivalent. A game from the late 90's could, for example, work properly when using a 3dfx Voodoo card but bug out if using an ATI FireGL card. Should the run be allowed to emulate the latter to abuse some glitches that don't happen with the former?
I want to mention that, as you get into the tens of thousands of digits, you have to be extremely careful when talking about prime numbers. There is an ever increasing misuse of the term "prime" to mean "probable prime" (a usage I will not defend), the reason being that it takes far less computation to establish a number as a probable prime compared to actually proving that it is prime.
On the other hand, proving that a number is not prime (and consequently that "there are no numbers of this form within this range that are prime") is much easier, as with most of those primality tests if they say "not prime", that's a certainty.
I suppose that when it comes to Mersenne primes, and the search of them, it's lucky that we have a quite efficient algorithm that gives a sure answer either way. All known Mersenne primes are that for certain (barring some strange bugs in the programs used by GIMPS.)
Also, can any regular hardware or software simulate vsync by enforcing consistent framerate when the game isn't configured to keep it consistent? For example, I see an option to force vsync for 3D apps in the videocard settings, but it doesn't seem to be all that flexible in which framerates it allows.
It is my understanding that the display driver / graphics card can "force" a game to vsync even if it isn't doing so itself, at least if the game is using DirectX, OpenGL or Vulkan. Essentially, if I understand correctly, what's happening is that the game tells the API to render something, and then the display driver deliberately waits for vsync before displaying the end result and informing the game that "ok, done, you can continue". (I'm assuming that depending on the game, and what kind of optimizations it has, this might not be the optimal way of running the game because since it's not itself aware of being "vsynced" it can't do something else while waiting for vsync. But this is just speculation on my part.)
I suppose that, in a sense, if the display card were able to otherwise render faster than the monitor can display it, the driver is artificially "slowing down" the game to match the monitor's vertical sync. The game just idles while waiting for it.
This is actually how g-sync and FreeSync work. If I understand correctly, to use either one, the game ought to be configured to not vsync, and the display driver then decides what the rendering pace of the game will be. (In normal situations the driver will tell the g-sync/FreeSync-capable display to show the picture immediately, unless we have reached the maximum refresh rate the display is capable of, in which case the driver deliberately waits for the display to become available again, doing essentially a vsync that's external to the game, as above.)
Running games at ridiculously high refresh rates bothers me less than running them at ridiculously low ones, because at least the high refresh rate doesn't detract from the enjoyability of watching the run.
However, one has to wonder if there nevertheless ought to be a sensible upper limit. If games are being run in an emulated environment, then there's no theoretical upper limit to the refresh rate (even if the host machine can't run it in real-time at that refresh rate, that doesn't matter; to the game it looks like it is, if it's emulated as if it were, even if in actuality it's being emulated at a much lower speed). So what stops a game from being run at a million Hz? Or a billion Hz?
At some point we reach a stage where the run simply cannot physically be reproduced in real hardware, not even in theory. TASes ought to at least theoretically be reproducible in the original hardware.
A related question: Even though 1000Hz keyboards exist in real life, I still have to wonder if it's physically possible to press keys, and have them register properly, at that frequency. For example can you alternate between two keys at that frequency, and have it work? It just feels a bit wonky if a TAS is theoretically reproducible... but doing so would require hardware that simply doesn't exist.
I just watched that segment and my impression is that he was just joking to argue the beast number is 666 instead of 616.
When he says "and I searched for up to n equals a hundred thousand... and no prime numbers", I don't get that impression. I really get the impression that he did use a program to test all the numbers of that form up to that size.
I believe that if he had realized that no numbers of that form can be prime, he would have said so, and explained why.
In the most recent episode of Numberphile, the university professor Tony Padilla is interviewed about "the most evil number", 1000000000000066600000000000001, which happens to also be prime. It's noted that some of the numbers in the form of 1(n zeroes)666(n zeroes)1 are prime.
In an extra video he tells how he started wondering if any numbers in the form 1(n zeroes)616(n zeroes)1 are prime, and says that he checked all the numbers up to a hundred thousand digits, and found no primes.
It appears that even university math professors can sometimes miss the obvious, because it's quite trivial to see that numbers of that form can never be prime.
The reason that 1990-era DOS games do not run on modern PCs is absolutely not that these PCs are simply too fast. Rather, the reason is that system architecture has completely changed in the intervening years. For instance, 1990-era PCs use 16-bit architecture, whereas contemporary PCs use 64-bit architecture.
That's incorrect. Intel's x86 architecture, and now x86_64 architecture, retains backwards compatibility with its historic 32-bit and even 16-bit counterparts. You can still switch your CPU to the old 16-bit mode, and it will work exactly like a pre-80386 16-bit Intel CPU.
In fact, and moreover, when you start up your PC, the CPU will actually start in 16-bit mode, for legacy backwards compatibility reasons. (Or, at least, the x86 CPUs did, ie. up until the Pentium4 or so. I haven't checked if the x86_64 CPUs also start up in 16-bit mode, but I think they do as well.)
The very first thing that the bootloader of your modern OS does, ie. the first thing that the CPU starts executing from your disk, is to switch the CPU from 16-bit mode to 64-bit mode (I think it has to switch to 32-bit mode in between, but I'm not sure).
In theory a modern CPU is completely capable of booting directly to a 16-bit MS-DOS boot disk. Heck, even GPUs still have support for the old text mode and VGA modes from the early 80's. (In practice MS-DOS might work very poorly, if at all, with a modern PC. Not because of the CPU, but because it doesn't have support with the vast majority of the remaining hardware. Forget about anything USB, and it might have trouble with modern mass storage media, and a bunch of other things. Although you might be able, at least in theory, to boot from an MS-DOS floppy disk. Assuming your PC still has a floppy drive.)
Which means that, in theory, a modern PC can still run old 16-bit MS-DOS programs natively, without the need of any sort of emulation.
The problem with many DOS games from the 80's is that they used things like busy-loops for timing. Famously (or infamously), many games from the 80's (perhaps even very early 90's) would measure the speed of the PC when they started, and adjust their busy-loops accordingly, but once PCs got too fast, the counter they used for measuring this would roll over, and thus their timing would be way off, or they could even crash.
(Busy-loops were a sadly common way of adjusting the speed of games back then. There was poor support for any "sleep" commands in the OS or the BIOS. In fact, MS-DOS used busy-loops itself. It didn't have support for idling the CPU, like all modern OS's do. Which means that if you were to run MS-DOS on a modern PC, it would run on one core at 100% utilization all the time, assuming it would run at all.)
It's a not uncommon among console players to think that "computers" are all the same thing, but that is a misconception and we really shouldn't be basing rules on it.
Intel CPUs have retained to this day backwards compatibility with their legacy CPUs, so it's not that far-fetched of a concept. As said, in theory even a modern Intel CPU can run 16-bit executables natively, in 16-bit mode.
I for one wouldn't protest very loudly if this were the rule, at least.
Note, however, that some PC games, even some modern ones, have a hard cap of 30fps (usually because they were developed primarily for consoles and ported to PC as an afterthought, and it turned out that the game doesn't really work well at 60fps. In at least one example physics can get all wonky and stuff, when they were badly designed for 30fps only.) But, of course, and rather obviously, in these cases using 30fps is 100% justifiable.
The thought also occurred to me of the polar opposite of what I have been talking before:
It might also happen with some particular game, especially an older one, that running it on a PC (real or emulated) that's too fast might make it glitch in some manner, or otherwise change its behavior in such a manner as to allow a faster completion.
There are many very old PC games from the 80's and very early 90's that simply don't run on a modern PC, and in some/many cases this is because the PC is just way too fast (several orders of magnitude faster than the PCs of the time), and the game hasn't been coded with that kind of processing speed in mind. (Nowadays the only way to run such old PC games is in emulated environments such as DOSBox, which deliberately emulate a slow PC of the time. If you tried to just install DOS into a modern PC (and assuming it even works at all) and run the old game as-is, it might well just crash on launch, hang, or otherwise not work correctly.)
It's not completely out of the realm of possibility that running a very old PC game on a modern super-computer of a PC does not immediately make it crash, and the game is actually completable, but might affect it in some way that allows for a faster completion.
Again, this would toe the line of what is "affecting the game from the outside" in a manner that goes against the spirit of TASing, and what isn't.
To me this is not a problem. If the run is not entertaining because of the low framerate, then it will be either rejected or it will go to the Vault.
I might have given the impression that my concern is purely about entertainment. It's not so. Sure, entertainment (or more precisely, lack of) would be an issue, because I doubt anybody would sit through a 1-hour run where each frame is shown for 10 seconds, after which the game jumps to a completely different location. However, it's not the main reason why I feel unease at the thought.
I think games should be speedrun at their own terms. Affecting the game from the outside feels like quasi-cheating. I don't think anybody would agree that, for example, if we are running a DOS or Windows game, it would be ok to run some custom program in the background that affects the game in some manner, allowing eg. glitches that wouldn't otherwise be possible. Emulating cheating devices in older consoles, like GameShark, isn't allowed because, once again, it's changing the game in some manner from the outside.
Moreover, and perhaps closer to this discussion, we would never allow overclocking a console (which would be quite easy to do in an emulator) in order to make the run go faster. The game should always be emulated in an environment that replicates the original console as faithfully as possible. Overclocking the console would be the cheapest and dirtiest possible trick to use in order to get a faster run, and nobody in the universe would accept that as legit.
Now, when we are talking about PC games, we are entering a much grayer area, in both aspects, given that there is no "standard" PC configuration for any given game, and the speed of PC computers can vary by orders of magnitude. Also the area becomes grayer due to the fact that in most PC games that aren't old as dirt, the speed of the PC doesn't affect the playing speed of the game (at least usually not in any significant manner).
However, I think the same principle ought to apply as above: If changing the speed of the PC somehow makes the game glitch, it just feels wrong. It's not playing the game at its own terms, but affecting it from the outside. It's not completely dissimilar, in principle, to run a custom background process that, for example, slows down the game. The only difference is that rather than doing the slowdown in software, we are doing it in hardware (at least in the emulated hardware). The end result is still the same. If we don't allow it done with software, why should we allow it if done with hardware?
My own preference would be that, at least by default, PC games ought to be run in an environment that closely matches the recommended specs given by the developers of that particular game. (Exceptions could be made in individual cases, but there ought to be very good reasons for it. I don't think "running the game at 0.1fps makes it glitch" is a good-enough reason.)
As Warp said, the framerate of nearly every modern game, especially on PC, has no impact on the speed the game actually plays at, so that would be a non-issue for most games when it comes to speedrunning or TASing.
Yeah, but my concern is that with some games, running it at a ridiculously low framerate might enable some glitches that aren't otherwise. Thus the question becomes whether the framerate should be allowed to be dropped that low for the sake of enabling the glitch.
There are already plenty of runs that have slowed-down encodes so that viewers can have a slightly better idea of what's going on. I see no reason why a 60 fps encode couldn't be made of a game that was played slow as molasses.
I think there's still a confusion here.
With modern games (and by "modern" I mean games made in the 2000's, and quite a bit earlier in the case of many PC games, probably since 1995 or around that) the framerate doesn't affect playing speed. You will still advance in the game at the same speed. It's just that with a lower framerate the game will "jump forward" at larger steps to compensate. You still get from point A to point B in the same time, regardless of whether the framerate is 120fps or 20fps.
Taking a game that has been played at 1fps and showing the end result at 60fps would mean that everything is happening 60 times faster. Imagine showing something like Doom 60 times faster than normal. It would be unwatchable and incomprehensible.
Showing each frame 60 times (in order to get a "60 fps" video) wouldn't make any difference. You are still staring at every frame for 1 second.
Not exactly true that "no one minds" them. I have presented my concern. To recapitulate:
If no hard lower limit for framerate is established, meaning that a game could be emulated with as low of a framerate as one wants, this could ostensibly with some games lead to completely unwatchable slideshows.
Someone might discover that in some game, if the framerate is low enough, some kind of glitch becomes possible. For example, suppose that if the framerate is dropped to 1 frame per second, it becomes possible to go through a wall (because the game now makes proportionally larger "jumps" in time, and thus in position, at each frame), skipping part of the level and thus making the run faster.
The problem I see with this is that in most cases it's probably not possible to change the framerate for one particular section of the run only, but that the framerate would need to be kept for the entire run. Imagine, for example, a 1-hour run at 1 frame per second, or even less. It would effectively be a slideshow with very little resemblance to actual gameplay. (Heck, if the framerate is indeed completely uncapped, nothing would stop the game from being emulated eg. at 0.1 fps or less. Imagine every frame being shown for 10 seconds, after which the game just jumps 10 seconds forward to a completely different location. And this for an entire hour.)
Not only would this be essentially unwatchable, I just can't help but to feel that it just goes against the spirit of TASing. It almost feels like some kind of quasi-cheating, where the game is affected by altering an external condition, rather than just playing the game on its own terms, in a normal environment. It's in some ways notionally not completely dissimilar to, for example, running some kind of custom background program that affects the game in some manner.
I would suggest that games ought to be run on the most typical framerate at the time when the game was published. (If we are talking about PC games, perhaps look for the "minimum recommended specs" of the game as some kind of rule of thumb.)
