Joined: 8/9/2004
Posts: 139
Location: Washington State
I figure we should make a thread about all the tools you wish you had access to while making a TAS.
just to get the ball rolling... These are a few ideas that have been floating around in my mind.
Dopesheet:
Anyone ever thought of creating a dopesheet plug-in for any emulators? So that you can view all of your save states on a timeline and edit them in the same window? Maybe even slide the savestate ahead or back however many frames needed?
SpriteInfo Display:
Select a sprite on screen to display the assotiated memory adresses and values?
Zoom in and out:
Can there be a tool that allows you to zoom in or out of the given frame? so that you can see more of the level? That way anyone who is anyone can controll the character when it has gone outside of the screen?
Also it would be sweet to have an emulator that wasn't just an emulator but more a "TASstudio" maybe even name it "TAStudio PRO" as a catchy title. :D
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
My two biggest needs:
1) I want a multi-track recorder where I can record a set of button presses and then record over with another set without destroying the first. This could be used to luck manipulation and would greatly ease the making of 2-player movies. You could record player 1 for a short segment, switch to track 2, and record player 1's movements.
2) A button press macro-editor, which is already in the works for FCEU. This allows the programming of various button combinations and assigning them to a single function. There is random key option for any frame. Ideally, it would have both two player support and compatible with the multi-tracking feature. Also, it would be cool to be able to import a macro from a movie file, by specifying the range of frames to import. This would turn it into a kind of mini-hex-editor
As for your ideas, the TAStudio Pro sounds awsome :) Something many windows pull down menu and lots of bells & whistles. And Savestate moving is a must.
I figure we should make a thread about all the tools you wish you had access to while making a TAS.
just to get the ball rolling... These are a few ideas that have been floating around in my mind.
Dopesheet:
Anyone ever thought of creating a dopesheet plug-in for any emulators? So that you can view all of your save states on a timeline and edit them in the same window? Maybe even slide the savestate ahead or back however many frames needed?
SpriteInfo Display:
Select a sprite on screen to display the assotiated memory adresses and values?
Zoom in and out:
Can there be a tool that allows you to zoom in or out of the given frame? so that you can see more of the level? That way anyone who is anyone can controll the character when it has gone outside of the screen?
Also it would be sweet to have an emulator that wasn't just an emulator but more a "TASstudio" maybe even name it "TAStudio PRO" as a catchy title. :D
The dopesheet idea sounds cool... the timeline part may be useful for keeping track of all the savestates especially for RPG TAS. The part on sliding the savestates back a few frames may not be feasible, cos it may screw up the way the game may randomise the rest of the level, hence destroying the subsequent save states.
Hmmm, as for the Zoom in/out feature, well, its hard to make it applicable for every game. From my understanding, the game map have to first be made, either by disassembling the game altogether, or by taking screenshots everytime the screen moves to the next panel. Then with the map in place, the emulator must find the memory addresses for the x/y-coordinates, then scale it back onto the map. The problem is that each game works differently, not only the memory addresses, but the way the maps are stored and stuff. So I guess its hard to program a feature that could do all these for every game :S With that said, nitsuja must have had a hell of a time with his sonic advance 2 run!
But if you're talking like dream/ideal tools, well that would be great! In that case, I wish that the emulator had bots that could automatically test for standard glitches like collision abuse and stuff... YAY! Maybe then we can see more cool wall walkings in games :P
>Dopesheet:
Quite doable I think. It just takes loads of CPU power to slide a savestate a step backward. You have to go the the previous savestate (which might not exist, meaning beginning of the movie) and compute every frame after that until you get to [n-1]. Moving a savestate a frame forward is trivial (read-only, read state, frame advance, save state).
>SpriteInfo Display:
I think this one is technically impossible. Sprites on screen are not linked to any memory addresses.
>Zoom in and out:
If all games for a console use the same memory positions for scoll position (which I think at least NES does, that's how Bisqwit's GIF ripper works), this one is possible. You could only see the parts of the level that is currently loaded, obviously. Not see what's behind doors and such.
What would I like to see... better savestate handling. It's not unusual to load a savestate with the old/wrong contents and continue playing from it. Or loading a savestate that is not part of the movie at all -- there are some checks for this, but not enough. It's not as easy as recalculating all savestates later in the movie than the one you load, because you might be testing something and want to go back to a later savestate afterwards. I don't know how it would work, just that it should. :)
It's not as easy as recalculating all savestates later in the movie than the one you load, because you might be testing something and want to go back to a later savestate afterwards.
Well, if you're recording, wouldn't loading a previous savestate mean that the later savestate is ruined anyway?
Joined: 2/28/2006
Posts: 2275
Location: Milky Way -> Earth -> Brazil
you're lazy
"Genuine self-esteem, however, consists not of causeless feelings, but of certain knowledge about yourself.
It rests on the conviction that you — by your choices, effort and actions — have made yourself into the
kind of person able to deal with reality. It is the conviction — based on the evidence of your own volitional
functioning — that you are fundamentally able to succeed in life and, therefore, are deserving of that success."
- Onkar Ghate
Bisqwit wrote:
atro city> Well, if you're recording, wouldn't loading a previous savestate mean that the later savestate is ruined anyway?
No, not any more, but most emulators had this misfeature previously. Now you can easily save state 2 at frame 5000, retry from state 1 at frame 3000, decide it didn't work out, load state 2 and be happily on your way. (The secret is to save a copy of the movie up to that point in every state.)
p_s> you're lazy
Helpful comment, that.
If all games for a console use the same memory positions for scoll position (which I think at least NES does, that's how Bisqwit's GIF ripper works), this one is possible. You could only see the parts of the level that is currently loaded, obviously. Not see what's behind doors and such.
No, the values that the "GIF ripper" uses are the PPU scrolling registers.
The PPU has RAM for two screenfuls of data at any given time -- you can use Nesticle's VRAM viewer to see how it works. The scrolling registers literally tell where is the origin of the current screen, within that VRAM.
Different games utilize the RAM a bit differently. In any case, the PPU scrolling registers are only written by the game; in an emulator, you can only read them. If you try to write them, the game ignores the writes, and it certainly doesn't allow you to force the game to render portions of the stage that have not yet been rendered. The game only renders stuff that it thinks is immediately going to be needed (such as half of the next or previous screen), so even viewing different windows of the PPU VRAM is not much help, except to gain insight on how the scxrolling works.
it would be already very good if all emulators had bullet-proof rerecording, and were (relatively) bug free.
another (not new, cf an old post from Highness) feature request : a live movie editor, to allow you to record inputs at whatever frame you want, without having to manually switch with dozens of savestates, and risking of losing parts of your movie (the emulator recreating the savestates on the fly)...
dopesheet isn't new either, I remember someone posting a screenshot of it too, it just seems so complicated to program since emulators have usually rerecording functions (that would need to be heavily edited) scattered over several, often obcure source files. but yeah, it seems a pretty interesting idea.
I never sleep, 'cause sleep is the cousin of death - NAS
The problem is that each game works differently, not only the memory addresses, but the way the maps are stored and stuff. So I guess its hard to program a feature that could do all these for every game :S With that said, nitsuja must have had a hell of a time with his sonic advance 2 run!
That was only for the Sonic Advance and Sonic Advance 3 runs. For Sonic Advance 2 I didn't even use a memory viewer or maps or anything like that. Making maps is different for each game, although the Sonic Advance games all use such similar engines that it was trivial to make (screenshot-based) maps for all three of them using almost the same code, and there are probably other games that are similar enough to do that.
adelikat wrote:
I want a multi-track recorder where I can record a set of button presses and then record over with another set without destroying the first. This could be used to luck manipulation and would greatly ease the making of 2-player movies. You could record player 1 for a short segment, switch to track 2, and record player 1's movements.
I did something like this for Sonic 2. I would have a hard time doing a 2-player run without it, now, because it makes it so much easier to be able to record the players individually without affecting the input data later in the movie of one or both players. It's simple for the emulator: there's a toggle for each player that, when on, causes the input data for that player to come from the active movie instead of from the buttons being pressed, even while recording.
The main problems with it are that the segments would need to be very short if the players interact a lot, and it can only change previous input in the movie if the number of frames remains the same (overwrite, not insert or delete). And it forces you to eventually watch (or fast-forward through) everything after the change that you want to keep, but then again that could be a good thing because it means you will always notice if the change caused a desync.
I know what I would like: Instant luck manipulator. Tell the program what you want to manipulate and it instantly tells you what you need to do it.
Hooray for wishful thinking.
Emulator Coder, Site Developer, Site Owner, Expert player
(3599)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
nitsuja wrote:
I did something like this for Sonic 2. I would have a hard time doing a 2-player run without it, now, because it makes it so much easier to be able to record the players individually without affecting the input data later in the movie of one or both players. It's simple for the emulator: there's a toggle for each player that, when on, causes the input data for that player to come from the active movie instead of from the buttons being pressed, even while recording.
Any chance you could make a feature like this for FCEU? (pretty please?) Of course there are prblematic elements to it but it would greatly ease the frustrations and keyboard limitations and making two player runs (double dragon 2 for istance).
Joined: 5/22/2006
Posts: 58
Location: Denver, CO USA
i actually had a supremely nerdy dream about a month ago about an application that i developed that was basically "TAStudio Pro" which had a layout similar to flash. I took down some notes in my dreamjournal about it, i'll go back and check it out later and write down all the features i had listed in it.
What would Mr Belvedere do? Probably eat some butter.
I would like to be able to strip the graphics down so all you can see is the hit boxes, walls and ledges. It would also make spotting glitches easier if you see an incomplete wall.
A universal emualtor that never desyncs with any game and allows soft resets would be nice also. Plus a TASbot that can brute force short hard to optimize stuff.
Joined: 8/9/2004
Posts: 139
Location: Washington State
hippo wrote:
i actually had a supremely nerdy dream about a month ago about an application that i developed that was basically "TAStudio Pro" which had a layout similar to flash. I took down some notes in my dreamjournal about it, i'll go back and check it out later and write down all the features i had listed in it.
Joined: 8/9/2004
Posts: 139
Location: Washington State
AKA wrote:
I would like to be able to strip the graphics down so all you can see is the hit boxes, walls and ledges. It would also make spotting glitches easier if you see an incomplete wall.
I would like to be able to strip the graphics down so all you can see is the hit boxes
Hit boxes are usually mathematical constructs that are not rendered in any way. There's no way to "see" them unless you can locate the relevant less-than and bigger-than comparisons from the game code and translate them to screen coordinates.
I would like to be able to strip the graphics down so all you can see is the hit boxes
Hit boxes are usually mathematical constructs that are not rendered in any way. There's no way to "see" them unless you can locate the relevant less-than and bigger-than comparisons from the game code and translate them to screen coordinates.
Couldn't you get the orginal source code and replace sprites with a blue coloured bitmap.
Regarding Snes9x:
1. Sound channels enabling/disabling
2. Save/Load of the memory watches
3. Allowance to select 2 games in the same time, seting the starting frame for both seperately and dual encode them side by side for comparisons
4. Perfectly working Net-Play support (like ZSNES already have)
Thats all I could think of currently.
