It would be nice to have a program that lets you see a ghost image of other TASes (of the same game, preferably) in a TAS. It could be implemented by running several emulators at once, and designating one of them as the main one. The total image would then start out as the main one, and then fetch the character's sprite and location (which room and which position within the room), and if the room is the same as the one in the main emulator, it would paste the sprite on top of that image at the appropriate location.
This sounds hard, but doable, though the code would have to be adapted to each game (game specifics lie in: grabbing the player sprite and location). I am considering trying to make this for Super Metroid, the main hold-back being that all the emulators and memory watch utilities seem to be for windows.
You would need:
RAM addresses for
- Sprite position
- Camera position
- "World" position (room, level, whatever)
Assuming you're some sort of programmer, it would just be easier to, say, create an emulator that writes these values per frame to a, say, text-file. Then the emulator would just have to load the proper value for each frame, compare it to the current information, and write some "marker" to the screen (say, a bounding-box or other information; drawing a box around the main sprite would help with this)
It would probably be easier than running multiple copies of an emulator at once and "ghosting" images, but you would still have problems with different games requiring completely different systems.
Explanation:
1. Emulator-Y opens game and movie, plays though entire movie writing above data to a text file, one line per frame
2. Emulator-Z opens the game and text file, uses text-file data to draw ghost while playing
These could be combined into one ("Write-mode", "Read-mode") emulator version to make things easier.
With all the needed information, I could do that. I'd just set up two emulators and an application reading the data between them.
I think I'll see the feasibility of a Mega Man X game. The info pages on the wiki include some useful information like X's current coordinates. Just do relative calculation and draw on the screen...
The problem with two emulators at once is keeping them synced up (using the same savestates). In the event your movie savestate overwrites one of the other emulator's saves, the movie will desync and the ghost will be broken.
Memory addresses also need to be checked between each "frame", and again, should one close/whatever, you'd have to re-calculate where each one is... and that's not even taking into account problems like not reading the correct input (not advancing a frame/loading a savestate properly).
That would be why I suggested generating a data file with all the information seperately, instead of running two emulators.
Xkeepers verion sounds a bit simpler, but would be less visually pleasing, as the ghost's character sprite and its animation would be missing then. Is frame-advance and load savestate really that fragile operations? My idea of implementing this, was to modify the emulator to have a mode where it can be signaled to start, frame advance, save/load state, etc, and then make another program that starts up several of these, tells them all to load the rom and their respective movie files, and then frame advances them all, collects information from them, draws the frame, advances, and so on. The hardest part would probably be to get the player sprite (ideally only the visible part of it, if parts of it are hidden behind something).
But there are good arguments for running through all the movies one by one first. One could then note the frames for entry/exit for each area, and create savestates for each of these. These savestates could then be used in the process described in the first paragraph. Normally, the best run will leave the other one behind, after a while, and one would not see much of the gost, but with such savestates, one could shift the gost to make them (say) enter every room at the same frame, giving automatic room-by-room comparisons.
I can read and write C and C++, but I am not familiar with Snes9x or memory watchers, or windows programming, but it could be a fun thing to try after my master is finished (in 2 months).
DeHackEd: I am looking forward to seeing the result of your test with Mega Man X!
Xkeepers verion sounds a bit simpler, but would be less visually pleasing, as the ghost's character sprite and its animation would be missing then. Is frame-advance and load savestate really that fragile operations? My idea of implementing this, was to modify the emulator to have a mode where it can be signaled to start, frame advance, save/load state, etc, and then make another program that starts up several of these, tells them all to load the rom and their respective movie files, and then frame advances them all, collects information from them, draws the frame, advances, and so on. The hardest part would probably be to get the player sprite (ideally only the visible part of it, if parts of it are hidden behind something).
They very well might not be (the operations).
But imagine that idea working when you try to play movies normally. You'd have several emulators trying to work together and communicate at 60FPS -- it's very unlikely to work without lagging or desyncing.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
What he did is quite different but pretty darn cool. You get a video showing all loaded states. I wish I could try it with other games but I'm not on a pc :(
Hey!
Although FODA is correct that the ghosting feature in my custom SNES9X only overlays different savestates of a single video, rather than combining different videos, it would be very easy to adapt it to your original idea of combining many different videos into one. This is something I have actually been wanting to try at some point.
The way that my emu hack actually works is similar to what XKeeper suggests, but a little simpler. It has a group of snes9x "movies", one for each savestate, and it has the emulator play through each one one by one. When it does this it disables all the layers except the sprite layer, and makes the background behind the sprites transparent. It then slaps the result into the layer of a quicktime movie. Each playthrough is eventually slapped into the same quicktime movie, so that they are all visible on top of each other. The different layers are kept aligned by monitoring a value in the GPU-- because the SNES happens to handle scrolling in hardware, the X and Y scroll offsets within the level are actually known at all times.
So all that would have to be done to change this to work with speedruns for different people would be to add a feature that loads a "movie savestate" and immediately begins recording from that point. (This would ensure that the recordings from all the different people begin at the exact same point.) You could then collect the recordings from everyone and have the existing quicktime export code smoosh the recordings all together.
FODA wrote:
I wish I could try it with other games but I'm not on a pc :(
Um, do you mean you're not on a mac? The full version of the hacked emulator I used to make the videos is actually mac only. I did get a windows version compiled but it can only record the multipath speedrun videos, it cannot export them to Quicktime.
Hm, rereading this actually I guess I misread what amaurea/CtrlAltDestroy's original proposal was. Amaurea seems to be suggesting that the ghost would be visible while you were playing the game. Right? Whereas the thing I did just creates a video mixing things together after the fact. Amaurea's idea would be a little more complicated to implement.
But if someone were going to attempt Amaurea's idea, you could probably simplify it a lot by stealing the idea that makes my hack so simple: Don't bother with multiple emulators or trying to monitor RAM, just save a literal video and then composit things graphically. For example when recording the "reference" playthrough you could just dump to a file containing, for each emulator frame, the PPU scroll x, the PPU scroll y, and then (assuming that this is a snes emulator) a graphical dump of the sprite layer. When you do "playback" you could just keep track of the frames since you started, and draw the approriate frame from the file to the screen, slipped between the sprite layer and the bg layers. I don't think that would be too hard.
(Side-note: your avatar is fairly annoying and probably violates rules. Consider removing it...)
...What is the purpose of "Export to Quicktime"? It seems like the same thing could be accomplished by using a 0-compression codec and recording directly to multiple tracks of an AVI.
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
Hey, that was original. I liked it a lot and I definitely think its entertaining. If someone would submit that type of run, I would most probably vote yes.
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
(Side-note: your avatar is fairly annoying and probably violates rules. Consider removing it...)
OK, I am sorry about that.
...What is the purpose of "Export to Quicktime"? It seems like the same thing could be accomplished by using a 0-compression codec and recording directly to multiple tracks of an AVI.
It is exactly the same thing. I do basically that just I record to tracks of a Quicktime file instead of tracks of an AVI. I did this because it was easier :)
It is exactly the same thing. I do basically that just I record to tracks of a Quicktime file instead of tracks of an AVI. I did this because it was easier :)
...
Then do you think it would be possible to implement this in a more normal AVI, instead of the propitary Quicktime format?
That alone would open up use to many more people.
It is exactly the same thing. I do basically that just I record to tracks of a Quicktime file instead of tracks of an AVI. I did this because it was easier :)
...
Then do you think it would be possible to implement this in a more normal AVI, instead of the propitary Quicktime format?
That alone would open up use to many more people.
I think that would be very possible. The problem is I do not have any experience with AVI, and I do not have a windows machine to do development on, so I do not know if I could do the port myself. Maybe if I had some AVI sample code I could try, I am not sure.
I would definitely like it if I had some way to open this up to windows/linux users.
Your best bet would be to check the sources of existing emulators used here.
Check the General forum's "Emulator Homepages" sticky. That contains a link to a page hopefully containing the source of most emulators used here, which (hopefully) contain the export-to-AVI code.
Hm, well I can try to take a look at some point but no promises.
The source for my changes is posted though if anyone else wants to take a crack at it ;shrug;
That is very interesting.
Also, apparently, there is a minor bug in the code: it sometimes puts a permanent white rectangle where a character disappered.
Also, the piranha plants that move up and down seem to work funny.
mcc, your trick employs similar techniques as my tiletracker. :)
I did something like this last night using Lua.
It only works for Blackthorne, but if anyone wants to check it out, here are the scripts: http://acranecorner.com/bthornelua.7z
The first script is labeled "blackwrite". It writes Kyle's X/Y coordinates to a file every frame. The other script (blackread) reads these coordinates and draws a rectangle to represent Kyle's ghost from the other movie.
In other words, it allows me record my performance from one WIP, and compare it my current WIP in realtime.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I'm not sure why, but there was nothing different when watching a movie I recorded in the windows version of this emulator. It just played like a normal TAS would. Is there any setting I need to adjust?
I'm not sure why, but there was nothing different when watching a movie I recorded in the windows version of this emulator. It just played like a normal TAS would. Is there any setting I need to adjust?
To make a video: First, use SNES9X’s “record movie” function to record yourself playing some game; while the game is running, use the save and restore feature at least once. When you’re done, you’ll find that SNES9X has created a yournamehere.smv file and also a series of files with names like yournamehere.smv.1, yournamehere.smv.2, etc. These .number files are all the different “mistake” playthroughs, so keep all these files together in one directory.
To turn this into an actual movie you can watch, you will need to use the OS X version of the emulator. Unfortunately, the Windows and Linux versions can only record multiple-run SMVs– they can’t do the export-to-quicktime thing. The quicktime-export code is based on alterations to the mac-specific parts of 1.43 (although considering that I hear the Quicktime API is mostly identical between Mac and Windows, it might be pretty easy to port that code to Windows at least…).
Anyway, in the OS X version, open up the appropriate ROM and choose “Export to Quicktime Movie” from the Option menu. Before leaving the export dialogue, make sure to click the “Compression…” button. You *MUST* choose either the “None” or “Planar RGB” codecs, and under the “Compressor” pane you *MUST* choose a depth of “Millions of Colors+”. The “+” is important. Once you’ve saved the movie location, go to “Play Movie” in the Option menu and choose the .smv you want to play. The emulator will play through each of the playbacks one by one; when it’s done (you’ll know because the background turns back on) your movie will appear in the location you chose. Note that there’s one more step! You won’t be able to actually play this movie, at least not very well, because the export feature works by creating a different movie track for each playthrough and the file will be huge and bloated. Open your video in Quicktime Player, then choose “export” and export to some video codec with actual compression (like H.264). This will flatten all the different layers of the movie into one. Okay, NOW you’re done.
Bisqwit wrote:
Also, apparently, there is a minor bug in the code: it sometimes puts a permanent white rectangle where a character disappered.
i think u're talking about the background^^ i thought it was a bug too..
<small>My big signature was cleared by admin; i should read <a href="http://tasvideos.org/ForumRules.html">forum rules</a>. But... who does?</small>
