Norman Sword

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.

Item location and editing. The items are in the global table and can be edited. Position and definition --- Easy to edit in the source listing - It uses a macro for x,y,number. Since I last looked I think there was about 15 bytes of spare memory in the 48k. Not enough space to even permit the changing of the definition (or enough space to change the definition - but no easy way of showing it was changed and to what it was changed) ----------------------------------------------- In the process of going out. - I will think about this whilst out. But I can not en visualise a solution in the memory available. ---------------------------------------------

Quirk that was unknown to me before doing this.... When Ms Kong is knocked of her perch, she falls down the screen. The platform she was standing on is erased. And Kong is moved down the screen. Because it can pass over one of the lower sprites Kong has her collision detection turned off for her fall. I mention the above due to playing around with the position of KONG and the position of the switches. It became possible (and still is) to enable the KONG sprite to pass over Graphics as it falls and also pass over Willy without flagging collision. I can think of no other sprite that turns off its collision in such a way. (the toilet in JSW is always off - Kong changes from active to passive)