Then, recently I saw the Humble Bundle can play games natively from the web, here. I guess they use a minimal OS with a light version of their game, so it can get a decent FPS.
I admit I haven't actually looked into this, but my guess is that these games were all built using a game engine, like Unity or UE4, that has the ability to build to an HTML5 build target (much like many engines can build to Windows, Mac, PSP, etc. targets). No idea how much Javascript is involved.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'm inclined to disagree with this (although my opinion isn't very well founded, so if you have good arguments otherwise ...). If, in an actual NES, a power cycle does not clear the RAM, then any emulator simply shouldn't either. It just seems like an emulation inaccuracy, rather than an issue on the verification side of things. It would seem that a bot-controlled power switch is viable to actually perform the hard resets, and if this doesn't correspond to what happens in an emulator, the emulator is at fault.
You're dealing with an analog problem though. When the RAM stops receiving power, the data stored in it gradually decays (as I understand it anyway). It doesn't stay fixed indefinitely, nor does it instantly go to zero; the bits fluctuate as charge gradually dissipates. In an "instant" power-cycle situation, presumably most of the bits wouldn't change, but which bits change would be functionally nondeterministic, which is lethal for TAS replayability.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I have trouble getting excited about Metroid 2 fan remakes considering how many of them have gone unfinished, but if this one bucks the trend then hey, awesome.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I agree with Patashu -- a TAS on hardware that used hard resets and had to wait for the RAM to clear after each such reset would, according to TheAxeMan, add enough real time to the clock that the TAS would not be competitive with a run that avoided such resets. Since we always prefer TASes that are run on more accurate emulators over ones that are run on less accurate ones, even if that means that the more accurate run is slower, we should clearly prefer the TAS that is fastest on the real hardware.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
You can clamp to a set number of bits pretty easily by doing a bitwise-AND with a bitpattern of 1s (same number of 1s as the number of bits you want to clamp to). You can represent a set of 4 1s as 15, 0b1111, or 0xf. I don't know offhand what the syntax is for a bitwise-AND in Lua, but in most languages it's a single &, so your command would be "value & 0xf", for example.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Bereft of redeeming qualities; flying over the world was interesting only once, and the game is bad enough that it's just bad, instead of entertainingly bad. I guess it's vault-worthy but I didn't find it entertaining, despite true's efforts to inject some interest into the game.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
How would you know? It depends entirely on how good of a writer YushiroGowa is. Let them give it a shot and then judge the results, instead of telling them not to do it in the first place.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
So is it even possible to get anything N64-related fixed, that isn't purely cosmetical? Like wrong physics?
Just asking, because I'm not really sure if it would be of any use if posted such a thing on the issue tracker.
I just want to note how huge of a project BizHawk would be if the devs had to take responsibility for the proper functioning of every emulator it fronts. It's already a big project done entirely by volunteers; let's not make their lives any harder than they are already. :) As adelikat and zeromus have noted, if there's a problem with the function of a specific emulator, then the primary responsibility for that problem lies with the developers for that emulator. And as always, the best way to get a problem fixed is to fix it yourself.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
This is going to be pretty vague since I'm not an expert on the topic, but it seems clear to me that the following things will result in nondeterministic behavior:
* Variable starting state. If the system doesn't start out the same every time then you can't guarantee that the inputs you make will result in the same results. We've had discussions about the state of uninitialized RAM in FCEUX, for example.
* Nondeterministic behaviors in the emulator itself. Seems obvious, but e.g. if your emulator decides to imitate, say, disc loading times by deciding randomly how long each seek operation takes, then that emulator won't behave consistently. More realistically, emulators that take advantage of multiple cores are going to be problematic on this front, because the host system (i.e. the computer the emulator is running on) has to schedule tasks on each core in what is effectively a nondeterministic manner, which in turn means that you can't predict when each task will finish or whether certain operations will happen before other operations in a consistent fashion.
* Incomplete savestates, or bugs in saving/loading states. If savestates don't capture all the state of the system, then when you load the state, you aren't perfectly restoring the system to the way it was when you made the state. This is similar to the "variable starting state" issue -- the aspects of the system that the savestate doesn't cover will be in an unpredictable state which will cause desyncs.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I know the really advanced encoders have special techniques for dealing with this kind of problem, but a simple solution that'd work just fine in this situation would be to generate a 30FPS encode by summing every two frames in the 60FPS encode.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
If you know where the random number is stored in memory, the most straightforward way to understand the formula is to read the assembly that changes that value (by, yes, disassembling the ROM). Theoretically you could reverse-engineer the formula by examining the values that the generator spits out, but since RNGs are designed to seem random, this would be a tricky project -- you'd have precious little in the way of patterns to use to figure out what was going on.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The entire point of this category is that the same input is used to complete all three games. Thus there's no need for three different SMVs, since their contents would be identical in any case.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Done. I'm not an ACE expert of course, and my understanding of exactly how consoles function may be incorrect, so I'd appreciate a proofread by someone with more low-level experience.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
That article reads like it expects you to have a lot of context that isn't in the article itself. Suggest the following modifications (I don't have a wiki-capable account):
1. How does code execution work?
Each system has an "instruction pointer" that points to the current portion of the program that is being executed. This is a location in memory that you will need to track down. The contents of that piece of memory are an instruction; for example a 1 might mean "add these two values together", and a 15 might mean "load this value from storage". Depending on the system, the instruction pointer will interpret different values as different operations. Thus you will need to know what operations the system supports and how those operations are represented in memory, so that you can figure out what exactly the system is doing.
2. How do I execute arbitrary code in this game?
It might not be possible. To execute arbitrary code, you need to convince the instruction pointer to point to a section of memory that is under your control. By controlling that section of memory, then, you control what operations the system performs. Ultimately, you usually want to get the instruction pointer to point to the area of memory that represents the controller's inputs. Once you have achieved this, you can write any program you like by simply changing your inputs; different inputs represent different operations.
3. Executing RAM
ACE requires you to be able to move the instruction pointer. This is where glitches come in, and will thus be different for every game. If you can corrupt the instruction pointer, then a common result is that the game will crash -- because the pointer is pointing to an area of memory that does not represent a valid operation.
However, it may be possible to carefully arrange memory so that the location the instruction pointer jumps to is a valid operation. For example, perhaps the pointer happens to jump to the middle of the part of RAM that describes the positions of the sprites on the screen; by changing which sprites are active and where they are, you could get different results from the glitch. Many games have an inventory system; if you can convince the instruction pointer to jump into the part of RAM that represents the inventory, then most likely by carefully arranging said inventory, you'll be able to achieve ACE.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
