Norman Sword

Removing most of the checks and leaving just two checks. On the same condition. 1) if a change in movement status. Then direct beam. this detects change of face direction. when static. 2) If moving left or right then direct beam. ------------------------------------------------------- In the spiral room. Beam can be rotated downwards as willy falls. Beam can be rotated upwards as willy climbs In the Eyeball room beam can be rotated as the floors collapse, or as you climb vertically In Eugenes . A quick walk of the first platform, and on the long fall. the beam can be rotated as you fall. A simple animation change from facing left to facing right. The beam will swap sides. No checking for jumping/falling. Just the movement status now (if moving) or a change in status ------------------------------------------------------ Airborne status is set to 6 when starting a fall. This is the point at which which forward movement is stopped and willy falls vertically. No longer testing for this condition. The code I used, lasted only 10 minutes, before removal.

Without looking at code. The conveyor problem could probably be implemented by looking at the keycode values. I.e. the routine for movement generates a composite value for keypresses. A conveyor effectively presses a key. If the opposite key is pressed then we have a null situation. The movement action treats a null situation as a continuation of previous movement. If I read the keycode value and not the movement value of willy. Then it would be possible to treat a conveyor movement as a static movement. Something I will not do - I stopped at version 4.

Return of Kong Tried the above kong fall. The beam stays pointing sideways on the fall. - I will look at again later - after I have watched a film. Intermission on film:- I suspect a similar reason to the fact that the mechanics do not permit Willy to change face direction on fall. no matter how far he falls. Think Jet Set willy and the leap from the top of the building. Getting complicated to insert code to check if falling and at max fall value. Then permit beam rotate.....Airborne=6 when on a long descent I added a check for Airborne =6, (which happens on max fall) and permitted beam rotate. Need super fast reflexes to point the beam on fall. If I was to do these checks then it would make more sense to do a force of the beam to point downwards whenever willy is on maximum fall speed. i.e. when Airborne=6. the beam points downward.... I will set up a series of screen/border flags to indicate game wise when Airborne =6. To clarify to myself if this only happens on max fall. and if so. Force the beam to point downward. If too convoluted - I wont bother. Without even adding any code - I can already see problems. ----------------------------------------- Whilst it works checking for the fall value of 6, which forces willy to look down works.. It negates the ability to look upward. Jumping on the spot will keep on re setting the beam to look downward on every landing. To counter that you need to set automatic upward facing beams. And whilst at it, carry on and angle the beam depending on the arc of travel...... Whilst I probably could do all of the above...I wont. This was supposed to be a quick addendum, which supposedly stopped at version 4. ---------------------------------------- --------------------------------------------------------------- Final game version accessible via This Link

Therefore it is not the jumping that is causing the problem. (can remove that new check) but the static direction change. - 1 min and I can see what that does. Removed the jumping check By only checking for changes in Willies movement status. The instance of landing and turning around will switch the beam static turn around will switch the beam. Jumping directly upward will not switch the beam. jumping sideways which has movement will switch the beam. --------------------------------------------------------------- Final game version accessible via This Link

Easy enough for me to change---- would not be an instant change, only because of the number of steps needed to create a working version. As opposed to an assembly download. I will force the direction when jumping. Which is not done now. Changed. Still allows willy to turn on the spot without changing the direction of the beam. But the instance of jumping will change the beam direction immediately Changed again. Any change in willies status will change the beam to face, whichever direction he faces. so on the spot static movement, but a change in direction will automatically rotate the beam to follow the new direction. --------------------------------------------------------------- Final game version accessible via This Link

The beam follows movement. Not direction. I can see how that would be interpreted as a glitch. If static then the direction is whatever you want it to be.

Those coloured backgrounds in the cold room prompted me to re write the flashing objects routine for those rooms. behind the scenes the game runs as normal. Just before the screen is copied I apply the light beam effect. I felt it needed the objects and the portal permanently left on display. So the portal and the object routine are called Yet again mid way through the routine to insert the objects and the portal. Both routines take very little time compared to the major copying overheads. The coloured backgrounds do not look correct when the area around the object is not illuminated. So the original routines method of colouring an object onto the background, also did not look correct. So I had to add another routine just to animate and colour in the objects. The bonus was the routine did not need to draw the objects and was therefore faster. ------------------------------------------------------------------------ --------------------------------------------------------------- Final game version accessible via This Link

