Cybernoid editor

1356

Comments

  • edited March 2007
    48K wrote: »
    I need to create appropriate graphics to represent the special codes E9 to FE anyway.
    I`ve made a pic of the 4 gaps of up/down enemies exactly as they appear in game, each gap is 5 pixels less than the previous, which may be a problem. Also important is the top one is the one that is positioned on the screen. Pics are double sized.
    F0-F3 (3E-45)
    F4-F7 (3E-45)
    I made the arrows myself, here they are
    ; arrow down
    	defb	$00, $00, $07, $E0, $07, $E0, $07, $E0, $07, $E0, $07, $E0, $07, $E0, $07, $E0
    	defb	$FF, $FF, $7F, $FE, $3F, $FC, $1F, $F8, $0F, $F0, $07, $E0, $03, $C0, $01, $80
    ; arrow up
    	defb	$00, $00, $01, $80, $03, $C0, $07, $E0, $0F, $F0, $1F, $F8, $3F, $FC, $7F, $FE
    	defb	$FF, $FF, $07, $E0, $07, $E0, $07, $E0, $07, $E0, $07, $E0, $07, $E0, $07, $E0
    

    To Mr. Anonymous, in Cybernoid 1 I had to change the CP 03 to CP 04 if adding another level, I can`t find the check when the level changes in Cybernoid 2. Doesn`t need one?

    Also thanks for the info on the sound. I`ve been banging my head trying to get the sound fx without the music, so that the menu can be changed to Music On/Off, instead of Sound On/Off on the 128k.
  • edited March 2007
    FrankT wrote: »
    in Cybernoid 1 I had to change the CP 03 to CP 04 if adding another level, I can`t find the check when the level changes in Cybernoid 2. Doesn`t need one?

    The initialize is at #634B and the level is updated at #F1FE. The AND #03 means that once you reach level 5 it will start again with level 1 data.

    Level No.
    =======
    00,01,02,03 (1st four levels)
    04,05,06,07 (same data as above)
    08,09,10,11 (same data as above) and so on...
    FrankT wrote: »
    I`ve been banging my head trying to get the sound fx without the music, so that the menu can be changed to Music On/Off, instead of Sound On/Off on the 128k.

    Remove the following. NOP them.

    #6544 CALL #EF42 ;This is the main one.

    #8201 CALL #EF42 ;This one occurs if you press '6' to toggle the sound. At #81F3-#81FA you will see it do the toggle.

    #83BB CALL #EF42 ;This one occurs if you enter the 'YXES' cheat on the redefine the keys option. At #839A-#83A1 you will see it removing the dec (hl).

    You can do it after a game has started but press '6' to toggle the sound. If you aren't sure if the sound is on anymore you can check the location of #830A (1=on, 0=off). All you need do then is to update the text in the menu.

    EDIT:
    Just thinking that's not actually what you mean. You still want the facility to turn the music on should you so desire. This would do that> Now toggle stops the music only.
                    org #81f6
    		defb #e6
    
    	        org #81fd
    		defb #dc,#fd
    
                    org #fddc
    		
    		call #ef3b
    		ld a,(#6543)
    		or a
    		ld a,1
    		jr z,miss
    		xor a
    miss	      ld (#6543),a
    		ld (#8200),a
    		ld (#83ba),a
    		ret	
    
    
  • edited March 2007
    (Break on #81BF and change to LD HL,#2000 at #FB86 ouch!

    I dunno, I quite enjoyed that! :D
  • edited March 2007
    Now toggle stops the music only.
    Hooray, sound fx without the music as it should be. Why would anyone want a silent game? I moved the new toggle music routine to #EECA because my level table is at #FDDC, seems ok.
    This is some serious debugging and bug fixing. Thank you, I`m learning loads too.
    Edit:
    #EECA is amongst the hive bullets gfx. Using #64EE instead, hopefully its unused space.

    2nd Edit:
    I`ve made a bug-fixed Cybernoid tzx for anyone that wants it, with just the hi-score bonus bug and music toggle fixed. I moved the music toggle code to #74C9 (the 3 levels tables of 24bytes). I moved the 24 byte level table to #FC00, there is lots of space to add more levels here. Also in this version all the blank screens are gone and the mapdata and maptable recompiled.
    I used my slowload maker for the loader.
    Cybernoid Bug Fixed
    I`ve played through it a little, seems to work ok.
  • 48K48K
    edited March 2007
    Hi Frank, I can't get your .tzx to load in FUSE at all. Your previous snapshots have been fine.

    Edit. My mistake - I need to turn off all the automatic loader options to get tzx to load. Looks good! Very flattered by the Hall of Fame :-) - but yes, Mr Anon, is the real star of this crack, without him, I don't think this project would have got very far at all.

    Edit 2. p.s. thanks for the lift graphics, unfortunately, I cannot think of an easy way to incorporate them. Last night, I too, made some new lift graphics: see below. Drawing the full lifts will be problematic in BASIC, so I am thinking of just these graphics to display the upper lift.

    http://i22.photobucket.com/albums/b339/ETamm/Cybernoid%20Editor/Liftnew.png
  • edited March 2007
    Nice one Frank! If you're struggling for space you'll be able to do the business on the character set to gain a few bytes.

    character set #C2F1 (8 bytes per char)
    ==============================

    #C3F1 SPACE....................#C4F9 A
    #C3F9 EXCLAMATION..........#C501 B
    #C401 QUOTES..................#C509 C
    #C409 ?UNUSED?...............#C511 D
    #C411 ?UNUSED?...............#C519 E
    #C419 ?UNUSED?...............#C521 F
    #C421 ?UNUSED?...............#C529 G
    #C429 APOSTROPHE...........#C531 H
    #C431 LEFT BRACKET.........#C539 I
    #C439 RIGHT BRACKET.......#C541 J
    #C441 COPYRIGHT.............#C549 K
    #C449 PLUS......................#C551 L
    #C451 COMMA...................#C559 M
    #C459 MINUS....................#C561 N
    #C461 FULL STOP..............#C569 O
    #C469 BACKSLASH.............#C571 P
    #C471 0...........................#C579 Q
    #C479 1..........................#C581 R
    #C481 2..........................#C589 S
    #C489 3..........................#C591 T
    #C491 4..........................#C599 U
    #C499 5..........................#C5A1 V
    #C4A1 6.........................#C5A9 W
    #C4A9 7.........................#C5B9 Y
    #C4B1 8.........................#C5C1 Z
    #C4B9 9
    #C4C1 SEMICOLON
    #C4C9 COMMA
    #C4D1 LESS THAN
    #C4D9 EQUALS
    #C4E1 GREATER THAN
    #C4E9 QUESTION MARK
    #C4F1 AT

    There must be a fair few of those on the left that are never used plus there are four (32 bytes worth) that look unassigned.
    48K wrote: »
    but yes, Mr Anon, blah blah
    Rubbish!
  • edited March 2007
    48K wrote: »
    thanks for the lift graphics, unfortunately, I cannot think of an easy way to incorporate them. Last night, I too, made some new lift graphics: see below. Drawing the full lifts will be problematic in BASIC, so I am thinking of just these graphics to display the upper lift.
    I could draw new lift graphics that are shifted, so 2 tiles for each lift in its shifted position. Then when you place the top lift, your program could draw the lower one with a gap of 2 tiles below it for the 3 largest gaps, gap of 1 for the smallest gap. It will need 8 tiles for all 4 lift sizes though.
    Nice one Frank! If you're struggling for space you'll be able to do the business on the character set to gain a few bytes.
    I hacked the loader and found that there is no more code after #FC00 for the main game block. #FC00 is the address of the loader itself.
    I had another brainwave. But this time it may not be do-able.

    To add another pick-up item! There must be a way to reverse engineer the ammo box, mace or rear gun items. So that one can assign a code for the mapdata (E8). My idea is to have a key item that removes a certain tile from the map, this tile removed could be a door for example. Would have to make a new map with interconnecting rooms, and possible make it so that you can re-enter the room you just left. Very ambitious I know, but it would add playability.
  • 48K48K
    edited March 2007
    FrankT wrote: »
    I could draw new lift graphics that are shifted, so 2 tiles for each lift in its shifted position. Then when you place the top lift, your program could draw the lower one with a gap of 2 tiles below it for the 3 largest gaps, gap of 1 for the smallest gap. It will need 8 tiles for all 4 lift sizes though.
    Yes, I realise it can be done this way during editing, the problem will be:
    1/ ensuring it does not foul other tiles - or if it does it will overwrite them, and if so, deciding what takes precedent in the final screen data:
    2/ Correctly displaying the lifts when the "draw screen" routine redisplays a previously edited and stored screen containing lifts. The routine would either have to perform a double pass of all the screen codes (the second time looking only for lift codes), or load the coordinates into a temporary table during the first pass, and then fill in from there. Both will be slow in BASIC.
    3/ additional problems if you place the lift too low in the screen (similar to 1/).
    I am interested in keeping it simple/bug free (if not completely polished) for now. These things can be added in an .asm sequel ;-).

    More important to me at the moment is placing the tiles into a more user friendly order, and implementing a crude cut-and-paste.
    FrankT wrote: »
    I had another brainwave. But this time it may not be do-able.

    To add another pick-up item! There must be a way to reverse engineer the ammo box, mace or rear gun items. So that one can assign a code for the mapdata (E8 ). My idea is to have a key item that removes a certain tile from the map, this tile removed could be a door for example. Would have to make a new map with interconnecting rooms, and possible make it so that you can re-enter the room you just left. Very ambitious I know, but it would add playability.

    An excellent idea, and one that could really extend the game. The difficulty I foresee is implementing this temporarily in a per-game, or even level specific manner. Perhaps this would just require a reset routine after each level/game - hey why not hijack the music data area? Doesn't this reset each game?

    Cracks to allow reentry into rooms would be welcome (although it would alter some gameplay challenges). But remember that all graphics will be reset when entering a room for the second time - including blocks removed by shooting them etc.
  • edited March 2007
    The 2 tiles below are blank for the 3 largest gaps, so couldn`t you have the bottom 2 tiles for the bottom lift as null tiles. So if the 2 new tiles are say E1 and E2 for codes, to write 00 when it finds E1, E2 etc on the scan.
    I`m only saying this because I just finished making the graphics.
    Lift graphics asm

    Also for my new pick-up item idea, was to get a key to access the end of level room. If the end of level room door was in the start room, you`d have to visit all the screens to get the key and return the way you came, doing the level backwards. Could have it so when the key is picked up, it will allow you to re-enter the previous room only for the room with the key.
  • 48K48K
    edited March 2007
    FrankT wrote: »
    The 2 tiles below are blank for the 3 largest gaps, so couldn`t you have the bottom 2 tiles for the bottom lift as null tiles. So if the 2 new tiles are say E1 and E2 for codes, to write 00 when it finds E1, E2 etc on the scan.
    I`m only saying this because I just finished making the graphics.
    Lift graphics asm
    Yes, but it depends on what order you display the tiles on the screen. As I said before, for the ediotr, it is not _so_ difficult, I just have to decide what takes precedent: inserted tiles for the lift (e.g. does it overwrite with 00 or not). The bigger problem is when the editor redisplays a screen that is stored in memory (allowing reediting to be performed). Currently it reads the codes row by row and displays the graphics accordingly. Upon finding a lift code, it could display the lift graphic, but then these would get overwritten as the routine displays subsequent rows of data (even if that data is 00 ). Also if might be nice to be able to place shootable blocks betwen the upper and lower lifts for gameplay features etc. The solution is to display the lift graphics after everything else, but that requires either a double pass of the screen display routine, or a temporary storage of the lift co-ordinates during the first pass.
    I'm not saying that I won't incorporate the graphics (I like them, and ideally I'd like to use them - well ideally I'd like the lifts to animate in real time within the editor;-) - but it just may be too complex to work it out without bugs).

    Below is my proposed reorganisation of the tiles. I have tried to group related things together. Comments are very welcome.

    Proposed new codes layout
  • edited March 2007
    48K wrote: »
    Also if might be nice to be able to place shootable blocks betwen the upper and lower lifts for gameplay features etc
    I`ve tried this, the lifts don`t collide with anything on the inside edges, collision detection is only on the outside edges.
    48K wrote: »
    Below is my proposed reorganisation of the tiles. I have tried to group related things together. Comments are very welcome.
    The gun turret (#52, #53), should be next to #50, #51 as the turrets are drawn in the original game. Everything else looks good. I thought of a good graphic for #EC to #EF, a little space invader and a big arrow for the direction they enter the screen, it doesn`t matter where these are placed in the screen.
    Graphics for EC-EF;
    EC, ED, EE, EF
    EC-EF source Cybernoid format.
  • edited March 2007
    FrankT wrote: »
    I hacked the loader and found that there is no more code after #FC00 for the main game block. #FC00 is the address of the loader itself.

    Don't know if this is any use but I've had a go at removing the custom loader from ftp://ftp.worldofspectrum.org/pub/sinclair/games/c/Cybernoid.tzx.zip and here's the result:

    http://www.zshare.net/download/cybernoid_basic_loader-tap.html

    This leaves the memory above $FC00 free for your own use.

    EDIT: Actually I've just thought, it should be possible to write a BASIC program to remove the loader by calling the appropriate loader routines and saving the code blocks from BASIC, rather than farting around in an emulator debugger. I'll have a look later and see if I can sort something out.

    EDIT 2: Ah, I've just realised that I hadn't read the thread properly and a BASIC loader version probably wasn't needed after all (I misunderstood what FrankT was saying about the loader being at $FC00). Ah well. I'll crack back under my rock now, unless a BASIC program to dump the code would be useful?
  • edited March 2007
    You should also try talking to 'Blackbeard' at the forums. He created the great Bombjack level designer and also a Commando editor. The Commando editor was a bit too complex for me but its amazing what he can do
  • edited March 2007
    psj3809 wrote: »
    You should also try talking to 'Blackbeard' at the forums. He created the great Bombjack level designer and also a Commando editor. The Commando editor was a bit too complex for me but its amazing what he can do

    That would be "badbeard", or as he's more commonly known.... Mr Anonymous :-)

    Shit, I hope I've not blown his cover...

    D.
  • 48K48K
    edited March 2007
    Finally, I understand:
    This thread makes a fantastic read - thanks 48K and Mr. BB ;).
    :)
    FrankT wrote: »
    I`ve tried this, the lifts don`t collide with anything on the inside edges, collision detection is only on the outside edges.
    What a swiz. I'd thought up some interesting uses. Do they collide when their outside edge hits the block? e.g. do they overdraw a tile completely and then bounce back?
    Edit: I see that they do not do that either :-(
    BB ;-), any interest in finding/altering the relevant code that checks for lift collisions, so that both inside and outside edges are checked?
    FrankT wrote: »
    The gun turret (#52, #53), should be next to #50, #51 as the turrets are drawn in the original game. Everything else looks good.
    I wanted to put all the special firing graphics together. And so I grouped all the wide pillars together as well. These are quite wasteful of space. Part of the gun turret: $50/51 is almost identical to $A6/A7.
    FrankT wrote: »
    I thought of a good graphic for #EC to #EF, a little space invader and a big arrow for the direction they enter the screen...
    Very cute. :)
  • edited March 2007
    Dunny wrote: »
    That would be "badbeard", or as he's more commonly known.... Mr Anonymous :-)

    Shit, I hope I've not blown his cover...

    D.
    You've mentioned it once but I think you got away with it...
    I wanna tell you a story 'bout a woman I know...
  • edited March 2007
    FrankT wrote: »
    Also for my new pick-up item idea, was to get a key to access the end of level room. If the end of level room door was in the start room, you`d have to visit all the screens to get the key and return the way you came, doing the level backwards. Could have it so when the key is picked up, it will allow you to re-enter the previous room only for the room with the key.

    You'd only want access to previous rooms whilst holding the key or free roaming regardless? The latter would save around 30 bytes at a glimpse. Just updated your fixed tzx a tad to get a drift of the idea. Download here. You have to pretend you have got the key atm and enter the value manually. Poke #C409,0 (default) for no key. Poke #C409,1 to hold the key.
  • edited March 2007
    You'd only want access to previous rooms whilst holding the key or free roaming regardless? The latter would save around 30 bytes at a glimpse. Just updated your fixed tzx a tad to get a drift of the idea. You have to pretend you have got the key atm and enter the value manually. Poke #C409,0 (default) for no key. Poke #C409,1 to hold the key.
    Thats bloody amazing;)
    Only access to previous room whilst holding the key I think is best. Although if the free roaming could be stopped once you leave the room with the key(as an option), you`d have to go in the reverse direction only, which would be good too.

    Been thinking that if needed you could use memory in the mapdata area. Probably get a whole 1k if the available screens were cut by 10 or so. Else make it 128 only and use the ramdisk for the mapdata, loaded one level at a time.
    Seeing that this is possible has given me even more ideas! Wouldn`t it be great if we could pickup the key like the ball in thrust! hehe, only joking.
  • 48K48K
    edited March 2007
    Good work Mr A. However, there are a number of caveats to allowing room reentry. One is the potential to allow multiple pickups of ammo boxes by reentering a room over and over again. It also allows you to escape an onslaught of enemy fire...making the game less tense. It certainly makes it easier, but in this kind of game the challenge is normally what keeps you coming back for more. In a similar way, you can keep reentering a room until it has the least aggressive aliens to deal with (since the choice of alien is random). On balance, I think you lose more than you gain - and it isn't actually necessary for Frank's idea, which is to allow both room reentry, and to pickup an item that unlocks (removes) a specific tile from the map - thus opening up passageways that were previously blocked. This could add direct access to an otherwise blocked level exit, or to completely new areas of the map.

    If, as Frank suggested the "key" would just unlock the exit, which was in the starting screen, but locked, an easy way to allow you to retrace your steps, whilst preventing direct screen reentry is to put in a simple screen loop in the level map. e.g. you fly all the way in one direction through the map. Then at the end, four screens are linked in a circular loop, one of which contains the key. After flying around the loop, you are free to fly round it again, or instead, retrace your steps to the exit :-)

    In fact, with careful level design, you wouldn't even need to implement the key/lock tiles - the exit could just be in a segregated part of the screen:

    e.g.example

    You cannot access the exit until you fly around the loop and come all the way back. In fact, I think this might be my first screen!

    Now I must stop this wibbling and get finished on the editor :-), we've got an entire game to design!
  • edited March 2007
    I understand about the respawning of the ammo boxes and weapons etc, it is a problem, but my original thought was to only allow re-entry to the room you left which had the key in it. i.e.
    Enter room, its a dead end, pickup the key, allow re-entry to previous room, remove door tiles from map, exit room, stop allowing re-entry to previous room. So the key will only allow you to re-enter once. But that shouldn`t stop you having more than one key per level. One idea i had for a level was to have 3 doors on the map in different screens which access a challenging room, 2 rooms for ammo/weapons with a key in each room to allow exit as it will be a dead end, and 1 room with the exit. So you`d have to fly to the end of level, get the key which opens all the doors, fly back, enter the bonus rooms looking for the exit door. It will allow you to open up hidden areas on the map as well as having dead ends.

    Nice screen! And editor is looking very nice.
  • edited March 2007
    Another hatchet job which is a bit bloaty atm. Poke #AACF,1. Then go out of the room and come back in.
  • edited March 2007
    Another hatchet job which is a bit bloaty atm. Poke #AACF,1. Then go out of the room and come back in.
    Superb, you`ve managed to get collision detection between lifts as well as a tile being removed from the map, these hacks will really enhance the gameplay and variety.
    Does the tile that disappears get read as the screen is drawn from the map, with a new map tile code that when it reads D9 for example to draw said tile if #AACF=1, or just poke the mapdata?

    If it would be possible to use the ramdisk for loading each level 1 at a time, I figured a maximum of 50 screens per level would be plenty, this would use a generous 5500 bytes for compressed screens on average, 34 screens uncompressed, leaves 2242 bytes free at 47920. And of course the map table would need loading with each level which gives 48 bytes free as well.
    Also, if the levels were loaded with the ramdisk, it could load a new success screen with each level at 30609, 78 bytes long maximum.

    I`ll have finished the new door and key graphics soon, I replaced the floor standing hive gun thing with the Cyan/White gun from Cybernoid 2 and made a new alien sprite. The animated sprites are 4 frames of 24x16, each frame shifted 2 pixels. Been designing a level on old fashioned pencil and paper.
  • edited March 2007
    FrankT wrote: »
    Does the tile that disappears get read as the screen is drawn from the map, with a new map tile code that when it reads D9 for example to draw said tile if #AACF=1, or just poke the mapdata?

    It's just straight into the map data. Here's another (same idea). This time poke #46 into #A854, #A860 and #A876. Go out and come back. Any item can go in there.
  • edited March 2007
    Tile #7A isn`t used anywhere in the standard Cybernoid levels. Also #09 and #0B are both the same graphic. Here is a new tzx with a crude gate and key graphic.
    Gate/Door is #0B, Key is #7A.
    This version is the same as the high-score bug fix and music toggle fix version with the new graphics added and maps patched to use #09 instead of #0B. You won`t see the door and key in the standard levels.
    Cybernoid newgfx tzx
    I suppose it all hinges on whether a new pickup item can be put in.
    Edit:
    Screenshot of door and key.
    p.s.
    Can you tell us how you achieved the collision detection between the lifts? I want to add it for my levels.
    Thanks
  • edited March 2007
    Yes I'd better. It still needs work to be done to get it smaller. Maybe Woody or someone can come up with a five byte fix :)
    Only shootable objects in there atm please.

    Important points to note.

    ORG 2+4 need changing. Put them in the map area for now. Org 1+3 need to remain as shown but must point to ORG's 2+4.
    [size=1]
    		org $9050
    		defb $50,$91
    
    		org $9150
    		ld e,(ix+0)       ;going up
    		ld d,(ix+1)
    		ld b,d
    		ld c,e
    		call $69e6
    		call nz,$9137
    		ld e,(ix+5)
    		ld d,(ix+6)
    		ld b,d
    		ld c,e
    		call $69e6
    		call nz, $9137
    		ld e,(ix+0)
    		ld d,(ix+1)
    		ld b,d
    		ld c,e	
    		jp $906b
    
    		org $9053
    		defb $80,$91
    
    		org $9180
    		ld e,(ix+5)    ;going down
    		ld d,(ix+6)
    		ld b,d
    		ld c,e
    		call $69c4
    		call nz,$9137
    		ld e,(ix+0)
    		ld d,(ix+1)
    		ld b,d
    		ld c,e
    		call $69c4
    		call nz, $9137
    		ld e,(ix+5)
    		ld d,(ix+6)
    		ld b,d
    		ld c,e	
    		jp $90d8
    
    [/size]
  • 48K48K
    edited March 2007
    OK, tonight I've been beavering away on the editor, which has made it to version 0.6.

    The big change (and challenge) was reorganising the tile graphics data into the order I proposed a day or two ago. This also required creating appropriate lookup tables so that correct codes get inserted into the screen data areas during editing, and so that correct graphics tiles get drawn during screen display.

    After much fiddling, I'm happy to report that it all seems to work fine :) The downside is that redisplaying a previously edited screen is now 160 PEEKs slower than it was before (due to having to reference the lookup table once per tile). But on balance, I think the more structured organisation during editing is worth it.

    It does not yet include the newly drawn graphics for the special codes. I'll put those in as the next job. Then I just need to finish up the compressor, implement a screen moving tool in the map editor, and write some basic input stuff for level/ship specific data and we are done!

    Here is a screen capture of version 0.6 showing the tiles in the new order.
  • edited March 2007
    48K wrote: »
    The downside is that redisplaying a previously edited screen is now 160 PEEKs slower than it was before.
    You could try compiling it with MCoder III. It made my very slow basic mapdata compressor program a bit quicker, which was all PEEK and POKE.

    Here is the source for the cargo bonus score fix, music toggle fix, lifts collison fix and re-enter rooms hack. I worked out what was done for the re-enter rooms hack. Makes things easier shifting code about with it all labelled in one file. The poke to enable room re-entry(key_enable) is at $FCAA, its set to 0 in the source.
    Cybernoid fixes/addons asm.

    Edit:
    I just worked out how to destroy/explode part of the scenery when a certain block is exploded next to it Can explode walls for exits! Need sleep now, i`ll do more digging tomorrow.
  • edited March 2007
    I wonder what Raffaelle Cecco would make of all this?
    I wanna tell you a story 'bout a woman I know...
  • edited March 2007
    karingal wrote: »
    I wonder what Raffaelle Cecco would make of all this?

    That could be the quest for our forum - find Raf Cecco and ask him :-)

    Now, where to start?

    D.
  • 48K48K
    edited March 2007
    FrankT wrote: »
    You could try compiling it with MCoder III. It made my very slow basic mapdata compressor program a bit quicker, which was all PEEK and POKE.
    Thanks for the tip. Well for now, I just run the editor at 500%. Do you think that is too lazy? :) I can't see the program easily becoming a standalone editor that works on a real Spectrum, anyway (it'll run, but extracting the new codes and patching them into the Cybernoid game will be very difficult). I am treating this as a program for the emulator generation. This morning, I've thought of a couple of ways of optimising the screen display routine - but which are faster: IF statements or PEEKs/POKEs...?
    FrankT wrote: »
    Here is the source for the cargo bonus score fix, music toggle fix, lifts collison fix and re-enter rooms hack. I worked out what was done for the re-enter rooms hack. Makes things easier shifting code about with it all labelled in one file. The poke to enable room re-entry(key_enable) is at $FCAA, its set to 0 in the source.
    Cybernoid fixes/addons asm.
    Thanks. I actually think the easiest way for people to use the editor will be to distribute it complete with the hacked copy of Cybernoid as a .tap/tzx which is augmented for patching-in the edited screen/map codes that you can export from the editor

    For version 2.0, i would like to get the Cybernoid game code in an upper memory area (in a 128K machine), and perform direct POKEd modifications to this, allowing export of a single binary patch file from the upper memory area. This will be much more user friendly (but that is not going to happen any time soon!).
    FrankT wrote: »
    Edit:
    I just worked out how to destroy/explode part of the scenery when a certain block is exploded next to it Can explode walls for exits! Need sleep now, i`ll do more digging tomorrow.

    Fantastic! I didn't even play around with placing the destructible blocks yet. A very interesting finding, and not at all what I was expecting!

    Edit: So the only blocks I could find that trigger an explosion are the first tile of the relevant screen graphic.

    e.g.
    $23 (top left of static plant thing) destroys tiles to the right, and the two below
    $27 (top left of hive gun) destroys tiles to the right, and the two below
    $2B (top left of static gun thing) destroys a tile to the right and diagonally to the right below
    $30 (top left of hanging hive gun) destroys tiles to the right, and the two below
    $A0 (top left of large static plant thing) destroys tiles to the right, and the four below

    Occasionally I get a corrupted attribute tile as a result of the demolition of scenery - need to look into this to check the editor is not at fault.

    It seems that whenever any of these special tiles are placed, the others become sensitive to destruction. e.g. you do not need to specifically target these tiles with a bomb/mace etc, only place them in the screen, and the tiles that are mapped to be destroyed can also trigger the destruction of the whole set.

    Most other screen tiles get destroyed - including gun emplacements, and animated blocks. Pickups do not get destroyed. Volcanoes get destroyed, but continue to erupt.

    You have to be a little careful about placing triggers next to each other - placing a short row of $2B causes the demolition routine to go haywire:

    Look at: before and after I shot the plant at the bottom. This effect is carried over into subsequent screens too.
Sign In or Register to comment.