That darn start image

Request patches for Keen Dreams.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

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?)
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

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.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

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.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

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?
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Taking another tack entirely, is it possible to skip all the compression completely and just replace the start image data with raw EGA data? I assume that would free up considerable space in the executable for adding stuff like music playing code and patches.
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Post by Malvineous »

What are you trying to achieve? If you want to replace the start screen, can't you just create a new LBM file and compress it with Softlib?
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

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?
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Post by Malvineous »

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!
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

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.)
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Post by Malvineous »

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?
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

I don't know what that last paragraph means, but I can make CKPatch patch data past the end of the executable file. (With as I have noted, some problems.)

I guess you're right, using an uncompressed ILBM will probably skip a lot of code.
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Post by Malvineous »

By the last paragraph I meant that the .exe file's header should indicate how much memory is required to store all the code. If you enlarge that number it should give you more space after the end of the .exe (in memory) to patch into, without encountering those problems.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Okay, now I'm very, very curious. Is this a standard feature of EXEs? Where is it located in the header?
User avatar
Malvineous
Posts: 113
Joined: Sat Mar 13, 2004 12:54 am
Location: Brisbane, Australia
Contact:

Post by Malvineous »

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.)
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Well I think I'll stick with skipping the compression stuff, it sounds easier.
Post Reply