2011-01-14, 08:43 AM
UPDATE: I have a hard time following your posts ML but still I am not able to tease much that makes sense (to me) out of them non-conventional structure aside. I just wanted to say in my prior post I meant to say decompile/decompilation... not disassemble/disassembly... I'm not sure which you were claiming to have achieved.
I'm kinda getting the impression you were possessed with monkeying with the apps that are not the the som_db.exe/som_rt.exe images. I gotta warn against that if so, because even if you get anywhere that way, it doesn't mean your output will be compatible with the executable files that ultimately have to run the game. You've said INI a few times though, and the only INI file I know of is the one that saves your in game options.
A) Resources hacking is only useful for the editors, and its really only cosmetic stuff. I suggested to John a few times he could really clean up his hexedited translations by using a resource editor. The final game doesn't have any resources.
B) The EXE images do include a field for reserved memory, but the number doesn't really matter, because if the program goes over the reserve more memory will be allocated for it. That might just cause a hickup, so some apps (few) might wanna reserve a fixed amount so they know this hickup will not occur. I have no idea what "video memory" might mean in that context. If it's not just an error message about the video card running low on onboard memory, it may be something GDI related. Like the size of the GDI canvas or something.
C) Yes there are some untranslated messages for the developers which are printed out to a debugger when attached. They are not programming comments as such. Just logs mainly. They are kind of annoying if you have really involved events because they will just flood the debugger like crazy in real-time. I could have them printed out to a console while using SomEx but I don't think there is would be any benefit in that.
I've been using Resedit. You will need something like that with Ex so you can add your game's icon to the launcher... which is generically called som_ex.exe.
You could also add English resources alongside all of the Japanese ones as a way to internationalize the editors. Or as many different languages as people want. It's not a very efficient way to internationalize stuff, but it's the only Microsoft way I know of. It might even be possible to change the charset of the text fields so you could use ANSI fonts/encodings other than 932 (Microsoft Shift_JIS) ... English is a subset of 932 but for other languages that might make a big diff.
Anyway if you don't talk about what you're up to while you're up to it, you kinda cut yourself off from input that might help you out / save you some trouble (I know this kinda stuff can be particularly frustrating)
EDITED: The "video memory" thing, if anything, sounds like a thowback to DOS days / probably part of the DOS header in PE structure. It may even be just the default size of the history in a console app in terms of a character grid.
I'm kinda getting the impression you were possessed with monkeying with the apps that are not the the som_db.exe/som_rt.exe images. I gotta warn against that if so, because even if you get anywhere that way, it doesn't mean your output will be compatible with the executable files that ultimately have to run the game. You've said INI a few times though, and the only INI file I know of is the one that saves your in game options.
A) Resources hacking is only useful for the editors, and its really only cosmetic stuff. I suggested to John a few times he could really clean up his hexedited translations by using a resource editor. The final game doesn't have any resources.
B) The EXE images do include a field for reserved memory, but the number doesn't really matter, because if the program goes over the reserve more memory will be allocated for it. That might just cause a hickup, so some apps (few) might wanna reserve a fixed amount so they know this hickup will not occur. I have no idea what "video memory" might mean in that context. If it's not just an error message about the video card running low on onboard memory, it may be something GDI related. Like the size of the GDI canvas or something.
C) Yes there are some untranslated messages for the developers which are printed out to a debugger when attached. They are not programming comments as such. Just logs mainly. They are kind of annoying if you have really involved events because they will just flood the debugger like crazy in real-time. I could have them printed out to a console while using SomEx but I don't think there is would be any benefit in that.
I've been using Resedit. You will need something like that with Ex so you can add your game's icon to the launcher... which is generically called som_ex.exe.
You could also add English resources alongside all of the Japanese ones as a way to internationalize the editors. Or as many different languages as people want. It's not a very efficient way to internationalize stuff, but it's the only Microsoft way I know of. It might even be possible to change the charset of the text fields so you could use ANSI fonts/encodings other than 932 (Microsoft Shift_JIS) ... English is a subset of 932 but for other languages that might make a big diff.
Anyway if you don't talk about what you're up to while you're up to it, you kinda cut yourself off from input that might help you out / save you some trouble (I know this kinda stuff can be particularly frustrating)
EDITED: The "video memory" thing, if anything, sounds like a thowback to DOS days / probably part of the DOS header in PE structure. It may even be just the default size of the history in a console app in terms of a character grid.