Norman Sword

Level of difficulty:- The screens seen are just outline screens from screen 5 onward. I can do most of the screens easily. The ones I can not do easily I will redo. I tend to not use the obscure Manic Miner movement quirks and prefer to just set a task which can be seen and attempted in an more or less obvious manner. Since the Title is Manic Panic, I had intended to set the Oxygen level to near the time taken to do a casual run. In a move towards ease I will allow the player to set an easy level. (already done) where the oxygen is set to full for every cavern. Rather beats the sense of Panic if each room can be done whilst drinking a cup of tea and reading the newspaper. The game as written does allow sprite contact and many other instances that should result in Willies demise, with lots of oxygen at the players disposal. It will make a lot of screens complete-able whilst doing the crossword in the paper as well. Programs by me. I am responsible for nothing else. Manic miner by Bug byte and software projects. Which plays exactly the same as the original. Manic 40 Miner - a demo of 40 screens for Manic Miner- it was just to show it could be done. JSW128VK 128 rooms in 48k (changeable speed) JSW128VL 128 rooms in 48k Double speed and portals (changeable speed) JSW128VM 128 rooms in 48k -triple speed and a whole host of game options (changeable speed) In JSW128VM the game has a built in rewind function (via portals). Manic Panic is just an idea to demonstrate the capability of the game engine stretched further than Matthew accomplished. The demo as seen is one weeks work. ------------------------------------------------------ Final game version accessible This Link

The copying of screens. Yes I could update just the areas changed. Just a lot easier to just block move. If you remember, the original logic as penned by a certain M. Smith. In that It was deemed fast enough to LDIR everything. For screen updates we have to update other areas as well . So it took a few goes at just updating the pixel area. Most routines were changed to update both at the same time. for example the conveyor routine draws to both the master and the working screen. The collapsing floor draws to both the master and the working screen. Wall removal as done by Kong's association is done on both the master and working screen. The instances were glitches showed an update was not being fully copied, forced the dual draw. Getting the code to work was enough to curtail enthusiasm to extend to the attributes as well. feedback. Update the slow attribute copy routines. :D The spiral room, which is around screen 24, is not in the file I uploaded. The final screen has been changed as well. The screens as seen can/could all be changed. ----------------------------------------------- final game version accessible This Link

The answer might surprise you. Guardians do not interact with anything on the screen. Guardians over fire cell- no response. Guardians over another Guardian- No response. Guardians over graphics- No response. ;------------------------------------------ Major change in design for willy and the sprites Manic miner and Jet set willy sprite logic:- (idealized model for sprite collision) 1) Willy is moved according to the program flow and keyboard activity. 2) Willy is drawn 3) The sprites are moved 4) The sprites are drawn. 5) For each sprite drawn the area behind the sprite is checked for pixel collision. 6) If a collision is flagged we exit and die else 7) copy the screen to visible screen (pixels and attributes) 8) copy the master screen (the screen with graphics, but no sprites) to the working screen. 9) copy the master attributes to the working attributes loop JSw2 uses a very different logic for most aspects of the game Jsw128 Vm uses a similar type of logic to jsw and MM but each routine is expanded and instead of part 8 we do a sprite and graphic refresh. The graphic refresh is achieved by tracking every change that occurs on the screen. And storing every change. The list of changes is used to refresh the screen. Manic panic;- does the following 1) Willy is moved according to the program flow and keyboard activity. 2) Willy's mask area is erased from the screen 3) The sprites are moved 4) The sprites are drawn. 5) 6) > Willy is drawn to the screen, checking for collisions. Any collision is flagged 7) copy the screen to visible screen (pixels and attributes) 8) > the sprites are reverse drawn: e.g. Instead of drawing a sprite we copy the master screen to the working screen for the area the sprite was in > willy is reverse drawn. e.g. Instead of drawing willy we copy the master screen to the working screen for the area that Willy was in 9) copy the master attributes to the working attributes loop The above is mainly concerned with sprite collision, of course lots of other bits and pieces. Concerning updates to conveyors, walls erased, item key flashes and portal update, oxygen depletion etc. also take place. The sprites themselves are treated as a moving graphic on the screen. They do not check for anything when drawn. This brings collision detection more in line with JSW2. And using this method I could do eggoids from JSW2 The above is the basic logic change. The program itself does most aspects which can be described by the same action in differing ways. For example the screen copy progression from version to version MM and JSW a simple LDIR JSW128Vk raster copy using ldi (originally) JSW128VL stack copy JSW128VM stack copy and the whole of memory reorganized to removed memory contention while copying. ( a very big change) Manic 40 Miner stack copy and the removal of memory contention for screen copying. Manic Panic stack copy and the removal of memory contention for screen copying. ;------------------------------------------------------------------------- Final version accessible This Link

