I've got some ideas ...

CKPatch is a set of patching tools for all Keen episodes.
Post Reply
User avatar
ckguy
Posts: 465
Joined: Tue Oct 14, 2003 11:20 am
Location: Wakefield, RI, US
Contact:

I've got some ideas ...

Post by ckguy »

I've got some ideas for the next CKPatch version ... anyone know hat I should do?

Some of the ideas are ...
  1. Built-in tileinfo resource patching (eg, %tileinfo filename)
  2. Commands for dumping egahead, egadict, etc. (that is, you don't need to remember to locations in the executable to dump them)
  3. Um ... more to come ...
KeenRush
Patch Maker
Posts: 1988
Joined: Sun Aug 31, 2003 2:52 pm
Location: Sand Yego
Contact:

Post by KeenRush »

Well, the sources are available.. ;) You could try to add those features, if you can. :)
User avatar
ckguy
Posts: 465
Joined: Tue Oct 14, 2003 11:20 am
Location: Wakefield, RI, US
Contact:

Post by ckguy »

Hmmm, weren't they written in Pascal? I have zero knowledge of that language.
Admiral_Bob
Posts: 7
Joined: Thu Mar 25, 2004 5:58 pm
Location: Melbourne, Australia

Post by Admiral_Bob »

Sorry about late reply, I've only just gotten around to registering an account on this board! :)
Built-in tileinfo resource patching (eg, %tileinfo filename)
That'd be rather easy to add. You'd need to add the tileinfo offset to each of the CXnPATCH.PAS source files, and make the parser recognise the %tileinfo command (look at CKXPATCH.INC source file around where %egahead, etc are handled). The comments in the source should make it apparent what goes where.

You also need to determine the length of the tileinfo resource in each Keen executable as well, since I added a safety check feature in CKPatch 0.9.0 to prevent oversized files from overwriting neighbouring resources.
Commands for dumping egahead, egadict, etc. (that is, you don't need to remember to locations in the executable to dump them)
This is similar to the above, just make the parser recognise the new syntax additions (look at CKXPATCH.INC). The resource offsets & lengths are all stored in the CXnPATCH.PAS source files, if you need to know them.
Hmmm, weren't they written in Pascal? I have zero knowledge of that language.
CKPatch is written in Turbo Pascal because it's the only DOS 16-bit real mode compiler that I've got on me.

I can't use DJGPP or any other 32-bit protected mode compiler, because the DOS extender takes away too much conventional memory, preventing the game from running.

Pascal, once you learn it, is much like a "friendlier C". It's still a procedural language, but there are subtle differences in syntax, and certain operations like set logic and string handling are built into the language; it's slightly more higher-level than C.

While adding more features is nice, you have to remember that CKPatch has to have a minimal memory footprint because it has to remain resident while the game runs; this is due to the way DOS likes to allocate memory. If you make the CKPatch executable bigger, by adding more features, then it might break CKPatch for some end users because they won't be able to free up the required conventional memory.

CKPatch already requires about 20kB of overhead. This means that you need 540kB free conventional memory to run Keen 1-3, and 580kB free conventional memory to run Keen 4-6. I'm planning not to increase this overhead any further; so far the current overhead seems to be trouble-free for majority of CKPatch users out there.

Turbo Pascal however adds some bulk overhead for each executable it generates, usually around 2-3kB for the run-time library. Each procedure that calls a function that returns a string also allocates 256 bytes of extra stack space, because of TP's calling conventions. I did some extensive profiling while I was working on CKPatch 0.9.0, and consequently was able to add the new features with only a minimal increase in memory footprint.

If someone was able to rewrite CKPatch in C or pure assembler, then these overheads would dissappear, so you'd get a more compact executable, allowing more room for improvements. However the main setbacks are that I can't seem to find any decent freely available DOS 16-bit C compilers, and writing CKPatch in 100% pure assembler would make code maintenace much more difficult. I hardly have enough free time as it is, getting caught up with uni and all! :)

In conclusion, you're more than welcome to make your own changes to CKPatch, since I've released the source code via GPL. However keep the memory footprint issue, discussed above, in mind. If you make some useful changes, you might like to email them to me and I'll include them for the next release of CKPatch (with appropiate credit).
User avatar
ckguy
Posts: 465
Joined: Tue Oct 14, 2003 11:20 am
Location: Wakefield, RI, US
Contact:

Separate parser

Post by ckguy »

How's this sound to you?

There is one program which parses the .pat file, and outputs this in some sort of tokenized thingy (one byte for each command). This would make the main EXE smaller, because it just needs to load the tokenized thingy, instead of parsing the patch file.

There wouldn't have to be many different tokenized commands - maybe just two: patch these bytes, and patch from file, and a single byte at the beginning of the file saying what episode this is for. Maybe you could even get rid of the patch from file command, by have the parser stick the contents of the file in at that point.

Is this feasible? Would it help? How much of the EXE size is the parser?

-- format of compiled PAT file, assuming no %patchfile command --

episode number (byte)
-- repeat from here ... --
start patching location (4 bytes)
number of bytes to patch (2 byytes)
actual bytes to patch (?? bytes)
-- ... to here --
Post Reply