-
Posts
618 -
Joined
-
Last visited
Everything posted by Norman Sword
-
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.
-
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)
-
Side track on those editor keyboard keys --- Which have all probably been worked out--- ************** NOTE 1 ***************** The original program that was at the beginning of this topic has been deleted. I added a piece of code just before I assembled it and then placed the code on this website. The code that I added was a bypass of the cheat code. This was done so that you would not need to have knowledge of what the cheat code is. Unfortunately that addition has made the code ( see the key combination Z H O ) Unable to remove the cheat code. ************ NOTE 2 ****************** I have attached a revised program. V2 The revised program has been modified to include (Item/key) editing This has changed the way this programs keyboard responds. *********** NOTE 3 ******************* I have attached a revised program. V3 The revised program has been modified to include 1) moving Willies start position and start animation frame in a room 2) Moving the position of the portals *********** NOTE 4 ****************** I have attached a revised program V4 The revised program has been modified to include. removal of Kong switch Bug removal of score Glitch A lot of small changes The addition of editor Mode 5 mode 5 permits altering a sprites room definition *********** NOTE 5 **************** I have attached a revised program V5 The revised program has been modified to include a means of defining a sprites room colour removed fixed colour on Kong - Still Red it it falls Rather than have multiple explanations of what the keyboard keys are. I will edit the text below. Since I have revised the code, I see no point in keeping an explanation of the old code current. (for now I will part indicate the changes) Explanation below is for V5 (Version 5) **************************************************************************** * This has not been updated to V6 - The explanation for V6 is available alongside the file in post #1 * **************************************************************************** ======================================================== 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. ===================================== At present the game starts with cheat enabled and this part editor in memory. It allows normal game play with cheat, and the ability to jump into this limited Editor. The editor does have the ability to delete/encrypt itself and turn the cheat and editor off. When that is done, it is still possible to type in the cheat code and again use the cheat. The editor and all its function will however not be available, Manic 40 Miner -- Editor While playing the game. When the game is played and the boot is shown on the lower portion of the screen. Beneath the cheat boot is the active room number. active keyboard keys for cheat. the "3" key is the cheat activator 3 - Reset the room to its start position 3 Plus 1 - Move back a room. Wrap around to 40 if on room 1 3 Plus 2 - Move forward a room. Wrap around to 1 if on room 40 3 Plus 0 - Activate the Editor (If available) Pressing the keyboard keys three and zero at the same time will enter into a limited editor. Provided the editor is still in memory ============================================================= From here onwards keyboard keys described are for the environment of editing the game ============================================================= There are a great deal of keyboard keys active. And remember that this also has the data for 40 rooms. The memory restriction placed on me due to the extra rooms, has forced convoluted keyboard key usage. In all modes (keyboard keys operational in mode 1, mode 2, mode 3, mode 4, mode 5) L - Toggle between the graphic room display and the hex room display modes K - toggle between hex with zero and hex with spaces (hex room display) J - toggle between graphic trail and no graphic trail (graphic room display) J - Toggle full screen display If in graphic room display mode - (switch Items/key, portals and sprites ) - on/off (switch graphic trails) on/off If in hex room display mode - (switch full hex) - on/off M - Toggle between the five screen edit modes 1) room tiles ------ (mode 1) - (define tile colours) 2) global tiles ----- (mode 2) - (define which tiles to use in (room tiles and edit tile)) (define item/key graphic) 3) edit tile ------ (mode 3) - (edit a tile definition) 4) edit room ------- (mode 4) - (define where the platforms etc are in a room) (define Willies start position/face direction/phase) (define the Portals start position) (define the position of keys) 5) edit sprites ------ (mode 5) - (identify sprite allocation) (change a sprite definition for the current room) (change a sprite colour for the current room) R - Move the cursor left - wraps on left edge T - Move the cursor right - wraps on right edge U - Move the cursor up - stops on the top H - Move the cursor down - stops on the bottom Q - Move to previous room W - Move to next room <ENTER> - exit room editor and resume play NOTE the purpose of allowing Graphic trails by switching the sprites on. Is so the user can see where the sprites move in any room. This enables the user to keep the rooms graphics out of their paths. ================================================= Room edit mode for room tiles (define tile colours) 1) room tiles. (mode 1) These are displayed in the lower left part of the screen There are 16 tiles, each tile is displayed as follows line 0 - The graphic as defined for the room. line 1 - The paper colour of the tile line 1 - can also have a dot displayed in the paper colour A dot indicates bright is set line 2 - The ink colour of the tile line 2 - can also have a dot displayed in the ink colour A dot indicates that flash is set line 3 - A hex digit signifying what key is designated to what graphic A room is built from these 16 tiles The cursor when moved will jump across the gaps between the upper eight tiles and the lower eight tiles. Whilst it moves it will stay illuminating the hex digits for the tile. The only method of changing the selection is via the cursor move keyboard keys. [ R-T-H-U ] active keyboard keys for room tiles in addition to the global keyboard keys (additional mode 1 keyboard keys) I - change the Ink P - change the Paper B - change the Bright - Note the dot - indicating bright F - change the Flash - Note the dot - indicating Flash all changes to the tiles will be seen instantly in the playing area ================================================= Room edit mode for Global tiles (define which tiles to use in (room tiles and edit tile)) 2) Global tiles. (mode 2) these are displayed on the lower right of the screen. 8 rows of 16 tiles in yellow. allowing access to 128 tiles The space for tiles is shared with the space for portals. The ability of expand past 128 is not included There exists a big block of empty shared memory for the portals and the tiles. When moving the cursor round the Global tiles using those pesky keyboard cursor keys.[R-T-H-U] It will be evident that the tile graphic under the cursor is displayed next to the room tiles. (middle lower left of the screen) The tile under the cursor can be selected as a room tile. Just by pressing one of the keyboard keys representing the 16 room tiles. E.g. pressing "1" will transfer that selection into position "1" of the room tiles The graphic is copied into the room and also if the room has those graphics displayed then the room graphics will also be updated instantly. *** Note *** transferring graphics into the room tile graphics does not affect any tiles colour. They are defined only via the room tile editor. Since the transfer of graphics is instantaneous, it pays to just mess around transferring graphics into the room tiles. active keyboard keys for Global tiles in addition to the global keyboard keys (additional mode 2 keyboard keys) 0 - copy current tile into graphic slot 0 - Background 1 - copy current tile into graphic slot 1 - Floor 2 - copy current tile into graphic slot 2 - Collapse 3 - copy current tile into graphic slot 3 - Wall 4 - copy current tile into graphic slot 4 - Conveyor ( moving from right to left) 5 - copy current tile into graphic slot 5 - Nasty 1 6 - copy current tile into graphic slot 6 - Nasty 2 7 - copy current tile into graphic slot 7 - Switch 8 - copy current tile into graphic slot 8 - Conveyor (moving from left to right) 9 - copy current tile into graphic slot 9 a - copy current tile into graphic slot a b - copy current tile into graphic slot b c - copy current tile into graphic slot n d - copy current tile into graphic slot d e - copy current tile into graphic slot e f - copy current tile into graphic slot f - Ignore tile (continuation of mode 2 keyboard keys) When the main screen is displaying the flashing keys e.g. when you can see the Items/keys flashing K - copy the current tile into the Item/Key graphic A note on the ignore tile (tile F). All tiles can be walked on. Manic Miner and Jet Set Willy treat any tile that is found under Willies feet as a tile that can be walked on. It treats collapsing floors as a special case. but everything thing else can be walked on. Walking on nasties will still kill you. Tile "F" is specifically checked for and deliberately ignored as a tile. What this means is that all tiles with the same colour as tile "F" can not be jumped or walked on. This does not permit the ignore tile, if it contains graphics, to be placed in the path of a sprite. That will still flag a sprite collision and result in the demise of Willy. An extra note on the ignore tile (tile F) We could use similar colours to tile 0 the background tile, to construct a platform or graphic area from. This would also be treated by the game as a platform that can not be waked on and would seem to make the need of (tile F) superfluous. Unfortunately the graphics are then treated as a background graphic, and willy passing over that graphic will change its colour, which is not what happens to every other game graphic used in conveyors, platforms, collapsing floors etc. So yes the graphics would look the same, but they will not be treated the same visually, and the difference is very noticeable. The plus side is you can define two non interactive sets of colours and willies interaction is different for the two graphically. But not in game movement. Light beams can pass through a platform generated by using the background colours. A light beam will not pass through an ignore tile. --- What happens if the ignore tile and the background are the same colour. Then the ignore tile is treated the same as the background. Willy passing in front of the tile will colour it in. A note on on Switch tiles (Tile 7). The switch tile is checked only when a Kong sprite is defined in a room. In any room that does not have Kong, this tile will act as a normal walk on tile. =============================================== Room edit mode for editing tiles (edit a tile definition) 3) edit tile - (mode 3) this is where the cursor is flashing on the graphic for the last tile that was under the cursor in Global tiles. The cursor can be moved around - space will toggle a bit on/off/on etc ***** NOTE **** all editing will affect all the graphics seen on the screen. If you are editing a tile, then if the tile is a graphic used in the room then you will see the rooms graphics changing as a result. ***** TIP ***** do not leave the sprite trails on while doing this. It is very distracting. If shift is pressed whilst moving the cursor then the tile definition will scroll. active keyboard keys for edit tile in addition to the global keyboard keys (additional mode 3 keyboard keys) space - Toggle the bit on/off/on etc shift + cursor = scroll the tile ============================================= Room edit mode for editing room layout (define where the platforms etc are in a room) 4) edit room layout- (mode 4) the top two thirds of the screen. The cursor can be moved around over the hex or graphic data. ***** TIP ***** do not leave the sprite trails on while editing tiles. It is very distracting. (and slow) pressing any of the alphanumerics 0123456789abcdef on the keyboard will place that tile on the screen at the cursor position. Because nearly all keyboard keys are active. I added the ability to lock a selection onto the keyboard space key. If a long platform is needed in say type 4 conveyors then press four on the keyboard to start the drawing off and then use the keyboard cursor keys [RTUH] along with the keyboard space key to move and deposit conveyors. (because of redraws the action is slow) active keyboard keys for edit room in addition to the global keyboard keys (additional mode 4 keyboard keys) 0 - place tile 0 at cursor location 1 - place tile 1 at cursor location 2 - place tile 2 at cursor location 3 - place tile 3 at cursor location 4 - place tile 4 at cursor location 5 - place tile 5 at cursor location 6 - place tile 6 at cursor location 7 - place tile 7 at cursor location 8 - place tile 8 at cursor location 9 - place tile 9 at cursor location a - place tile a at cursor location b - place tile b at cursor location c - place tile c at cursor location d - place tile d at cursor location e - place tile e at cursor location f - place tile f at cursor location space - place last tile selected (additional mode 4 keyboard keys) (added for V2) When the main screen is displaying Willy the portal and the keys e.g. when you can see the Item/keys flashing K - Place an Item/Key in the current position if no item/key available - request is ignored if an Item/key is already at this position - the item/key will be deleted (additional mode 4 keyboard keys) (added for V3) When the main screen is displaying the start position of Willy and the portal e.g. when you can see Willy and the Portal P - Move the portal to this position. only legal screen positions are allowed for the portal N - Move Willies start position. If already at this position then cycle through the frames and reverse. ===================================================== (added for V4) Room edit mode for room sprites (define room sprites) 5) edit sprites (mode 5) When in this mode the graphic that is normally displayed just left of the centre on the lower portion of the screen changes colour. It will change from the normal black and white with blue underlying text to one of two sets of colours 1) Red and black, (no underlying text) 2) Yellow and black (no underlying text) There will be no screen cursor. The graphics drawn in the normal graphic box will be either a "+"(plus) or a "-"(minus). The symbol shown is indicating the direction that graphics will be changed. Pressing the letter "S" will toggle the "+" to "-" or toggle the "-" to "+" If the screen is NOT showing static sprites. Then the "+" or "-" will be shown in red. Red indicates No changes can be made If the screen is showing Static Sprites. Then the "+" or "-" will be shown in yellow. Yellow indicates sprites can be changed What follows below is when the sign indicated > the "+" or "-" is in yellow. Each room has eight sprites slots. And a Guradian/sprite can occupy any of the eight slots. Pressing the digits 12345678 will flash an active sprites colours if it is in the sprite slot indicated by the digit. This is used to identify which sprite is in which sprite/Guardian slot. A number if when pressed, gives no visual indication on the screen. Is indicating that that sprite/guardian slot is not used. Having identified a sprite/Guardian, we can change the sprite/guardian by pressing the shift key and the corresponding number for that sprite. The direction of change is defined by the "+" or "-" seen on the screen The sprites can be changed, but no help is given with adjusting sprites from 8 phase to 4 phase. No help making sure that horizontal sprites are placed in horizontal definitions. And the same with verticals. No boundary restriction on where the data is taken from. This means we scan the full 32 pages , and not all are used or defined. In addition V5 adds the ability to force a sprites colour active keyboard keys for sprite edit in addition to the global keyboard keys (additional mode 5 keyboard keys) (from V4 onward) S - Change the sign and direction of change When Sign is Yellow 1 - Identify sprite slot 1 2 - Identify sprite slot 2 3 - Identify sprite slot 3 4 - Identify sprite slot 4 5 - Identify sprite slot 5 6 - Identify sprite slot 6 7 - Identify sprite slot 7 8 - Identify sprite slot 8 shift +1 - Alter sprite in slot 1 (direction of change is indicated by the "+" or "-" sign) shift +2 - Alter sprite in slot 2 (direction of change is indicated by the "+" or "-" sign) shift +3 - Alter sprite in slot 3 (direction of change is indicated by the "+" or "-" sign) shift +4 - Alter sprite in slot 4 (direction of change is indicated by the "+" or "-" sign) shift +5 - Alter sprite in slot 5 (direction of change is indicated by the "+" or "-" sign) shift +6 - Alter sprite in slot 6 (direction of change is indicated by the "+" or "-" sign) shift +7 - Alter sprite in slot 7 (direction of change is indicated by the "+" or "-" sign) shift +8 - Alter sprite in slot 8 (direction of change is indicated by the "+" or "-" sign) In addition from V5 onwards Pressing a number will up cycle the sprites colour. Used to identify a sprite slot. If the "C" key is held down then the colour is stored. The border will also change colour to match the sprites colour. added keyboard keys for V5 C +1 - Set colour of sprite in slot 1 C +2 - Set colour of sprite in slot 2 C +3 - Set colour of sprite in slot 3 C +4 - Set colour of sprite in slot 4 C +5 - Set colour of sprite in slot 5 C +6 - Set colour of sprite in slot 6 C +7 - Set colour of sprite in slot 7 C +8 - Set colour of sprite in slot 8 Method to use... Find a sprite/guardian slot with keys 1 to 8 When the sprite that needs its colour changed is found, hold down the keyboard "C" key and tap the number that corresponds to that sprite slot. The border and the sprite will up cycle colour. The colour remembered for the sprite is the border colour while up cycling and the keyboard "C" key was pressed. Subsequent changes of colour are ignored if the keyboard "C" key is not held down. This changes only one sprite's colour at a time. Not a logical or easy set of operations to follow - (the best I can do in the space I have) ===================================================== This is a global keyboard key press that changes everything (available in all modes -- e.g. mode 1, mode 2, mode 3, mode 4, mode 5) While in the editor ... Holding Z H and O <all are letters> will result in a block slowly moving across the screen. ( on a red screen this might not be noticeable) The amount of time it takes to fully activate, is deliberate. Once done all the code for the editor is deleted. The game will be put back into a standard uneditable game, without cheat activated. If this is aborted part way through the screen might need refreshing by pressing any key that updates the screen. ==================================================== The storage of the tiles was made as simple as possible. This was to enable editing from any hex editor. The rooms have no compression and are very simple to edit. The colour of each tile defines what action is taken by the game. If a tile is defined with multiple tiles in the same colour it will exhibit normal Manic Miner duplication of actions. Tile "0" is the background. Tile "1" is the standard floor tile. (can be walked on) Tile "2" is the crumbling floor tile. (can be walked on but crumbles) Tile "3" is Wall tile. (Blocks movement through it) Tiles "4" and tile "8" are conveyors in the opposite directions. The tiles are scanned on building the room to display. The positions of the conveyors are noted and copied into a list. This list has a finite size. Any more than the maximum number of conveyors will just be ignored. This means they will still be conveyors- but not animated. Tile "5" is Nasty 1 (kills if touched) Tile "6" is Nasty 2 (kills if touched) Tile "7" ( the switch tile) is also tracked when a room is built. The first two switches found in the room (scanning from the top left) are the active switches for Kong. They can be placed anywhere in the room, or even omitted. Tile "9" Free to use. Tile "A" Free to use. Tile "B" Free to use. Tile "C" Free to use. Tile "D" Free to use. Tile "E" Free to use. Tile "F" (ignore tile) is specifically checked for and deliberately ignored as a tile. What this means is that all tiles with the same colour as tile "F" can not be jumped or walked on. This does not permit the ignore tile, if it contains graphics, to be placed in the path of a sprite. That will still flag a sprite collision and result in the demise of Willy. ============================================================ Room events Editing these is not undertaken in this editor skylabs 1) Can descend or ascend 2) They can step left or right after each ascent/descent 3) The sound of crashes are selectable from a list of four 4) They can animate or stay static Light beams 1) standard light beam - down and left 2) left light beam switching on and off - down and right 3) moving light beam - down and left switching periodically to down and right 4) Light beams can be mixed and can be used in any room. Kong 1) Kong's switches can be anywhere in a room 2) the order the switches are pressed is unimportant 3) Kong can be anywhere in a room 4) Kong's distance if Fall is definable 5) The wall opening is part definable 6) It still has a fixed sprite that can pass through a fixed opening. Eugene 1) Eugene can be placed anywhere 2) Range definable Sprites/guardians 1) any type of guardian/sprite can occupy any rooms sprite/guardian slot this means you can/could have eight verticals or eight horizontals in any room 2) any type of guardian/sprite can be mixed with any other 3) Eugene is a guardian/sprite and not a room event 4) Skylabs are a guardian/sprite and not a room event 5) Kong is a guardian/sprite and not a room event ============================================================= The edit function was added as a mess around. Its purpose (to me) was to see how much code it would take to add an edit function. I ran out of space and the amount of code needed to expand the scope of editing is not available with 40 rooms as well. What it does not edit PORTALS - NO - (V3 now includes altering start position of portal) SPRITES - NO - (V4 now includes altering sprite definition) (V5 Includes basic colour changing) START POSITION - NO - (V3 now includes altering start position and animation frame) ROOM NAME - NO
-
Spotted a few errors in the above - . This is a general walk through and not specific. A room now consists of:- (This is a draft layout (A lot of data and scope for errors) and might get updated) The lines starting with > are what was originally in the room and comments on that data > Room name - original 32 bytes 32 bytes the room name - no change in data size > tile definitions (expanded from the original 8 types) - original 8 by 9 bytes - 72 bytes 16*2 bytes the 16 tile definitions *** NOTE this defines 16 tiles and not 8 as originally *** 1 byte the key definition - Originally stored elsewhere - the original was 8 bytes Carrying on through the room data > The next 7 bytes define Willies start position etc > 1 byte - The pixel y is defined by the attribute - so can be deleted > 1 byte - animation frame and direction is less than 4 bits > 1 byte - Direction and movement flags --- can be described in 2 bits > 1 byte - Airborne status > 2 bytes - Willies attribute position - can be described in 9 bits > 1 byte - jump animation counter > The macro below :- defines all the wanted data from above in two bytes WILLY 0,0,13,2 --- this defines Willy at 13 down and 2 across + various flags >The next four bytes are copied to 806F and specify the direction, location and length of the conveyor. > 1 byte Direction of conveyor > 2 bytes Location in the screen buffer of the conveyor > 1 byte Length of the conveyor The above is not needed. The room layout data contains enough information to decode the position and direction of conveyors > The next byte is copied to Border_Col_32883 and specifies the border colour. - Originally 1 byte 1 byte - Border colour ; MOST BITS used > the next byte was not used - so deleted > The next 25 bytes specify the location and initial colour of the items in the cavern >The below macro's reduce the key data from 25 to 10 bytes;- we do not need a starting colour key1 3,0,9 ;23561 ;Item 1 at (0,9) key1 4,0,29 ;23581 ;Item 2 at (0,29) key1 5,1,16 ;23600 ;Item 3 at (1,16) key1 6,4,24 ;23704 ;Item 4 at (4,24) key1 3,6,30 ;23774 ;Item 5 at (6,30) > The next 37 bytes define the portal >the portals have had their graphics moved out of the data portals reduced to 4 bytes + exterior data for the portals 1 byte defines the Attribute 1 byte gives the definition index 2 bytes the location in the attribute buffer > the next eight bytes define the object - moved to one byte after the graphic definition index data > The next two bytes define the game clock and air bar The following macro in 1 byte defines the game clock and air bar GamePeriod 63,252 ;===============Guardians=============== the space for the guardians the terminators and the guardian definitions > 4 horizontal guardians at 7 bytes each > 1 byte terminator > 2 unused bytes > 4 vertical guardians at 7 bytes each the above 59 bytes are replace by 8 by 8 byte definitions - original 59 now 64 --- more data, but allowing more scope to change order, definitions and actions. and again the guardian definitions are moved into a continuous space and indexed into ----------------------------------------------------------- The above to extract uses a lot of code. But the savings are worth the effort.
-
Space for 40 rooms. The numbers game. From this point on we start to play the numbers game. Here we look at the data and do a simple calculation on how much code is needed to compress the data. For manic Miner and twenty rooms, compression is rather pointless in most cases. To save a byte in the room data needs to take less than 20 bytes to extract from the data. In JSW the bytes saved for each room needs to take less than 60 bytes to save any memory and then we loose the nice page alignment that makes the data so easy to use. In expanding JSW to 128 rooms we now have the bigger savings. Each byte saved in a rooms data, can be offset by needing 128 of code to make the saving not worth while. 128 bytes of code is a large piece of code. Back to 20 rooms and Manic Miner. If we look at the bigger room count of 40 rooms, we can see that each byte saved in a room now can be matched against needing less than 40 bytes of code to justify its inclusion. The definitions for each tile are stored in each room. Manic miner has space for the definitions used in 20 rooms, each room storing its own tile definitions for space/floor/wall/collapse/nasty 1/nasty 2/key/conveyor. That is 8 character/tile definitions per room or 160 tile definitions in total. Manic Miner does not use anywhere near that amount of tile definitions. Scanning the data it was found to use less than 80 tile definitions. If the room count is expanded to 40 rooms. Manic Miner, if left unchanged would store enough tile definitions for 320 tiles. Whilst the original 20 room Manic Miner manages with less than 80 definitions, this suggest we have leeway in reducing the amount of tile definitions used. It would not compromise how the rooms are stored and drawn. If we undertook a massive reduction from the 320 tile definition possible, down to 128 tiles in total. From past usage this would not introduce a great restriction. Saving (320-128)*8 bytes . The problem now is now how does the room store the new data, and how much code does it take to expand out. One problem at a time. 1)The tile data is very rarely referenced. Its main and biggest reference is drawing the rooms. So the room draw routine needs changing to reference tiles in a more obscure way. The room draw routine has been changed to uses nibbles for its data, changing the room draw routine to permit tile numbers instead of the tile graphic data does not take much code. Probably less than fifty bytes. which is dwarfed by the amount of data potentially saved. 1a) The keys use the tile data to repeatedly draw the keys. It is easier and quicker to copy each rooms key data into a buffer (when drawing the room) and use that data. 1b) The storage of the graphics is separated from the room data. This changes how the room stores the graphic data. I kept the colour byte and replaced the eight definition bytes for each tile with a tile index value. This changes the original layout and reduces the size of the tile data from 64 bytes per room to 8 bytes per room. (At a later date this was expanded to use the whole 16 possible tile definitions) 1c) The room and its data size is now less than a nice page aligned value. We now need to calculate the offset to each room. Playing the numbers game. Data reduction by shifting the graphics(tile) data out of the rooms into a separate list is reduced by having to write several pieces of code and having to incorporate a new set of indexes into each room. Data lost from each room for a 40 room version of Manic Miner is 56 bytes. but we also now have a big table of data being all the tile definitions which is (128*8) bytes overall for 40 rooms the figures are. 40 rooms reduced in size by 56 bytes or 2240 bytes against adding the tile data (128*8) byes or 1024 byes + the code. It is a very large piece of code that consumes nearly 1116 bytes - it is worth the convoluted effort to use separate tile graphics The above is a start. we can compress .... (edited --- 2)
-
The purpose and scope of the routine was primarily a proof of concept. After asking myself how easy is it to edit the original Manic Miner and compress the data slightly to enable 40 rooms. I decided to take a new naked listing of Manic Miner and look at how the original stored its data. Matthew stored the room graphic layout as an attribute tile for each and every one of the 512 tiles. In JSW the tiles were stored as a bit stream of pairs of bits describing one of four types, resulting in a reduction from 512 bytes down to 128 bytes plus an eight byte overhead to describe one stair and one conveyor. Manic Miner has more tile types and two bits does not give enough scope to describe the room without more add ons. Manic Miners room layout can be described with a stream of three bits (giving enough scope for all the rooms) . But a three bit stream of data is not easy to visualise or edit, and we still need to tag on one extra bit to describe the direction of the conveyors. Easy enough to write in code- but as I said not easy to edit the bit stream when seen as data. It makes more sense and is easier to visualise if we expand to a four bit stream of data. Here each four bits corresponds to a nibble of data. Very easy to edit, easy to visualise and editable with just a hex editor Expanding to nibbles to describe a room, actually compresses the original 512 bytes of data describing each rooms layout in Manic Miner down to 256 bytes. *** NOTE *** this compression is designed to be primitive in its layout. I could compress down to a quarter of this size if I used a more aggressive method. Editing naked layout data then becomes very difficult. Once I decided on using nibbles to represent each of the tiles, it is obvious I can have more types of tiles described by each nibble. Reducing each basic room layout and definition from 4*256 bytes to 3*256 bytes still does not give enough scope to greatly expand the room count... It has released 20*256 bytes of data, which is nearly enough for seven rooms. So doing just this slight compression allows 27 rooms for Manic Miner. It would not take much effort to do this- an expansion to 27 rooms is very easy. It just needs the indexing of rooms and the drawing of the rooms to be changed. (ignoring the few data reference's that also need changing) 40 rooms needs a bit more effort.
-
The reason the game has the cheat invoked at run time, was to facilitate the discovery of the other features.
-
I will post the novelty tomorrow. It is something I have not written for Manic Miner before. The novelty was aimed at a group such as this - It was how ever not finished due to lack of space in 48k. I use an assembler and editing is just a text file to play with. Of interest - In conversation recently with Matthew I asked him about the way he edited Jet Set Willy. Due to the nature of the Tandy hex memory editor it seemed more than likely that the data was page aligned due to the Tandy's method of Paging memory displayed in the editor. This then makes each room a page on the Tandy and each piece of data is fixed in position on the Tandy screen. You can flip pages and the conveyor data for each room stays in the same place. as does all the other room data. Easy to flip through the rooms changing bits and pieces. He confirmed to me that he edited the data for each room directly in hex- no editors- no room editor- no sprite movement editor- each room was edited directly in hex. Think about editing the room shape in hex for every room- without an editor - just editing the hex. Which considering that each of the 60 playable rooms has 256 bytes editable- I find it amazing that he managed to get to the end with just one bit wrong for the arrow. The other errors are the result of not having quick and fast access to each room. The easiest and probably best method of finding errors is having the demo room flash past. The arrow problem (MIGHT) have been spotted. For manic Miner he wrote an editor - What format that took I have no idea.
-
This starts by default with cheat switched on. If edited, the cheat can be switched off . To enable a normal start to the game.
-
Changed the wording on the download file from "top 20 caverns" to "Last 20 Caverns". Questionable the depth of the caverns- because the very last cavern provides access to ground level. To jump caverns press the combination of "3" and "1" to move to a previous cavern- or press "3" and "2" to move to the next cavern. Pressing "3" resets the cavern. Each cavern has 16 tiles from which it can be drawn. Kong is movable. Multiple conveyors Switches are movable Any sprite in any room any combination of sprites in any room any event Kong-Skylab-Light beam in any room any combination of events in any room But the above is NOT what is different with this version.
-
Manic 40 Miner After I stopped developing the JSW128 VK VL VM engine. I spent a week writing a version of Manic Miner called Manic 40 Miner. This does not contain any new rooms. They are the original and Ligans rooms. This is NOT meant to be a playable version. It was just a test routine. The rooms have a lot more scope to edit and have a lot more tiles to play with. NOTE this runs in 48k the same as the original. It does a lot more than is obvious from a quick glance. ---------------------------------------------------------------- addendum. The feature that I mentioned with the comment "It does a lot more than is obvious from a quick glance." was explained in more detail in Post #14. The file size become excessive to edit online. So that explanation in post #14 is only current up to V5. I have attached a file that explains the current version here on post #1 Surprised that the earlier versions are still being down loaded. (i will delete them - they now serve no purpose) V1 was down loaded 4 times V2 was down loaded 9 times V3 was down loaded 6 times V4 was down loaded 3 times V5 was down loaded 3 times V6 was downloaded twice V6a followed by V6b fixing- specific flaws caused by one line of code deleted and an assembler problem Plus too much haste. V6c downloaded 37 times - version was not completable without editing Only the last version V6 revisions has been left. Manic 40 Miner V6 Editor Text.txt Manic 40 Miner V6c6.tap The Final final version V6c6 - this is a data changed version from V6b The version v6c6 is playable through all the 40 caverns. (other versions are not)
-
Logical progression from version to version. Main changes. Version K was a completable version introducing several aspects of game play, and 128 rooms in 48k Version L removed the superjump, which had no real purpose, and removed the live's bonus. The reason for those two changes was the introduction of a portal. This I felt was sufficiently different to justify a rename of the versions. Version L demo, updates the games structure completely. Which is the reason for the dramatic increase in speed Version L demo update. (this version has never been released) This was an update where I added a lot of (now unseen/deleted) routines that expanded the graphics. Used mainly on pause and demo. These graphic routines redrew the screen in double and quadruple size. Whilst it was interesting to write those routine. I decided I could use the memory taken up by those routines in a better way. ------------------------------------------------------------------------------------------------------------------------------------------------- The standard game and inclusive of version K has a death sequence where when Willy dies, if he has lives left. Then he is shown re-emerging into the same room. Version L changed the sequence to when Willy dies, if he has time left. Then he is shown standing in the last portal he visited. This might be a long way away from where he died and all the objects collected since visiting the portal are all reinstated into the game. This is a major change in logic, and necessitates a lot of routines to be changed ---------------------------------------------------------------------------------------------------------------------------------------------- Version M has the ability to switch between these two basic game formats. The standard "die and re-enter the room" (version K and standard format games) and the extended logic used in version L where the standard "die re-enter the room" is changed "to die emerge from portal" In order to switch between the two differing logics was to me a challenge. I needed to back track all the changes I had made and modify the code to swap logics. Version M is version "K" and Version "L" combined. So in essence it supersedes both of the earlier versions. In order to have the ability to switch the logics I needed the simple addition of a key to press and perhaps a graphic indicating what is being changed. Instead I decided to add a graphic page with options. The memory needed for the options page was taken from the double and quadruple draw routines. Which is why they no longer exist in the game. Version "M" can play in the same basic way as version "K", and also has the ability to switch to the game mode introduced in version "L". It also uses the extended logic written into version "L" demo. The options page adds the ability to start in most of the rooms. selectable for every game start. It permits the ability to switch the shooter on and off. It permits the ability to change the shooter graphics. It permits the ability to use one of sixteen predefined Willies to play the game. It permits the player to switch off the many flashing screen graphics. It adds a proper in game tune playing ability.. The options page and all the changes that necessitated in the game consumed quite a lot of memory. The memory was found by deleting the double and quadruple draw routines. It also cut short the extension of game logics. I had added quite a few and had started to add the features into the game. I think only one or two now remain and the others deleted. The Major problem I have describing changes is that familiarity to the changes blurs what is new to me. For example the cold room has twinkling stars in the room. When those stars started to twinkle and in what version would necessitate my going back through all the versions looking to find when it happened. I have better things to spend my time on, and those twinkling stars are just one of the hundreds and hundreds of changes I have done.
- 11 replies
-
- 128 room
- norman sword
-
(and 4 more)
Tagged with:
-
JSW128vM View File The logical sequence from JSW128VK and JSW128VL. The game changes are very few. This final version written very soon after jsw128VK, and has been sitting on my hard drive, for six months - awaiting further changes. Since I have decided to do other things, it has become obvious to me that this will not be updated in any way. short Condensed notes on game. 128 rooms Runs in 48k Can play In long notes for game music and not clicks triple speed multiple game options Game options menu 16 game characters to use ability to use portals ability to change start rooms extensive inbuilt cheat Cheat is activated by typing "IWroteQuip" or as spoken ( I Wrote Quip ) - without the spaces Submitter Norman Sword Submitted 12/25/2019 Category Jet Set Willy [Remakes]
- 11 replies
-
- 128 room
- norman sword
-
(and 4 more)
Tagged with:
-
Version Version 1
113 downloads
The logical sequence from JSW128VK and JSW128VL. The game changes are very few. This final version written very soon after jsw128VK, and has been sitting on my hard drive, for six months - awaiting further changes. Since I have decided to do other things, it has become obvious to me that this will not be updated in any way. short Condensed notes on game. 128 rooms Runs in 48k Can play In long notes for game music and not clicks triple speed multiple game options Game options menu 16 game characters to use ability to use portals ability to change start rooms extensive inbuilt cheat Cheat is activated by typing "IWroteQuip" or as spoken ( I Wrote Quip ) - without the spaces- 1 review
-
- option menu
- 48k
-
(and 4 more)
Tagged with:
-
1) The topic is well known about and has been discussed by various forums. 2) The graphic layout of the piano keyboard although wrong has been copied onto various other machines. It is what Matthew drew, so even though it is wrong, it has been copied with the incorrect layout. 3) The locations of the notes being played and displayed on the graphic keyboard, have no relationship to the music playing. The offsets to each note that is played is based purely on its arithmetic value and this creates a linear offset to each note. The offsets should be logarithmic. 4) The note that is highlighted never encroaches onto the upper portion of the keyboard. The parts illuminated are all identical. 5) The music played is a simple Pulse wave (square wave). Which because Matthew decided to use two waves generates a pulse wave difference. The sound you hear is the characteristic sound produced by the shifts in the values of each pulse. Similar to hearing Doppler shifts and harmony beats. The values used by the music have no bearing on how the music notes are seemingly played on the keyboard. So the values chosen were not influenced by the graphic depiction, With the consequence that no attempt was being made to avoid any part of the keyboard. The light up routine could play play a piano slide and thus light up each note in sequence if it was needed.