Whilst I was aware of the technicalities of the loader from Technician Ted, never felt the need to load the game and watch it. The TITLE screen in this program (as above) is about the tenth version. And the basis of what you see is simply the game it is based on. A lot of screens have horizontally moving sprites. I duplicated a screen for the title screen. Then reduced the sprites to only one (Willy). Then removed the diagonals. then the colour. The overall plan was to give no clue as to what you will later see. For example after the mega long scrolling message the program will do a manic miner style flash past of all the screens that you have played (plus the first). It will not reveal un played screens. The more screens played, the more that are included in the demo loop. I have no plans on uploading multiple versions, especially since I have tested the program without the port read on the +2a etc and it runs. The generosity of oxygen will make a lot of the screens very easy. This supply of oxygen will not end up as generous when I finalise the screens. When the program runs for each cavern it initialises a counter. For every game loop it increases the counter. When the portal is entered I can display the counter. Which is the time taken to complete a room. The final oxygen level will be set to the value of the counter plus a small amount. (the counter and its display output are one of the multitude of in program routines, which are in the program, waiting to be deleted on finalisation)

Technical info:- The oxygen meter has a progressive rate of depletion. The lower the level the faster it moves. The oxygen depletion caused by any of the normal death instances, causes a fixed amount of oxygen depletion. What this means is a touch of a sprite at the start of playing a room, will have much more of an effect than the same touch near completing a room. When the true oxygen levels are set. any contact/death noise near the start of playing a room, will tend to make it impossible to finish the room. Each type of contact with a sprite/baddy/ or fall will deplete the oxygen by an amount that is fixed for each type of touch/fall. Sprites can pass over any other sprites. Sprites can pass over anything on the screen. Willy is now drawn with a sprite mask Sprites correctly colour in the background Each room can be constructed of 16 differing tiles. A development from Manic 40 Miner Rooms can have ignore tiles. A development from Manic 40 Miner A proportionally spaced double height scroll routine is used. Rooms can be defined as any size to fit the screen. (or part of) nine baddy sprites per room eight objects per room Sprites can be mixed in any combination old style events such as eugene/kong/skylab are sprite definable and not room events. sprites can move diagonally. all sprites have a vertical and a horizontal component. (excepting kong/skylab/eugene) ------------------------------------------------------------------------ final version accessible This Link

I know exactly why this program will not run on other machines. It concerns the way the hardware ports are read. One reason I was reluctant to include the routine. (it stops judder- or helps to) - I can remove and permit the judder instead. Regarding the Title screen - Never loaded Technician Ted on a computer, so never seen the title screen. from that game. On a real (original) spectrum it is possible to read the screen attributes. On the various updates the port/ula was changed and the ability to read the port was removed. It is the reason several games will not run on newer hardware. Final comment on the hardware - I removed the routine that was added and was scanning a port. The original version ran a lot faster. And the speed made the Title screen Judder. Over several versions, it was deliberately slowed down. The difference in speed between what is seen and the original is considerable. The present slow version has no need for the port scanning routine. ------------------------------------------- Final version accessible via This Link

This file is mostly playable. It is NOT the finished product, and basically I am posting here for feedback. In most caverns you are given far too much oxygen. The oxygen level has not been definitively set. No music routine playing. It needs music- It contains enough space for music routines. No loader screen. various screens from game. Title screen Intro screen - 16 wide / 9 high = 144 tiles Trainer screen - 22 wide / 16 high = 352 tiles Peril size screen - 20 wide / 19 high = 380 tiles Manic style screen - 31 wide / 16 high = 496 tiles (normally 512 tiles) Game playing screen - 31 wide / 23 high = 713 tiles After a week the file that was here- was deleted. The file was downloaded 11 times. 7 posts in the week that followed. ;---------------------------------- The final Version which is playable is:- This Link

Talking about the Final Barrier in Manic Miner. and graphic matching using the CPIR code. (re write to clarify) 1) When the final barrier is drawn. The top part of the room contains graphic data. Which is also interpreted as the colours for the room. The room is then expanded out after matching these graphics colours. They are colours from the picture, but the room draw routine will interpret tham as room graphics The colours are not intended to match the room graphics, they are the colours of the picture but the CPIR routine will still try to match the colours. From memory I think the top graphic data has more than 9 differing colours. Checking one of my source code lists . The top part has around 18 differing graphics- so in every case the graphics will not match the room graphic colour data. So in every case this would. if unchecked. possibly scan all memory. 2) If the CPIR steps past the last known graphic, and onto stair data etc. Then it indicates that the loop should be shortened to stop on the last known graphic,

