EModKeen 3 thread
- Shadow Master
- Posts: 129
- Joined: Fri Oct 20, 2006 3:14 pm
- Location: Santiago, Chile
- Contact:
EModKeen 3 thread
I decided to start a new thread in order to clarify the difference between LModKeen/EModKeen 2.x development and EModKeen 3 development.
I've uploaded the source code (NOTE: no binaries) for the latest Alpha tree. Thanks grafix for hosting. This version is EModKeen 3 alpha 2, it features a brand-new directory tree and C++ ports of huff.c and pconio.c (now it's Multicon.cpp, my own console functions wrapper library for Win32 and ncurses).
You MUST NOT try to compile it. It simply won't. Believe me, it's intentionally broken, because I haven't had time to fulfill some parts of the new code structure, etc.
Most notably, I separated all the game data routines to approximately 6 files.
The latest source code can be downloaded here: http://shadowm.rewound.net/src/emodkeen ... en3.tar.gz
Again, I mention that it's not supposed to compile/run in your system. It's just a reference release (mostly released to ensure you know I'm still active and coding).
Have fun reading this masterpiece (no, not really)!
I've uploaded the source code (NOTE: no binaries) for the latest Alpha tree. Thanks grafix for hosting. This version is EModKeen 3 alpha 2, it features a brand-new directory tree and C++ ports of huff.c and pconio.c (now it's Multicon.cpp, my own console functions wrapper library for Win32 and ncurses).
You MUST NOT try to compile it. It simply won't. Believe me, it's intentionally broken, because I haven't had time to fulfill some parts of the new code structure, etc.
Most notably, I separated all the game data routines to approximately 6 files.
The latest source code can be downloaded here: http://shadowm.rewound.net/src/emodkeen ... en3.tar.gz
Again, I mention that it's not supposed to compile/run in your system. It's just a reference release (mostly released to ensure you know I'm still active and coding).
Have fun reading this masterpiece (no, not really)!
Hello, it's me again. I was just wondering whether it is possible for EModKeen to import more than the usual number of tiles into Keen? It seems that at present it simply uses the 'default' amount of bitmap, ignoring anything that comes after that, but it appears extra tiles can be inserted into Keen, and certainly it's easy to add them to levels using alteration in the GFXINFOE.CKX files for Ted5.
- Shadow Master
- Posts: 129
- Joined: Fri Oct 20, 2006 3:14 pm
- Location: Santiago, Chile
- Contact:
It is?levellass wrote:Hello, it's me again. I was just wondering whether it is possible for EModKeen to import more than the usual number of tiles into Keen? It seems that at present it simply uses the 'default' amount of bitmap, ignoring anything that comes after that, but it appears extra tiles can be inserted into Keen, and certainly it's easy to add them to levels using alteration in the GFXINFOE.CKX files for Ted5.
I don't know, I would have to get my hands back at this, and try to simulate what LL did for Keen 1-3 Modkeen with Keen 4-6. It sounds interesting, but based on Ceilick's Keen 4 mod, that had the same tileset size as the original Keen 4, my best guess is that it would quickly cause OoM (Out-of-Memory) error in KEEN4E's engine.
Well, the main problem you'll encounter is that new tiles will have no tile information for them, they'll all be do nothing, be nothing, et cetera. This part of the problem will be very difficult to solve as it would involve expanding the tileinfo space.
Fortunately, most tiles in Keen are background or do nothing tiles, they don't *need* tile info and so can be added without any problems. For example, try opening your GFXINFOE.CK4 file and changing $04 from $0 $05 to $22 $05 ($510 background tiles expanded to $522) You'll now be able to add the first row of your foreground tiles to the background of Keen. (The colors are off due to rgb sifting.) Keen will accept these tiles, and indeed any foreground tiles into the background layer without a hitch, all with just two bytes of editing.
The real task is to find a way to add tiles to the masked and unmasked sections of Keen's graphics, and though I have made progress with this, it is slow.
The relevant parts of GFXINFOE.CKX are bytes $4-$7 and $10-$13 which store the number of unmasked and masked 16X16 tiles followed by their offsets. (Thanks Andy!)
Fortunately, most tiles in Keen are background or do nothing tiles, they don't *need* tile info and so can be added without any problems. For example, try opening your GFXINFOE.CK4 file and changing $04 from $0 $05 to $22 $05 ($510 background tiles expanded to $522) You'll now be able to add the first row of your foreground tiles to the background of Keen. (The colors are off due to rgb sifting.) Keen will accept these tiles, and indeed any foreground tiles into the background layer without a hitch, all with just two bytes of editing.
The real task is to find a way to add tiles to the masked and unmasked sections of Keen's graphics, and though I have made progress with this, it is slow.
The relevant parts of GFXINFOE.CKX are bytes $4-$7 and $10-$13 which store the number of unmasked and masked 16X16 tiles followed by their offsets. (Thanks Andy!)
- Shadow Master
- Posts: 129
- Joined: Fri Oct 20, 2006 3:14 pm
- Location: Santiago, Chile
- Contact:
And that would involve CK Guy's extending Ck456Tli, and we to find a way to modify the load address of the tileinfo data, to be in an external file and not the EXE. Probably impossible.levellass wrote:Well, the main problem you'll encounter is that new tiles will have no tile information for them, they'll all be do nothing, be nothing, et cetera. This part of the problem will be very difficult to solve as it would involve expanding the tileinfo space.
I'll write down that.Fortunately, most tiles in Keen are background or do nothing tiles, they don't *need* tile info and so can be added without any problems. For example, try opening your GFXINFOE.CK4 file and changing $04 from $0 $05 to $22 $05 ($510 background tiles expanded to $522) You'll now be able to add the first row of your foreground tiles to the background of Keen. (The colors are off due to rgb sifting.) Keen will accept these tiles, and indeed any foreground tiles into the background layer without a hitch, all with just two bytes of editing.
The real task is to find a way to add tiles to the masked and unmasked sections of Keen's graphics, and though I have made progress with this, it is slow.
The relevant parts of GFXINFOE.CKX are bytes $4-$7 and $10-$13 which store the number of unmasked and masked 16X16 tiles followed by their offsets. (Thanks Andy!)
Feature request/suggestion:
Extract the "COMMANDER" and "KEEN" images used during the opening credits. I figured out the format here last December, and then failed to publish any sort of importer/exporter.
Extract the "COMMANDER" and "KEEN" images used during the opening credits. I figured out the format here last December, and then failed to publish any sort of importer/exporter.
- Shadow Master
- Posts: 129
- Joined: Fri Oct 20, 2006 3:14 pm
- Location: Santiago, Chile
- Contact:
Forgot to mention: aside from modifying the load address, it might require to make Keen allocate some extra space of memory, and copy, say, TILESET.TLI file there.levellass wrote:As I said, there's no pressing need as long as you just want extra background tiles, but I'll see if I can do something.
About the other requests: alright, I'll check them.
- Shadow Master
- Posts: 129
- Joined: Fri Oct 20, 2006 3:14 pm
- Location: Santiago, Chile
- Contact:
It's basically how programs which lack an external I/O manager work. They have to do all by themselves.
Although this is mostly based on my researches about the way NTLDR (Windows NT/2K/XP/2K3 loader) works, it seems to apply to DOS as well, the only difference being that NTLDR works on 32-bit protected mode as soon as possible (as soon as it prepares the memory address space, it seems), and most DOS programs such as keen run on 16-bit real mode.
The address schema also brings some important implications to the available memory and the method of allocating new blocks; fortunately, though, this is not a problem in patching Keen as it's a program that uses only one address scheme AFAIK. Problems would arise when patching DOS programs that run on 32-bit mode (DPMI) such as Duke Nukem 3D... fortunately, most of those have their source code published nowadays.
I just wish it was the same for Keen, but it would probably spoil most of the fun.
Nevertheless, if you are going to patch Keen for reading an external tileset, that would require a lot of testing to make sure everything works right; most importantly, check that border cases (the last tile and the first tile in the set) work properly.
EDIT: btw, opposite to what most people think, Keen is no emo kid. :P
Although this is mostly based on my researches about the way NTLDR (Windows NT/2K/XP/2K3 loader) works, it seems to apply to DOS as well, the only difference being that NTLDR works on 32-bit protected mode as soon as possible (as soon as it prepares the memory address space, it seems), and most DOS programs such as keen run on 16-bit real mode.
The address schema also brings some important implications to the available memory and the method of allocating new blocks; fortunately, though, this is not a problem in patching Keen as it's a program that uses only one address scheme AFAIK. Problems would arise when patching DOS programs that run on 32-bit mode (DPMI) such as Duke Nukem 3D... fortunately, most of those have their source code published nowadays.
I just wish it was the same for Keen, but it would probably spoil most of the fun.
Nevertheless, if you are going to patch Keen for reading an external tileset, that would require a lot of testing to make sure everything works right; most importantly, check that border cases (the last tile and the first tile in the set) work properly.
EDIT: btw, opposite to what most people think, Keen is no emo kid. :P