Norman Sword

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

The only reason I will change the version I have uploaded, is if a bug comes to light. I would fix the bug and perhaps implement a sliding bonus routine (written). I do not want multiple versions. Once I start down that path, I can add new rooms, edit the rooms, change the sprites add new routines, change the scolling message, add new .... etc --------------------------------------------------------------- Final game version accessible via This Link

Flashing objects In one test version I wrote an "or" version , an "xor" version, and an "and" version. and several other versions (I even wrote a masked version) So I am familiar with all the effects I can generate.

Bonus life for points, as the game is played. Since the code is new and we exist in the rollback era. It was not something I even thought about. ------------------- curiosity -------------------- 23 bytes is all it took to add a 10,000 bonus per life.... Just completed (one room) and scored 30,170 ----- (changed code - so completion was after the first room) -------------------------------------------------- ADDENDUM for 30 bytes I can implement a sliding bonus. Awarded when the final cavern is completed. None per life in trainer mode 1000 per life in Normal mode 2000 per life in Expert mode 3000 per life in Ace mode --------------------------------------------------------------- Final game version accessible via This Link

Multiple expansions on the highest score. Give only one life. State number of lives used. Give a big bonus for lives not used. <<< this being probably the easiest to do; Bonus of 10,000 per life. --------------------------------------------------------------- Final game version accessible via This Link

:1st: The Bonus points for Kong's fall was increased from the previous version. The height of fall does dictate the amount of bonus given. The move to Ace will/should give even less score. Due to having less time. The difference should not be a great deal. The time allowed on one or two screens is generous. This was because I have a list of the times taken for each screen. And in some cases I had to ignore the faster times i had written down. Simply because I was concerned that i might have changed something that allowed the faster time. If I had then used the faster times, the completion of some screens might have been impossible. Although strictly speaking I have completed every room first in every case. --------------------------------------------------------------- Final game version accessible via This Link

Amstrad version of Jet Set Willy 2. The Amstrad(CPC) version of Jet set willy. Was written as Jet set willy, where the programmers decided to fix the weird layout of Jet Set Willy. By adding some extra rooms into the gaps of a neatly planned layout of jet set Willy. From the outset of writing the game on the amstrad(CPC) it was decided to use a very simple run line compression. The compression was added to a room designer written on the CPC. This was written in a few lines of basic. Each designed room was then output in compressed form. As a set of data statements and sent via an RS232 link. The RS232 link was via a z80dart connected to the CPC. The receiving Machine was a Tandy model 4. All rooms received by the tandy model 4 from the CPC were of the compressed data. Any room that needed to be edited was either re-drawn or the compressed data was hand edited. This data and the code that was written for the cpc was the basis of the version released on the Spectrum called JSW2 the final frontier. The room data is an exact copy of the CPC data with editing of that data to change the way the spectrum uses colour compared to the CPC four colours. At a later date. After JSW2 was released on the zx spectrum. A need arose for the CPC to have a version that was more inline with the other versions of JET SET WILLY e.g. only had 60 rooms. This was necessitated for the release of "they sold a million" compilation tapes. Which had been released on other machines, and a version was planned for release on the CPC. For the "they sold a million" version on the CPC it was decided to remove all the extra rooms and leave the game with only 60 rooms. This later version on the CPC was released in the compilation "they sold a million" on the CPC. The net result is that the data for both CPC versions are very similar to the spectrum version of jsw2. And all are compressed with that simple run line encoding. Written in a couple of lines of CPC basic.

