Ok, I ran some more tests and the above statement is not entirely accurate. The movie BoltR sent is proving troublesome, but all other tests I've conducted have resulted in valid VBMs (i added a quick debugger that basically just does a byte-by-byte comparisson of the source and and edited movie).
If anyone else is having difficulties with VBMs not working properly after being saved, let me know, but don't worry otherwise ;)
Nothing to report as of yet, but I figure while I'm working on a new release, maybe someone wants to give me a hand with other aspects of this project:
1) I'm looking for a new icon I can use for this app (32x32 ico)
2) The help file is pretty weak. If someone wants to proof it, or possibly expand upon it ... well, that would be just super :)
Aside from that, always looking for new, sexy features. Currently I'm working on a movie comparission feature, possibly adding an input animation editor, adding additional subtitle formats.
Also working on tightening existing features, such as bulletproof VBM, M64 output, a better input editing interface, control event r/w for FCM and SMV (reset events mainly), controller de/muxing, savestate extraction ... etc.
Any ideas, as always, are welcome ;)
Well, I've been kind of busy for the last month or so with other projects, but they're starting to wind down again so I thought I'd do some more work on the editor.
I've implemented a rudimentary movie comparer to help everyone pinpoint differences in similar movies. This is still pretty alpha, so I'm gonna do the ol' screenshot post and see if anyone has any ideas on how to best proceed with this module.
This should be out with the next release, as I've got it working at about 90% reliability (still need to add some checks for disparate controller counts, similar format checks and whatnot).
What I'm hoping for is some comments regarding how to make this module more useful. What would the TASVideos community like to see?
Joined: 4/11/2006
Posts: 487
Location: North of Russia :[
make sure to make this possible: compare movie 1 starting from address NNNN with movie 2 starting from address MMMM. if both addresses could be changed on-the-fly and be negative (to shift one movie without cropping display of other) it would be even better ^^
Joined: 2/28/2006
Posts: 2275
Location: Milky Way -> Earth -> Brazil
Uh, Maximus... is there a special reason (in VBM) for the program to read L and R (shoulder buttons) as <and> (sorry, PHPbb didn't want them two to be colored) these two ? Also, I think you should use miniature images of the buttons, instead of those stupid ascii characters (I hate them). I'll pm you if I have more specific ideas.
"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:
(Last I checked, "<" and ">" are used for the directional pad, not the shoulder buttons.)
Anyway, for "input display" each button can have only one character, so "LSB" and "RSB" are not possible.
Maximus:
Have you thought about showing the movie inputs vertically stacked?
Uh, Maximus... is there a special reason (in VBM) for the program to read L and R (shoulder buttons) as <and> (sorry, PHPbb didn't want them two to be colored) these two ? Also, I think you should use miniature images of the buttons, instead of those stupid ascii characters (I hate them). I'll pm you if I have more specific ideas.
The method of rendering input display is not written in stone, and I have been writing a few test controls to see how best to use images .... I just haven't put one in yet. I'm hoping to have this all ironed out by the time this is promoted to v1.0.
The ascii display was fine if only FCM/GMV were being shown, but with more input, it's getting kind of cluttered (look at an M64 and you'll see what I mean :P)
creaothceann wrote:
Have you thought about showing the movie inputs vertically stacked?
I don't think I'm going to use this method. Though I like zefiris' formatting method, I was going for something a bit more unique. If I can accomplish the above (image rendering of input), I don't think the separate columns will be necessary.
For the moment though, since the ascii rendering works, I'm just looking to add features while I figure out how best to show input. It will be fixed though ... hopefully sooner than later :P
i.e. like it's now, just with only one "frame" column.
Ah. The reason for two frame columns though is that you can compare run segments, so this let's you know where you are in which run. I could probably merge those two columns into one with a [xxxx - yyyy] type of dispay though.
Joined: 4/11/2006
Posts: 487
Location: North of Russia :[
frame number may be different if you compare movie from different starting points. so, two columns are required~ ^^
just a random thought: maybe a switch "show movie 1 frame numbers/ ..movie 2.. / ..both movies.." would help~ not really worth it though.
I just had a thought. Would it be possible to add support for a parsed ascii file format for movies? It would be a lot more intuitive for when it comes to editing and pasting around frames.
Joined: 4/11/2006
Posts: 487
Location: North of Russia :[
CtrlAltDestroy wrote:
I just had a thought. Would it be possible to add support for a parsed ascii file format for movies? It would be a lot more intuitive for when it comes to editing and pasting around frames.
may be you are looking for this? <_< http://tasvideos.org/forum/viewtopic.php?t=5257
I suggested adding something like this to Maximus's editor, but the whole idea of this editor is to avoid such things and make editing as easy as possible with simple user interface made specialy for that purpose~ I remember he said he'll consider adding it to his editor though ^^
I had considered adding support for exporting frame input files as something more intuitive, but it sorta invalidates the usefulness of the editor.
Zefiris has some good tools for this already, so there's really no need to re-invent the wheel. If both applications are maintained and improved, users have an option as to how to edit their movies. Personally, I think that's the best bet. Some people are extremely against upgrading to .NET 2.0 (beats me why, but that's not important). As a result, they would have an option that doesn't involve upgrading, and would give them the ability to do pretty much the same editing functions as my application, but with a text editor.
Just to show that I still listen, here's a taste of what I'm hoping will be working for the next release ....
Turns out this routine doesn't kill performance (works with virtual lists) and hopefully makes working with input more intuitive. If someone has a preference for how the input should look and wants to provide me with some icons ... groovy :)
Joined: 4/11/2006
Posts: 487
Location: North of Russia :[
Yay ^__^ well, functionality goes first, configuration waits~ ^^ But when everything is finished, I expect skins for those button states and adjustable colors for lines ^^ Don't rush it~
Yay ^__^ well, functionality goes first, configuration waits~ ^^ But when everything is finished, I expect skins for those button states and adjustable colors for lines ^^ Don't rush it~
DEAL, on ONE condition: the next version of TASHex has to be built with .NET ... just to piss people off!!! :P (j/k)
On that topic though, is there any reason I should support your format or is that overkill (over using a standard text editor that is).
Joined: 4/11/2006
Posts: 487
Location: North of Russia :[
Maximus wrote:
DEAL, on ONE condition: the next version of TASHex has to be built with .NET ... just to piss people off!!! :P (j/k)
I can't, I don't know how :D I can make it shareware~ :D :D
On that topic though, is there any reason I should support your format or is that overkill (over using a standard text editor that is).
None at all~ Really, why bother if opening text file that's meant to be edited with text editor will result in the same thing as loading original file, while text file would require new method to read as it's not binary file? Well, if you ever consider adding text file format support, using same format as tashex does is a good option, but... why? I am voting no on this ^^
I'm a big fan of individual controller button locations - meaning that the active buttons are not stacked up together, but each is on its own place.
Could you make that an option? I guess (?) others would like that too...
I'm a big fan of individual controller button locations - meaning that the active buttons are not stacked up together, but each is on its own place.
Could you make that an option? I guess (?) others would like that too...
Shouldn't be a problem. I'm trying to avoid any kind of horizontal scrolling when viewing input, but I guess If i'm aligning input, that might be necessary (for 5 controller SMVs or M64s ... assuming I ever finish support for them that is).
v0-12 should be out soon, and I'll try to squeeze it in for that release. If I decide to drop M64 support as an option, would anyone really notice? I think there aren't too many mupen runners at the moment, and M64s desynch like crazy, so support may not really be feasible, even if I can write the files properly.
If the statement about mupen is accurate, v0-12 will likely be RC1 for this editor ;)
Edit: v1-0-1 will probably introduce ZMV support, assuming people start using ZSNES more frequently .... feel the love Nach :P
This should be out with the next release, as I've got it working at about 90% reliability (still need to add some checks for disparate controller counts, similar format checks and whatnot).
What I'm hoping for is some comments regarding how to make this module more useful. What would the TASVideos community like to see?
Turns out this routine doesn't kill performance (works with virtual lists) and hopefully makes working with input more intuitive. If someone has a preference for how the input should look and wants to provide me with some icons ... groovy :)