Okay, after looking through that, what's the problem with FBA? It emulates perfectly, has enough re-recording tools to get the job done, so what else is missing?
I am just a silhouette, a silhouette of a memory of a solitary night .. nothing more.
Good point. That would screw with the timing of the actual run. Would it be possible to implement such a feature? (dramatic) Or am I doomed forever to have such quality go to waste? (/dramatic)
I am just a silhouette, a silhouette of a memory of a solitary night .. nothing more.
100MB!?! What arcade roms are you using?
Looking at a few of mine, I see the biggest being kof2000. Most of the bigger games seem to be fighters anyways, and it seems most fighter just end up being a combo demo of the same one over and over (if for pure speed). Most of the runnable games are under 30 megs. And by runnable I mean being able to be completed fast AND look cool.
Still not sure what you mean, Shakespeare. Are you talking about modifing the file it self to be read-only?
Also still not understanding the no FBA thing. Looking for understanding...
I am just a silhouette, a silhouette of a memory of a solitary night .. nothing more.
I think that the discrimination agains FBA also has to do with the fact that some arcade game images can be over 100 megs.
It's not actually a good reason. ps2 games are in Gbs and people wish to see tas of them in future.
I have a large ( but now slightly out of date) goodset of arcade games. I beleive it's 40GB, and some games need cd images and ARE in the GB. Size may not matter to you, but I can bet you that encoders like Bisqwit aren't going to be willing to download that much to encode videos.
I don't see how that could be a factor since we do not distribute ROM images, so who cares how large they are?
It is not a matter of tasvideos distributing the files, it is a matter of easy accessability. For a huge number of people, a 100 meg file is an overnight affair, at best. People can download the avi if they have the bandwith, but if they don't, with a little ingenuity and computer smarts they can have that same video in 4 megs, at worst (using snes as a standard).
And besides, it says it in the faq, it not like I made this stuff up. It's not like the administrator(s) of this site rule the land with an iron fist. If enough people support and fulfill an idea, as long as it's not a total dumb ass idea, Bisqwit would allow it.
I agree. The issue really isn't file size. It's those who would actually do them, and those who would like to see them that would actually decide if FBA TASes would start to get out. I guess I'm just jumping the gun a little bit? But still, if possible I would like to know if there is anything that I can do to do get this running. If it's just a few small things like record from power up, I hope that there is some awesome/cool person who could implement that.
I am just a silhouette, a silhouette of a memory of a solitary night .. nothing more.
100MB!?! What arcade roms are you using?
Looking at a few of mine, I see the biggest being kof2000.
The ROM file size is change in every emulator. Here are some examples..
KOF 2002 [WinKawaks -> 39.8MB] [FBA -> 78.7MB] (The Biggest One)
Metalslug 4 [WinKawaks ->29.4MB] [FBA -> 60.4MB]
FBA uses Mame32 Roms Sets. As I heared, Initial Dump work stars from mame. I don't know the reason of different filesize of same game in different emulator.
Shadow Byrn wrote:
Still not sure what you mean, Shakespeare. Are you talking about modifing the file it self to be read-only?
Duh... Let's take Fceu as an example...
I am making Tas, i want to save another state 100 frame forward from currently saved one. between the record input running, I pressed Shift+F5 (Make Movie Readonly) Made a new save state. Pressed Shift+F5 again, it will now un check readonly.. Cuntinue Tasing. Got it? I want to do same with FBA
feitclub wrote:
Grambo wrote:
I think that the discrimination agains FBA also has to do with the fact that some arcade game images can be over 100 megs.
I don't see how that could be a factor since we do not distribute ROM images, so who cares how large they are?
All information contained within the movie file must be parseable and interpretable without access to the game or the emulator (complete documentation of the movie file format is required).
I somehow missed this my first few times over that page. It means someone needs to tear the input file up and see how it works? Mostly for verification puposes like no cheat/savestate using, and things like that. I guess that would be a pain, though. So is there no documentation for the FBA .fr format? Seems strange....
On this site, movies are usually made in the form of speed records, that will be challenged by other players. It is therefore mandatory to provide a common ground for all movies of a particular system. That common ground is usually decided to be power-on or reset.
But it's like I've been saying the whole time...I'm no programmer (tried once, so I do know what goes into it) this doesn't seem too hard to implement, if a record from power-on is needed. In my FBA tinkering I haven't seen a record from power on feature, but then again, I haven't really looked for it too hard, because I just paused, hit re-set and then advanced a little and then hit the record button.
Soooooooo, this seems to be the vibe that I'm getting here:
Until someone somewhere somehow in someway implements the 2 or 3 small features that seem to be holding FBA (or other arcade emulators) back, I just gotta chill or continue making noise until I'm heard. Or try to do it myself (hmmm.....sadly not an option. Like I said earlier, I got out of programming ages ago).
Shakespeare said
Duh... Let's take Fceu as an example...
I am making Tas, i want to save another state 100 frame forward from currently saved one. between the record input running, I pressed Shift+F5 (Make Movie Readonly) Made a new save state. Pressed Shift+F5 again, it will now un check readonly.. Cuntinue Tasing. Got it? I want to do same with FBA
Ah! I get it! (/stupid) Sorry for the misunderstanding. Hmmm, I see why you would like to use that, but I'm unaware of how to do it in FBA. Mostly because if I wanted to do something like that I was just REALLY careful. Of course this more than once cause me to make a mistake and lose like an hour of work.....
I am just a silhouette, a silhouette of a memory of a solitary night .. nothing more.
*Gives nitsuja a Pichu* Cool. One step further to world domina...ummm...TASing cool arcades.
nitsuja wrote
I filled in that page, although now that it is documented, you will probably find that it fails to meet several of those conditions.
To be honest, I'm still in the dark as to what THOSE conditions are. I've guessed, but I would just like to know for certain which is missing. And if there's anything I can do to help move this in the right direction.
I am just a silhouette, a silhouette of a memory of a solitary night .. nothing more.
I'm still in the dark as to what THOSE conditions are. I've guessed, but I would just like to know for certain which is missing. And if there's anything I can do to help move this in the right direction.
The file signature ("FB1 ") fails to contain any characters that couldn't be typed into a text editor. [not a problem]
There's no re-record count stored in the movie. [not anymore]
There's no framerate indicated and thus no way to determine how long the movie is in seconds. [always 60 FPS?]
There's no space for author's info in the movie. [not anymore]
There's no way to be sure a given movie has a reset at the start. You could check that the pre-emulated frame count value is low, but that's not tamper-proof at all, and you can't check for the "Reset" button at the start of the input data because it has a different value depending on the game and might require decompressing a large part of the movie to examine. Also, I'm not sure about this but it might be possible to find a savestate that lets you cheat even after resetting after it, which would make detecting a reset not enough.
EDIT: I realize some of those are such low priority that they are more suggestions than requirements.
EDIT2: This wasn't including Blip's modifications, I added notes above for that.
> The file signature ("FB1 ") fails to contain any characters that couldn't be typed into a text editor.
That's not a requirement.
> There's no space for author's info in the movie.
That's a low-priority requirement (which can be ignored if conditions demand so).
> [...] re-rerecord count [...] framerate [...] reset at the start [...]
Those are high-priority requirements.
ShadowByrn, "those" conditions are the ones I linked to from my previous post in this thread (quoted in the post you replied to).
> There's no space for author's info in the movie.
That's a low-priority requirement (which can be ignored if conditions demand so).
Actually there is, You can Write Author's info, when you start movie recording, and it show when you replay movie.
Bisqwit wrote:
> [...] re-rerecord count [...] framerate [...] reset at the start [...]
Those are high-priority requirements.
I think rerecord is available. when you replay a movie file -> It shows the no of rerecord made.
So framerate & record from reset is required.
And off course support of Older to Latest Games Available, and better save state feature like Fceu.
Okay! Now I know. Yeah, the .fr format will give you the length of the movie, the number of records, the author's name/comments. The only two things are like Shakespeare said, the framerate and the record from reset.
Now if the framerate is used to determine length, and the program tells you the length, wouldn't the only thing that's holding this thing back be record from reset/power up?
I am just a silhouette, a silhouette of a memory of a solitary night .. nothing more.