VERSION 0001.0 This is a full game based on the continuation of the story FULL SCREEN GAME PLAY ----------------------------------------------------------------------- All version have been replaced by the latest version ----------------------------------------------------------------------- 1st version MP_0001.TAP - 10 downloads 3 basic versions of play, immediately available 1) Trainer mode - lots of air and allowance for sprite contact, nasty contact and falls. Very slow air depletion - no end game 2) Normal mode - fixed amount of air and allowance for sprite contact, nasty contact and falls. Moderate speed air depletion - game can be completed to end game 3) Expert mode - very little air. Just enough to finish a cavern. All contact and falls kill. Very rapid air depletion.- game can be completed to end game 4) ACE mode - only available after completing the game in Normal or Expert mode. Faster air depletion than ACE - no time to look around Each mode has its own high score --------------------------------------------------------------------------- 2nd version is Mp_0001C.TAP - 10 downloads This is basically the above game with a final end of game bonus Bonus end game bonus 1000 for each life in Normal 2000 for each life in Expert 3000 for each life In ACE --------------------------------------------------------------------------- third version was MP_0001T,TAP - 7 downloads This was an expansion exploring the dark light basic concept. This version takes the original idea and expands into a playable version. The two extra options, lantern and candle are playable. The lantern version more so than the candle version. The biggest challenge will be the inability to see the solar light beams. In the candle version the clock stops when ever Willy stops moving. In Lantern and Candle version the beam of light can be rotated when static using the keys "H" and "K" for one direction and "J" and "L" the other direction. Due to more options available in this technical demo - the end game bonus is also increased. ---------------------------------------------------------------------------- Version 4 Mp_v12.tap --- 5 downloads Fixes several design quirks. Modes of play 1) Trainer mode - lots of air and allowance for sprite contact, nasty contact and falls. Very slow air depletion - no end game 2) Normal mode - fixed amount of air and allowance for sprite contact, nasty contact and falls. Moderate speed air depletion - game can be completed to end game 3) Expert mode - very little air. Just enough to finish a cavern. All contact and falls kill. Very rapid air depletion.- game can be completed to end game 4) ACE mode - only available after completing the game in Normal/Expert/Lantern/Candle Faster air depletion than ACE - no time to look around continuation of modes - the following two modes incorporate a beam of light from Willies helmet lamp 5) Lantern mode - same time as Normal. background is blue-ed- allowance for sprite contact, nasty contact and falls. Moderate speed air depletion - game can be completed to end game 6) Candle mode - same time as Expert mode - background is blacked out. clock stops on no movement. All contact and falls kill. Very rapid air depletion.- game can be completed to end game Rotate the light beam in Lantern/Candle by pressing "H"-"K" or "J"-"L" when Willy is static Each mode has its own high score Since this incorporates every change that has been written into the above separate versions. Those old versions have been deleted. 1 fixes blue-ing of the portal when passing in front in candle and torch mode. 2 increased compression of data. 3 added an on screen version number on the title screen. 4 updated the light rotate on torch mode. Forces beam change on static turn. 5 numerous small changes. 6 changed title screen animation. ---------------------------------------------------------------------------------------- and for the observant a possible update which only affects candle mode Version 4 Mp_v13.tap mp_V12.tap mp_V13.tap

All room times set :- I should play through again but I am not that willing. Speed factors set as 8 - 6 - 4 and trainer 3 ACE MODE The speed setting of 8 gives just enough time to finish. It is the time taken by me plus a few air bar segments .Since the air bar is progressive in nature. A few segments can be as many as a hundred frames. Instant death if touched. This speed option is not available until the game has been finished once in normal or expert mode. EXPERT MODE based on the ACE MODE. This mode gives around 20% more time. This mode can be selected from the start. Instant death if touched NORMAL MODE based on the ACE MODE. This mode gives around 30% more time. This mode can be selected from the start. Permits the occasional touch. One less sprite in the room TRAINER MODE based on the ACE MODE. This gives around 100% more time. Which normally gives a lot of time. This mode can be selected from the start. The air bar is always set to full for the start of any room. In Later rooms the setting to full is not as big an advantage when the air bar needs to be set to a high level anyway. This mode permits quite a few touches in early rooms. Also less sprites to block path and slow progress Each mode depletes the oxygen bar at a different speed. The Maths involved in the time taken is skewed slightly (deliberately so) to adjust the times overall. This has allowed me to set the highest possible air bar in difficult rooms. Otherwise the full height of the air bar would never be needed and the changes in speed between the various levels becomes too great. --------------------------------------------------------------- Final game version accessible via This Link

