Keen 3 requests

Post by **Fleexy** » Sat Sep 05, 2009 2:30 am

I have two patch requests:

Rank: Really Cool:
I would like one of the Keen 3 platforms to follow a trail of either sprites or tiles (doesn't really matter which). Oh, say, sprite #314 makes a moving platform trail. If impossible, could Messie be put in a level?

Rank: Nice
Could the raygun win the game when collected?

levellass · Post by **levellass** » Sat Sep 05, 2009 11:04 am

First one... no idea. I've tried this before with no luck. Ask Lemm.

Second one, I think so, if it can be patched to give 'level 16 done' when got. (Unless something else is required to end the game.)

Post by **Fleexy** » Sat Sep 05, 2009 2:07 pm

OK. Lemm, can you help?

Never mind about the second one, found something better. Now I have three more:

Rank: Important:
Could the pogo, along with giving pogo, take all of Keen's keycards?

Rank: Quite Trippy:
There is a Keen 1 patch to make doors not 'slide' or take Keen's keycard. Could this be done for Keen 3 as well?

Rank: Critical:
I need the pogo to be taken away when either when 1) entering the level, or 2) exiting the level, by dying or by exiting.

Hope these are possible, along with the elevator trail!

lemm · Post by **lemm** » Sat Sep 05, 2009 2:15 pm

Short Answer:

It might be possible. However, I wouldn't do it making a "trail" of tiles; I think it would be easier to make "turn a direction" bricks that will cause the platform to turn in that direction if it contacts that tile. Then, if you want the appearance of the platform following a track a la keen5, just connect the dots with background tiles.

What I would like to know is, how is tile information stored in the tileinfo file.

Long answer (my suggestions):

OPTION 1 (easier): Mimic keen background tile checking for the platform.

Search this file for detect_world_col(). This is the routine called every loop to detect what keen is standing in front of and what should be done. If a similar routine is written for your platform, and additional tile types are defined (look at the switch case block) in the tileinfo, then this might be doable.

OPTION 2 (harder). ADD LINES TO SPRITE COLLISION DETECTION.

Near the end of a sprite's think routine, compute_sprite_delta() is called. This computes the "delta_x or _y" which is the value that the sprite is moved (for one draw_level loop in 256th's of a pixel, I call them map units or centipixels for short.)

Now, at the end of compute_sprite_delta(), check_ground() is called. The basic algorithm is:

0. Limit delta_x, delta_y to 3840 map units (1 tile = 4096 map units)

1-A. Add delta_y to bounding box top and bottom.
1-B. If sprite has crossed a horizontal boundary which it shouldn't have, then move the sprite one pixel outside said boundary and set the y_velocity to zero.
1-C. Add a bit to the return value**

2. Repeat for the left right axis.

3. Return to compute_sprite_delta(), which then returns to sprite think function.

**Return value: if the sprite was moving ______ and got stopped, add:
Down: 2
Up: 8
Right: 4
Left: 1

This return value is kept and used by the sprite's think function. For example, in the yorp walk, if return = 4 or 1 (hit a wall), then the x velocity is set accordingly.

Why I think it can be done: During check_ground(), the tile data for the relevant map tile checked against a constant... i.e if(tile_data == constant), stop moving. If we could add an IF(tile = number X), then move in whatever direction, then it could be done. Also, the routine can be more compactly rewritten to take advantage of 32-bit registers emulated by DosBox.

Post by **Fleexy** » Sat Sep 05, 2009 2:23 pm

Glad to know it might be possible! I can make "turn a direction" tiles. I was planning "tracks" like in Keen 5, so this is perfect. Do you need to know the tile numbers for the turn tiles to make the patch?

lemm · Post by **lemm** » Sat Sep 05, 2009 2:24 pm

There is a variable called "got_pogo," so #3 should be easy.

For #1, I see the location where got_pogo is set to 1, so all the keycards can be set to zero as well.

For #2... probably?

Post by **Fleexy** » Sat Sep 05, 2009 2:42 pm

Excellent! Any progress on the track?

lemm · Post by **lemm** » Sat Sep 05, 2009 2:55 pm

For those three are you talking keen 1 or keen 3?

The platform thing would take a while if possible. I don't know how tile information is stored, but someone here must.

Post by **Fleexy** » Sat Sep 05, 2009 2:59 pm

Keen 3. And I can wait, my 1LM won't be done anytime soon.

EDIT: For Keen 3, the tileinfo is stored at $198C8 to $1BA4B.

levellass · Post by **levellass** » Sun Sep 06, 2009 1:39 pm

Yes, however he wants to know HOW it is stored. Information on this and other file formats can be found in the patch index here: http://levellord.toxicsheep.com/Index/File%20Formats/

Specifically you want: http://levellord.toxicsheep.com/Index/F ... leinfo.txt

