Locked



Post subject: On Hex Editting:
Player (36)
Joined: 9/11/2004
Posts: 2630
From what I gather from reading the source each frame is represented in 16-bits (assuming you have one controller). One for button pressed down, zero for not. But I haven't been able to figure out which buttons are which. And if it's done like this you have 4 bits left over for each. Are they used for anything, or even checked? (Heh, I could write secret messages in my .smvs. ^o^)
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Former player
Joined: 3/30/2004
Posts: 1354
Location: Heather's imagination
someone is out there who will like you. take off your mask so they can find you faster. I support the new Nekketsu Kouha Kunio-kun.
Player (36)
Joined: 9/11/2004
Posts: 2630
I've already read that.
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Player (36)
Joined: 9/11/2004
Posts: 2630
I've gotten this from experimenting. But I'm not 100% sure about the offset. The ones that are XX00 could be 00XX for all I know. But this way made more since in my test file so: 0001 = Right 0002 = Left 0004 = Down 0008 = Up 0010 = Start 0020 = Select 0040 = Y 0080 = B 1000 = R 2000 = L 4000 = X 8000 = A
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Former player
Joined: 3/19/2004
Posts: 710
Location: USA
They probably are used for something else. Two bytes is just an arbritrary number. If some bits were empty, they would have used less than two bytes. FCM files record more than just key presses. And even if some are empty, I wouldn't mess with them in case they do get implemented one day. Oh, and I don't think it's practical to actuallty edit the key presses. The only think that you should really be doing is cutting and pasting. It'll be way to hard to try and edit stuff like that.
Editor, Reviewer, Experienced player (979)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
>They probably are used for something else. Two bytes is just an arbritrary number. Probably not. Two bytes is not arbitrary, it is the smallest number of bytes required to describe 12 binary variables (buttons). Whole bytes are used for a number of good reasons. >If some bits were empty, they would have used less than two bytes. Highly impractical and not worth the time to implement it. You sacrifice easy coding and editing of the SMV files just for 4 measly bits per frame. It's not like we're running out of diskspace from SMV files. :P
Former player
Joined: 3/19/2004
Posts: 710
Location: USA
Yes, I realize that two bytes is two bytes, but I still don't think it should matter. If you are dealing with them bit by bit, how they are grouped should not matter. And I'll take what disk space I can get >_>
Player (36)
Joined: 9/11/2004
Posts: 2630
Bob Whoops wrote:
Oh, and I don't think it's practical to actuallty edit the key presses. The only think that you should really be doing is cutting and pasting. It'll be way to hard to try and edit stuff like that.
It's a good way to add or delete a frame or to add or subtract a button press from the frame after the fact. And the game I'm working on has no randomness whatsoever. Which is refreshing because SM:RPG gave me a headache. I'm tacking Uniracer's right now. Much easier.
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Former player
Joined: 3/30/2004
Posts: 1354
Location: Heather's imagination
Bob Whoops wrote:
And I'll take what disk space I can get >_>
SO.. turn on disk compression. These files are extrememly compressable as they tend to have repetitive patterns.
someone is out there who will like you. take off your mask so they can find you faster. I support the new Nekketsu Kouha Kunio-kun.
Editor, Reviewer, Experienced player (979)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
Maybe it's because you think you can read/write data bit by bit? There is no such thing as a bit reader. The smallest possible value you can read from disk is one byte. It would matter for example when reading for next frame's input. You can simply "read two bytes and move values to buttons" instead of "calculate how many bytes we need to read and which bytes are where and transfer right bytes to right button and then maybe seek one byte backwards". Also rewinding can be done by "seek(framenumber + offset)" instead of "seek(some horribly complicated formula) then read the bits pertaining to previous frame and preserve them for next write operation if you have overlap" sort of thing. All from a relative layman... I haven't even looked at the code, only the specs. You have so little diskspace that it matters wether you save 25% from a 350kb file? Get a bigger harddrive or delete some pr0n. ;)
Player (36)
Joined: 9/11/2004
Posts: 2630
Bob, you can only grab info a byte at a time. It is then broken into the bits. You could break up as 2 frames every 3 bytes. But that's not the simplest way to code it. And keeping the code readable and quick is paramont, especially over 4 bits a frame.
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Former player
Joined: 3/19/2004
Posts: 710
Location: USA
I wasn't serious about being worried about my disk space. Though that pr0n idea sounds good. >_> Or remove the empty bits from the pr0n files :) (yes, I know there are none) Yes, I realize that, but I still don't think it would be that hard. But it doesn't matter. We can settle this (or not) once we find out whether this is even relevent or not.

Locked