mz
New Member
Posts: 19
|
Post by mz on Feb 6, 2008 18:45:45 GMT -5
If only the input would be recorded it would go out of sync real fast. TASVideos Luck ManipulationEvery re-recording emulator available only records the input.
|
|
ShendoXT
Full Member
Prototype
Posts: 124
|
Post by ShendoXT on Feb 6, 2008 20:07:27 GMT -5
Thanks for clarifying mz. I never knew that. Now that i do, input recording would be one great feature to add to pSX.
|
|
|
Post by Gamesoul Master on Feb 6, 2008 20:33:29 GMT -5
Some games calculate "luck" through a string of randomly generated numbers and use them on a high/low basis (some of the Fire Emblem games are a good example of this). Of course, this type of system only works on a game that moves mostly, if not completely, on events. And even then, it's not the sole factor.
But for the most part, it would be interesting to have input recording in pSX. If nothing else, it'd be fun to see which games use input as the main factor in factoring random events or not.
|
|
|
Post by Gamesoul Master on Feb 22, 2008 1:43:52 GMT -5
Bumping the thread with a new post, partly to ask a new question relating to my previous post...
Although many games of the type I discussed above use a string of randomly generated numbers, I'd imagine that the source for calculating those strings are still based on the same concept of being based on the player and timer. But I'm not too sure... Are there input recordings of some of those games to verify this? Fire Emblem 7 is a good example to try. I'll look around to see if I can find anything about it, but I figured I'd ask in case I don't find it (or somebody offers more insight than I can find).
On the thought in general, input recording should be fairly simple, shouldn't it? With frameskipping off, wouldn't it just involve creating a file that records any input frame by frame? I'd imagine some simple compression might be needed so the file doesn't get so large though in a short time. But besides that... all it'd have to do is be able to write and read that file, right?
|
|
|
Post by amaurea on Feb 22, 2008 13:36:59 GMT -5
A proper emulator should insulate the emulated machine from the underlying system. This means not only that the speed at which the emulator is executed, or the timing of the cd rom or make of graphics card should have no effect, it also means that the local time or other sources of randomness your computer would use as a basis of random numbers, is not available to the emulated machine. That leaves the provided input as the sole source of randomness. This means that the same input being replayed twice should give exactly the same result, no matter which game it is, and that is also the case for rerecording emulators like snes9x, vba etc.
There rare cases where this fails are called desyncs, and happen either due to incomplete savestates (parts of the emulated state was not saved, and so reverting to a savestate does not truly bring the emulated machine back to the original state) or incomplete encapsulation.
The first case is not a problem when recording (just writing input per frame to file, without using savestates), but naturally becomes a problem when rerecording. The difference between recording and rerecording, is that the movie file (the file containing the buttons pressed so far) is contained in the savestate in the case of a rerecording emulator, but not in the case of an emulator without rerecording support.
Plugin-based emulators seem to have trouble both with incomplete savestates and incomplete encapsulation. Mupen, for example, which is used for tool-assisted speedrunning of N64 games, is quite prone to desyncs, and so is pretty hard to work with. That is the reason why tool-assisted speedrunners are interested in rerecording support for pSX emulator: Its lack of plugins and focus on accurate emulation would hopefully make it as little desync-prone as the emulators for older systems.
It is, by the way, surprising that many here seem to be unaware of the concept of emulator movies (files containing just the inputs), as that concept is about as old as console emulators themselves. Such movies are very small even without compression, and are typically smaller than 1/100th of a corresponding avi file, making them easy to store and distribute. They also have the advantage of verification. One might doubt the truth of some avi file, or similar, showing some amazing feat, and put it down to video editing or cheat use, but with an emulator movie, it is as simple as playing back the file. Any use of cheats would simply cause the movie to desync.
Finally, I should note that the precision level used in tool-assisted speedruns often uncover emulator bugs that would otherwise go unnoticed; mostly savestate and encapsulation issues, but occasionally other things. This has resulted in a branching of the emulators used in speedrunning. For an emulator that cares about accuracy, implementing rerecording and letting tool-assisted speedrunners use it would be a good way to discover problems.
|
|
|
Post by patrickp on Feb 22, 2008 15:35:51 GMT -5
I have to say I find this very interesting, and I would think most members who take the time to read through these posts would too. There are a lot more ramifications to this than simply recording games.
However, the bottom line is that this emulator is entirely the baby of one person, pSX Author. So, it's entirely down to him whether this is incorporated into pSX or not. It's likely that any re-recording/input recording inclusion in the emulator would need to be done entirely by him: he's indicated in the past that he's not willing to share the source code for the emulator, and I've no reason to believe he'll change his mind now.
Edit: it seems, looking at the TASVideos site that speedruns are actually recordings of an entire game played through using all the optimisation that input control can give you - is this correct?
|
|
|
Post by amaurea on Feb 22, 2008 16:21:37 GMT -5
Yes. Each speed run is a file containing the sequence of inputs that is the current record holder for the shortest completion time. A normal speed run would create that sequence of inputs in one go, in realtime, and is therefore a work of skill and reflexes. It could be compared to a sport like tennis. A tool-assisted speed run, on the other hand, crafts the set of inputs more like a sculptor crafts a statue: working in minute steps and continually refining. In order to research what the best sequence of inputs would be, one uses various tools, like savestates, to explore the results of various actions, and thus find the action leading to the best result, or memory watch: looking at the contents of the game's memory to see precisely what your speed and coordinates are, for example. To have the greatest possible control over the situation, this is usually done frame by frame. However, even though various tools are used in this process, the result is still just a sequence of inputs.
On tasvideos, avi files are provided as a convenience for those who don't have the game. However, the emulator movie files are the actual speed runs. The emulator movie file is to an avi file as source code is to an executable.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 22, 2008 18:04:03 GMT -5
How sensitive are the input files? Ripping PSX games can be done so many ways, would different kind of rip (cue/bin vs. ccd/img/sub, for example) have an effect on sync/desync?
|
|
|
Post by patrickp on Feb 22, 2008 18:44:32 GMT -5
I usually find, Mika, that comparing the MD5SUMs of properly ripped .cue/.bin and .ccd/.img/.sub formats, the .img and .bin files of the same CD are normally the same. The difference, at least with those formats, it seems to me, is the descriptor files (.cue and .ccd) and the .sub file with subcode that the .ccd/.img/.sub format has.
So I'd expect games played from either format to run exactly the same: the difference is that the more explicit .ccd file and the .sub file in the case of protected games make it easier (or sometimes even just possible) for the emulator to read the main image file correctly.
Edit: I'd assume, though, that different versions of the same game (eg PAL and NTSC-US versions) would play differently.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 22, 2008 23:04:53 GMT -5
Properly ripped is all well and good, but the truth is that because of special hardware required to dump cartridges, the roms that are now "available" are usually done by people who know what they are doing, and as such are properly dumped and should have no problems. However, because pretty much everyone can rip CDs, the potential for shitty rips is huge (and the stuff that is already floating around the web is mostly crappy as well) and man what a mess it will be when those input files end up played on bad rips. Of course everyone would replay the input files with a physical cd in drive, but again, not all drives can read subcode, and it might cause some issues. Just you know, pointing out the obvious. I just see a lot of problems when doing TAS on images that doesn't exist on roms. A lot more variables that may or may not make it more difficult than some may expect. The audience also might be quite a bit smaller. With roms, everyone today has somekind of collection stored in the backpocket , with PSX games it's quite a bit different. My personal collection for example is quite small, and I don't imagine other people have huge collections either. Not counting ataribuff's PAL collection, of course. But now I'm just rambling. I'm actually excited about this a little, pretty much like I was when I first heard about TAS on NES and saw the Super Mario Bros. 3 TAS run with the super entertaining 1up collection in the 8-1 stage. I think the TASvideos site was still Bisqwit personal site or something like that. That was like June 2004, so it's been a while. In any case, it would be interesting to see re-recording on pSX.
|
|
|
Post by Sune on Feb 23, 2008 16:49:23 GMT -5
Maybe the quality of the rip doesn't matter as long as the game works from beginning to end.
A bad rip of Tomb Raider with glitches in the CD Audio wouldn't necessarily cause desyncs in the replay, if the bad audio doesn't affect gameplay and timing.
I'm thinking there could be problems when playing from worn or scratched physical media. What would happen if there was a read error on the CD, causing the emulated PlayStation to halt for a split second or longer while re-reading the data?
What about games that auto-save to memory card? Should the emulator automatically insert two formatted memory cards only during the replay?
|
|
|
Post by amaurea on Feb 24, 2008 2:39:18 GMT -5
Rerecording emulators usually do store a few more bits of information than just the input when making emulator movies. They also store - The checksum of the rom used
- The version of the emulator used.
The first of these points is understandable. Each game usually comes in different versions, some containing bugfixes that others lack, for example. Such differences almost always lead to desyncs eventually. The same applies to bad dumps, which are also detected through the use of checksums. There are usually lists available of the checksums of different known dumps of each game, known as GoodNES, GoodSNES etc. These can be used to check which revision of the game one has, and weather it is a good dump. The second point, however, would not need to be there in an ideal world. If two emulators both emulate accurately, then an emulator move would be compatible between them (as long as they both understand the format). I am not aware of any console emulators that are that accurate. There is usually some small timing difference between emulators, and thus a movie made with the previous version of the emulator may desync in a newer version, and will certainly desync when played on a different series of emulator. This would not be a problem with completely accurate emulation. The emulator having to reread data from the CD would have no effect on the emulated machine. Such problems are a part of the emulators environment, which it is its job to insulate the emulated machine from. The emulator emulates the the playstation's CD drive, not yours. How, then, can the emulator use a long while to read some information without that translating into a long wait for the emulated machine? Emulated time does not need to flow at the same rate as proper time, and in this case, no time will run for the emulated machine while the emulator is rereading information. Of course, not being able to read the information at all would be a problem, as the emulator then wouldn't know how to emulate how the emulated CD drive responds to the request for data. Regarding saves, the emulator movie contains information about the starting conditions, such as "starts from power-on" or "starts from the following savestate". It would be natural to specify the condition of the memory cards at the same time. If I remember correctly, snes9x has the option "starts from blank sram", where "sram" is the snes equivalent of memory cards.
|
|
|
Post by patrickp on Feb 24, 2008 10:53:04 GMT -5
Rerecording emulators usually do store a few more bits of information than just the input when making emulator movies. They also store - The checksum of the rom used
- The version of the emulator used.
The first of these points is understandable. Each game usually comes in different versions, some containing bugfixes that others lack, for example. Such differences almost always lead to desyncs eventually. The same applies to bad dumps, which are also detected through the use of checksums. There are usually lists available of the checksums of different known dumps of each game, known as GoodNES, GoodSNES etc. These can be used to check which revision of the game one has, and weather it is a good dump. This is perhaps a little more complex for the Playstation, as the majority of users probably make their own images; users will also be playing from the original CDs as well, as you note below and Mika has already commented on. The problem is, and I guess this must go for most emulators to some extent, is that the Playstation is not a properly documented console. Playstation emulator developers are still trying to piece together an accurate picture of just how the console works and, inevitably, this will make for significant differences in successive versions. It's well known that what fixes one game sometimes breaks another! This actually happens: apart from faulty drives or CDs, if a game is copy or mod protected and the drive can't read the subcode necessary to satisfy the protection requirements, the game won't play. pSX has a number of starting options (use the -h switch in Windows or Linux for a list of command line options); however, Ultima has produced a Frontend for the emulator that achieves even more starting options by writing directly to pSX' configuration. I suppose the information the movie includes must control how the game will be replayed?
|
|
|
Post by piratesephiroth on Feb 27, 2008 13:57:02 GMT -5
However, the bottom line is that this emulator is entirely the baby of one person, pSX Author. So, it's entirely down to him whether this is incorporated into pSX or not. Even if he doesn't desire to share the source code, he could start a thread on tasvideos' other emulators section. He could ask very specific questions about how to implement re-recording and even about avi dumping. If today there's re-recording support for any emulator, all the merit goes to the coders there (like the site says, "our heroes"). And hmm... the quoting system for this board is different...
|
|
|
Post by patrickp on Feb 27, 2008 16:12:20 GMT -5
Even if he doesn't desire to share the source code, he could start a thread on tasvideos' other emulators section. He could ask very specific questions about how to implement re-recording and even about avi dumping. If today there's re-recording support for any emulator, all the merit goes to the coders there (like the site says, "our heroes"). pSX Author has, of course, always developed the emulator exactly as he wants, piratesephiroth: he does AFAIK exchange views and code with other developers. However, what he decides to do about this is entirely up to him. Personally, I hope he does investigate this line: re-recording looks very interesting. FWIW (I know it's nothing to do with re-recording) he plans including video recording in the next pSX release. I've come across quite a few boards that do it recognisably the same way - but you can quote in two ways: either you can click the button on the post you want to quote for an attributed quote of the whole post - editable, of course - or you can just wrap [quote][/quote] tags round the text you want to quote. You can also look at anyone's post with the button, of course, to see how they've done something.
|
|