2009-05-23, 10:03 PM
I think the way I've decided to organize this for now, is...
Basically there is no reason at this time that the exe files other than som_db.exe and som_rt,exe (I think that's the name) need to run through this proxy ddraw dll.
If I name it ddraw.dll all the exe in the tools directory will try to use it, so I'm going to call i ddbug.dll, and you will need to hexedit your som_db.exe file, and replace DDRAW.dll with DDBUG.dll.
Once you make your runtime game, you will want to copy ddbug.dll into your game.exe folder, and hexedit your <your_game_name>.exe file to replace DDRAW.dll (if the some_db.exe file isn't just copied/renamed)
I think though to avoid confusion, the file name in the final distributed games should be changed to proxy.dll, and you should hexedit in PROXY.dll instead.
PS: Of course it isn't unforeseeable that two versions of the dll might emerge... one with debugging features, and one without (any future extensions will be loaded by the original module via other dll files)
Basically there is no reason at this time that the exe files other than som_db.exe and som_rt,exe (I think that's the name) need to run through this proxy ddraw dll.
If I name it ddraw.dll all the exe in the tools directory will try to use it, so I'm going to call i ddbug.dll, and you will need to hexedit your som_db.exe file, and replace DDRAW.dll with DDBUG.dll.
Once you make your runtime game, you will want to copy ddbug.dll into your game.exe folder, and hexedit your <your_game_name>.exe file to replace DDRAW.dll (if the some_db.exe file isn't just copied/renamed)
I think though to avoid confusion, the file name in the final distributed games should be changed to proxy.dll, and you should hexedit in PROXY.dll instead.
PS: Of course it isn't unforeseeable that two versions of the dll might emerge... one with debugging features, and one without (any future extensions will be loaded by the original module via other dll files)