Author
|
Topic: Hex editor problem (Read 1 times)
|
Mauron
Guest
|
 |
« on: March 18, 2010, 03:57:52 pm » |
|
So far I've tried Translhextion and WindHex, and they both have the same problem - multibyte characters split over two lines aren't read as the same character.
For example, in Breath of Fire, 03 signifies a Huffman compressed character, so while D7 is "W", 03D7 is "need". Both editors I mentioned say a line starts with "W".
Does anyone know of an editor without this problem?
|
|
|
|
|
Vegetaman
Guest
|
|
« Reply #1 on: March 18, 2010, 07:52:05 pm » |
|
I would assume that most hex editors aren't smart enough to decipher huffman encoded text files on the fly. That'd be... A pretty complex editor. I mean, you'd have to give 'em the tree, and everything. I'm not sure of any that offer what you ask, TBQH.
Maybe you can fix it with tables? I don't really know, as I hardly ever use them. But a hex editor on it's own would have no reason to think that 03d7 is need when it would expect 4e454544 to be need.
I mean, in Lufia I, certain things like 0c or 0d call dictionary functions. But I'm on my own to figure out what word 0c84 points to.
|
|
|
|
|
UglyJoe
Guest
|
|
« Reply #2 on: March 18, 2010, 08:33:32 pm » |
|
I think what the OP is saying is that a multibyte entry in a table, when split over two lines, won't be properly displayed in the hex editor.
|
|
|
|
|
Mauron
Guest
|
|
« Reply #3 on: March 18, 2010, 09:24:22 pm » |
|
Sorry if I wasn't clear. What UglyJoe said is correct.
My table file has 03D7=need, but it doesn't display properly if split over two lines in the editors I mentioned.
|
|
|
|
|
Bongo`
Guest
|
|
« Reply #4 on: March 18, 2010, 11:18:40 pm » |
|
Sorry if I wasn't clear. What UglyJoe said is correct.
My table file has 03D7=need, but it doesn't display properly if split over two lines in the editors I mentioned.
Sorry that you are having problems with that. The reason this is happening is because the program buffers the data in blocks of 16 or whatever width the editor is currently set to. So if you have... 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E D7
03 FE 23 A3 CD C4 B1 23 A3 CD C4 B1 23 A3 CD C4
then the last byte ( $D7 ) is read and then the "End of buffer" test is done. So it sees the end of the buffer and decides to display the data for $D7only.  |
|
|
|
|
Vegetaman
Guest
|
|
« Reply #5 on: March 19, 2010, 12:20:45 am » |
|
Ohhh, I get it. My bad. :beer:
|
|
|
|
|
Mauron
Guest
|
|
« Reply #6 on: March 19, 2010, 01:14:20 am » |
|
Sorry that you are having problems with that. The reason this is happening is because the program buffers the data in blocks of 16 or whatever width the editor is currently set to. So if you have... 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E D7
03 FE 23 A3 CD C4 B1 23 A3 CD C4 B1 23 A3 CD C4
then the last byte ( $D7 ) is read and then the "End of buffer" test is done. So it sees the end of the buffer and decides to display the data for $D7only. That explains the problem, but is there a way to avoid it?  If not, it isn't a big deal, as the game is mostly single byte. Every few lines I might hit the problem, but I can always check my table file manually if need be. |
|
|
|
|
danke
Guest
|
|
« Reply #7 on: March 19, 2010, 01:27:34 am » |
|
In Windhex, Ctrl + Left/Right will increase/decrease rows, showing those bytes.
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #8 on: March 19, 2010, 08:51:26 am » |
|
I once spoke to Maël about implementing table support in HxD. This is actually pretty complicated to implement 100% gracefully. It causes quite a few obstacles in a hex editor design. Forget ROM hacking tables for a moment, but can any hex editor properly display multi-byte to multi-characters spanning across lines properly like that with any encoding? I'd image not many, if any exist. You could have some big problems with display and alignment if you had things in your table like: 1A2CED=reallylongtextthatwillscrewupthislinewhendisplayedinahexeditorastext Something like that spanned across a line boundary would definitely look unruly in any hex editor even if it were somehow supported. That's an extreme example, but still demonstrates some of the issue. |
|
|
|
|
Bongo`
Guest
|
|
« Reply #9 on: March 19, 2010, 09:55:36 am » |
|
I once spoke to Maël about implementing table support in HxD. This is actually pretty complicated to implement 100% gracefully. It causes quite a few obstacles in a hex editor design. That's a nice looking editor. If that person added table support that would rock. I wonder why it has not been supported yet. Table support ( basic ) is probably one of the easier parts to implement. I say give'em another nudge and see what happens.  |
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #10 on: March 19, 2010, 12:11:10 pm » |
|
You shouldn't be doing much work in a Hex Editor. Most the time they should really only be needed to get a quick idea of what is at a location. Inserting text via a hex editor like Thingy is an ancient technique and one that will really screw things up in the long run.
|
|
|
|
|
Mauron
Guest
|
|
« Reply #11 on: March 19, 2010, 01:06:40 pm » |
|
Inserting text via a hex editor like Thingy is an ancient technique and one that will really screw things up in the long run.
I wasn't planning on it; in fact I want to do something quite the opposite. I was just hoping to make reading the text a little easier at the moment. |
|
|
|
|
Tauwasser
Guest
|
|
« Reply #12 on: March 20, 2010, 02:10:46 am » |
|
Inserting text via a hex editor like Thingy is an ancient technique and one that will really screw things up in the long run.
I call bullshit. You don't really build a dumper/inserter for every itsy bitsy table in the rom, do you? If you know what you're doing, thingy is awesome. This will obviously not work for big text blocks, but for text here and there, it's adequate. cYa, Tauwasser |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #13 on: March 20, 2010, 01:13:35 pm » |
|
Can't you just say something like 'I disagree and have an alternate opinion' instead of umm.. 'calling bullshit'. Something just not quite wired the same as everybody else in that head of yours. For small bits of data or text, this can be done via your project build file and/or assembly file. More modern methods of ROM hacking involve assembling or building your project rather than hex editing directly so you can manage all changes and build a full fresh project every time. I think that's the kind of thing he was getting at rather than editing bytes in a hex editor forgetting what was done, how it was done etc. Quick excerpts example using xkas with text and data. org $d80000
itemdescriptions:
\tincbin itemdescriptions.bin\t;Item descriptions
mainmenustruct:
\tdb $03,$01,$01,$01,$01,$01,$00,$01,$01,$01,$01,$01,$01,$FF
\tdb $01,$01,$01,$01,$01,$00,$01,$01,$01,$01,$01,$FF
\tdb $01,$01,$01,$01,$00,$00,$01,$01,$01,$01,$FF
table tenshie.tbl,rtl\t
org $c098c9\t;Menu character Names (Used for BOTH 8x16 menu display AND 12x16 general!! Plenty of space for English. (10 characters)
\tdb 'Rayard',$00,$00
org $c098d5
\tdb 'Callana',$00,$00
org $c098e1
\tdb 'Leon',$00,$00
No hex editing done at all for all kinds of misc. or small things. It's basically project management. |
|
|
|
|
Mauron
Guest
|
|
« Reply #14 on: March 20, 2010, 01:26:52 pm » |
|
Nightcrawler, that snippet was very helpful. Thanks. |
|
|
|
|
|
RHDN Forum Archive
