Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Allright, the "ViewCopyBuffer" function seems to work flawlessly. :)
An idea that just hit me is that it would be a good idea to have a few new error messages in the "Splice Movie" section. For example. if you neither have a source movie or a target movie selected and press "Splice", it says "Movie types don't match". Instead, it would be nice if it said "You must select at source movie and a target movie", or something like that. The same goes for if you have a source movie selected but no target movie, it could just say "You must select a target movie". I think you get my point.
An idea that just hit me is that it would be a good idea to have a few new error messages in the "Splice Movie" section. For example. if you neither have a source movie or a target movie selected and press "Splice", it says "Movie types don't match". Instead, it would be nice if it said "You must select at source movie and a target movie", or something like that. The same goes for if you have a source movie selected but no target movie, it could just say "You must select a target movie". I think you get my point.
Makes sense. I think this can be worked into the next release. I actually have a question for everyone (except my 2 current active users =P) ... is there any value in migrating this over to MSVC++ or Borland C++ so that the .NET framework is no longer a requirement.
Well, I do love a challenge, so as a result, I think I'm going to try porting this from .NET to MFC. This will hopefully make this more useful, as .NET would no longer be required.
The tests that I've run seem to show a definite performance increase (especially with redraw times ... damn does .NET add overhead :P).
(the above is actually in Borland C++ Builder 2K6, but the IDE is so brutally slow, I'm switching over to MSVC++).
Just in case this ends up taking longer than I'd like, or I get hit by a snowmobile, here's the source for v0.7.1 (C#): http://www3.sympatico.ca/alex.bevilacqua/tas-movie-splicer/tas.movie.splicer-v0-7-1-src.7z
Keep the ideas coming though.
Rock on dude! Shoutout to all editors... the downloads page really need an updating as mentioned earlier! As soon as this becomes more portable, it ought to gain a place on that page as a all-in-one movie editor...
Not much to ask for already; most requests have already been mentioned. I just hope that the new version would make it much easier to edit/copy individual player tracks rather than having to work with both player inputs together.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Wow, that new interface looks sweet. I can't wait to get my hands on v 0.8. :) Good luck with the programming, and remember all the stuff I've mentioned earlier so you don't forget to implement anything. :)
If you can supply an address which has the latest version, and also will continue to have the latest version when you release a new verion, I can put up the link at once. (Pointing to forum posts usually becomes obsolete very quickly.) This program already seems to have more features and usability than the others we link to.
Truncated: Ah, the fiendish instrument of torture speaks ;)
Maximus wrote:
The Gens_Editor doesn't seem to work with TESTA movies (>=Gens-9f i think)
I guess this requires updating as well... thanks
Maximus: I guess this means that you should keep the file name consistent on the webhost to prevent 404 of the links on the download page
I guess this means that you should keep the file name consistent on the webhost to prevent 404 of the links on the download page
Can do. Looking for more permanent hosting, but i don't know if i should stick this up on zShare or one of those hosting services. If anyone knows of a good one, let me know (if not, my personal space holds about 10 megs ... which is plenty since I only started using it for source/binary hosting).
Can do. Looking for more permanent hosting, but i don't know if i should stick this up on zShare or one of those hosting services. If anyone knows of a good one, let me know (if not, my personal space holds about 10 megs ... which is plenty since I only started using it for source/binary hosting).
Joined: 5/22/2006
Posts: 58
Location: Denver, CO USA
schneelocke wrote:
Maximus wrote:
Can do. Looking for more permanent hosting, but i don't know if i should stick this up on zShare or one of those hosting services. If anyone knows of a good one, let me know (if not, my personal space holds about 10 megs ... which is plenty since I only started using it for source/binary hosting).
Sourceforge?
seconded here.
just a though, even though it's not that big of a deal, but it might be nice instead of <, ^, etc..., the program used icons for the directional arrows, though that might add unnecessary overhead, i think for the most part it should be a negligible difference.
anyways, that said, your program is coming along really nicely, impressive work!
What would Mr Belvedere do? Probably eat some butter.
http://sourceforge.net/projects/tas-editor
:)
Maybe we can get more people working on this and really crank out a defacto TAS tool.
EDIT. I keep see-sawing back and forth between wanting to re-write this in a more portable/available framework/structure, but I kind of want to move forward, not laterally. I think I'm going to do a bit more cleaning, maybe implement some new, sexy (hopefully functional) features, and keep v0-8 in .NET 2.0.
If anyone wants to collaborate on the re-write, any help is appreciated. I'm still not 100% sure on whether it should be C++ (MFC, wxWidgets, Glade/GTK+) or Java (SWT).
I think this could prove to be a pretty useful tool, but for it to be REALLY useful, the Linux community shouldn't be excluded. Currently, the codebase is extremely Windows-centric (i doubt Mono can handle Windows.Forms that well ... yet).
Anyhoo, there's still about 10-15 things on the todo list that can be cranked out a lot easier under the .NET framework than not, so I guess I'll keep working on it as such until I have another sudden change of heart :P
The code is available (here on TASVideos as well as SourceForge), so if you have any suggestions as to how we can tighten up some routines ... shoot :P
just a though, even though it's not that big of a deal, but it might be nice instead of <, ^, etc..., the program used icons for the directional arrows...
This is something that's been looked into. Before I introduced editing, I actually had a seperate form with an image of the respective format's controller with checkboxes over the directional pad and the buttons :P This bloated the file and proved to be kind of cumbersome when it came to actually editing.
I am however looking to improve the editing process, since right now, i can't filter out unnecessary input values (you can type anything you want into the controller input fields and update as such). Even though saving discards unusable data (ie. if you type in QWUFDPSFSDF<>AB for controller input, it'll display it, but won't save anything but the S<>AB) it's not visually pleasing :P
Ideas are welcome as to how to best tackle this. So far, it seems all other editor authors have gone the route of dedicated columns per input type per frame (see figure 1), whereas I've gone with the mashed together approach
From what I've seem, I've got the first editor to break from the above tradition. The question now is whether or not it's an improvement (I think so :P). If we break from ASCII character representation of frame input though, what should it be replaced with? Should it be a simple representation like luke did with FCEU 98.16's frame input view? How should the editing features change then?
This is something I was considering using if I ever made a TAS editor. Mine would be arranged horizontally though, with lines extending for held buttons, looking more like an audio sequencer. Bonus points for those who know where I lifted the design from.
I didn't do it like that because you have to visually scan each line for a key, rather than looking it up via its column.
I went for player by column vs. player input by column, allowing all available players' input to be visible at once. I like the way vSNES has the player tabs visible (other editors have that hidden in menus), but I figured users might want to see everything in the same list.
>I figured users might want to see everything in the same list.
Yes please. That is probably the best reason for using your version. I wouldn't want to see that changed.
Although, if you can fit in "<>^vABXYLRsS" five times on one line, it should be possible to line up the characters all the time too just by putting spaces where a button isn't pressed down (assuming monospace font).
>
>
> A
> vA
> vA
^ A
Another option is to color-code every button, but i suspect it's hard to find 12 colors different enough, and probably not fun to code either.
New function suggestion:
How about a "Skip to next frame with an input" function? I can imagine in this same dialogue that appears, you can also skip to the next frame with a "B" input, or skip to next frame with exactly a ">B" input. Something to this extent. Useful in situations where there are plenty of blank frames and you are trying to source for when the next input occurs, or remove the next ? input, or add something different immediately before or after a particular input. Hope my description is sufficiently clear...
Btw, I like Truncated's idea
>I figured users might want to see everything in the same list.
Yes please. That is probably the best reason for using your version. I wouldn't want to see that changed.
Huh? Don't know why you'd want that, but I haven't done any serious editing/running either. :) At least you can switch quickly via Alt+1..5.
Anyway, 14 buttons * 16 pixels * 5 players would already consume 1120 pixels horizontally, hence the trend to separate planes. Do you want to list the 5 players vertically, for each input frame? Or display only the required number of columns?
Anyway, 14 buttons * 16 pixels * 5 players would already consume 1120 pixels horizontally, hence the trend to separate planes. Do you want to list the 5 players vertically, for each input frame? Or display only the required number of columns?
I'm going to assume that they only want the required number of columns. It's very, very rare to see >2 players worth of input in a given movie, and I default my columns to 75px (which is overkill for the current display method), and with only a maximum of 5 columns (the sixth being for the frame counter), it's 450px total.
For the next version though, I'll try to clean up the input display method.
Joined: 5/22/2006
Posts: 58
Location: Denver, CO USA
Maximus wrote:
http://sourceforge.net/projects/tas-editor
:)
Maybe we can get more people working on this and really crank out a defacto TAS tool.
EDIT. I keep see-sawing back and forth between wanting to re-write this in a more portable/available framework/structure, but I kind of want to move forward, not laterally. I think I'm going to do a bit more cleaning, maybe implement some new, sexy (hopefully functional) features, and keep v0-8 in .NET 2.0.
If anyone wants to collaborate on the re-write, any help is appreciated. I'm still not 100% sure on whether it should be C++ (MFC, wxWidgets, Glade/GTK+) or Java (SWT).
I think this could prove to be a pretty useful tool, but for it to be REALLY useful, the Linux community shouldn't be excluded. Currently, the codebase is extremely Windows-centric (i doubt Mono can handle Windows.Forms that well ... yet).
Anyhoo, there's still about 10-15 things on the todo list that can be cranked out a lot easier under the .NET framework than not, so I guess I'll keep working on it as such until I have another sudden change of heart :P
The code is available (here on TASVideos as well as SourceForge), so if you have any suggestions as to how we can tighten up some routines ... shoot :P
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?
As far as the rewrite goes once you get the .NET version where you want it featurewise, I'd definitely be up for helping you plan/develop the cross platform version... it'll be better than trying to work with this frustrating codebase of HuGo
What would Mr Belvedere do? Probably eat some butter.
you guys could use cross-platform GUI libraries such as wxwidgets. (actually, I don't how any other free one).
this would probably be true too for many emulators around here (no more specific platform code maintaining, no more abandoned linux users, no more lonely coders, etc.).
I never sleep, 'cause sleep is the cousin of death - NAS
(the above is actually in Borland C++ Builder 2K6, but the IDE is so brutally slow, I'm switching over to MSVC++).
Just in case this ends up taking longer than I'd like, or I get hit by a snowmobile, here's the source for v0.7.1 (C#): http://www3.sympatico.ca/alex.bevilacqua/tas-movie-splicer/tas.movie.splicer-v0-7-1-src.7z
Keep the ideas coming though.
From what I've seem, I've got the first editor to break from the above tradition. The question now is whether or not it's an improvement (I think so :P). If we break from ASCII character representation of frame input though, what should it be replaced with? Should it be a simple representation like luke did with FCEU 98.16's frame input view? How should the editing features change then?
This is something I was considering using if I ever made a TAS editor. Mine would be arranged horizontally though, with lines extending for held buttons, looking more like an audio sequencer. Bonus points for those who know where I lifted the design from.
