over this weekend i'm gunna go through what you have so far and take some notes and maybe jog down some ideas for the future... do you have your todo list or a roadmap up anywhere?
Todolist is split between the NOTES.TXT file I maintain, as well as inlined with the code (I have 3 sections for easy searching if you're looking through the code, TODO::, DEBUG::, NOTES::)
As far as a roadmap is concerned, I haven't really thought that through. I think once I get VBA and mupen incorporated into this application, nail down any issues with the copy-pasting algorithm and tweak a couple features, this thing'll be done.
Nothing noteworthy. I ended up wasting a couple weeks attempting to redesign the application (I got rid of the tabbed interface for a while and went to listing changes textually ... then I thought that was dumb so I reverted back). I tend to get on this redesign kick too often, and it affects my ability to move forward with development :P
I've finished laying out mupen64 and starting writing the save/load routines for that and visualboyadvance. All your comments and everyone elses are noted and slowly being implemented ;)
I'll hopefully have something for everyone before christmas.
... then I thought that was dumb so I reverted back [...] I tend to get on this redesign kick too often, and it affects my ability to move forward with development
I do that, too. Progress stalls, but the existing features become stronger.
In the end it'll all fall into place. :)
Since I'm back from Phoenix (tradeshow and conference), I'm hoping to keep pounding away at v0-8. Aside from some additional codebase cleaning, bugfixes (I hope) and general improvements, I'm aiming for both VBM and M64 READ support to be enabled.
However, i figure I can release a new verision once I have WRITE support for at least one of those two nailed down. The question now is, which one do y'all think is more urgent? I got an email recently asking for mupen support, but there doesn't seem to be any (major) urgency to the request.
If no one's got a preference, I'll just do whatever I think'll be easiest :P (FMV perhaps? :P)
I would think MUPEN write support would be the hardest to implement, considering the analog movements and stuff... I would say go for FMV first, since most movies are still done for NES, then move to VBM and M64. Just my opinion though.
>If no one's got a preference, I'll just do whatever I think'll be easiest :P (FMV perhaps? :P)
I think FMV is the least needed, if you already have FCM. FMV movies are not produced any more, so there is not really any need to edit them.
I vote VBM. Juding from the amount of published movies the demand should be higher there.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Maximus, I noticed today that if you open a movie in the TAS movie splicer that you're currently playing with an emulator, the program crashes (I noticed this when I opened a .fcm-file while playing it with FCEU, and I'm guessing that it's the same for other formats as well). Is this something that can be fixed? Perhaps an error message saying "File already in use by emulator", or something like that. I'm guessing that moviefiles don't like it when two different programs are using them at the same time... :P
Maximus, I noticed today that if you open a movie in the TAS movie splicer that you're currently playing with an emulator, the program crashes (I noticed this when I opened a .fcm-file while playing it with FCEU, and I'm guessing that it's the same for other formats as well). Is this something that can be fixed? Perhaps an error message saying "File already in use by emulator", or something like that. I'm guessing that moviefiles don't like it when two different programs are using them at the same time... :P
Oops. Yeah, the emulators lock the stream when they're actively using the file. I actually had this happen before, noted it, said I'd fix it, then forgot :P
I'll add it to the list.
EDIT
I think I know what i'm doing for the new release (as far as UI overhaul goes).
The top portion is what the app is so far. The lower is what I'm going to replace the tabs with. I think, though the tabbed interface looked pretty, it's kind of overkill for what I'm trying to accomplish (especially since NONE of the fields are editable).
(especially since NONE of the fields are editable).
Any chance of this changing? It'd be handy to have a utility to change things like authors, emulator version, ROM checksum, sync settings, etc. Although usually they don't need to be edited much, so maybe a button would need to be clicked to "unlock" them first.
I just checked this out tonight and it's looking very very good. Looking forward to future versions!
Edit: LOL @ About screen :)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Eventually the metadata fields will be editable (Author/Description .. depending on format).
Not really sure why you'd need to change anything else (other than sync settings maybe) but i don't see it being a problem down the road.
Well, it's been a while in the works, but a new release is finally finished. The main feature addition is support for VisualBoyAdvance (VBM) movie files.
The second main change is an overhaul to the interface. Gone are the tabs in favour of a more simplified, streamlined treeview. This makes it easier to add more information logically.
Buffered frames can now also be saved/loaded from file.
Just for the fun of it, I've also added FMV saving :)
EDIT. I'm no longer hosting the files on my (crappy) sympatico account, so if you want the application or the source, see the sourceforge project at http://sourceforge.net/projects/tas-editor/
Enjoy
v0-8
- UI::Changed application title to TAS Movie Editor (no longer TAS Movie Splicer)
- UI::Tabbed interface removed. Replaced by a treeview.
- UI::Fixed a bug where the app would crash if trying to access a locked file
- UI::Removed frame count and file name from status bar (frame count no longer used in buffer length calculations)
- UI::Buffer saving to file implemented
- UI::Buffer loading from file implemented
- VBM::Header parsing implemented
- VBM::Controller data parsing implemented
- VBM::Splicing implemented
- VBM::Saving implemented
- FMV::Saving implemented
- FMV::Splicing implemented
- FMV::Fixed a bug where the bytesPerFrame kept increasing when an FMV was closed (crashed after about 3 loads)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Looking good. :) Some comments though (some of these are not really important, they're just some things that I'm personally interested in):
1. What is "signature" under Header? it has the same value for all movies I've opened so far.
2. What does the "version" tag under header mean? It says "2" on all movies I've checked with so far... But version of what?
3. It seems to be a small bug when editing FCM's recorded with any FCEU-version other than 0.98.12. It says that the movie is recorded "from save", even though it is from reset, and it also says that the timing is PAL, when it's actually NTSC. You should check that out.
3. An idea, under under "frame count" in the Header section, it would be nice to see that time in minutes and seconds, just like it's displayed when you're about to replay a movie in FCEU.
I also played around with editing the input for a movie, and I found some things inconvenient.
4. For starters, if you want to edit input for several frames, you begin with marking the frames you want to edit by dragging a box around them. As it is right now you can only create the "box" to mark the frames with by starting the box next to the frame number. Wouldn't it be easier if you also could start the box anywhere on the frame data field? I hope you understand what I'm saying, otherwise I'll show you with a picture or something.
5. Let's say that you want to edit input for several frames at a time. You begin with dragging a box around the frames you want to edit. Then, you go to the "Controller 1" field to type in the input. My small complaint is that once you have clicked on the "Controller 1" field after marking your frames, the blue color on the frames you chose disappears, so you don't see the frames you just chose. It would be nice if the blue filling for the chosen frames is still there, even after you clicked on "Controller 1".
6. This is pretty much the same thing as comment number 5. If you select more than one frame, the "Frame" box under "Controller 4" still only displays the first selected frame... could you make it so it displays all the frames that are marked?
7. What is this "Find input" and "Goto frame"? (shouldn't that be "Go to frame, anyway?) I couldn't get it to work when I tried it... I had a movie with some frames with the input "A". I typed A in the field and clicked on Goto frame, but nothing happened...
There are also some old things I've mentioned earlier that still aren't there, but I won't nag about them again. :) I trust that you will fix those in due time.
That's all I can think of for now... I like the interface of this new version. :) Keep up the good work!
1. What is "signature" under Header? it has the same value for all movies I've opened so far.
2. What does the "version" tag under header mean? It says "2" on all movies I've checked with so far... But version of what?
Signature/Version are used to verify that the loaded movie is valid. They "should" always be the same for a given format (GMV's can be version 9 or A). This was always there, I just didn't display it for lack of space.
One of the reasons I changes the interface to a treeview was so I could display even more information about a given movie. Internal check values aren't really necessary, and if they prove to be confusing, they can be removed.
3. It seems to be a small bug when editing FCM's recorded with any FCEU-version other than 0.98.12. It says that the movie is recorded "from save", even though it is from reset, and it also says that the timing is PAL, when it's actually NTSC. You should check that out.
It's been addressed. It turns out I was defaulting the timing to PAL, and that wasn't being changed (so if it's NTSC or timing info isn't present, it still reads as PAL).
3. An idea, under under "frame count" in the Header section, it would be nice to see that time in minutes and seconds, just like it's displayed when you're about to replay a movie in FCEU.
Can do :) It may not always be 100% accurate though (FPS isn't always known).
4. For starters, if you want to edit input for several frames, you begin with marking the frames you want to edit by dragging a box around them. As it is right now you can only create the "box" to mark the frames with by starting the box next to the frame number.
This is a limitation of the ListView control that holds the frame information. I may be changing the control to something else eventually, but for now, if you're selecting a group of frames, you can click the first frame, hold shift and click the last frame.
5. Let's say that you want to edit input for several frames at a time. You begin with dragging a box around the frames you want to edit. Then, you go to the "Controller 1" field to type in the input. My small complaint is that once you have clicked on the "Controller 1" field after marking your frames, the blue color on the frames you chose disappears, so you don't see the frames you just chose. It would be nice if the blue filling for the chosen frames is still there, even after you clicked on "Controller 1".
6. This is pretty much the same thing as comment number 5. If you select more than one frame, the "Frame" box under "Controller 4" still only displays the first selected frame... could you make it so it displays all the frames that are marked?
The current method of editing was kinda hacked together. I'm not really impressed with it and it is going to change. I'm hoping to eventually make frames "directly" editable (ie. if you select a block of frames, just start typing ... no need to click a textbox, type in the change and then press update).
7. What is this "Find input" and "Goto frame"? (shouldn't that be "Go to frame, anyway?) I couldn't get it to work when I tried it... I had a movie with some frames with the input "A". I typed A in the field and clicked on Goto frame, but nothing happened...
Goto frame is for jumping to a specific frame number. Find input "was" going to be a way to search for a given input pattern, but it wasn't working and I wanted to get a release out ;)
Hope that all makes sense. One thing that i'm hoping to have done for (whenever) v1-0 is released is some form of supporting documentation. I haven't decided on whether I should go the CHM route or just PDF/TXT.
Also, if someone wants to give me a hand writing it, that would be much appreciated.
Yo.
I pasted some stuff after the end of a movie, and it didn't update the frame count. This is important in SMV format at least (FCM and VBM too, I believe) because even if there is existing data past that frame number in SMV, the movie will still stop playing.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Are you referring to the framecount in the treeview? (if so, this won't update until the movie is reloaded since it refers to the original and isn't effected by edits)
Could you try saving the movie you just edited and re-open it. If the frame count doesn't change, then I made a mistake :P
EDIT: Now that I'm off work, I can confirm that saving does update the frame count. The treeview node for Frame Count doesn't update while editing though. I used to display an updated frame count in the status bar, but that was removed for this version. JXQ brings up a good point in that it's a necessary piece of information that needs to be available while a movie is being edited. As a result, this information will be available again (somewhere visible) in the next release.
EDIT2: I think I broke SMV saving :( I'll release an update shortly to address this.
v0-8-1
- UI::Fixed timing display for FCM files (was showing as PAL if no timing info existed)
- UI::Fixed copy-buffer save/load filter (contained a closing parentheses)
- UI::Fixed pasting from a loaded copy buffer (bad, bad, bad logic error)
- UI::Reintroduced the frame counter to the statusbar (updates on edit)
- GMV::Loaded movie now display's XYZMode values (doesn't save these yet though)
- SMV::Fixed saving (wasn't handling null input gracefully)
- M64::Header parsing implemented (not 100% ... controller selection still wonky)
- ETC::Rewrote format validation routine
EDIT: This build has some elements that aren't in production yet (Input Pattern Searching, Auto-Fire Update Mode, Input Comparison, M64 Support) so don't be too disappointed if something doesn't work (if something that should work doesn't though, please let me know =P)
I'm working on a similar project, though it's nowhere near as far along as this (Still fleshing out UI functions and code architecture)... I might just steal some ideas.. ;) j/k
I just tried it and it looks pretty good, except for a couple of things:
*Editing input for a frame allows the same button multiple times e.g. "B><><B" is valid. Not fatal, perhaps, but confusing. (Also allows nonexistant buttons like "C" in an FCM)
*"Copy buffer does not contain the same number of columns as the current movie" even though i copy pasted within the same movie. (EDIT: Which I now see that you already knew. :))
*Inability to edit Control Events, such as FCM's Reset,PowerCycle and such.
Having said that, it looks very promising. Keep up the good work! :)
There is a whole new world beyond these walls. Break them down.
Steal away, the source is available, just remember to mention who's yo daddy in the creds (j/k :P)
The input editor is slowly being overhauled. The current method was kinda hacked together and was never meant to be in the application for more than a couple releases, but I got lazy and didn't get around to updating it. I'm thinking of going with forcing input selection from a separate form available from a context ment (ie. right click->edit), and this would also let me add control event editing.
Currently, entering non-existent input or redundant input won't cause any errors (input of "<<>>UIQE<<>>" will only register as "<>") but is confusing since it will register in the list. Also, you can't group update a single controller column.
Good luck on your project though. If you need any help, feel free to ask. Also check out Zefiris' editor. He recently overhauled the project and it's looking pretty cool.
Using a DataGridView is another option if you're stuck with .NET 2 anyway. I'm using it and it makes input constraints a breeze. Plus, it looks good. :) You'd have to write some extra copy/pasting code but still.
There is a whole new world beyond these walls. Break them down.
I looked into using a DataGridView, but I was having some issues getting it to work in VirtualMode. Since I'm ultimately looking to move away from direct editing, a ListView should do ... for now :P
What are you planning to write your editor in?
It's in C#, because I'm currently studying for certification in it. I've already written an FMV module to preview some things I wasn't sure of. So far it's a pretty different approach to yours. It's nowehere near as clean/readable as your project either.. >_>
There is a whole new world beyond these walls. Break them down.
The top portion is what the app is so far. The lower is what I'm going to replace the tabs with. I think, though the tabbed interface looked pretty, it's kind of overkill for what I'm trying to accomplish (especially since NONE of the fields are editable).