I will correct the notion that it does a search. It uses an algorithm that does not do any searches. it places known data from a fixed position into a fixed position. It also removes the major bug that stops duplication of colours that should allow differing graphics, if specified. E.g. in JSW (out on a limb) we specify a stair and a platform to have the same colour. Using the method I use will allow a stair to be drawn as well as the platforms. NONE of the methods listed elsewhere will permit this to happen

The portal routine as now:- Used by the routine at 870E. First check whether Willy has entered the portal. 8FC5 LD HL,($80B0) Pick up the address of the portal's location in the attribute buffer at 5C00 from 80B0 8FC8 LD A,($806C) Pick up the LSB of the address of Willy's location in the attribute buffer at 5C00 from 806C 8FCB CP L Does it match that of the portal? 8FCC JR NZ,$8FDF Jump if not 8FCE LD A,($806D) Pick up the MSB of the address of Willy's location in the attribute buffer at 5C00 from 806D 8FD1 CP H Does it match that of the portal? 8FD2 JR NZ,$8FDF Jump if not 8FD4 LD A,($808F) Pick up the portal's attribute byte from 808F 8FD7 BIT 7,A Is the portal flashing? 8FD9 JR Z,$8FDF Jump if not 8FDB POP HL Drop the return address from the stack 8FDC JP $9028 Move Willy to the next cavern Willy has not entered the portal, or it's not flashing, so just draw it. 8FDF LD A,($808F) Pick up the portal's attribute byte from 808F 8FE2 LD (HL),A Set the attribute bytes for the portal in the buffer at 5C00 8FE3 INC HL 8FE4 LD (HL),A 8FE5 LD DE,$001F 8FE8 ADD HL,DE 8FE9 LD (HL),A 8FEA INC HL 8FEB LD (HL),A 8FEC LD DE,$8090 Point DE at the graphic data for the portal at 8090 8FEF LD HL,($80B2) Pick up the address of the portal's location in the screen buffer at 6000 from 80B2 8FF2 LD C,$00 C=0: overwrite mode ;-------------------------- The changed code preceded by -. on each line -.8fc5 ld de,(#80b0) ; portal address to de -.8fc8 ld hl,(#806c) ; will att to hl -.8fcb or a -.8fcc sbc hl,de ; a collision sets the zero flag -.8fce ex de,hl -.8fcf ld a,(#808f) ;the portal colour -.8fd2 jr nz,part2 -.8fd4 pop hl ; we clear the stack -.8fd5 bit 7,a ; decide if portal or death -.8fd7 jp nz,#9028 ; next cavern -.8fda jp #8d0f ; the kill routine -.8fdd nop ; spare 5 bytes -.8fde nop -.8fdf nop -.8ff0 nop -.8fd1 nop part2 8FE2 LD (HL),A Set the attribute bytes for the portal in the buffer at 5C00 8FE3 INC HL 8FE4 LD (HL),A 8FE5 LD DE,$001F 8FE8 ADD HL,DE 8FE9 LD (HL),A 8FEA INC HL 8FEB LD (HL),A 8FEC LD DE,$8090 Point DE at the graphic data for the portal at 8090 8FEF LD HL,($80B2) Pick up the address of the portal's location in the screen buffer at 6000 from 80B2 8FF2 LD C,$00 C=0: overwrite mode ; the problem that I see with doing this is the vagueness of the collision detection. An outline :- subject to typing errors and miscalculations. plenty of space to fit the code.

The routine is still playing a linear keyboard. The only changes are the compression of the data, the redrawing of the keyboard, the full key light up and removal of the silent keyboard light ups. Long time since I looked at the routine. A quick glance does indicate I could change to a key reference lookup quite easily. E.g. permit each note to designate a value for its true key position. Not something I would bother to do.

