There's one practical problem with this checking: Since you need the physical game cartridge, the person(s) who owns the bot needs to get hold of it, and they can be pretty hard to come by in some cases, and often not free. Who is going to pay for all this checking?
And I think the reset button is one of the input keys, with games supposed to be designed to handle it in certain way. The key just is not located physically in the same place as the other inputs, but it is still an input button.
I agree completely with Bisqwit on this issue.
How exactly do games "handle it in certain way"? AFAIK NES (and for that matter most other console) games cannot hook to nor detect that the reset button is being pressed and act accordingly. Granted, I don't know the exact details of the NES hardware, but I'm assuming that when you press the reset button, it's tantamount to pulling the plug: The program just stops right where it was (simply because the CPU stops working), without giving it any chance to do anything. The reset button is not input to the game.
FODA wrote:
Yep, I think the same. Saying that "only controller input is allowed" sounds really arbitrary. There's no reason for that at all, there are other buttons the player can use for a speedrun.
It's not arbitrary at all. The game reads input, you supply it input. Shutting down the console is not input. That's pretty unambiguous.
Tanooki Teabag wrote:
Who's to say that the controller is the only valid method of input? If someone did a run of an Atari 2600 game by the rules proposed, he/she wouldn't be able to use the switches on the console - only the joystick and the fire button. There are a number of games that make use of the difficulty and TV switches for various gameplay-related purposes, usually to make up for the lack of buttons on the controller. Would these inputs not be allowed because they don't come from an external controller?
You are misreading what I wrote. I was talking about the NES controller for the simple reason that on the NES it happens to contain all the buttons that the game can read (and hence the buttons that can supply input to the game). The physical location of the buttons are not the issue here. Even if the reset button was on the controller it wouldn't make any difference. You are missing the point.
...for example, the game corrupting its own save data due to a programming error (which is triggered by some unusual untested situation) and the save data becoming corrupted because the console was shut down while the game was writing the data. ...abuses hardware (which IMO should not be part of TASing, or even speedrunning in general).
I understand that this is only an opinion, but really... unusual untested situation? 90% of the TASes makes use of this. The first thing came up in my mind reading this line was the Up+Down and Left+Right combination. It's impossible to press on regular gamepads, you have to dissassemble them and of course they will work, and it's heavily abused in TASes. One of the greatest "unusual untested situation". So this also counts as an invalid gameplay?
I think you misread what I wrote. I didn't say that errors caused by "unusual untested situations" constitute invalid gameplay. I said that there's a clear difference between savedata being corrupted because of a programming error in the game (and which is triggered by controller input) and savedata being corrupted because of shutting down the console while it's being written. In fact, I was implying the exact opposite of how you understood what I wrote: In other words, gamedata being corrupted because of a programming error in the game itself is ok in my books (because it's just regular bug abuse) while gamedata being corrupted because of shutting down the console is not (because it's hardware abuse).
(The "unusual untested situation" was simply a reference to why such a bug might happen in a game: The situation where it happens was never properly tested and was never caught, or was deemed too implausible to be triggered by regular play. That's why the majority of bugs exist in games.)
Actually i ended up with around 399xxx so yeah it's a bit faked but not alot.
But why?
Rerecord counts don't affect the validity or acceptability of the run, but they are still interesting information (and used for example in the statistics page). What purpose does faking it have? The information is interesting only if it's honest.
So according to your logic, it's valid to press various button combination to reset the game1 which should be nearly (or exactly) the same as pressing the reset button, but it's invalid to press the reset button2 ?
There's a difference between the game quitting to its main menu and the console shutting down. This even if we disregard how it's done. (I don't think the NES even supports shutting down or resetting via software. That's a relatively modern phenomenon in consoles.)
Likewise there's a difference between, for example, the game corrupting its own save data due to a programming error (which is triggered by some unusual untested situation) and the save data becoming corrupted because the console was shut down while the game was writing the data. The former abuses programming errors, the latter abuses hardware (which IMO should not be part of TASing, or even speedrunning in general). There is a clear distinction.
Um... Would it be OK if I set the frame rate to 400 fps? That would be terrifying...
If the H.264 codec works even slightly competently, that shouldn't change the size of the result significantly. (Repeated frames do not contain additional information that should be stored.)
You mean TASes using the "reset" button or using a restart sequence by pressing various button combinations on the controller (1/2)?
I'm talking about the reset button on the console.
In my opinion "playing a game" consists of supplying input to the game which the game reads and interprets. "Playing a game" does not consist of shutting down the console and restarting it (which is what resetting essentially is). Just because you can shut down the console, and just because many emulators have support for emulating this, doesn't make it a valid form of playing. (IMO it's no different from using gamegenie codes: Just because you can do it with a real console and just because many emulators support it, doesn't make it a valid form of playing.)
The first thing came up in my mind after reading the code is the lack of sending the "reset" input. As far as I know you can't send it via controller, so my question would be that can you make an attachment/external device to handle the reset button?
I'm still of the opinion that resetting is not valid input in TASes and should be banned. and this only strengthens that opinion.
A quadrilateral with sides of length 223, 297, 228 and 296 is inscribed inside a square. None of its angles is right. Find the perimeter of the square.
Isn't there more than one way for a quadrilateral to be inscribed inside a square? Or do you mean that the square is as small as possible?
Really all you need to get started is the emulator and roms. Essentially everything else can be done after that.
And a slight problem with that is that ROMs (and where they can be found) cannot be advertised in this forum as a matter of policy, so you'll have to figure that out yourself. (And in principle you would have to also consider the legal issues with it.)
Plevens forbid that someone should enjoy a story that happens to feature faster-than-light travel.
I wonder if any sci-fi story has explored the hypothetical implications of the actual physics of general relativity in this context.
The thing is, from the point of view of the traveler himself, he can go anywhere in the observable universe in an arbitrarily little time. In other words, if you travel with a speed very close to c, you can reach the next galaxy in a few minutes (from your own point of view).
The catch is: If you now travel back to Earth (again, in a few minutes from your own perspective), thousands of years will have passed on Earth. Now you will be thousands of years in the future, everybody you knew will be long dead, and the civilization might well be completely different than it was (if they didn't outright destroy themselves, in which you will come back to a barren post-nuclear-holocaust planet).
This consequence of the theory of relativity actually opens up very interesting possibilities for storywriting. Perhaps some people want to "fast-forward" in time a few centuries or millenia (even at the risk of returning to a destroyed planet). And all this can be done completely within our current understanding of physics. (Basically the only actual sci-fi part is the propulsion system needed to reach velocities close to c.)
Hey, I can see the future! I'm applying to the JREF $1 million right now.
Here's a compilation of quotes:
He would also have died in the under water scene at 5:05 5:10 5:11 5:12 5:14 and 5:16 but that's not the biggest tell that it is fake. Since when does an NES system start up that quickly. . .
Also Mario doesn't move forward, at least not nearly that far, while facing backwards.
Sorry, this is faked. At 4:50, notice how the Piranha Plant disappears when Mario jumps up onto the tube. It doesn't retract, it just disappears as he lands on it.
For all you "too young to know the original Mario game", Mario can't "wall jump" like he does @ 3:54. I call BS on this. It's either fake or the game was altered, which doesn't merit a WIN in my books. I say FAIL...
However, as mentioned in earlier comments i have some problems with your video. Mario can't wall jump.
Yeah I noticed that none of the plants hurt him, that he was running across gaps, and could run through walls that as far as I know of you could not do before.
Next Instructible from him should be "How to heavily mod Super Mario Bros. so that you can phase through walls, disregard Piranha Plants, and ignore virtually any other threat in the game."
now try that without cheats.
All this "evidence" of fakery reminds me a lot of all those conspiracy theories and their "evidence" of fakery.
One thing I think should be considered is the length of the movie. As a reminder, starred movies are not a list of the best movies. They form a list of suggestions of where to start looking if you are a newcomer and want to get a feeling of the awesomeness of TASes. (Sometimes, and in fact very often, the two definitions may overlap. However, this is not necessarily always so, and I think the longer the movie is, the more disparity between the two goals.)
Not that we already don't have starred movies which are even longer than this (currently the longest seems to be 1 hour 22 minutes long; perhaps it should be reconsidered if that's a bit too much for a first-time viewer). Perhaps there's nothing wrong in having two or three long starred TASes, but I'd say that the majority should be relatively short.
Honestly, some users voted "no" simply because of this. That's exactly like voting "no" to a fighting game for not liking fighting games. You'd never like it in the first place, so is it really surprising you didn't like the movie?
Maybe the idea is more like: "Would this be an entertaining movie for the average viewer? I am average and I didn't find it entertaining, hence IMO no."
Personally I don't have any problem in TASes being published even though only a minority of viewers would enjoy it. I don't see what's wrong with that.
Making a frivolous DMCA claim is considered perjury by the DMCA. However, I have never heard of anybody suing and winning a big media conglomerate for perjury.
Your video, Sylvian joululaulu , may include content that is owned or administered by these entities:
* Entity: Music Publishing Rights Collecting Society Content Type: Musical Composition
The author of the lyrics died in 1898, and the author of the melody died in 1871. This means that the song has been in the public domain for at least 50 years. Any rights claimed by this "Music Publishing Rights Collecting Society" (a rather amusing name) is completely frivolous.
(No, this has nothing to do with the issue discussed here. Just wanted to share.)
Hmm. I wonder if the parallel port of a PC can be connected directly to the joypad socket (with some pin adaptation of course). Or a serial port. If I had a TV (with which I could try to use my NTDec, a Famicom clone), I would try this. No need for a special Arduino board if a PC can be used...
Or, in modern times, a NES controller - USB adaptor. This would indeed be more versatile than a separate board because it would allow programming and running the logic directly from your PC (as long as you can interface with the USB, or paralle, port from your favorite programming language).
As you're also keeping track of the input for each branch, you can store a state every n frames, then "deduct" the state for a given node by applying it's input to the closest node that does have a stored state.
Well, if you don't mind your search being at least an order of magnitude slower... (After all, every time you create a new node, in other words, in emulator terms, every time you advance one frame in any search branch, you would have to find out if the resulting state is identical to an existing state... anywhere in the tree. Getting this to be even moderately fast would require very clever algorithms, and having to run the emulator on each node to get its state would certainly not help.)
Well, thinking about it, you could actually store just a checksum of the state in each node. This checksum could be used as a quick-rejection test (if the checksum is different, the node is most probably not identical; of course one would have to use a checksum algorithm that minimizes collisions). Only if checksums match then one would have to figure out the actual state of the node.
Also, my last post was kinda meant to point out that, unless you use a heuristic that will be incomplete and hence will not produce movies like Chrono Trigger or Pokemon Yellow or anything similarly glitched, the only option is actually brute forcing.
I think you mean "if you use a heuristic" (rather than "unless"), it would not find glitches?
It's extremely hard to decide what to vote.
I love go, and I love Hikaru no Go, and I would probably like this game (if it were in English). However, from a viewer's point of view nothing much happens in this run, as the story is not followable (at least if you don't know Japanese, and even then you would have to pause to read all the text).
The games themselves probably look random to people who don't know the game (which is probably the majority of the potential viewers). Even for someone who is a player the games are a bit... simplistic. Bonus points for the slightly unconventional starting moves, though, and some really odd moves (like the corner move in the game against Akira; way to pwn the AI).
Imagine if this very concept could be applied to the latest 0 star Mario 64 run.
I haven't acquainted myself with the N64 hardware, but I fear that the more modern the console, the more difficult, if not outright impossible, running pre-recorded playing on it would be. For example, if the console happens to have a battery-backed-up clock and the game initializes its random number generator from it, you can absolutely forget about it. There are also many other things that make it extremely difficult to run things deterministically from controller input only.
You don't need to keep a state for every node though, you could use a keyframe-like system.
I don't understand what you mean.
The only way two search branches will be identical is if they start from the exact same state. This means that all CPU registers and the entire RAM are identical in both nodes. The only way to know this is to store the state in each node so that you can compare them.
The NES has 2 kB of RAM, which isn't a lot. However, it starts becoming quite a lot when you need to store it billions of times in that many nodes.
