That darn start image
Many thanks! It also seems to avoid the reloading bug. This will be investigated thoroughly.
Also, any information you have on the SLIB compression would be highly valued, you can dump it all here: http://www.shikadi.net/moddingwiki/SLIB_compression
(PS. How did you get that decompressed file from the game's memory?)
Also, any information you have on the SLIB compression would be highly valued, you can dump it all here: http://www.shikadi.net/moddingwiki/SLIB_compression
(PS. How did you get that decompressed file from the game's memory?)
No problem.
I looked and looked but I couldn't not find any information on SLIB. The SLIB decompression functions in keen dreams generate some sort of table.. but yeah there is just too much for me to reverse engineer.
I got the decompressed file from memory by using dosbox debugger to dump the memory right after the file had loaded and was decompressed.
I looked and looked but I couldn't not find any information on SLIB. The SLIB decompression functions in keen dreams generate some sort of table.. but yeah there is just too much for me to reverse engineer.
I got the decompressed file from memory by using dosbox debugger to dump the memory right after the file had loaded and was decompressed.
So you had to push a button really quickly before the program went on to display the image? Could I use it to get the similar files out of Dangerous Dave 3 and 4?
I've found out the function of all those chunks, DeluxePaint makes most of them. According to Mr Hall they used that program to edit a lot of their images and just compressed up the output for the title.
I've found out the function of all those chunks, DeluxePaint makes most of them. According to Mr Hall they used that program to edit a lot of their images and just compressed up the output for the title.
So I've been poking a bit, and I see that LOADSCN.EXE is used to decompress .SHL files. (Specifically when you exit the ending DOS screen is bought up by the executable saying 'LOADSCN LAST.SHL endscn.scn', which suggests that the LOADSCN utility may also have something to do with the start image compression. Can anyone confirm this?
- Malvineous
- Posts: 113
- Joined: Sat Mar 13, 2004 12:54 am
- Location: Brisbane, Australia
- Contact:
Yes, but that's tedious, it takes a long time to load and in theory isn't necessary. If I replaced the file or the data in it with raw EGA data that didn't need to be decompressed or converted it'd make things easier to code and would also save a lot of space in the executable (No need for all that decompression stuff.) for patches, yes?
- Malvineous
- Posts: 113
- Joined: Sat Mar 13, 2004 12:54 am
- Location: Brisbane, Australia
- Contact:
Well I'm not sure I understand what you're trying to do! Instead of replacing the title screen in its current format, you want to write your own image loading routine to patch into the game .exe so that you can load the title screen in a different image format, then remove the decompression code and the old image loading code? But why?
Yes it would save space in the executable (if your replacement image loading routine is efficient) but since the .exe isn't anywhere near a size limit what would all that effort achieve? To me that seems *way* more tedious than running a couple of Softlib commands. If you're looking for more room for patches can't you just use CKPatch to stick your extra code at the end of the .exe file and jump to it as needed? I don't understand why the title screen decompression code is such a problem!
Yes it would save space in the executable (if your replacement image loading routine is efficient) but since the .exe isn't anywhere near a size limit what would all that effort achieve? To me that seems *way* more tedious than running a couple of Softlib commands. If you're looking for more room for patches can't you just use CKPatch to stick your extra code at the end of the .exe file and jump to it as needed? I don't understand why the title screen decompression code is such a problem!
Everything in Keen is EGA data, yes? Therefore there is already code for reading an image made of EGA data, but also code for decompressing that data and converting it. As far as I can tell Keen Dreams does the following with the title screen:
* Identify titlescreen file, confirm it is in fact an SLIB file
* Read the header and use that to copy the compressed data into memory
* Check the compression, none, LZW, LZH; each will have its own decompression code
* Take the decompressed LBM file, convert this to four planes of EGA data that can be displayed
In theory then if we cut out the middleman, we can just replace the start image with EGA data and skip all the steps. This shouldn't take much more than blanking out some calls. We won't need a new image loading routine because the EXE already has all it needs in there.
The end of the EXE I use already for new start screen patches. It is also unsuitable because the game stores some other things there which keep overwriting patches. (I found this out when I put patches at the end of the file then dumped the file and saw all the gibberish that was inserted.)
* Identify titlescreen file, confirm it is in fact an SLIB file
* Read the header and use that to copy the compressed data into memory
* Check the compression, none, LZW, LZH; each will have its own decompression code
* Take the decompressed LBM file, convert this to four planes of EGA data that can be displayed
In theory then if we cut out the middleman, we can just replace the start image with EGA data and skip all the steps. This shouldn't take much more than blanking out some calls. We won't need a new image loading routine because the EXE already has all it needs in there.
The end of the EXE I use already for new start screen patches. It is also unsuitable because the game stores some other things there which keep overwriting patches. (I found this out when I put patches at the end of the file then dumped the file and saw all the gibberish that was inserted.)
- Malvineous
- Posts: 113
- Joined: Sat Mar 13, 2004 12:54 am
- Location: Brisbane, Australia
- Contact:
Well as you've indicated in your steps, there is no step for "copy EGA data into video memory" so you'd have to write your own image loader routine to replace the LBM one. I don't know what format the LBM file is in, but if it's EGA format already (suitable for direct copying into video memory) you might not gain much by writing your own loader. Just using an uncompressed LBM might be enough.
I still think there are probably better ways to get more memory for patching. Presumably the memory directly after the .exe is used for the heap. What happens if you enlarge the code section in the .exe file? Does that move the heap further out in memory, giving you some more empty space to put patch code into? Or is it too late to patch things like that using CKPatch?
I still think there are probably better ways to get more memory for patching. Presumably the memory directly after the .exe is used for the heap. What happens if you enlarge the code section in the .exe file? Does that move the heap further out in memory, giving you some more empty space to put patch code into? Or is it too late to patch things like that using CKPatch?
- Malvineous
- Posts: 113
- Joined: Sat Mar 13, 2004 12:54 am
- Location: Brisbane, Australia
- Contact:
- Malvineous
- Posts: 113
- Joined: Sat Mar 13, 2004 12:54 am
- Location: Brisbane, Australia
- Contact:
I'm afraid I've never looked in enough detail to know how standard it is. The common standard is that .exe files have relocation tables which I think are used to patch memory references, but then on top of this compilers produce .exe files with multiple sections - typically one for code, one for data, etc. This is why all the text messages are usually in one block towards the end of the file. If you could specify that the data section was loaded into a different memory location (instead of directly after the code) then that would leave the space directly after the code unused, and you could place whatever you like there without fear of overwriting something.
If you wanted to do this though, you would have to alter the .exe before it gets loaded - i.e. patching with CKPatch would be too late, by that time the data is already in memory at the final location. But you might be able to modify CKPatch to put the sections elsewhere while it is loading the .exe, depending on how it does so (i.e. if it loads the .exe sections itself it should be relatively easy, but if it uses DOS to do the load it would be more difficult.)
If you wanted to do this though, you would have to alter the .exe before it gets loaded - i.e. patching with CKPatch would be too late, by that time the data is already in memory at the final location. But you might be able to modify CKPatch to put the sections elsewhere while it is loading the .exe, depending on how it does so (i.e. if it loads the .exe sections itself it should be relatively easy, but if it uses DOS to do the load it would be more difficult.)