Norman Sword

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.

Considering the origins of Manic Miner. (from Miner 2049'er). Every time I type the full file name I am thinking Manic 49'er. So I guess that is why I would type Manic 49 Miner and not give it a second thought. Duly changed the second file to Manic 40 Miner V3 in post #1 (deleted original and uploaded new version (just to correct file name)) Its taken a long time to change a file that started out as a test file with an addition and no plans on changing it. What it did show me was I needed far more space than what was left, after the data for 40 rooms was included.

I have added "Manic 40 Miner V3.Tap" as an amended version to the end of post #1 I have revised the Manic 40 miner - editor keys in post #14 ---- Not much change I will start with a WARNING. If the program file is edited so that the first room is unplayable. Then going back to the title screen can cause a lockout of the editor. The room needs to be drawn and the first loop of the game passed before the keyboard is scanned for both the cheat code, the cheat type in, and all the editor keys. If the sprites are set to start with a collision on the first room or Willy started over any Nasty graphic. Then death will occur before any other action can take place. This means that further editing and even game play can not proceed. If the start of any other room causes instant death then the editor is still reachable via any other room, and the problem area can be changed via editing. (hopefully) It is the first room that can remove access to editing and for that reason editing the first room needs more care than any other room. I will copy the WARNING text into post #14 Noticeable change for V3 The last cavern has had a routine added that was rem'd out in my code. (a switch able room option) I assume that is noticeable that I redrew most of the title screen text. And changed yet again the title screen piano graphics.

Shuffled the data around - Included the ability to change and store animation phase. (I do not like the code I wrote- so will re write) The above worked but not to my satisfaction.... Graphic trails was the only mode that updated the screen - sprites can pass over willy and make him disappear. Fixing the rare occurrence of a sprite passing over willy is adding more and more code. Whilst it is easy to write additional code - I do not have the space to do so. Jumped the gaping pit. performed a quirkaflleg. No closer to my goal

One of the multitude of data bytes removed from the start of a room was the animation phase. Starting in a particular animation phase is a cosmetic addition, for 99% of room starts. The left and right start phase is fixed.

I added the ability to move the item/keys. The amount of code was a lot bigger than the available space. So as I stated on a previous post I used some of the unused graphic data. The problem that exists for me is that the code has had nearly everything compacted, re written multiple times and re structured multiple times. Those compaction's of data and rewrites are what has enabled me to have 40 rooms in 48k. For my own curiosity - - - - - - - I wondered how easy would it be to add more edit functions. The task of adding the code to enable such change's. First involves going through all the other code looking for areas that I can compact even further. When I have compacted further some of the code, I can then add more functions. Having spent a day just looking at the routines , I managed additional re structuring and code re writes to squeeze out a few more bytes ;------------------------------------------------------ I have added the ability to display Willies start position ------------------------------------------------------ I have added the keyboard letter "P" This additional code letter "P" allows the portals to be moved on screen. Where "P" stands for portals ------------------------------------------------------ I have added the keyboard letter "N" This additional code letter "N" allows the start position of willy to be moved. ----------------------------------------------------- I have added the ability to turn Willy to face either way on room start. ----------------------------------------------------- Just adding the code to respond to a keyboard key takes an accumulative larger and larger chunk of code. --------------------------------------------------- I can think of nothing I can add now that is feasible in terms of the amount of memory it would take to write. Each addition sounds like it would only take a simple key check to implement it into this editor. That is simply not the case. For example when allowing the re positioning of portals. The x and y positions on the screen need checking for the edges. Simple checks, but the amount of code needed just grows and grows. The above additions have not been added to the program on post #1 I am reluctant to keep adding revisions. I normally have hundreds of updates for everything I write. So this update is being held back until such time as I feel it is the last one for some time.

Key is the original description.

Z H O key combination was just random keyboard keys- as far apart as possible and unlikely to be pressed by accident. Some keyboard keys lock the keyboard and wait for release. So that group was excluded --------------------------------------------- A list of the unused keys - at present that could be used as an item/object/key/etc Y O S G Z X V N + K (used now) Y = O = Objects S = Specials - Skeleton Key I = Items (duel usage) G = Z = X = specials (as in X marks the spot) V = N = K = Keys I have no hurry to change code ------------------------------------------------------------------ A quirk on editing keys- remove all keys from the room and the portal will flash)

I have revised the revised revision of the revised revisions for the keys/items explanation. ( post #14 ) The revisions as explained below are specific to post #14 *** post #14 only deals with versions up to V5. further versions have the editor details along side the downloads in post #1 The word Key if meaning a keyboard key - is preceded by the word keyboard. The word Key if meaning a collectable Item is written as Item/key. Addendum:- If it was necessary I can do dual usage of the "I" key There is no conflict; changing (I)nk is not in conflict with changing (I)tems

Re wrote the code and made smaller. There was really no memory to add the edit key function. What I have done is delete some of the space allocated for extra graphics and portals, and used that memory for code. Revised the editor explanation code - spent a lot longer typing the revised explanations than I did to writing the code. I will shortly attach the revised code to the first post- Manic 40 Miner v2

Managed to add a key edit function. Works well enough. But I will analyse my code and possibly rewrite.