Post subject: What about trying to add the "easier hex-editing tool&q
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
http://tasvideos.org/forum/viewtopic.php?t=2607&postdays=0&postorder=asc&start=0 As discussed here. I think it'd be even more usefull on n64 movie recording than on gens. Yes i know it's hard and nitsuja has already done a LOT of work on many emulators, but can it be considered? it would be really usefull...
Joined: 11/16/2005
Posts: 46
I'll take a look at it. At the very least I'll made a viewer.
Emulator Coder, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
The M64 format is simple enough that it shouldn't be hard to modify that external viewer/editor to handle it. Getting support in the emulator like that screenshot in the other thread is another matter, though (not that you said it isn't). And it wouldn't work nearly as well as it could in other emulators because it takes so long to emulate that many save states will need to be made for random access, but save states are huge and also take a long time to save/load. Maybe that's not a reason to not do it at all, but it seems like enough of a reason to try it in a different emulator first. Also, I didn't think an editor (or hex editing) would be very useful at all for N64 movies, but maybe games like Mario 64 are predictable enough that a redone level could be spliced into the input without disrupting later levels very much. And an interesting consequence of the way the input is stored is that extra frames of lag will not screw up the synchronization as it does for other emulators (because input isn't even recorded or played back on lag frames).
Joined: 11/16/2005
Posts: 46
Since you only record input when N64 reads the controller, why can't you output the frame number as well? For frames that don't use input, just don't record them at all... Would this solve the problem of not being able to calculate the movie length using the input, and wouldn't it also make an external hex editor more useful?
Active player (278)
Joined: 5/29/2004
Posts: 5712
What, record how many real frames have passed for each input frame? Wouldn't that make the file a lot bigger? You'd be adding some number of bytes per frame, and you don't know how large it could get, so you might not know the maximum number of bytes you need per frame in advance. That may be a problem.
put yourself in my rocketpack if that poochie is one outrageous dude
Joined: 11/16/2005
Posts: 46
Well, right now it uses 4 bytes per input. We just need about 2 bytes to record the frame number. 2 bytes can represent a frame for a movie 18 hours long at 60 frames/second. So we would increase the movie size by about 150% Considering that movies are highly compressable and are not that long right now (in the magitudes of kilobytes right now), it wouldn't be bad to increase movie sizes by 150%
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Ok, making it short, you want to store, for each frame, a 2 bytes long frame number? that is uncessessary because the movie already stores that info. It's the position each 4-byte is. That is the frame number.
Emulator Coder, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
Ok, making it short, you want to store, for each frame, a 2 bytes long frame number? that is uncessessary because the movie already stores that info. It's the position each 4-byte is. That is the frame number.
No, it's not. But you don't really need to know the frame number, only the number of input samples. The frame number isn't used for anything anyway. As for multiple controllers, I think it's actually pretty safe to assume that the N64 reads all of the active controllers in a row (in increasing order) (despite what I may have said about that before).
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
well it is, if you subtract the header. or something. that's what i meant. you can easily get the frame number from any frame position in the movie format we have now, just by checking the byte position and doing the right calculation. right?
Joined: 11/16/2005
Posts: 46
Not from what I understand. N64 doesn't read input for every frame, therefore input isn't recorded in the movie for every frame. Input is recorded in a movie only when N64 reads input. Therefore there may be frame in between input where N64 doesn't read input.
Active player (278)
Joined: 5/29/2004
Posts: 5712
Do you really need to know realtime frames, though?
put yourself in my rocketpack if that poochie is one outrageous dude
Emulator Coder, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Yeah, I don't see why a tool designed to view or edit the input needs to know how many no-input frames pass by.
Joined: 11/16/2005
Posts: 46
You might be able to deduce when what input is happending, but that requires intimate knowledge of what the movie/player is done at what point. I am not saying that you don't need knowledge of what the player is doing if you knew the frame number, but I am just saying it would make things a lot easier for somebody trying to edit a movie to know, "Oh, so then I didn't input anything for this long" Unless I am mis-understanding something, you can't figure out how many frames has passed between inputs unless you emulate the rom, or had the frame number.
Emulator Coder, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Oh, well I assumed anybody trying to edit their movie would already know what input sample count range they're interested in from looking at the in-emulator counter. It sounds like it could be useful from what you're saying, but I don't want a change to make the movie files more difficult to hex edit normally, and I don't want to store any extra data per input sample. It's probably impossible to avoid both of those at the same time, though, and I'm not sure which one is worse. EDIT: On second thought, the best and most straightforward way to implement this would be to simply record dummy/duplicate input samples for every no-input frame.
Active player (278)
Joined: 5/29/2004
Posts: 5712
Aw, but then it'll be just like all the other emulator movies...
put yourself in my rocketpack if that poochie is one outrageous dude
Joined: 11/16/2005
Posts: 46
Ah yes, it would be harder for somebody to manually hex edit if he had to worry about a frame field... Thus, dummy records would be best solution for all (expect it takes the most space, but as I said before, space is a non-issue at the moment.)
Active player (278)
Joined: 5/29/2004
Posts: 5712
No, space is a big issue! I still don't get the point of knowing when the non-input frames happen.
put yourself in my rocketpack if that poochie is one outrageous dude