I see one potential problem in adding TASing capabilities to the game itself, rather than the game being run unmodified inside an emulated environment: Namely, the game effectively becomes a hack.
The attitude towards accepting TASes of hacked games has loosened a bit recently, but there's a difference: The hacked games are not even intended to pass as the original games: It's made clear that a TAS of a hacked game is certainly not the same thing as a TAS of the original game.
The problem with what you are proposing is that you are basically trying to pass a TAS of a hacked game as a TAS of the original, unmodified one.
The TAS would be completely non-problematic if the resulting recording file could be playable with the original, unmodified game (some games officially support user-recorded "demos", which would allow this). However, not many games support this. If the recording file is only playable with the modified game, the question raises whether it's equivalent to playing the original game. How can be know that the modifications didn't modify some elements of the gameplay itself? (It could be conceivable that such modifications could change some delays and such.)
I don't know why nobody came up with this idea earlier
Oh, the idea is really old, much older than this website. Tool-assisted speedrunning started in the Doom speedrunning community by doing exactly what you are suggesting: By patching the (then already open source) Doom source code with features which allowed what were effectively rerecording and savestates (and IIRC pausing). TAS-Doom was an entire subgenre of Doom speedrunning back then.
The idea of using emulators to TAS old console games is actually newer than tool-assisted speedrunning itself.
I'm not sure if this is applicable to whatever software you used, but did you do a "quick" format or a "full" format? As I understand it, recovery of the latter may not be possible.
Actually it is possible in most cases, but it will cost you a s**tload of money. There are companies specialized in data recovery of erased (and broken) hard drives, but they are not cheap (it requires dedicated technology, it cannot be done by the hard drive itself).
Of course that's usually out of question for most individuals, so unfortunately there's little one can do about it. After a full format the data is as good as gone.
Hardly. The state of the puzzle is randomised to begin with and it is not obvious without a lot of systematic analysis to determine the optimal solution to the puzzle as provided (even under TAS conditions), much less determining which initial states can be solved the fastest.
I think it could be compared to tetris in this regard.
How much can the RNG be manipulated? Could it be possible to manipulate it so that it gives you a scrambled cube which actually has some "pretty pattern"? That would be awesome.
Warp, the times used were for the single cube solutions, not for the average.
You mean in this TAS? That's exactly my point: Trying to compare the times in this TAS with the world record is a bit moot because the WR is measured as the average of solving several cubes, while this TAS only solves one cube.
I mean, you're entitled to your opinion, but the facts are clear that this submission beats all official human records despite the handicap of the animation time.
Note that the official world record is determined as the average time of solving several cubes (IIRC 5 cubes are solved and the slowest and fastest times are discarded), In other words, a human can solve even a completely scrambled cube (one where even the most optimal solution has at least 19/20 rotations) faster than the world record in individual cases (even when the solution is not trivial).
"Test-driven development" can also be a different way of budgeting time to get any tests written at all. If you wait until the module or program is ready to be tested, all too often you'll end up going off to work on implementing some new module instead of writing tests for the existing module. In the long run this ends up costing you more time (from increased support costs, bugs slipping through, and so on) than writing the tests early would have.
Basically you are saying that having some tests (which is what test-driven development gives you) is better than having no tests at all. But this assumes that the developer will not create the tests at any point, unless demanded by the development process.
But if that's the case, then your problem is deeper than your development process. If your developers are skipping proper testing, the problem is elsewhere.
My point was that if you have two types of testing procedure: 1) the traditional way, where you implement first, then create tests for all the features, and 2) you first create the tests and then implement, you might end up in a situation where the program passes all the pre-made tests in the second case, yet is still buggy because not all features (which were impossible to predict when the tests were created) are being tested, while in the first case, if proper procedures are followed, more bugs would have been found early on (because after implementing you know what you have to test).
If "test-driven development" exists to get around the problem of lazy programmers not being bothered to write testcases, then the problem is not in the development procedure. The technique is used to fight the symptoms rather than the cause.
As with most new and fancy "development techniques" which might sound really cool and inspiring, you should always take them with a grain of salt. A quite old saying in programming says that "there is no silver bullet", and it does apply today as well as it did back when it was first uttered.
As with other similar recent fads, "test-driven development" may sound wonderful in theory, but when put in practice, it often leads to less than optimal results. One could argue whether this is due to problems in the technique itself or whether it's because developers don't use the technique correctly, but the end result is the same.
One of the basic ideas behind test-driven development is that rather than going the traditional way of implementing something (such as a function, a module, a class or an entire program) first and then testing it, you do the opposite: You first implement the testing procedures (which basically amounts to defining the specifications and requirements of the module) and then you implement the module so that it will pass the tests. The basic idea behind this is that it makes development faster because there are less bugs to fix later in the project, when bugs are found in the testing stage.
While this idea has its merits, the problem with this is that it's impossible to predict how the module will need to be implemented, what kinds of things it will do, and hence what kind of tests should be used to test it thoroughly. With your pre-made tests you will only be testing part of the module (sometimes even a very small part) while large parts of the module may end up being completely untested.
"Ok, that's fine and understandable. Just add the additional tests after the module has been implemented." But the problem with this is that it now goes to the traditional development process, which is what test-driven development wanted to avoid in the first place. What this causes is that the test-driven development mentality induces developers to skip adding tests after modules have been implemented, relying solely on the pre-made tests. This may cause large portions of the program to be completely untested, causing big problems later. (The later in the development process that you have to fix a bug, the more difficult/expensive it will be.)
So, in short: Writing unit tests is ok, but what "test-driven development" says is that you should write them first, and implement the module then. The problem is that it's impossible to predict in advance all the unit tests you would need to thoroughly test the program. If you want to test the module thoroughly you will end up going back to a more traditional development model, so the whole "test-driven development" idea gets watered down by necessity.
If I've got a finished run (let's say, Super Mario World for example) and just want to change one level because there is a skip or something I've overlooked or I played sloppily there, how do I do that while keeping the rest of the run?
It's unlikely you will be able to make a modification in the middle of the run while keeping the rest working. It's very likely that the rest of the run from that point forward will desync. (There might be limited exceptions to this.) Usually the only way to do this is to redo the entire run from that modification point forward.
I think there are a few cases where small modifications are possible without causing desyncs. I believe a hex editor is often used to do such modifications directly to the movie record file.
I'm not completely certain of this (because I have little knowledge of the gaming culture of the 80's in the US), but I think that in Europe the "home computers" (such as the C64, Amstrad and ZX Spectrum) were much more popular as gaming platforms than they were in the US, in relation to actual game consoles (such as the Atari 2600, NES, SNES and Mega Drive). Hence there was a rather rich proliferation of game companies and freelance programmers making games for those "home computers".
Back then it was quite common in some countries, such as Spain, to have companies and freelancers making games principally for their own country (iow. in their own language). I have personal experience from Spain about this: Many, many Spanish gaming companies and programmers were writing games in Spanish only, for the Spanish markets, and almost exclusively for the "home computers" (because they did not have any limitations and it was easy to develop and distribute games for them). Nowadays it's almost unthinkable to write big games for one's own country only (although there are exceptions to this, of course, but they are rare).
Great Britain was a big producer of home computer games back then, and they were much more popular internationally. One company name which I remember clearly is Ocean Software (with its distinctive logo).
As said, I don't really know how popular these home computer games were in the US in the 80's, or if the US was more a NES/Genesis country.
The historical argument (even throwing away "It's not official") is that language patches tend to be works in progress. Such works may be hard to find the older, sync-stable version at a later time and the original authors may not approve of us hosting an outdated version of their work $X months after the publication.
Maybe if we set some ground rules (as always, individual special exceptions may be granted):
1) The translation has to be well-known and published on a well-known site (such as dejap).
2) The translation must have been marked as "100% complete" by the authors.
3) It must have been so for at least a year, without further updates (iow. it has been a completely stable translation for at least a year, without further fixes).
I'm not saying it must be exactly like this. Just throwing some ideas.
I have the feeling that many of the videos linked are not really all that crappy. Let's remedy that problem, shall we? I'll start:
http://www.youtube.com/watch?v=MKzqP4-0Z6M
Now I obsessively compress large batches of PNGs using PNGOUT and then run DeflOpt on them.
One thing that you can sometimes try is to reduce the amount of colors in the image to 256 (or sometimes even less). With some images, such as GUI screenshots and such, 256 colors is completely sufficient to convey what you want to show, and it can make the png file significantly smaller.
In fact, I do this so often that I have actually made a zsh function which automatizes the whole process (reduces the amount of colors and then runs optipng and pngout on the result). It might work on other shells as well:
reducecolors () {
if [ "$2" = "" ]
then
echo "Usage: reducecolors <infile> <outfile> [<colors>]"
else
if [ "$3" = "" ]
then
echo "Reducing $1 to $2 with 256 colors..."
convert -colors 256 +dither "$1" "$2"
else
echo "Reducing $1 to $2 with $3 colors..."
convert -colors "$3" +dither "$1" "$2"
fi
if [ $? = 0 ]
then
echo "optipng..."
optipng -o 7 -q "$2"
echo "pngout..."
pngout -q "$2"
fi
fi
}
(Note that it turns dithering off when reducing the amount of colors because dithering really kills compression ratios, and with most of the intended images dithering is unneeded.)
All I'm saying is that the site should be consistent. If it allows this J rom for this run, it should allow the next one if need be.
That's not being consistent. That's changing the rules on a whim.
The rules allow exceptions on special cases. That doesn't mean that one exception changes existing rules. Being consistent means sticking to the rules as they are, not changing them every time a special exception is granted for a single submission. That's what "exception" means. "Exception" does not mean "let's change the rules if we break them once because of special circumstances".
I bet that many/most people would end up donating their award money to the site anyways, so having award money from the website funds seems a bit pointless...(but I have no idea how many people would really do that.)
