Posted: 5/4/2006 4:31 AM
Post subject: Nesmock
Quote
Radz
Joined: 12/14/2004
Posts: 261
Location: Mars
I think Nesmock should have a GUI with different editing options, It might be a good idea to add this utility to FCEU as a new Movie Convert Tab. what do you think?
Radz.
Posted: 5/4/2006 6:18 AM
Quote
JXQ
Experienced player (761)
Joined: 5/6/2005
Posts: 3132
NES TAS of 2008 Speedy TAS of 2008 SNES TASer of 2007 TAS of 2007 SNES TAS of 2007 Funny TAS of 2007
I think if FCMs weren't in some goofy compressed format, we wouldn't need Nesmock.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Posted: 5/4/2006 6:43 AM
Quote
Bag_of_Magic_Food
He/Him
Player (206)
Joined: 5/29/2004
Posts: 5712
Heh, Luke was saying in IRC how it's especially dumb that they store a whole uncompressed savestate in the movie file anyway, so you might as well have FCEU read from a zip file if you want compression.
put yourself in my rocketpack if that poochie is one outrageous dude
Posted: 5/4/2006 6:48 AM
Quote
Phil
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
I think the savestate is gzipped.
Posted: 5/4/2006 6:49 AM
Quote
Bisqwit
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
It's not that FCEU movies are compressed anyway. They are event-driven. Each frame, besides joypad input events, any of other events may happen, such as a reset, poweron, a coin insert, a disk change, etc. Encoding all those possibilities without making the stream events variable-length is not quite feasible. Nintendulator, Famtasia and Snes9x don't support that kind of things, and thus, their streams are raw, seekable, indexable. But VirtuaNES does support events, and thus, therefore, VirtuaNES movies are not seekable either. Edit: No, FCM-embedded savestates are not gzipped, just as are not plain file savestates either. SMV -embedded savestates are gzipped, just as are plain file savestates too.
Posted: 5/4/2006 7:00 PM
Quote
Luke
Player (87)
Joined: 2/10/2006
Posts: 113
Location: US
It's not hard to get the best of both worlds. It would just take more memory per frame. For example, have 1 byte each frame recording the special events. Then, that could be followed by the input data for that frame. Even though this is not a very efficient format, if you ran this through zlib, it would compress excellently. And like I mentioned, FCEU has zlib in it already (for reading ROMs), so all the tools are there to have it write savestates and movies in zip format. That's how I would do it, if I were designing the format. (Why I said FCEU's format is compressed: the event-driven format has the advantage of run-length encoding--if you hold the A button down for 20 frames, it only records two events: A on, A off. So for most movies, this saves quite a bit of memory.)
Use the force