Having no memory to change the code, has made progress very very slow. Which adds to a lack of enthusiasm from me. For every idea I can think of, no matter how small. A change is needed in the main code to allow the addition of extra code to permit the idea to take place. This would have been far easier if I had not included a part editor... Which took all the the space normally used to expand game ideas. The file included here, is included solely for the changes I have done to room 23. Whilst other code changes have taken place. They are not visible or have little effect on what is experienced. Room 23 whats in it that's different to Manic Miner This room has a moving light beam Has a moved Eugene, different graphics. This Eugene routine can specify which item Eugene reacts to, or reacts when all collected. This room has multiple Kongs Each Kong can define where it removes a wall section from Each Kong is movable in position Each Kong has a definable drop Each kong has a definable definition. (no other definition is provided in this file) Each Kong has a definable colour Has a skylab Skylab moves upward - definable either way Skylab has a definable crash sound - definable from 4 Skylab has a definable image and animation stages (not provided in this file) Skylabs can step backward or forward Note most of the above can not be changed via the limited game editor: I am demonstrating what can be done. Or more specifically what I can change. -------------------- Addendums:- problem solving to be completable 17th August 2021 : Manic 40 Miner V6c1.tap modified room 21 - removed the conveyor collapsing floor added an extra collapsing floor just above the portal ================================ 17th August 2021 : Manic 40 Miner V6c2.tap modified room 21 - added an extra collapsing floor just above the portal collaspsing conveyor floor left as in V6c ============================== Game completeable version V6C6 - this allows the game to be played through all 40 caverns, without editing. Manic 40 Miner V6c6.tap

I think this might be the final version. Listed as Complete game .... I have not uploaded it to verify https://highriser.itch.io/the-perils-of-willy?fbclid=IwAR0qnZNHEXY9hQHEar6tVZWNU-6N_kcCpvCwiaoN8S5eOFsVyy7M2HP6m2U

Try the above or the below - both the same https://www.dropbox.com/s/icnp3lby4xfdzin/PerilsOfWillyDemo1.zip?dl=0&fbclid=IwAR22yghpOlmRHGUGaP6XHcQXlQ4vUNxctXIhzSBpy3LndmizuSoCrVDHkgY

The program has progressed. The demo as mentioned above : via a drop box - THIS IS A Z80 zx spectrum game file - playable https://www.dropbox.com/s/icnp3lby4x%E2%80%A6/PerilsOfWillyDemo1.zip'>https://www.dropbox.com/s/icnp3lby4x

And the version 6a won't work until I remove the additional check for logic flow. The phase change is rem 'd out Now version 6b - 3 in one day

Eventually found the problem...A deleted opcode. The direction of change indicated by the "+" or "-" symbol was added to the graphic index. Well it was until I deleted the opcode. I have just swapped to a new Pc. I need to swap back to my old Pc keyboard or reconfigure the editor a bit better. This Pc has some very strange buttons on it, or more specifically buttons in places I never had buttons before. The one I do not like is having a button to turn the Pc off, situated on the keyboard. Pick the keyboard up, accidentally brush against a sticking out memory stick on the destk top unit, and the pc suddenly switches off. (who ever thought that was a good idea, must have missed the on - off button that desktop units have) I have managed to turn this Pc off, just by pushing the keyboard up against the main unit, and have a usb memory stick turn the computer off .....

Re changing sprite in v6- downloaded the version that is present in post #1- no problems---

Placing platforms in a room has been substantially improved. By changing a lot of code and logic order. Added a Phase change in Mode 5 - pressing "P" changes phase on horizontal sprites. Mode 5 uses colour to indicate options. yellow(editable), red( not editable) Blue background(8 Phase ) Black Background(4 phase) These changes are not notified, because to me they are one of thousands of changes I will make. And as mentioned in post #'48 that version is already obsolete due to a flaw.

In every version up to now that has a mode 5; The "+"(plus) sign or the "-" (minus) sign would change to red if the sprite was un editable. Graphically I have forced a distinction between yellow and editable and a big five in red saying < Yes you are in mode five. But I can not allow editing whilst displaying the hex screen or the graphic trail screen> change display till the "+" or "-" are seen. This version is flawed- I have found a flaw in the assembler which has introduced problems. The assembler can sometimes incorrectly value a variable, with the wrong value. E.g. A-B should be the same as -B+A. or written another way that removes it from looking like assembler opcodes. X-Y should equal -Y+X. What has happened is during a re-write of variables I changed some around. ( a layout change) ld hl, Flag-100 should be the same as ld hl,-100+Flag The assembler for thousands of these type of calculations has no problem. But I have found in the last check I did. That the assembler can sometimes give the wrong answer. What the parameter for the error is. Is not going to be investigated further. I have written giga bytes of assembly using this assembler. And I have found a problem on less than a handful of occasions.

