IRF Posted January 30, 2017 Report Share Posted January 30, 2017 (edited) It might have been usable, with some optimisation, if I'd spotted it early enough in the development of WNM-SE. No matter! Edited January 30, 2017 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted March 1, 2017 Report Share Posted March 1, 2017 I think the CP #FF at #96A3 could be replaced with an INC A (saving one byte). I previously mentioned some similar savings here: http://jswmm.co.uk/topic/196-dont-mind-your-head-while-walking-left-bug-fix-for-jsw/?p=5802 And I originally got the idea from J.G. Harston's second Pause Bug Fix, as listed here: http://mdfs.net/Software/JSW/JGH/Docs/Pause.htm (I still think that's the most elegant Pause Bug Fix, even though Jonathan has recently added SkoolKid's more byte-efficient solution to the list.) jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted April 4, 2017 Report Share Posted April 4, 2017 (edited) There are a few instances in the JSW code where the following sequence of commands are used: LD A, (#0000) INC A LD (#0000), A That's seven bytes in total. This can sometimes be replaced with the following four bytes (saving three bytes): LD HL, #0000 INC (HL) e.g. the updates within the Main Loop to the game's internal 'ticker' (#85CB), or to the Music Note Index (#85E1). EDIT: And to the Jumping Animation Counter in Move Willy (1). N.B. This approach couldn't be used in circumstances where the HL register-pair is currently in use for another purpose (e.g. to update the Game Mode Indicator during the course of the 'Draw the items' routine), without bookending with PUSH HL and POP HL (which negates two of the three byte saving). EDIT: in circumstances where the program subsequently does something else with the updated variable, then you'd have to follow the above with LD A,(HL), thus reducing the saving to two bytes. Edited January 28, 2018 by IRF Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
Metalmickey Posted April 5, 2017 Report Share Posted April 5, 2017 thinking about the Moonlight Sonata theme music, there's a lot of repetition there, could there not be a way to make that routine more byte efficient? or has that been tried before? Quote Link to comment Share on other sites More sharing options...
IRF Posted April 5, 2017 Report Share Posted April 5, 2017 Any savings you might make, may be eaten up by the extra code required to set up a loop to perform the repetitive bits? jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted April 5, 2017 Author Report Share Posted April 5, 2017 It's not been tried before, TTBOMK, and I doubt there could be much saving, because the repetition is limited. I mean, you may have five notes (values) which are the same as a little bit later on, and then one note (value) which is different. Even though the five are repeated, say, four times, the one different note following them is always different. So making the sequence of five notes repeat but with the one note at the end different each time would be quite tricky, I think. Please note I'm just writing it off the top of my head to illustrate (what I think is) the problem. The info about five notes and then one note is most probably inaccurate, I'm just using approximate numbers to illustrate the pattern. I'm not sure how much spare space you need, but there is quite a lot of it in the original "JSW". SkoolKid shows most (although not all) of it. In the Special Edition of "Willy's New Mansion" we (meaning Ian and myself) have pushed its use to the limit, I believe, trying to use up every single byte of spare space plus introducing various space-saving optimisations to the original code. "WNM SE" Readme documents it thoroughly, so probably you might find some ideas there if you really need some more free space in your project :ph34r: . Metalmickey and IRF 2 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted April 7, 2017 Report Share Posted April 7, 2017 (edited) The number of posts means I have not read most of them. This routine expands the graphics as a room is entered ROOM ATTRIBUTE FIX and SPACE SAVER org 8d33h ; start is 8d33h 36147; end of this is around 8da6h 36262 (lower since mods) ; end of Matthews code 8dd2h 36306 ; size is less than 115 bytes saves 44+ bytes L5E00h equ 5E00H ;ROOM ATTRIBUTESL7000h equ 7000h convey_len equ 80d9hconvey_add equ 80d7hRamp_len equ 80DdhRamp_add equ 80dBhRamp_dir equ 90DahBack_Tile equ 80a0hChar_print equ 9699h ;969bh in my assembler wrong address given (label was moved) ; note ****; This routine uses only one call; NO repeated push/pop due to poor register allocation. (in one example I have seen); 100% elimination of all attribute cell block drawing effects; permits multiple graphic definition with the same colour (attribute) **; ** Matthews code will still give stair/ramps ramp/stairs stair/floor etc;; saves around 44+ bytes Draw_Room ld de,8000h ;room definition ld HL,L5E00h ;5e00h the room attributesEXPANSION ld b,4 ;four cells per byte ld a,(DE)exp rlca rlca ld c,a ;temp save "a" and 3 ; values 00b,01b,10b,11b (types) ld (hl),a ; write the type into the cell ld a,c ;restore "a" inc l djnz exp ; repeat for the byte (4 cells) inc de jr nz,EXPANSION ; first 256 done inc h ; this second check is done twice in the 512 loop bit 5,h jr z,EXPANSION ; part 1a) add conveyor tiles (if any). LD A,(convey_len) OR A JR Z,No_Conveyor LD HL,(convey_add) LD B,Aconvey_set LD (HL),5 ; write TYPE 5 =CONVEYOR into this cell INC L ; The conveyor animation routine also does inc l/inc e DJNZ convey_set ;part 1b) add ramp tiles (if any)No_Conveyor LD A,(Ramp_len) ; the only reference to this data in the whole program OR A JR Z,DRAW_TILES ld b,a LD HL,(Ramp_add) ; LD A,(Ramp_dir) ; LD DE,-33 ;primary change here is for clarity OR A JR Z,Ramp_set INC E INC ERamp_set LD (HL),4 ;write TYPE 4=RAMP into this cell; this does not check for screen bounds (or ramp length) ADD HL,DE DJNZ Ramp_set ; ; NOW EXPAND AND OVERWRITE/DELETE THIS DATA ;L5E00H holds the TYPES in each cell THIS WILL BE OVERWRITTEN BY THE TYPES attribute from its definition; THE GRAPHICS WILL ALSO BE EXPANDED TO THE COPY SCREEN;part 2) expand the room definition into a graphic and attribute definitionDRAW_TILES ld ix,L5E00h ;start of the TYPE DATA:- CHANGED as each one is read TO COLOUR DATA ld de,7000h ;graphic buffer where the graphics will be drawnloop ld a,(ix) ;get THE TYPE from its cell LD B,A ;calculate the graphic (tile) ADD A,A ADD A,A ADD A,A ADD A,B ; 9 bytes per graphic entry LD HL,Back_Tile LD C,A LD B,0 ADD hl,bc ; the first byte is the graphic (tile) colour ld a,(hl) ; the TILES colour attribute ld (ix),a ; overwrite its type in the attribute buffer with the graphic attribute INC IX ; next source (attributes/type/cell) inc hl ; move from graphics attribute to the graphics definition ld c,d ; temp save d call Char_print ; (what the routine at char_print does) ;char_print ; ld b,8 ;draw_me ; ld a,(hl) ; ld (de),a ; inc hl ; inc d ; djnz draw_me ; ret; calculate the next char ld a,d ;save modified d ld d,c ;restore d inc e jr nz,loop ld d,a ;reload the modified d cp high(L7000h+1000h) ; 80h defined this way for clarity jr nz,loop ret Edited November 26, 2018 by IRF IRF and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted April 8, 2017 Report Share Posted April 8, 2017 (edited) ;In the above I mentioned the conveyor animation org 38137 ;animate conveyor :skoolkit comments L38137 LD HL,(32983)z38140 LD A,Hz38141 AND 1z38143 RLCAz38144 RLCAz38145 RLCAz38146 ADD A,high (7000h) ;112z38148 LD H,Az38149 LD E,Lz38150 LD D,Hz38151 LD A,(32985) ;Pick up the length of the conveyor from 32985z38154 OR A ;Is there a conveyor in the room?z38155 RET Z ;Return if notz38156 LD B,A ;B will count the conveyor tiles ;>added;>code from here is moved INC H INC H ;point hl to third graphic row z38157 LD A,(32982) ;Pick up the direction of the conveyor from 32982 (0=left, 1=right)z38160 OR A ;Is the conveyor moving right? ;>changed ;z38161 JR NZ,L38182 Jump if so jr,z,L38163 ;** changed from the incorrect L38316 :>added ex de,hl ;The conveyor is moving left. (or right)L38163 LD A,(DE) ; Copy a pixel row of the conveyor tile to Az38164 RLC A ;Rotate it left twicez38166 RLC A ;>deleted ;z38168 INC H ;z38169 INC H z38170 LD C,(HL) ;Copy this pixel row to Cz38171 RRC C ;Rotate it right twicez38173 RRC CL38175 LD (DE),A ;Update the first and third pixel rows of every conveyor tile in the screen buffer at 28672z38176 LD (HL),Cz38177 INC Lz38178 INC Ez38179 DJNZ L38175z38181 RET ;The 1 added instruction and slight change in logic flow ;removes the need for the code below 9 bytes shorter ;>deleted ;The conveyor is moving right. ;L38182 LD A,(HL) Copy the first pixel row of the conveyor tile to A ;z38183 RRC A Rotate it right twice ;z38185 RRC A ;z38187 INC H Point HL at the third pixel row of the conveyor tile ;z38188 INC H ;z38189 LD C,(HL) Copy this pixel row to C ;z38190 RLC C Rotate it left twice ;z38192 RLC C ;z38194 JR 38175 Jump back to update the first and third pixel rows of every conveyor tile ;-------------------------------------------------------------------------------------------------; Edited April 4, 2018 by IRF jetsetdanny and IRF 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted April 8, 2017 Report Share Posted April 8, 2017 (edited) jr,z,L38613 I presume that should read "Jr z, L38163"? (Jumps forward by one byte to skip the EX HL, DE command.). EDIT: That should have read EX DE, HL. That would be a usefully-placed optimisation in Manic Miner, as it would allow the insertion in situ of a test of the Conveyor length ("Is it zero? If so, RET"). Thus allowing a cavern to have no Conveyor animation without corrupting the screen. (In the existing MM code, if you don't have a Conveyor in a cavern, then you have to insert a 'hidden' one, at least one byte in length, within an Air cell. Because the routine that animates the Conveyor interprets a Conveyor length of zero as a length of 256 bytes!) Edited November 20, 2017 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted April 8, 2017 Report Share Posted April 8, 2017 (edited) ; note **** ; This routine uses only one call ; NO repeated push/pop due to poor register allocation. (in one example I have seen) ; 100% elimination of all attribute cell block drawing effects ; permits multiple graphic definition with the same colour (attribute) ** ; ** Matthews code will still give stair/ramps ramp/stairs stair/floor etc I think Geoff Eddy's games may take a similar approach. Certainly there's a room in which there are two ramps, drawn in opposite directions. However, getting both ramps to behave as they should in terms of Willy's movement along them (and the pixel-height at which he is drawn whilst on a ramp) requires a Main Loop Patch Vector approach, to vary the Ramp Direction Byte in the room buffer as Willy's horizontal coordinate changes within the room. Edited October 2, 2017 by IRF Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.