keenmaster486 wrote: ↑Wed Jan 22, 2020 6:34
Keen refuses to detect both XMS and EMS at the same time. It grabs an extra 64K of RAM from the EMS, and refuses to get any more. So Ocflore loads the first level after this, but I did try to warp to a different level (9) and it ran out of memory again.
Keen can't use more than 64k of EMS (and not more than just under 64k of XMS) anyway. Programs that use more than that just store the data somewhere in EMS/XMS and then need to use the EMS/XMS driver every time the program needs to access that data. Keen needs to have access at any time without having to invoke the driver again, therefore it's limited to 64k.
I guess the memory manager was originally targeted at an earlier DOS version and might have worked with XMS at some point. As I mentioned earlier, I can't get XMS to work either.
Now let's take a look at the memory requirements. If the game doesn't list at least 443k of total available memory at the startup screen, you won't be able to load level 9 at all. (At least not on the highest difficulty setting). Level 9 requires the biggest amount of memory (without music). With music, you need at least 455k (for level 7).
On top of that, the original Keens 4-6 have rather poor memory management. So you probably need a little more than what was mentioned above, but I think the worst thing that will happen is that you won't get any music in the level. Also, warping from one level to another can cause issues because the game doesn't remove the current sprite and tile graphics from memory when a new map is loaded. If the new map is bigger than the old one, you are very likely to encounter "out of memory" crashes. I wrote a fix for that, which should make it into the next official release. If you want to try it early, here it is:
Code: Select all
#Free sprites and tiles before loading a level
%patch $61DD
$74 $0A # jz no_demo
$C7 $06 $7A6Cw $0002w # mov gamestate_difficulty, 2
$33 $C0 # xor ax, ax
$EB $03 # jmp init_rndt
#no_demo:
$B8 $0001w # mov ax, 1
#init_rndt:
$50 # push ax
$9A $1D020002rl # call US_InitRndT
$58 # pop ax
$9A $05C40006rl # call FreeUpMemory
$90 $90 $90 $90 $90 $90
#Don't free the paddle war sprites (in case loading a game fails)
%patch $5C4B $0081w # default: $007Cw
Also, don't try to run the game via CK4PATCH. CK4PATCH itself takes up over 20k of memory, so it's an absolute no-go for running memory-hungry mods on real DOS machines. But you can use the latest version of
my patching utility to create a fully patched standalone executable.
If you want to try that, change the beginning of the patch file like this:
Code: Select all
%exefile keen4e.exe 251712 # for K1n9_Duk3's patching utility
#%ext ck4
#%version 1.4
###########################
# The Usual Junk Required #
###########################
# Load the edited loading screen
%patchfile $1fe47 ck4load.bin
# Load the modified graphics please
#%egahead EGAHEAD.CK4
%patchfile $21080 EGAHEAD.CK4
# Load the maps now
#%maphead maphead.ck4
%patchfile $24830 MAPHEAD.CK4
My utility doesn't handle the "%level" commands, so you will have to replace them with the equivalent "%patch" instructions like this:
Code: Select all
############################
# Level Names and Entries #
############################
%patch $1F040 "Ocflore V" 0
%patch $1F050 "Ocflore Airport" 0
%patch $1F060 "Imber Inlet" 0
%patch $1F070 "The Enkri Borough" 0
%patch $1F090 "Jungle Crags" 0
%patch $1F0B0 "Frigid Quarry" 0
%patch $1F0C0 "Enkri Sanctuary" 0
%patch $1F0D0 "Pelagic Pillars" 0
%patch $1F0E0 "Ostrum Absorbor" 0
%patch $1F0F0 "Mount Amnis" 0
%patch $1F100 "Dorsal Obelisk" 0
%patch $1F110 "Ancient Observatory" 0
%patch $1F130 "The Enkri Shanty" 0
%patch $1F150 "Savanak Temple" 0
%patch $1F180 "The Dorsal Battleship" 0
%patch $1F1A0 "Swallowed Spire" 0
%patch $1F1B0 "Evergreen Gate" 0
%patch $1F1C0 "Sunken Sanctum" 0
%patch $1F1D0 "The Thicket Steeple" 0
%patch $1F1F0 "Keen navigates" $0A "planet Ocflore" 0
%patch $1F210 "Keen splashes down at" $0A "the Ocflore Airport" 0
%patch $1F240 "Keen paddles to the" $0A "Imber Inlet" 0
%patch $1F260 "Keen cuts through" $0A "the Enkri Borough" 0
%patch $1F290 "Keen plunges down" $0A "the Jungle Crags" 0
%patch $1F2D0 "Keen cascades into" $0A "the Frigid Quarry" 0
%patch $1F300 "Keen beholds the" $0A "Enkri Sanctuary" 0
%patch $1F330 "Keen dangles on" $0A "Pelagic Pillars" 0
%patch $1F350 "Keen burrows his way to" $0A "the Ostrum Absorbor" 0
%patch $1F380 "Keen conquers" $0A "Mount Amnis" 0
%patch $1F3A0 "Keen filters through " $0A "the Dorsal Obelisk" 0
%patch $1F3D0 "Keen reveals" $0A "the Ancient Observatory" 0
%patch $1F400 "Keen cracks into " $0A "the Enkri Shanty" 0
%patch $1F430 "Keen delves into " $0A "the Savanak Temple" 0
%patch $1F470 "Keen teleports aboard" $0A "the Dorsal Battleship" 0
%patch $1F4B0 "Keen subsides into " $0A "the Swallowed Spire" 0
%patch $1F4E0 "Keen passes through" $0A "the Evergreen Gate" 0
%patch $1F510 "Keen plunges into " $0A "the Sunken Sanctum" 0
%patch $1F540 "Keen catapults up " $0A "the Thicket Steeple" 0
There are a few more issues in the patch script, but those should get fixed in the next official release.
keenmaster486 wrote: ↑Wed Jan 22, 2020 6:34Did you change the video refresh code for some reason? (edit: I should mention this doesn't happen at all with vanilla Keen 4, which works perfectly)
Yes, I did. My main goal was to be compatible with DOSBox first and formost, since that's how most people play Keen mods nowadays. The code also worked perfectly fine on almost all of my systems (see linked thread). Since then, I also got myself a 286 system (12 MHz / 6 MHz) and my patch is working perfectly fine in 12 Mhz mode on that machine. I didn't play much in 6 MHz mode. Also, that machine requires SVGA compatibility mode, so I can verify that this option is indeed necessary on certain SVGA cards.
It's hard to tell what exactly is going on on your end, since you didn't say how fast your CPU is and if the PC has an AdLib-compatible sound card. Maybe you could record a video showing the mod running with and without the "Fix jerky motion" option enabled. What I can say is that my code waits for a vertical retrace on the CRT after updating the screen position. The original code didn't do that, which led to issues in DOSBox and also on fast DOS systems.
What happened with the original code was that the game sets the new screen position and then (because the CPU is faster than intended) manages to update the level objects and modify the video memory before the video card actually updates the screen position. So the video card ends up displaying parts of the video memory while the game is modifying them, which led to display issues. On slow systems like your 286, the time that is spent waiting for the vertical blank might better be spent updating the level objects. I could have rewritten the code to wait for the VBL before the game starts drawing the tiles and sprites, but that would mean the fix would only work in-game and you'd still get glitches in the Terminator intro or the Star Wars text crawl.
If the original scrolling works fine on your machine, then you could just disable or remove the screen update fix from the patch file. But then you can't use my color patch anymore and would have to play Ocflore with the wrong colors again.