Post subject: Tools for easier hex editing?
Player (70)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
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.
Editor, Reviewer, Experienced player (968)
Joined: 4/17/2004
Posts: 3107
Location: Sweden
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.
Player (70)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
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?
Joined: 4/26/2004
Posts: 213
Location: Montréal, Québec
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
Joined: 2/14/2005
Posts: 10
Location: Sweden
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.
!ERAU QSSI DLRO WEHT
Editor, Reviewer, Experienced player (968)
Joined: 4/17/2004
Posts: 3107
Location: Sweden
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.
Joined: 4/26/2004
Posts: 213
Location: Montréal, Québec
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)
Editor, Reviewer, Experienced player (968)
Joined: 4/17/2004
Posts: 3107
Location: Sweden
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?
Joined: 2/14/2005
Posts: 10
Location: Sweden
!ERAU QSSI DLRO WEHT
Joined: 4/26/2004
Posts: 213
Location: Montréal, Québec
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)
Joined: 7/28/2005
Posts: 13
Location: UNCA, North Carolina, US
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!
Joined: 7/28/2005
Posts: 13
Location: UNCA, North Carolina, US
Told ya it was simple. Gotta add saving and fix some bugs with loading certain GMV files, and I'll release it.
Player (70)
Joined: 8/24/2004
Posts: 2562
Location: Sweden
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
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
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)
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
I like that idea... Only flaw is that the save states aren't neccesarily related.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Well yea of course, if you re-record a frame, then all the savestates after it are instantly deleted.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
That depends on how rerecording is implemented in the emulator, not all are like that. Snes9x for example treats each rerecord save state independantly.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
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?
Active player (410)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
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.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
FODA wrote:
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?
Yes that's true. But you can have state 2 and state 3 being two branches of state 1. Just because state 2 has a higher frame count than state 3 doesn't meant you want it deleted when editing state 3 branch. Also showing state 2 info while editing state 3 branch or vica versa is illogical.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I'm not talking into branches. If its higher, delete it, i'm talking about normal, single branch movie recording.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Well yes sure, but this still would have to take branches into account, and I know people like Phil make good use of them.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I dont doubt the usefullness of branches, but it shouldnt be a reason to not make the tool, imo, if it's too complicated.
Player (36)
Joined: 9/11/2004
Posts: 2623
Or instead you could just make every savestate an entire movie file, instead of using branches. It's simpler if more hackish.
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
nesrocks
He/Him
Player (241)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
That would be unpractical, as loading a savestate would mean having to re-emulate the whole game from frame 0 to current frame..