Now, Lemm's probably got all of these under his hat already, but I thought I might as well chip in with a patch or two. You don't have to use it of course, since better ones will no doubt be along soon.

First up, critical: When Keen exits a level four variables are set to zero. By default these are the four keycards. It is possible to change most of this.

Code: Select all

%patch $8625 $1E     #What is removed (Yellow keycard and next 3)
%patch $862F $04     #Number of items to affect (4 = all 4 cards)
%patch $8627 $00 $00 #Set to this (0 takes, 1 gives)
%patch $8625 $14     #Don't affect anything

#What first byte is:
$14: Joystick  $16: Vaccum      $18: Whiskey  $1A: Pogo
$1C: Battery   $1E: Yellow card $20; Red card $22: Green card 
$24: Blue card $26: Level 1     $28: Level 2  $2A: Level 3
$2C: Level 4   $2E: Level 5     $30: Level 6  $32: Level 7
$34: Level 8   $36: Level 9     $38: Level 10 $3A: Level 11
$3C: Level 12  $3E: Level 13    $40: Level 14 $42: Level 15
$44: Level 16  $46: Lives       $48: Ammo     $4A: Points

So to remove the pogo on level exit by any means we need this patch:

Code: Select all

#Remove pogo and keycards at level exit:
%patch $8625 $1A     #Start at pogo
%patch $862F $06     #Remove pogo AND cards

Now of course we can be real sods:

Code: Select all

#Keen loses everything, lives, points, shots, etc, on level exit
%patch $8620 $FB
%patch $862B $FB

Next up, let's do that door patch you wanted:

Code: Select all

#Doors don't open, Keen can just walk right through them
#If he has the right key- over and over. (Doesn't take Keen's key.)
%patch $5E64 $C3

Hope these tide you over!

Post by **Fleexy** » Sun Sep 06, 2009 10:29 pm

Eggcellent.

But what about the important one about 'pogo takes keycards'?

And one new one:

Rank: Critical:
I need either the other grunt (sprite 11) to shoot a meep bullet sometimes or the Vortimom to act as a grunt in moving/jumping, but still shoot.

levellass · Post by **levellass** » Mon Sep 07, 2009 11:29 am

Aaah patchers! They're never satisfied, not really.

We hit the Lemm-needed problem, other sprites can shoot the Meep bullet only once. I ask you Lemm, this happens with the Tank in Keen 1, why, WHY can no other sprite shoot the bullet more than once? Something's being set, isn't it?

Code: Select all

#Let the Vorticon shoot Meep shots (Only once! Waaaugh!)
%patch $4893 $75 $42 #After shooting,b e a Vorticon again
%patch $4252 $D3 $47 #Vort shoots here

#Change what animation is used for shooting, so Vort doesn't fall through floor:
#NOTE: Can be ommitted if you make the Meep shoting sprites Vort sized
%patch $47EA $3F $00 #Shooting left
%patch $47E2 $43 $00 #Shooting right

#Stop Meep shooting
%patch $477A $EB

Our second patch steals the main behavior from the Vorticon, making it act strange indeed. However, it should be possible, if anyone cares, to use spare space to duplicate the Vort's behavior, so the Grunt itself remains unchanged. Tell me if this is what you desire.

Code: Select all

#Vortimom jumps and jives:
%patch $4469 $4A $41 #Vort move

#And shoots its shot:
%patch $4252 $B9 $44 #Random when walking
%patch $419D $B9 $44 #When hits walls
%patch $4211 $B9 $44 #In mid jump!

#Vorticon doesn't move anymore, or it'd turn into a Vortimom:
%patch $3C4E $75 $42 #Default, slide
%patch $42C6 $75 $42 #After sliding, slide some more

lemm · Post by **lemm** » Mon Sep 07, 2009 1:39 pm

Hmm, I don't know why that would be. But I think the solution would be to rewrite the vorticon pausing behaviour so that it creates a sprite properly. Well I'll take a look at it when I'm done this platform patch.

Post by **Fleexy** » Mon Sep 07, 2009 6:16 pm

The Vortimom jives well, but the problem is in jumping: she shows a Vort animation while frozen, then jumps a few pixels, shoots, and falls. Also, could the mom kill on touch?

lemm · Post by **lemm** » Mon Sep 07, 2009 9:50 pm

Okay, here is "phase 1" of the platform patch. The yorp is now a dummy sprite, and the keycards are track tiles.

There are two patchfiles.
plat.bin contains the code to move the yorp
cg.bin contains the sprite-tile collision rewritten for 32bit processors (saving 300 bytes)

http://files.commanderkeen.org/users/omp/platform.zip

CK1Patch is provided; unzip into a Keen1 directory and run "keenmod.bat"

Now, the hunt for all the platform code in keen 3!

Yes, the mom can kill on touch. Just need to find the keen collision handler and set the appropriate subroutine.

Keen: Modding

Keen 3 requests

Keen 3 requests

Platform update