The candle mode(black background), was originally unplayable (as a game) due to not being able to know what was directly under Willies feet. The names, lantern /candle, are as names, strictly speaking wrong. In both cases Willy is using a directional beam lamp. Which from my experience of using torches . Spread a great deal of light in the direction they shine. And unless reflected back, leave your immediate surroundings pitch black. Originally in the black background mode, I directed the beam as can be seen, with a narrow beam starting out around the placement of the lamp on Willies hat. This unfortunately does not illuminate the area around Willies feet. The addition of adding reflected light to that beam was not a simple option (Not thought about in detail, until I wrote this explanation here) But the idea was not a simple and immediately viable option (more though and longer planning and it might have been) The none reflection of the light meant that where platforms ended was often just a guess. Remembering how far away that next jump needed to be, when willy and the platform was not visible, nagged at me. I could have expanded the light pattern to include Willy and the platform. The problem with that was it was NOT how a directional lamp works. A lantern or a candle give a localised light, which fits more with the description I have given to these levels. A localised light which would illuminate Willy and also illuminate the area around Willies feet. But Willy has a miners helmet, and on that is a directional lamp. The directional beam is as I have included in the design. The simplest method I could visualise was to just blue willy and the cells he was stood on. A very crude localised reflected light. Leaving the helmet light beam as originally coded, which was directional. When I tried out this simple change it at last allowed me to play several of the opening screens without a a great deal of trouble. To me the blacked out option was at last playable. Which is why the lantern / candle modes are now included. --------------------------------------------------------------- Final game version accessible via This Link

I have added a Technically changed version to the others. This Link No major change apart from the addition of the light beams in lantern and Candle mode. Keep pressing "T" till those options come around. --------------------------------------------------------------- Final game version accessible via This Link

Someone posted an old advert for Software projects. I enlarged and sharpened the picture. I adjusted the border. (I did not re-skew the picture) this normally has a detrimental impact on the resolution. I have edied the picture and inserted next years Calendar. 2nd file is a LARGE picture 1st file is the 2nd picture resampled to reduce the resolution

Officially for me the only versions of Manic Panic are the ones in post #112 here This Link The first being without the final Bonus, the second with the Bonus. The preference now being to use the 2nd version. As a technical extension, I might add a third version, with dark/light in it. (written) If I add the third version it has two more playing modes. Lantern and Candle These modes are in addition to the original modes. trainer/normal/expert/ace The Lantern mode plays with the blue Background and the rotate beam. Timer runs as normal. Can touch baddies and oxygen depletes The Candle mode plays with a black background. To me it is practically unplayable. Death on any baddy contact. In order to play the game with a black background. I have added into the timer the recognition of when Willy is moving or not. If Willy is moving left or right then the clock ticks down. If willy is jumping or falling the clock ticks down. If willy is static then the clock stops. While willy is static and the clock is stopped he can rotate the light beam. Perhaps someone can get somewhere with it like this ????? Note I say I might add a third version. Not I will add a third version Any third version I add, will be a novelty version. --------------------------------------------------------------- Final game version accessible via This Link

Previously I said Since this would always be known as the Pgyuri's effect, I see no point in carrying on further. This version V4 is the last version that I am doing, where the beam when static can be rotated by "H"-"k" one direction and "J"-"L" for the other Since this is a demo the black/blue background can be changed by pressing "enter" ( no keyboard de-bounce) This was just an exercise is see what I could do over a couple of days. Rotate.tap

Was watching the tv and had an idea to extend the logic further..... The direction the torch points is controlled by Willy using the keys "k" and "L" The beam can rotate clockwise or anti clockwise The beam has eight directions it can point Left, left and up, up, right and up, right, right and down, down, left and down. Routine was easy enough to do- I will post tomorrow. Logic version 4

The problem was a logic change..... I found an inconsistency in the logic I had used. The routine effectively did the equivalent of minus minus. To correct a wrong label reference. I went through the versions (or though I had) correcting the various references. swapping left and right and changing rotates to the opposite direction. I missed out one reference. Which causes the inverse of the light beam pattern I wanted. The .Tap.Tap file was the file in question (now deleted) I am still unhappy with how this looks and plays.

For the version with "K" and "L" keys. You can press and hold either of those two keys and the light beam will stay facing that direction. E.g. Set the beam down to willies feat by holding down "k" There is darkness in these caves. That's my lot for today. black void.tap