I am amazed I have got this far without the collection sound being included. I had written the code a long time ago, just never bothered to call the routine. -------------------------------- That was yesterday. And today having revised around 1700 lines of code / comment/ data. I have added a new key "C" in mode 5 The figure of 1700 for the lines of code/comment/data, show what started as a trivial add onto the program, is now consuming a lot of memory. What follows are very quick and rough figures. Size wise the code is just over 1.5K for the editor To put that in perspective:- The code for Manic 40 Miner without the data is around 4.75k A quick look at the original Manic miner , gives a code size of around 3.5K. Which shows the trade off between having nice simple data layout, and compressing everything in sight. So I have added around 1.25k in code just for the compression of data. ----------------------------------------------------------------------------------------------------- The addition of 1.25k in game code, plus re- writes of most of the other code, has permitted the addition of 20 more rooms and the addition of more features. Plus I have also managed to have 1.5k of free space (used by the editor) as well. Without the extra code and compression, those extra 20 rooms would need an extra 20k of space. That would somehow need to be fitted into the unused memory from #934c to #9d00 around 3.25k ---------------------------------------------------------------------------------------------------- The end result is, after juggling the figures around. I have fitted the extra 20 rooms in 1.75k of the memory that was free. ----------------------------------------------------------------------------------------------------

The guardians can occupy any slot in any order. Matthew's data layout, is complicated by the addition of two control codes into the data. If zero skip, if #ff then end. Editing a colour needs to check for past end of enabled sprites. The 00 skip colour or the #FF terminator. Try doing that in less than five bytes. Ld hl,data ld de,offset --- out of memory

I ran out of memory way back in version 1 since then I have added:- 1) the ability to define the keys used in a room 2) the ability to delete keys in a room 3) the ability to add keys to a room. 4) the ability to move portals 5) the ability to define the start position of willy 6) the ability to define the start phase of willy 7) the ability to identify which sprite uses which sprite slot 8) the ability to increment a sprite page in a sprite slot 9) the ability to decrement a sprite page in a sprite slot. The above are editor specific additions. I also added a variable tune speed playing routine I can not keep adding routines to Ram I do not have. --------------------------------------------------------- When editing in mode 5: The colour indicated when pressing a numeric key is only to identify which sprite occupies which sprite slot. The colour change is not stored. Evident if any drawings is done then the sprite will revert back to the colour it is defined as. Last time I looked there was about five bytes of memory left. The figure for memory left changes with each edit of the code. It looks very tempting to enable sprite colour changing. But even if the space available was around 50+ bytes, I can see no way of enabling such a change, and I have repeatedly tried. Bar a major re-think on this code. There will be no more additions. I will look for quirks and flaws and sort them out. --------------------------------------------------------- Re -organised memory to place all the game data in a continuous block and not variable depending on code.

Attached to the end of Post #1 version V4 Changed text in Post #14 to reflect the change from earlier posts. The amount of data that can be changed is immense, and every time I add something it reinforces to me the vast scope of options that can be edited and are not editable by this part game editor. Quick list:- Portals colour- definition sprites phases - colour - direction - min - max - start -step -colour change - adding - deleting specials Skylab - phases - sound - direction - min - max - step specials Eugene - phases - min - max specials lightbeams - any activations music speed room names editing sprite definitions editing portal definitions Etc Perhaps the space occupied would be better suited to game additions after I actually created a proper set of rooms.

The original file was written in a week, mainly due to using the available space and copying routines I had written elsewhere. As stated elsewhere the main purpose was to show how easy it is to extend past 20 rooms, with just a slight compression of the room data. I added bits and pieces and posted the result V1,V2 and then V3. Re visiting the file and playing around with editor, I became aware of the inability to progress past KONG. The Kong routine had been tested repeatedly and worked, yet try as I might, I could not get the second switch to trip without dying. Looking at the code gave no clues, until I spotted a line of code I had added at the very last minute to implement a red Kong as Kong fell. The simple instruction to change the colour. One instruction, also turned on sprite collision and instant death. So as can be imagined it took just changing the value of that one instruction to fix the problem. Several other problems were found and removed I rewrote a lot of routines, that gave up a few more bytes of memory. I have used that space to add a mode 5 onto the four existing room edit modes Mode five is a bit convoluted and not much help in editing a game. It was added because I could. To enable mode five:- Stand on your left leg and using your right arm place your right elbow on your nose. with your left hand touch your left knee and chant "Jet set willy edit thee" 3 times. then... Not as bad as the above, but close to it. Mode five allows very primitive and very very unhelpful changing of individual sprites in a room. This only allows the definition to be changed and does not adjust the sprites basic parameters to match. So an improved version 4 with a few flaws removed is next.