I have other things to do at the moment. Which will stop any further looks or comments on this.

I ran one of the versions listed above. I modified the file by changing one instruction from LD (HL),L to LD (HL),B. The original opcode is used to wipe the attributes, the changed opcode just sets them all to BLUE ink. This one byte change allows you to see the method used to draw the area illuminated by Willies head lamp. (allows you to actually play the room- within the limits of what the change in code does) Note no other change was undertaken by me... What you see is how this program does the illumination. dim version.szx has the cheat already activated dim 2 version.szx does not have the cheat activated ---- With the mods Note change from dim2 version.szx to dim 2 version .szx ADDENDUM The poke is Poke 37733,112 - Changing the value from 117 to 112 - changing the opcode from LD (HL),L to LD (HL),B The poke is Poke #9365,#70 - Changing the value from #75 to #70 - changing the opcode from LD (HL),L to LD (HL),B dim version.szx dim 2 version.szx

Example of two of those routines . The big graphic showing duplication of tiles. 2nd picture showing the tile linkage. And Overwriting the lower status area the game cycle counter and the collisions so far plus air bar value (meaningless when shown in trainer mode)

The time between pressing F9 to assemble the program and pressing F10 to run is less than a second. It is very easy to have a variable that specifies a start room and jump the game into that room. It takes no effort to assemble and play doing any room. The program does have built in, beside the timer display routine, some other routines. When designing a room we have 16 tiles to play with. The game control uses the colours to assign to each tile a purpose. So we can have conveyor floors or conveyor walls, or even conveyor nasties. So when designing a room and assigning the colours. I needed to be able to see what tile has what property. e.g. Have I duplicated a colour. So I wrote a routine to display the tiles and their usage. The routine draws each tile as a graphic in a big square on the screen. For every graphic it scans the playing screen for the usage of that graphic. Then it scans all the other graphics to see if any graphic is defined in a similar colour. If it finds another graphic with the same colour. It places a marker on the screen to show the graphic colour duplicate. It then re scans the playing screen to see if the duplicate colour tile is also used. It then marks it as a duplicate and used and not just a duplicate and un-used, which can be ignored. (just one of the multitude of routines, that has been written. But will never be seen) The music debug routine (in addition to the placement on the keyboard) shows numerically the note position in the sequence, the note, its octave, the note length and the note value eg. F# --- again never seen. The game timer shows the current game cycle and the number of death contacts - not seen The initialisation routine checks memory overflows during compression and program overflow - not seen --------------------------------------------------------------- Final game version accessible via This Link

Even though it might appear as if nothing is happening. I am still adding bits and pieces, and changing what happens and how it happens. The routines are scanned and have to pass my criteria on what is acceptable. For example the game completion routine has an addition of data added to the display, it now plays three sequences of noise/music. The two tunes at the start were re written, the music routine was changed and extended. The room order is slightly different, one more room added. The sound effect from touch was altered to have more impact from touch. The original made a sound which did not impact on play. (e.g. it was not really noticeable) touches and falls now impact on play. Playing through all the rooms. Undecided if I go back to the original timer settings. The reason being that in expert mode, the time as now set, which will be based on how long it takes me to do a room, is far too lenient. Giving some figures for the number of frames needed to finish a room. Room1-102, room 2-377, room 3-629, room 4-613, room 5-1263 ------- room 8-1479 . If I allow 50% extra time on room 8 that is 700+ frames enough time to finish room 3. The three levels of play are trainer/normal and expert. Hardly an expert if it takes an extra 700 frames compared to me. Put another way. If i can run a mile in 4 minutes, then an expert is not going to run a mile in 6 minutes, and the normal runner in eight minutes. far too much leeway. Notice I left the trainer mode out of that list. The trainer can run the mile in around an hour. What I am doing at the moment is playing each room to completion. And taking a note of the frames to completion. (where a frame is a complete game cycle and not a 1/50th sec video refresh cycle). I will decide at the very last instance what speed the game is set to. I have added an extra room, this is done by compressing the game data. I have done this in a convoluted method. Explanation to follow. Room compression:- Manic Miner has no room compression. JSW has a 2 bit steam compression. Manic 40 Miner uses a simple 4 bit stream compression, that enables editing in hex nibbles. Manic Panic . Starts with a 4 bit stream compression . e.g. nibbles It then takes the stream of nibbles and expands the data out into bytes containing one nibble each. the Data in the lower nibble It then takes the stream of bytes each with one nibble of data and compresses into a repeat count bit stream of nibbles. It stores the repeat count bit stream of nibbles. Then discards the original data. This allows the original rooms to be edited as hex nibbles and not the awkward repeat stream of nibbles. The program also allows the definition of willy to be edited, the program will then generate the mask needed to play the game. When the game is run... the routines listed above will be overwritten. --------------------- Doing all this on my own, with basically no reason to do so. Means I am not pushing to finish this. By the end of the week I should have set all the rooms to completion times. -------------------- --------------------------------------------------------------- Final game version accessible via This Link

