TASVideos discussion board

[Highness]

I was wondering if there is a program already or if someone easily could make a program that allows easier hexediting?

I was thinking of a very user friendly program that perhaps converts a certein hex value into an arrow to show wether I pressed left or right or a better value saying I pressed A, B or C etc and at what frame etc I did so.

Some sort of GMV editor for us that doesn't understand hex editing. I mean.. FF DS FF FF FE DE doesn't say me much at all. And I'm kind of often in need of hex editing. So I always have to ask someon about it as I still haven't found a good giude that explains what all those values equals on a genesis controller.

Please help me out here.

[Truncated]

I don't remember which bits represent which buttons, but it should be easy to check.

In any case it's something that should go on the GMV.html page when it's done.

One thing I seem to remember is that the bit is 1 when not pressed, and 0 when pressed.

[Highness]

Ok. That answer didn't help me much at all. But I hope I can dra others attention this way to help us all out by creating a GMV tool for easy editing.

These tools would be great to have in the program:

* Frame number
* Pressed button as well as for how long it's pressed and then release.

This might be hardcore but anyways:

* Possibility to load the rom and GMV, and perhaps the use of savestates to easy correct problems?

[Jyzero]

If someone try to create such tool, it could work not only for GMV but for SMV, FCM, name it.

They all have similar structure : 1 bit per button

[Laban]

If someone could post more details on how all this works I would be able to cook something up with PHP. I PM:ed Genisto and asked for his easy_bytes_modifier.php to see if there's something to improve or change.

[Truncated]

Well, you could start with http://tasvideos.org/GMV.html if you haven't seen it already. Which bits = which buttons is not listed, but it should be very easy to check. Just record a test file pressing every button for a couple of frames in an order that you write down. Note that 1 = not pressed and 0 = pressed.

[Jyzero]

3 bytes per frame

byte 1: lowest bit to highest bit

Up
Down
Left
Right
A
B
C
Start

byte 2 : same order as byte 1 but for controller 2

byte 3 :

X
Y
Z
Mode
for player 1 then
X
Y
Z
Mode
for player 2

(or same order as byte 1for player 3 data if 3 player movie)

[Truncated]

Put it where it was supposed to be (GMV.html).

If you can you tell me how the header changed to incorporate 3-player functionality, I'll add that too.

EDIT: just for clarification, by lowest bit, you mean least significant, right?

[Laban]

Can this help anyone?
http://133an.sytes.net/~laban/gens/gens.php

[Jyzero]

Yes by lowest I mean least significant

byte 0x0F is GMV file format version. The most recent is 'A'

Byte 0x14 is controller config for player 1 : ascii 3 for 3 buttons and 6 for 6 buttons

Byte 0x15 is the same but for player 2

Byte 0x16 has some special flags (Version A and up only):

bit 7 (the most significant) is Frame per second (1 for 50 Hz, 0 for 60Hz)
bit 6 is savestate required (1= savestate required)
bit 5 is 3 player movie (1 = 3 players, 0 = 2 players)

[Travis Wells]

Hmm. The format isn't that complex, it wouldn't be hard to write a simple .GMV editor (no hex editing required, just clicky buttons)

I'll look into it!

[Travis Wells]

Told ya it was simple.

Gotta add saving and fix some bugs with loading certain GMV files, and I'll release it.

[Highness]

Weee!!

I'm so happy this thread spawned something useful!

Thanks to Laban who helped alot in this on request.
Thanks to Jyzero who explained everything in detail.
Thanks to Truncated for helping as well.
And thanks to Travis Wells for making an editor.

This is my 1000th post BTW! :D

[nesrocks]

incredible. but i've thought of something even nicer, but that would be up to someone who can change the emulator:



see, you can slide the timeline to whatever frame you want, and the game will be emulated based on the last savestate to that frame, and the buttons combinations that are set on the table bellow. you could just drag the mouse and go "painting" buttons presses as you wish. this would be the perfect tool, for me.
notice the savestate indications, it shows which frames have a savestate and which savestate number it is.

(a savestate slot would have to be reserved for saving every 30 frames or so, so that the emulator don't have to calculate a too big range of frames at once)

[Nach]

I like that idea...

Only flaw is that the save states aren't neccesarily related.

[nesrocks]

Well yea of course, if you re-record a frame, then all the savestates after it are instantly deleted.

[Nach]

That depends on how rerecording is implemented in the emulator, not all are like that. Snes9x for example treats each rerecord save state independantly.

[nesrocks]

Cant the emu just read which frame number the savestate has and delete it if its bigger than current frame, being unimportant if the movie state belongs to the movie or not?

Anyway, that is the same flaw that all current emulators have, so i dont see the point. The movie would just be out of sync past that point, you mean if someone load a wrong savestate or something?

[Phil]

Well, there may be this editor option and when used, it plays the movie once and makes temp savestates for each 1000 frames or something like that.

[Nach]

FODA wrote:

[nesrocks]

I'm not talking into branches. If its higher, delete it, i'm talking about normal, single branch movie recording.

[Nach]

Well yes sure, but this still would have to take branches into account, and I know people like Phil make good use of them.

[nesrocks]

I dont doubt the usefullness of branches, but it shouldnt be a reason to not make the tool, imo, if it's too complicated.

[OmnipotentEntity]

Or instead you could just make every savestate an entire movie file, instead of using branches. It's simpler if more hackish.

[nesrocks]

That would be unpractical, as loading a savestate would mean having to re-emulate the whole game from frame 0 to current frame..