I have incorrectly changed a label somewhere on the 2nd version. I will find it and correct. problem found and corrected. New version updated. I am editing 3 sets of the same routine... I get mixed up with the thousands of lines of code,which version I am editing. Each version is a copy of the previous, then edited to change what it does.

Note the 2nd version added to post 136 The update was because the headlamp was mentioned ( I read the post today)- so I undertook version 2, then version 3

With the guys untold wealth, he bought a bigger and better battery pack and upgraded the torch to a Cree Fitment. Please Note this displays DEMO in multiple places. Dates and text reflect the original release, because this is NOT an update. Info:- removed light fringe. extended height and width reverted back to illuminated background (in blue) added the objects added the portals ---------------------------------------- 2nd version allows you to use the keys "k" and "L" bigger pack.tap directed beam.tap

A lot of code needed to backtrack the light beam. Simpler would be to set the amount of oxygen sap depending on the amount of objects collected. The code below concerns only the mod needed to change the sap original 8D88 EXX Switch to the shadow registers briefly (to preserve DE and HL) 8D89 CALL $8A3C Decrease the air supply by four units 8D8C CALL $8A3C 8D8F CALL $8A3C 8D92 CALL $8A3C 8D95 EXX Switch back to the normal registers (restoring DE and HL) replace with ld a,4 ; set this value to 0,1,2,3,4 etc or a jr z,skip ; permit no sap ld b,a zap : exx call $8a3c exx djnz zap skip: nop Addendum:- If the value is never set to zero then even simpler ld b,4 ; set this value to 1,2,3,4 etc zap : exx call $8a3c exx djnz zap nop nop nop nop nop

Playing in the darkened room. Possible the person playing has a screen with the fully lit cavern displayed on it, to guide them. What i did find when playing the version I modified (manic panic version) was that having the attributes flicking from square to square as you walk. attunes you to the points at which you need to jump. I found the pixel perfect jumps that are sometime required to leap from platform to platform were a lot easier.

An addendum to the above file - directional beam --- I mentioned it --- so I then needed to do it. Directional beams of light. looking left and looking right - when in a normal blue background room MPTorch2.tap

i spent an hour this morning, and then another hour tweaking the various effects. --- Re- [File] Manic Miner - DarkLight Modification since the file on hand was the last file I modified, i used that file to see what various effects I could do. Whilst doing this is not difficult. I am not attempting to do the same in Manic Miner or Jet SET Willy. The code would be pretty much identical for both versions. In jet set willy , he does not use a lamp- so less obvious to use. --------------------------------------- problems If the background is blacked out - the screen has to be memorized. Not easy on unfamiliar screens. So I stopped looking at black background versions straight away. if the background is blued out, then distinction with blue platforms disappears. They look just blued out. coloured backgrounds undecided what that looks like in this version I hallowed the light in yellow. looked better than white- saw no point in blue- as I always prefered the background left in. (and that was blue) The screen layout I am using has problems mainly due to the oxygen bar. Any other glitches are due to not bothering any further. The original aim was a directional light, I started with a general surround light and felt no need to add a few lines of code for the directional light. MP_torch.tap

counting the bytes:- If you count the number of letters and numbers along the bottom of the playing area H-score000000Lives1Room17Score000000 you will count 36 alphanumeric; then add the space for the oxygen/air you have 37 across the screen. --------------------------------------------------------------- Final game version accessible via This Link

Since I uploaded the version yesterday. it nagged at me that it was just a quick patch into the code. I have changed the version in post #112 deleted MP_0001B and replaced with MP_0001C. Accessible via This Link This version will state the bonus given on the final screen. (as opposed to just increasing the score) file size increases from the original. Version B. Quick patch 54 bytes (both patch routines included). Version C. Patch and text 77 bytes More haste - less speed. --------------------------------------------------------------- Final game version accessible via This Link

Post #112 now has an extra file ---- Untried but apart from the Bonus on completion the same program . Accessable via This Link Addendum when I uploaded the file I was looking at the size of the file. Knowing the amount of code added was around 30 bytes. The original file was 36.93 K bytes and the revised was 36.98 k bytes. Seemed to be too big a change in the file. So I went back to the assembled file. I had written two routines. the first awarding a fixed value in points, then I added a second routine which awards a sliding value. The second routine just jumps over the first when it has completed. The file I uploaded includes both routines, and only executes the second routine. The first routine just wastes some bytes of memory. (it will never be executed) More haste - less speed --------------------------------------------------------------- Final game version accessible via This Link