academic... His legs are not tested for the collision, only his upper half. The amount of sideways movement for the upper half passing through a switch would be considerable. supposing he jumped sideways at a switch. intending to land on it. The switch platform is either one or two characters above his feet. normal arc of passage would allow the sprite to effectively move sideways after missing the platform (switch) and his lower body would move effectively 4 pixels sideways before the upper part of the sprite is registered as being in the switch square. On a switch block one char higher than his feet. if the switch was was two chars higher than willies feet then Willy would move effectively six pixels into the char. ----- Not a trivial amount. The area that would now be checked for pixel collision with the switch would be the area around the middle of Willy. The original comment about collision was an instantaneous off the cuff remark.

The arc of fall does not always land on a block (When it has a side component). Think how often you jump trying to land on a platform, and watch Willy pass through it sideways. I was expanding the passage of sprites through movement. Agree that standing on a switch is possible. I am surprised that the switch has managed to progress so far, without it being a problem (to me). Skylab was written first, light beams second, and for no particular reason Kong was written last. The problem encountered when producing routines is the consistency of how you self test them. No matter how much you try to vary the way you test a routine. It is not the same as the real world. I wrote a short game program that contained a space ship that fired a gun. Never crashed in the month I ran it. Someone else came along and crashed the game pretty much straight away. Baffled I asked the person to crash the program again, and they did. What that person did was switch the auto fire on, on the joystick. This sent the program constantly into a subroutine which did not handle the stack properly. The auto fire kept adding junk to the stack and over the space of a few minutes the game crashed. Yet all the time the game was being displayed on the screen, there was never a reason to fire a bullet. When the firing sequence was needed and bullets fired. The game reset the stack. I did not expect someone to just fire the gun, because he could. The above was pretty much the first routine I had ever written, a couple of thousand lines of code, and it taught me quickly to keep track of the stack. Short cuts must abound when nasties sap a plentiful supply of air. All the screens with spiders dangling from webs. Just walk through the web and jump. No worse than using rollback and playing via that method. My other half used to play hidden objects games. I bought about 100+ of the games and gave her access to them. Halfway through the 100+ games, she stopped using a pc completely and moved over to an android smart phone. So I had a mass of unused games. They were never even download and existed unused for around 10 years. Until two months ago, I down loaded one of them. (around 1 giga bytes) and played it. Great graphics, nice tune. Yet in a lot of circumstances I had no idea what was expected and I spent the weeks just clicking the hints button. Most of the game puzzles were easy enough to do, but some words do not translate well across the pond. The hints button would keep highlight something, where that the american word, to me, was obscure. Or indicate an object where the correlation to another object was vague . I finished the game having played (clicked on hint) it all the way through. Not tempted to go back and play again without the hints button, but I suppose the constant "hints" is just another form of cheating. Therefore in Manic Panic I now class jumping on and passing through nasties, as just using the games hints. (Now without the jumping on part) --------------------------------------------------------------- Final game version accessible via This Link