2009-11-12, 08:44 AM
If you "remove" something just be sure you adjust every offset byte in the file to account for the difference. It doesn't make sense really to operate on the file. It's easier to think in terms of of translating a file into an all new file, or rewriting the file in other words.
If you understand how the file works there should be no need to test it in any rigorous way. Either way, believe me you will know immediately if you messed something up when you try to use the file in any realistic way. SOM is very finicky. If you don't fully understand every single piece of relevant information in your file then you need to do more tests until you do.
Here btw is the encoding for the text message instructions. I don't have any plans to do anything in the dept. you appear to be interested in. I will need the encoding for the other instructions however when I remake SOM. So I hope you document everything and share with the community along your way.
16bit opcode
16bit offset (including opcode/offset bytes)
....? ?? info
^That is presumably the pattern for every instruction. The offset is a pure number. I'm assuming the opcode itself includes all 16bits and is always the same per each type of operation/instruction.
0000=message (1 string)
0001=message2 (r/g/b/0/size/size/0/0/string/font)
008D=IF(choice) = (3 strings)
008F=ENDIF
^Above are the opcodes for these 4 instructions, and the byte layout (I did not concern myself with ENDIF)
size/size is a 16bit number 0~900 for the size of the font (whatever that means) and 'font' is a string... 0 might not always be zero.
These are just my notes. There's probably a clearer way to write this up.
PS: I haven't really looked into the records. Off the top of my head there is a 30 byte name. 60 bytes in there is the first of 16 32bit stage offsets. Then every 96bits there is another (in other words there are 64bits sandwiched between each offset)
If you understand how the file works there should be no need to test it in any rigorous way. Either way, believe me you will know immediately if you messed something up when you try to use the file in any realistic way. SOM is very finicky. If you don't fully understand every single piece of relevant information in your file then you need to do more tests until you do.
Here btw is the encoding for the text message instructions. I don't have any plans to do anything in the dept. you appear to be interested in. I will need the encoding for the other instructions however when I remake SOM. So I hope you document everything and share with the community along your way.
16bit opcode
16bit offset (including opcode/offset bytes)
....? ?? info
^That is presumably the pattern for every instruction. The offset is a pure number. I'm assuming the opcode itself includes all 16bits and is always the same per each type of operation/instruction.
0000=message (1 string)
0001=message2 (r/g/b/0/size/size/0/0/string/font)
008D=IF(choice) = (3 strings)
008F=ENDIF
^Above are the opcodes for these 4 instructions, and the byte layout (I did not concern myself with ENDIF)
size/size is a 16bit number 0~900 for the size of the font (whatever that means) and 'font' is a string... 0 might not always be zero.
These are just my notes. There's probably a clearer way to write this up.
PS: I haven't really looked into the records. Off the top of my head there is a 30 byte name. 60 bytes in there is the first of 16 32bit stage offsets. Then every 96bits there is another (in other words there are 64bits sandwiched between each offset)