-
Posts
628 -
Joined
-
Last visited
About Norman Sword
Recent Profile Visitors
9,211 profile views
Norman Sword's Achievements
Advanced Member (3/3)
1.4k
Reputation
-
UncleWan reacted to a post in a topic:
MM and JSW ports to SDL2
-
Spider reacted to a post in a topic:
What does NCB mean?
-
JianYang reacted to a post in a topic:
What does NCB mean?
-
UncleWan reacted to a post in a topic:
What does NCB mean?
-
It does indeed mean National Coal Board. Software projects received a threatening letter from the National Coal Board, about usage of the NCB logo without permission. Remember this was at the same time as Mr Arthur Scargill, was having a good laugh with the NCB. Whilst the games MM and JSW do not have reference to The NCB (directly), the artist( Roger Tissyman) responsible for the cover design of the software projects release of these two games inserted the NCB graphic into his artwork.
-
from the post above Are you planning on doing JSW2 at any point? (For one, I always preferred JSW2 and secondly (and more selfishly), I'd love to look at the difference between the movement code between the first and second games.) The code for JSW2 was not a rewrite of Matthews code. It was writen from scratch, using just visual information from the original. e.g. Look at the game mechanics, and write the code. JSW's method of movement was not even looked at (source code or dissassembly)
-
CPL reacted to a post in a topic:
MM Movement and Collision Detection explanation
-
MtM reacted to a post in a topic:
The Invisible Man
-
JianYang reacted to a post in a topic:
The Invisible Man
-
Jet Set Willie reacted to a post in a topic:
MM Movement and Collision Detection explanation
-
Jet Set Willie reacted to a post in a topic:
The Invisible Man
-
jetsetdanny reacted to a post in a topic:
The Invisible Man
-
And to take all the work out of modification... The data needed is in my "INVISIBLE TAP" file This is the minimum change needed to interact with willy - NOTE this omits the other changes I added ; to get this data look at these addresses in "INVISIBLE.TAP"- ; modification at start of rope draw - draw Willy to screen at #92a4 call willy_draw_on (3 BYTES) nop (1 BYTE) old LD IY,ytable (4 BYTES) ; with xor ??? if willy is present then no change here - leave to indicate looked at and aware of check at #92c9 and (hl) old (no change - read comment) AND (HL) ; the rope pixel changes from {or} to {xor} at #9311 xor (hl) (1 BYTE) old OR (HL) (1 BYTE) ; the final rope mode modification - get rid of Willy at #935e call willy_draw_off (3 BYTES) old LD A,(rope_status) (3 BYTES) ; Original Willy draw - now just saves data positions at #9660 jp save_willy (3 BYTES) old --- note 3 bytes which is the first instruction plus 1 byte from the next LD B,#10 (2 BYTES) LD A,(willy_att) (3 BYTES- ONLY FIRST BYTE NEEDS TO BE CHANGED) ; the code that is being called - org #9f00 screen_pos dw 0 screen_def dw 0 save_willy: ld a,(willy_att) and #1f or (ix+0) ; the x position ld L,a ld h,(ix+1) ld (screen_pos),HL ld (screen_def),de ret willy_pause: ld hl,(screen_pos) ; shift from #60 to #40 res 5,h call willy_xor1 LD DE,#0000 ret willy_draw_on: call willy_xor LD IY,ytable ret willy_draw_off call willy_xor LD A,(rope_status) ret willy_xor: ld hl,(screen_pos) willy_xor1: ld de,(screen_def) draw_xor: ld b,#10 loop_xor: ld a,(de) xor (hl) ld (hl),a inc de inc L ld a,(de) xor (hl) ld (hl),a inc de dec L inc h ld a,h and 7 jr nz,legal_val ld a,L add a,#20 ld L,a jr c,legal_val ld a,h sub 8 ld h,a legal_val: djnz loop_xor ret --------------------- PLUS Stop dancing willy routine - delete call remove Willy on plinth in death routine - delete call ------------------------------- A lot of effort for something I am not doing ---
-
Just checked the code - was aware it seemed different from what I normally do - e.g. was part modifying someone elses code. I can see the layout does not adjust for the screen 1/3rds correctly. so here, is how I do it as opposed to modifying someone else's code --- Too much time doing this. sprite_xor ld b,#10 loop_xor: ld a,(de) xor (hl) ld (hl),a inc L inc de ld a,(de) xor (hl) ld (hl),a dec L inc de inc h ld a,h and 7 jr nz,legal_val ld a,L add a,#20 ld L,a jr c,legal_val ld a,h sub 8 ld h,a legal_val: djnz loop_xor ret Addendum:- just to show what I said works --- 1) no idea what version of jsw I have used - so no idea how many of the original bugs are present 2) deliberately not the same as the file you want to edit. 3) comes equiped with spray paint - Pause to show where willy is 4) due to the pause addition.... Can play by pressing pause to see where willy is and movement keys .eg hold "gh" and play as normal. Willy is treated as still invisible in the game code. Addendum 2:- with a ghostbuster's radar - we track the invisible man. And that concludes my effort. INVISIBLE.tap INVISIBLE_Tracking.tap
-
because the sprite print routine adds pixels - it never erases pixels - similar to 1+4=5 or 1+3+2=6. The result never gets less no matter how many positive numbers you add.Although technically the print routine gives the result as (1 or 4 =5) and (1 or 3 or 2=3) NOTE - the routine I mentioned uses XOR - and any number xor'd with itself is always 0. So how difficult is the xor version of the sprite print routine. Original hacked to xor - call once to draw and once to erase. sprite_xor ld b,#10 loop_xor: ld a,(de) xor (hl) ld (hl),a inc L inc de ld a,(de) xor (hl) ld (hl),a dec L inc de Inc h ld a,h and #07 jr nz,legal_val ld a,h sub 8 ld h,a ld a,L add a,#20 ld L,a legal_val: djnz loop_xor ret
-
Because this would always be attributed to the original person. I have no incentive to add code to what (as far as I can see) is a simple deletion of the willy definition. So in the words used on Dragons den "I'm out" ------------------------------- path that could be taken - just not by me 1) To collide with the rope, Willy needs a definition. The deletion of Willies definition, means that path is out. 2) If the definition is intact modify the code that draws willy - instead of actually putting the pixels to the screen- instead save the draw definition and the draw position, and return in the rope draw routine - add a routine to use Willies draw definition and Willies draw position to xor Willy to the screen Draw the rope - using xor - Willy will be flagged as collided in the normal way - movement on rope etc will still occur. on rope exit add a routine to use Willies definition and Willies draw position to xor Willy off the screen. The xor routine is a very simple sprite draw routine. Which would need adding, The above allows Willy to interact with the rope.... The original modification was simply deleting Willies definition. This is adding ten times the effort of the original person to try and fix his hack. Addendum:- Just looked at this again - every reference to drawing willy elsewhere .. e.g the dancing Willies/ death screen etc. would need deleting.
-
A big post of z80 code The reason for the left right anomaly is simply caused by poor code layout as done by Matthew. When setting up movement code - it is normal to mirror the code for left and right. This simple procedure allows quick and accurate visual comparisons. Here the first lot of code is the layout of checking left and right movement when possibly on a ramp NOTE this has unused opcodes and does not mirror left and right Expect visual changes - over time on what you can see here. I will probably edit the visual layout. And correct errors as I see them. MATTHEWS CODE:- Used by the routines at 8DD3 and 8ED4. This routine moves Willy left or right if necessary. 8FBC LD A,($85D0) Pick up Willy's direction and movement flags from 85D0 8FBF AND $02 Is Willy moving left or right? 8FC1 RET Z Return if not 8FC2 LD A,($85D6) Pick up the rope status indicator from 85D6 8FC5 DEC A Is Willy on a rope? 8FC6 BIT 7,A 8FC8 RET Z Return if so (Willy's movement along a rope is handled at 935E) 8FC9 LD A,($85D0) Pick up Willy's direction and movement flags from 85D0 8FCC AND $01 Is Willy facing right? 8FCE JP Z,$9042 Jump if so ; LEFT AND RIGHT CODE - DISPLAYED NEXT TO EACH OTHER Willy is moving right. ; Willy is moving left. 9042 LD A,($85D2) ; 8FD1 LD A,($85D2) Willy's animation frame from 85D2 9045 CP $03 ; 8FD4 OR A Is it 0? 9047 JR Z,$904E ; 8FD5 JR Z,$8FDC If so, jump to move Willy's sprite left across a cell boundary 9049 INC A ; 8FD7 DEC A Change Willy's animation frame at 85D2 904A LD ($85D2),A ;8FD8 LD ($85D2),A 904D RET ; 8FDB RET Willy's sprite is moving right ; Willy's sprite is moving left across a cell boundary. In the comments that follow, (x,y) refers to the coordinates of the top-left cell currently occupied by Willy's sprite. 904E LD A,($85D1) ; 8FDC LD A,($85D1) Pick up the airborne status indicator from 85D1 9051 LD BC,$0000 ; 8FDF LD BC,$0000 Prepare BC for later addition 9054 OR A ; 8FE2 CP $00 Is Willy jumping? 9055 JR NZ,$9078 ; 8FE4 JR NZ,$900A Jump if so 9057 LD HL,($85D3) ; 8FE6 LD HL,($85D3) Collect Willy's attribute buffer coordinates from 85D3 ; 8FE9 LD BC,$0000 Prepare BC for later addition (again, redundantly) 905A LD A,($80DA) ; 8FEC LD A,($80DA) Pick up the direction byte of the ramp definition for the current room from 80DA 905D DEC A ; 8FEF DEC A Now A=0x1F if the ramp goes up to the left, or 0x41 if it goes up to the right 905E OR $9D ; 8FF0 OR $A1 9060 XOR $BF ; 8FF2 XOR $E0 9062 LD E,A ; 8FF4 LD E,A Point HL at the cell at (x-1,y+1) if the ramp goes up to the left, or at the cell at (x+1,y+2) if the ramp goes up to the right 9063 LD D,$00 ; 8FF5 LD D,$00 9065 ADD HL,DE ; 8FF7 ADD HL,DE 9066 LD A,($80C4) ; 8FF8 LD A,($80C4) Pick up the attribute byte of the ramp tile for the current room from 80C4 9069 CP (HL) ; 8FFB CP (HL) Is there a ramp tile in the cell pointed to by HL? 906A JR NZ,$9078 ; 8FFC JR NZ,$900A Jump if not 906C LD BC,$0020 ; 8FFE LD BC,$0020 Prepare BC for later addition 906F LD A,($80DA) ; 9001 LD A,($80DA) Pick up the direction byte of the ramp definition for the current room from 80DA 9072 OR A ; 9004 OR A Does the ramp go up to the right? 9073 JR Z,$9078 ; 9005 JR NZ,$900A Jump if so 9075 LD BC,$FFE0 ; 9007 LD BC,$FFE0 BC=-32 (the ramp goes up to the left) 9078 LD HL,($85D3) ; 900A LD HL,($85D3) Collect Willy's attribute buffer coordinates from 85D3 ; check extremes far right ; and far left - jump room 907B ADD HL,BC ; 907C INC HL ; 907D INC HL ; 907E LD A,L ; 900D LD A,L Is Willy's screen x-coordinate 0 (on the far left)? 907F AND $1F ; 900E AND $1F 9081 JP Z,$949E ; 9010 JP Z,$948A If so, move Willy into the room to the left; 9084 LD DE,$0020 ; 9087 LD A,($80B2) ; ; 9013 ADD HL,BC Point HL at the cell at (x-1,y+1), or at the cell at (x-1,y) if Willy is on or about to step onto a ramp that goes up to the left, or at the cell at (x-1,y+2) if Willy is walking down a ramp ; 9014 DEC HL ; 9015 LD DE,$0020 908A ADD HL,DE ; 9018 ADD HL,DE ; 9019 LD A,($80B2) Pick up the attribute byte of the wall tile for the current room from 80B2 908B CP (HL) ; 901C CP (HL) Is there a wall tile in the cell pointed to by HL? 908C RET Z ; 901D RET Z Return if so without moving Willy (his path is blocked) 908D LD A,($85CF) ; 901E LD A,($85CF) Pick up Willy's y-coordinate (Y) from 85CF 9090 SRA C ; 9021 SRA C Now B=Y (if Willy is neither on nor about to step onto a ramp), or Y+16 (if Willy is walking down a ramp), or Y-16 (if Willy is on or about to step onto a ramp that goes up to the left) this will be Willy's new y-coordinate 9092 ADD A,C ; 9023 ADD A,C 9093 LD B,A ; 9024 LD B,A 9094 AND $0F ; 9025 AND $0F Is Willy at a point in a jump (left) where his sprite occupies three rows of cells? 9096 JR Z,$90A1 ; 9027 JR Z,$9032 Jump if not (Willy's sprite is cell-aligned) 9098 LD A,($80B2) ; 9029 LD A,($80B2) Pick up the attribute byte of the wall tile for the current room from 80B2 909B ADD HL,DE ; 902C ADD HL,DE Point HL at the cell at (x-1,y+2) 909C CP (HL) ; 902D CP (HL) Is there a wall tile there? 909D RET Z ; 902E RET Z Return if so without moving Willy (his path is blocked) 909E OR A ; 902F OR A Point HL at the cell at (x-1,y+1) 909F SBC HL,DE ; 9030 SBC HL,DE 90A1 LD A,($80B2) ; 90A4 OR A ; 9032 OR A Point HL at the cell at (x-1,y), or at the cell at (x-1,y-1) if Willy is on or about to step onto a ramp that goes up to the left, or at the cell at (x-1,y+1) if Willy is walking down a ramp 90A5 SBC HL,DE ; 9033 SBC HL,DE 90A7 CP (HL) ; 90A8 RET Z ; 90A9 DEC HL ; 90AA LD ($85D3),HL ; 9035 LD ($85D3),HL Save Willy's new attribute buffer coordinates (in HL) at 85D3 90AD XOR A 90AE LD ($85D2),A ; 90B1 LD A,B ; 9038 LD A,B Save Willy's new y-coordinate at 85CF ; 90B2 LD ($85CF),A ; 9039 LD ($85CF),A 90B5 RET ; 903C LD A,$03 Change Willy's animation frame at 85D2 from 0 to 3 ; 903E LD ($85D2),A ; 9041 RET ;============================================= The above code laid out with symatry - NOTE the bug can be inserted by just removing the head check. Here I relay out the code with symetry Used by the routines at 8DD3 and 8ED4. This routine moves Willy left or right if necessary. 8FC2: LD A,($85D6) Pick up the rope status indicator from 85D6 DEC A Is Willy on a rope? RET m Return if so (Willy's movement along a rope is handled at 935E) LD A,($85D0) Pick up Willy's direction and movement flags from 85D0 bit 1,a Is Willy moving left or right? RET Z Return if not bit 0,a Is Willy facing right? ;set up some data for later LD A,($85D2) Pick up Willy's animation frame from 85D2 LD BC,$0000 set no displacement in bc JP Z,rampR Jump if facing right Code would drop through to rampL Willy is moving right. ; Willy is moving left. rampR: ;rampL CP $03 OR A Is it 0? JR Z,right ; JR Z,left If so, jump to move Willy's sprite left across a cell boundary INC A ; DEC A Decrement Willy's animation frame at 85D2 LD ($85D2),A ; LD ($85D2),A RET ; RET Willy's sprite is moving right ; Willy's sprite is moving left across a cell boundary. In the comments that follow, (x,y) refers to the coordinates of the top-left cell currently occupied by Willy's sprite. right: ; left LD A,($85D1) LD A,($85D1) Pick up the airborne status indicator from 85D1 OR A ; OR A Is Willy jumping? JR NZ,nrampR ; JR NZ,nrampL Jump if so - NO RAMP ADJUSTMENT LD HL,($85D3) ; LD HL,($85D3) Collect Willy's attribute buffer coordinates from 85D3 LD A,($80DA) ; LD A,($80DA) Pick up the direction byte of the ramp definition for the current room from 80DA DEC A ; DEC A Now A=0x1F if the ramp goes up to the left, or 0x41 if it goes up to the right OR $9D ; OR $A1 XOR $BF ; XOR $E0 LD E,A ; LD E,A Point HL at the cell at (x-1,y+1) if the ramp goes up to the left, or at the cell at (x+1,y+2) if the ramp goes up to the right LD D,$00 ; LD D,$00 ADD HL,DE ; ADD HL,DE ; is the ramp undefoot ? LD A,($80C4) ; LD A,($80C4) Pick up the attribute byte of the ramp tile for the current room from 80C4 CP (HL) ; CP (HL) Is there a ramp tile in the cell pointed to by HL? JR NZ,nrampR ; JR NZ,nrampL Jump if not ; set bc for ramp downwards LD BC,$0020 ; LD BC,$0020 Prepare BC for later addition LD A,($80DA) ; LD A,($80DA) Pick up the direction byte of the ramp definition for the current room from 80DA OR A ; OR A Does the ramp go up to the right? JR Z,nrampR ; JR NZ,nrampL Jump if so ; set bc for ramp upwards LD BC,$FFE0 ; LD BC,$FFE0 BC=-32 (the ramp goes up to the left) ; before going any further check for going off screen nrampR: ;nrampL: LD HL,($85D3) ; LD HL,($85D3) Collect Willy's attribute buffer coordinates from 85D3 ; position adjust INC HL ; INC HL ; LD A,L ; LD A,L Is Willy's screen x-coordinate 0 (on the far left)? AND $1F ; AND $1F JP Z,$949E ; JP Z,$948A If so, move Willy into the room to the left; ; the above jumped room at the left/right edge ; adjust position if on a ramp - i.e move up/down - note bc=0 if not on a ramp add hl,bc ; ADD HL,BC this is the ramp adjustment ; re align the checking for walls ; DEC HL ld de,$0020 ; LD DE,$0020 Displacement for the tile below ld a,($80b2) ; LD A,($80B2) Pick up the attribute byte of the wall tile for the current room from 80B2 LD B,A ; LD B,A save wall tile value in b ; head check - to implement bug - remove the check - can do either left or right - perhaps both CP (HL) ; CP (HL) Is there a wall tile in the cell pointed to by HL? RET Z ; RET Z Return if so without moving Willy (his path is blocked) ; BODY CHECK ADD HL,DE ; ADD HL,DE CP (HL) ; CP (HL) RET Z ; RET Z ;calc new y position LD A,($85CF) ; LD A,($85CF) Pick up Willy's y-coordinate (Y) from 85CF SRA C ; SRA C Now B=Y (if Willy is neither on nor about to step onto a ramp), or Y+16 (if Willy is walking down a ramp), or Y-16 (if Willy is on or about to step onto a ramp that goes up to the left); this will be Willy's new y-coordinate ADD A,C ; ADD A,C LD c,A ; LD c,A ; now check if cell aligned AND $0F ; AND $0F Is Willy at a point in a jump (left) where his sprite occupies three rows of cells? JR Z,ramp3R ; JR Z,ramp3L Jump if not (Willy's sprite is cell-aligned) ; if not aligned check 3rd tile LD A,B ; LD A,B ADD HL,DE ; ADD HL,DE Point HL at the cell at (x-1,y+2) CP (HL) ; CP (HL) Is there a wall tile there? RET Z ; RET Z Return if so without moving Willy (his path is blocked) OR A ; OR A Point HL at the cell at (x-1,y+1) SBC HL,DE ; SBC HL,DE restore back to position before 3rd tile was checked ; adjust position back to level with the top tile ramp3R: ;ramp3L: OR A ; OR A SBC HL,DE ; SBC HL,DE ; ; and re REALIGN for top left DEC HL ; ; save data and exit LD ($85D3),HL ; LD ($85D3),HL Save Willy's new attribute buffer coordinates (in HL) at 85D3 ld a,c ; LD A,c Get Willy's new y-coordinate LD ($85CF),A ; LD ($85CF),A Save Willy's new y-coordinate at 85CF xor a ; LD A,$03 Change Willy's animation frame at 85D2 from 0 to 3 ld ($85d2),a ; LD ($85D2),A RET ; RET ;============================================== The Feature that is displayed in the movement code. When it was implemented it allowed a feature and that feature was used. It is similar to the pause bug, attic arrow bug, missing and uncollectable objects etc Whilst I think my code is correct - if I notice errors - then I will correct them. The purpose of the code is to show code being laid out as similar for both directions. ;
-
See "altered reality" for corrected Willy movement. And it does not feel strange.
-
941C JR NZ,$940E 941E LD A,($85DE) Update the counter of items remaining at 85DE, and set the zero flag if there are no more items to collect 9421 INC A 9422 LD ($85DE),A 9425 JR NZ,$942C Jump if there are any items still to be collected 9427 LD A,$01 Update the game mode indicator at 85DF to 1 (all items collected) 9429 LD ($85DF),A 942C RES 6,(HL) Reset bit 6 of the first byte of the entry in the item table: the item has been collected 942E JR $9452 Jump to consider the next entry in the item table The above (taken from a skoolkit dissasembly) shows that the variable #85de stores the playing games total amount of objects. - Start a game and change the value to #ff Then only 1 object is required to initiate the game over sequence. e.g. Maria will be gone and the jump on bed sequence can be done. A more extensive change can be done by changing the initialisation routine. This change makes every game have only 1 object to complete. 8800 LD H,$A4 Page 0xA4 holds the first byte of each entry in the item table 8802 LD A,($A3FF) Pick up the index of the first item from A3FF 8805 LD L,A Point HL at the entry for the first item 8806 LD ($85DE),A Initialise the counter of items remaining at 85DE 8809 SET 6,(HL) Set the collection flag for every item in the item table from the above it can be seen that the value at #a3ff holds the initilisation count for the objects. Setting this value to just #ff will force the game to have just one object. stored at #a4ff - Collect that one object and the can will be completed. ** NOTE. doing this does NOT remove the other objects from the object list. They still remain, but will not be active and will not be collectable NOTE. the object stored at #a4ff needs to be close to the Maria screne so it can be collected easily. For example if placed in room #00 then that room will need to be visited to collect the one and one only object. Whilst the above sets in motion a single object to collect, and initiate the game completed sequence. It is just as easy to initiate without collecting any objects. From the first listing, it can be seen that a value of #01 is inserted into the location at #85df. So start game and place a value of #1 into #85df. On entering the bedroom Maria will not be present and you can jump on the bed. A very big note. The above is for JET SET WILLY as written by Matthew. ADDENDUM. ** ignore this addendum. I was adding a point that is not important.
-
Jet Set Willy and Manic Miner "related" songs.
Norman Sword replied to Jet Set Willie's topic in Chat
A quick search - Would anyone sing a song about a "BANYAN TREE" --- it seems some one did. You can find most things..... -
[File] Manic Miner By S.P. And Bug Byte
Norman Sword replied to Norman Sword's topic in Download Discussions
I have added the extra keys used, in the file heading.- 7 replies
-
- norman sword
- rewrite
-
(and 2 more)
Tagged with:
-
Norman Sword reacted to a post in a topic:
[File] Manic Jet Set Willy V3
-
People? Concerning MJSW V3 Extracted data from JSW Central Number of edited rooms: 81 84 Number of rooms accessible without cheating: 81 84 (There is an additional room in relation to the previous versions: "Blue sky", an almost empty room (except for a flying pig) located above "Rescue Esmerelda".) Number of rooms which need to be visited to complete the game: 80 ("Entrance to Hades" should be omitted as entering it results in a multiple-death scenario.) ========================================= V3 has 84 rooms - all rooms accessible, without cheating. In V2 the original data was mainly left. This did allow strange room jumps. So for V3 I went through the data and changed the data as needed, to remove most of those strange room jumps. In some cases it was just as easy to add interconnecting rooms to tidy up the room layout. In JSW jumping up from the Watch Tower takes you to room zero. The data was not set to any logically connected room, and the data was left as zero. So jumping upward from the Watch Tower takes you to room/cavern 0. Which is defined as The Off Licence Whilst most of the wrong interconnections were simply changed to the nearest logical room. In some cases I added the undefined logical room. So now 1 jumping upward from the "Watch Tower" takes you briefly into "Tower over". Where you immediately fall back into "Watch Tower". 2 jumping upward from "Rescue Esmerelda" takes you briefly into "Blue sky". Where you immediately fall back into "Rescue Esmerelda" 3 jumping left from "Out on a limb" takes you through "Limbless". Where you fall downward into "the Front Door" and carry on downward into "The Security Guard" 4 Falling into "Entrance to Hades" will drop through into "A brief Visit" and carry on falling into "The Security Guard" Whilst playing and not taking wrong paths. The only room that should be seen, very briefly, is "Blue sky". The other added rooms are to remove infinite death loops, or to place Willy back in a more logical game map position. Falling into "Entrance to Hades" is no longer a death loop. After losing a life you will end up in "The Security Guard" - Safe to carry on. Jumping left from "Out on a limb" is no longer a death loop. After losing a life you will end up in "The Security Guard" - Safe to carry on. Note also you can do the jump from "On top of the house" and land in "Ballroom East" with the loss of one life only.
- 50 replies
-
- norman sword
- 48k
-
(and 3 more)
Tagged with: