Nukey Shay Posted September 18, 2004 Author Share Posted September 18, 2004 BTW since the use of a "skeleton key" by this method would allow more doors than we really have time to deal with, you could make one or two of them into seperate locks with seperate keys using the extra ram. Think ""Master Key" ala Zelda. Just edit the KeyOffsets line to add or remove custom keys. Quote Link to comment Share on other sites More sharing options...
EarthQuake Posted September 19, 2004 Share Posted September 19, 2004 Wow, I like these little (heh, little) tutorials you keep putting out. As soon as I get Odyssey in a stable form, then I will start working on a distributable HTML version of these. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 19, 2004 Author Share Posted September 19, 2004 Incidentally, putting text messages into the game does not cost any ram at all. But it does burn an object number (so watch the overhead...there can only be 32). Here's how you do that... Up top...define a new label for the message... Author2Number = Author2Data - Objects And paste a new line in the object matrix...directly below the Author data... AuthorData: .word AuthorInfo,AuthorCurr,AuthorStates .byte $CB,$00;Author Signature #$04 Flash, Small Author2Data: .word Message2Info,AuthorCurr,Message2States .byte $CB,$00;"Welcome to Hell" Flash, Small Note: You can keep using "AuthorCurr"...unless you want it to be animated. Then, fill in the labels with data in an open area of memory...filling in the labels for the GFX address, room number, and X/Y location... ;Object #4 : States Message2States: .byte $FF,<GFXmessage2,>GFXmessage2 ;State FF at &FD88 ;Object $4 : Author's Name Message2Info: .byte $21,$50,$69 ;Room 21, (50, 69) Then create a bitmap... GFXmessage2: .byte $A8 ;X X X .byte $A8 ;X X X .byte $FA ;XXXXX X .byte $07 ; XXX .byte $E2 ;XXX X .byte $A2 ;X X X .byte $E0 ;XXX .byte $87 ;X XXX .byte $E5 ;XXX X X .byte $07 ; XXX .byte $80 ;X .byte $80 ;X .byte $C0 ;XX .byte $05 ; X X .byte $E7 ;XXX XXX .byte $85 ;X X X .byte $E0 ;XXX .byte $07 ; XXX .byte $E5 ;XXX X X .byte $A7 ;X X XXX .byte $E4 ;XXX X .byte $07 ; XXX .byte $F8 ;XXXXX .byte $AA ;X X X X .byte $AA ;X X X X .byte $03 ; XX .byte $E0 ;XXX .byte $A2 ;X X X .byte $E2 ;XXX X .byte $82 ;X X .byte $E3 ;XXX XX .byte $00 And that's all there is. So you can get an idea of how all these changes affect the game, here's a copy of it. This last little step filled in all available rom space in the 4k image...so I'm going to have to use a new file for the examples anyway 7 dragons. One is orange (to make it harder to see in the catacombs), and one is grey (to make it invisible against the background). 7 gates...using 2 keys. The black key will only open black gates...and the flashing key opens flashing gates and secret wall panels There are 4 regular black gates, 1 flashing gate, and 2 wall panels. The gates are on castle bitmaps...so there's 5 castles in all. The magnet and the dot must be used together at one of the panels to get the chalise...and when you do, the dragons will ressurect themselves (so high-tail it out of there!). I'm not sure if game #3 is winnable (because I didn't test all of the random variations)...but game #2 definately is. adventure_hell.zip Quote Link to comment Share on other sites More sharing options...
EarthQuake Posted September 19, 2004 Share Posted September 19, 2004 This WILL slow the game down a small amount...but not by an annoying amount. What was just done is that the main loop now has extra time to execute added routines. You'll have enough time to move 2 dragons above the added DoVSYNC, and 2 more above the added PrintDisplay. Let's put a new JSR to move the black dragon just above the DoVSYNC... IMO, YOU ARE WRONG... heh... I felt like an old man when playing your hack! Adventure is a fast paced thriller. If you take away something vital like the speed at which it plays, then the gameplay is seriously altered. But, if you are insane enough to put 7 dragons, 3 bats, 9 castles, and 10 keys in Adventure, then you deserve to be punished one way or another. Anyways, since I only added the one dragon, there is enough time to work all four of them without having to sacrifice game speed. I tried it out, and everything seemed to work fine. Four dragons. Fast gameplay. Ownage. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 19, 2004 Author Share Posted September 19, 2004 Interesting. It used to get rumbles when attempting that...but not anymore (probably due to the program's smaller size now...200 bytes is quite a lot of code). Here's some changes to speed things up... From the main game loop... JSR PrintDisplay ;Display the room and objects. ;6 ;added lines LDY #$00 ;Allow joystick read - all movement. ;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR MoveBlackDragon ;Move and deal with the Black dragon. ;6 JSR MovePurpleDragon ;Move and deal with the Purple dragon. ;6 JSR DoVSYNC ;Wait for VSYNC. ;6 JSR MoveOrangeDragon ;Move and deal with orange dragon. ;6 JSR MoveWhiteDragon ;Move and deal with white dragon. ;6 JSR PrintDisplay ;Display the room and objects. ;6 BNE MainGameLoop ;always branch ;2 That bumps up the player's speed. Then the opponents can be altered by changing the deltas (the value of Y before MoveGameObject is jumped to). Here's the bat's... MoveBat: INC BatR+4 ;Put Bat in the Next State. ;5 LDA BatR+4 ;Get the Bat State. ;3 AND #$07 ;Has it Reached the Maximum? ;2 STA BatR+4 ;(reset to zero when bit 3 is reached) ;3 LDA BatR+6 ;Get the Bat Fed-Up Value. ;3 BEQ MoveBat_3 ;If Bat Fed-Up then Branch. ;2 INC BatR+6 ;Increment its value for next time. ;5 LDA BatR+3 ;Get the Bat's Movement. ;3 LDX #BatR ;Position to Bat. ;2 ;changed Y from 3 to 4 LDY #$04 ;Get the Bat's Deltas. ;2 JSR MoveGroundObject ;Move the Bat. ;6 JMP MoveBat_4 ;Update the Bat's Object. ;3 ;Bat Fed-Up MoveBat_3: LDA #BatR ;Store the Bat's Dynamic Data Address ;2 STA Delta1 ; ;3 ;changed Y from 3 to 4 LDA #$04 ;Set the Bat's Delta. ;2 And all of the dragons can be speeded up by just changing the value of Y in their headers. Example: ;Move the Red Dragon MoveRedDragon: LDA #<RedDragMatrix ; ;2 ;changed Y from 3 to 4 LDY #$04 ; ;2 LDX #RDragonNumber ;Select Dragon #1 : Red ;2 BNE MoveDragon ; ;2 Slight problem with this is that the player moves slightly faster than it should. I'll have to add in something to limit the movement perhaps 1 frame out of 8 or something (kind of easy to outrun everybody currently). Thanks for pointing it out adventure_hell.zip Quote Link to comment Share on other sites More sharing options...
EarthQuake Posted September 19, 2004 Share Posted September 19, 2004 I was wrong about there not being any problems. I noticed that if two or more items were occupying the same vertical space on the rightmost side of the screen, the screen would blink. I didn't catch this before... Anyways, although you increased the player speed in your last binary, the gameplay is still heavily affected. The dragons move significantly less smoother, and everything from the gates opening to the sounds being played, are reduced in speed. It doesn't seem possible for Adventure to handle much more than 3 dragons without having to sacrifice something. I think unless there is some major rewrite of how the main loop handles the dragons movement, we should just stick to having only the three. Speeding or slowing things down just really throws off the perfect balance of the game. It's too accurate to mess with. Also, a question: If the main loop was altered to handle more at once, but there was no addition to the dragons or objects, would the engine appear to run faster than normal? (Just the opposite of what's happening now) Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 What you see when the main loop executes is actually a new display every time PrintDisplay executes. The original code for Adventure handles 3 sets of displays...with the player moving all directions on one of them, and just 2 directions in two others (by doing the latter, the ball sprite is given the ability to move while bouncing against a wall...so that collisions don't stick you back in the exact same position). The bat and dragons are also handled 1 frame out of 3 (that's why most of the deltas are set at 3). If it were possible to remove another set of DoVSYNC/PrintDisplay jumps, the sprites would then be moving 1 frame out of 2...so yeah, they would definately be faster. Rather than go that route, you'd try to make the existing routines take less time to perform (like chopping the portals routine in half by only checking odd or even gates...for example). And I think that I've got another one... The delta (movement) routine uses a loop to count down each movement...and checks all directions even after moving in one way (i.e. it still checks "down" even after a sprite has been moved "up"). This is wasteful...since there's no way that the sprite WOULD be moving both of those vertical directions. It's either down or up...and either left or right. In addition, the loop itself is VERY wasteful...moving sprites 1 pixel at a time - two times, or three times, via cycle-hungry INC's and DEC's. So I cleaned that routine up...first by using SBC's and ADC's (to add or subtract the entire delta all at once)...that also eliminates the need for a loop...and secondly by altering the code so that only 1 horizontal/1 vertical direction is handled at a time: REPLACEMENT ROUTINE ;Move the object in direction by delta. MoveObjectDelta: STA ObjDir ;Stored direction wanted. ;3 MoveObjectDelta_2: STY Temp ;Count down the delta. ;3 ;more use of the BIT instruction... LDA VBLANK,X ;Increment the X coordinate. ;4 BIT ObjDir ;Get direction wanted. ;3 BMI MoveObjectDelta_3 ;If no move right then branch. ;2 CLC ; ;2 ADC Temp ;Count down the delta. ;3 BNE MoveObjectStoreX ;If no move right then branch. ;2 MoveObjectDelta_3: BIT ObjDir ;Get the direction wanted. ;3 BVS MoveObjectDelta_4 ;If no move left then branch. ;2 SEC ; ;2 SBC Temp ;Count down the delta. ;3 MoveObjectStoreX: STA VBLANK,X ;Save the X coordinate. ;4 MoveObjectDelta_4: LDA ObjDir ;Get the direction wanted. ;3 ASL ; ;2 ASL ; ;2 BMI MoveObjectDelta_5 ;If no move down the branch. ;2 LDA WSYNC,X ;Decrement the Y coordinate. ;4 SEC ; ;2 SBC Temp ;Count down the delta. ;3 JMP MoveObjectStoreY ;If no move right then branch. ;2 MoveObjectDelta_5: ASL ; ;2 BMI MoveObjectDelta_6 ;If no move up then branch. ;2 LDA WSYNC,X ;Decrement the Y coordinate. ;4 CLC ; ;2 ADC Temp ;Count down the delta. ;3 MoveObjectStoreY: STA WSYNC,X ;Save the Y coordinate. ;4 MoveObjectDelta_6: RTS ; ;6 That should trim enough time whenever moving a sprite to allow moving 3 dragons on a single frame. In addition, the Portals routine should be able to handle all 7 gates now...so I put that routine back to do all of them... ;Deal with Portcullis and Collisions. Portals: LDY #Gates ;Add to the number of gates-1 ;2 ...and... Portals_9: DEY ;Number (by two). ;2 BPL Portals_2 ;Do next portcullis. ;2 RTS ; ;6 And here is the revised main game loop, with dragon routines moved to spots that had the most free time... REPLACEMENT ROUTINE MainGameLoop_2: LDY #$00 ;Allow joystick read - all movement. ;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR MoveCarriedObject ;Move the Carried Object ;6 JSR DoVSYNC ;Wait for VSYNC ;6 JSR SetupRoomPrint ;Setup the room and objects for display. ;6 JSR PrintDisplay ;Display the room and objects. ;6 JSR PickupPutdown ;Deal with object pickup and putdown. ;6 LDY #$01 ;Disallow joystick read - move vertically only.;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR Surround ;Deal With Invisible Surround Moving. ;6 JSR MoveOrangeDragon ;Move and deal with orange dragon. ;6 JSR DoVSYNC ;Wait for VSYNC ;6 JSR MoveBat ;Move and deal with bat. ;6 JSR Portals ;Move and deal with portcullises. ;6 JSR PrintDisplay ;Display the room and objects. ;6 JSR MoveGreenDragon ;Move and deal with the green dragon. ;6 JSR MoveYellowDragon ;Move and deal with the yellow dragon. ;6 JSR MoveBlackDragon ;Move and deal with the Black dragon. ;6 JSR DoVSYNC ;Wait for VSYNC. ;6 LDY #$02 ;Disallow stick read/bridge check-move hor.only;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR MoveRedDragon ;Move and deal with red dragon. ;6 JSR Mag_1 ;Deal with the magnet. ;6 JSR PrintDisplay ;Display the room and objects. ;6 JSR MovePurpleDragon ;Move and deal with the Purple dragon. ;6 JSR MoveWhiteDragon ;Move and deal with white dragon. ;6 JMP MainGameLoop ;always branch ;3 So now the movement speed is back to the original Try this one... adventure_hell.zip Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 By moving bits 4 and 5 into the bit 6 and 7 positions just after checking left/right...the replacement routine can be shorter I didn't realise that ObjDir is OK to corrupt (because it's only used here and not used again for each object). ;Move the object in direction by delta. MoveObjectDelta: STA ObjDir ;Stored direction wanted. ;3 MoveObjectDelta_2: STY Temp ;Save the delta wanted. ;3 ;more use of the BIT instruction... LDA VBLANK,X ;Load the X coordinate. ;4 BIT ObjDir ;Get direction wanted. ;3 BVC MoveObjectDelta_3 ;If moving left then branch. ;2 BMI MoveObjectDelta_4 ;If no move right then branch. ;2 CLC ; ;2 ADC Temp ;Increase the X location (move right) ;3 BNE MoveObjectStoreX ;Always branch ;2 MoveObjectDelta_3: SEC ; ;2 SBC Temp ;Decrease the X loaction (move left) ;3 MoveObjectStoreX: STA VBLANK,X ;Save the X coordinate. ;4 MoveObjectDelta_4: ASL ObjDir ;bump up the direction wanted... ;5 ASL ObjDir ;...by 2 bits (move up/down into bits 6/7) ;5 LDA WSYNC,X ;Load the Y coordinate. ;4 BIT ObjDir ;Get direction wanted. ;3 BPL MoveObjectDelta_5 ;If moving down then branch. ;2 BVS MoveObjectDelta_6 ;If no move up then branch. ;2 CLC ; ;2 ADC Temp ;Increase the Y location (move up) ;3 BNE MoveObjectStoreY ;Always branch ;2 MoveObjectDelta_5: SEC ; ;2 SBC Temp ;Decrease the Y location (move down) ;3 MoveObjectStoreY: STA WSYNC,X ;Save the Y coordinate. ;4 MoveObjectDelta_6: RTS ; ;6 To save time, this should definately be used instead...and now there's enough time to move 3 dragons on a single frame. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 Here's the 3 assemblies (8k, 4k w/screen data unshared, and 4k w/screen data shared). In that last one, it's up to 520 bytes free now adventure_optimized_assemblies.zip Quote Link to comment Share on other sites More sharing options...
atwwong Posted September 20, 2004 Share Posted September 20, 2004 This is splendid work, Nukey! But now I can't decide whether or not to change the speed in my hack... Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 How do you mean? Edit the main loop back down to using only 3 frames? Might want to give it a shot. But you have more custom routines in there...so it might not be possible. I guess that the only way to know would be to try it and see if it rumbles. If it does, comment out each section until you can zero the problem one(s)...and then see if the JSR's can be reorganized to match cycle times a bit better with other frames. NOTE: notice that I'm moving stuff BELOW the last PrintScreen JSR I didn't know that it was possible to do this before. If you didn't either, a couple of routines could be moved there. I'm using it for 2 dragons. Quote Link to comment Share on other sites More sharing options...
atwwong Posted September 20, 2004 Share Posted September 20, 2004 Yes, you're right. Much more difficult to edit the main loop with the custom stuff - I got a screen full of blank, but it could be something that I did while trying to make changes. But with the custom stuff, who knows? Anyways, I'll keep plugging away until it works or I get tried. Quote Link to comment Share on other sites More sharing options...
atwwong Posted September 20, 2004 Share Posted September 20, 2004 I got your routine working for the main loop to use only 3 frames!!! LOL, the Eye Guy (white dragon) was moving twice the speed because I changed your orange dragon to white! Everything seems fine with no rumbles; this means I may be able to use 7 drag - ere - creatures, with 37 bytes free still. I couldn't use your new MoveObjectDelta routines - they drove all my objects into utter chaos (moving barriers, creatures starting in wrong positions, etc. Also, I amazingly had to revert back to the old portal routine to get the portals working. But now becasue of your awesome skills, I don't know which version to stick with!!! Maybe I'll have two flavours of Haunted Adventure II... Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 That's odd...it shouldn't have. This routine is doing the exact same thing as the old one...but without the loop What ram location is set up as Temp? The same one as Player0def? Quote Link to comment Share on other sites More sharing options...
atwwong Posted September 20, 2004 Share Posted September 20, 2004 You mean it shouldn't have worked? Yes, Temp is set as Player0def. But I forgot that I'm out of free ram so I can't add anymore dragons. I'll send you the current source code if you promise not to lecture me about neatness! You can also take a look at Brian's neat random routine. I'll let everyone see it once I tidy it up. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 Nooo...I meant that the edited MoveObjectDelta routine shouldn't have messed things up like you described...at least I don't see how it did. A and Y are the only registers being used (same as the old one), and nothing is altering the stack. As long as it ended with an RTS, there shouldn't have been a problem. Quote Link to comment Share on other sites More sharing options...
atwwong Posted September 20, 2004 Share Posted September 20, 2004 Hmmm... I'll keep looking at the routine - I might have messed up (again ), maybe when adding in the Move__Dragon routines... Quote Link to comment Share on other sites More sharing options...
atwwong Posted September 20, 2004 Share Posted September 20, 2004 Here's the MoveObjectDelta routine that is currently working for me (from your original 8kAdvent): ;Move the object in direction by delta. MoveObjectDelta: STA ObjDir ;Stored direction wanted. ;3 TYA ;check if no delta ;2 BEQ MovementReturn ;2 STY Temp ;Stored delta wanted. ;3 MoveObjectDelta_2: LDA VBLANK,X ;start with the X coordinate. ;4 ASL ObjDir ;Get direction wanted. ;3 BCS MoveObjectDelta_3 ;If no move right then branch. ;2 CLC ;2 ADC Temp ;Add the delta to X ;3 MoveObjectDelta_3: ASL ObjDir ;Get the direction wanted. ;3 BCS MoveObjectDelta_4 ;If no move left then branch. ;2 SEC ;2 SBC Temp ;Subtract the delta from X ;3 MoveObjectDelta_4: STA VBLANK,X ;Save the new X co-ordinate. ;4 LDA WSYNC,X ;Now do the Y co-ordinate. ;4 ASL ObjDir ;Get direction wanted. ;3 BCS MoveObjectDelta_5 ;If no move down the branch. ;2 SEC ;2 SBC Temp ;Subtract the delta from Y ;3 MoveObjectDelta_5: ASL ObjDir ;Get the direction wanted. ;3 BCS MoveObjectDelta_6 ;If no move up then branch. ;2 CLC ;2 ADC Temp ;Add the delta to Y ;3 MoveObjectDelta_6: STA WSYNC,X ;Save the new Y co-ordinate. ;4 RTS ;6 The newer ones posted seem to place "dragons" in different locations from were they are supposed to start; the barriers now appear to be okay, so it could be my code(ing)... Quote Link to comment Share on other sites More sharing options...
atwwong Posted September 20, 2004 Share Posted September 20, 2004 A crazy thought: if the object's (dragon's) initial movement direction was $00, would the newer MoveObjectDelta routines possibly displace or start these objects/dragons to move? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 No...because it would be adding or subtracting $00...just as yours already is. The routine would execute, but no change would happen to the object's X/Y. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 Oops...it does (the yellow dragon is already in the black castle in _hell). The fix for this is to set their $00 movement to $FF in the Game1Objects/Game2Objects data table (they won't move until an object appears that they react to). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 Dealing with "secret" rooms... If you look at the DealWithRight routine...the game manually forces room number $1E into the player's room when the player is moving right from room $03 AND the dot is no longer in room $15. If you wanted to add in more of these secret rooms, you would supposedly need to add in a seperate check for EVERY single room that features this. But there's an easier way You can use the BCC and BCS branches to check if the current room number falls within a range of rooms...and then just subtract or add a value to the current room value to get to the new secret room. In addition, you can add the ability for another object (like an added second dot) to the game to pass the left panels. To accomplish this...the collision routine would need a bit of editing (i.e. "do not collide if this object is present"). This collision check is right at the BallMovement routine. Here's the code that I set up for Advent (which uses the Magnet to pass left panels)... ;Check ball collisions and move ball. BallMovement: ; using BIT to check the two most significant bytes: BIT CXBLPF ;Get ball-playfield collision ;3 BMI PlayerCollision ;Branch if collision (Player-Wall) ;2 BIT CXM0FB ;Get ball-missile00 collision. ;3 ;new left panel routine... BVC CheckRightBar ;Branch if no collision. (Player-Left Thin) ;2 LDA CurrentObject+3 ;If object2 (to print) is ;3 CMP #MagnetNum ; not the magnet then collide. ;2 BNE PlayerCollision ;2 CheckRightBar: ;unchanged right panel routine... BIT CXM1FB ;Get ball-missile01 collision. ;3 BVC BallMovement_2 ;Branch if no collision. ;2 LDA CurrentObject+3 ;If object2 (to print) is ;3 CMP #DotNum ; not the black dot then collide. ;2 BNE PlayerCollision ;2 That takes care of the panel collisions...the bar might need to be flashing to pass through (since the required object is only the 2nd object to be printed half of the time). I just used the magnet as the second "dot" (so I wouldn't need to waste 3 more bytes of ram on a new 2nd dot)...but you could use any object in the game. Then, a range of rooms can be set up to deal with a bunch of secret rooms rather than just 1 of them. What I did was I moved the existing secret room to a higher room number. I also used a range of 8 rooms for both left and right...and had those 8 rooms overlap in the center (left panels with secret rooms are at rooms #$64 to $6b...and right panels with secret rooms #$68 to $6f...#'s $68 to $6b overlap and feature panels that go to a secret room in both directions). If moving left, 8 is subtracted (making the new room #$5c to $63)...and if moving right, 8 is added (making the new room #$70 to $77) That's a lot of secrets...so many that I never did end up using all of them In addition...the panels can still be used in any room even if no secret room exists behind them. And the rooms WITH secret rooms can still lead to other rooms if the required object is not present. Here's the revised code to use the magnet/dot and check for a group of rooms...the routine sits directly above the "get new room" routine. ;Check and Deal with Left. DealWithLeft: LDA VBLANK,X ;Get the object's X coordinate. ;4 CMP #$03 ;Is it Three or less? ;2 BCC DealWithLeft_1 ;IF so, branch. (off to left) ;2 CMP #$F0 ;Is it's &F0 or more. ;2 BCC DealWithRight ;2 ;Check and Deal with Left. DealWithLeft_1: CPX #PlayerRoom ;Are we dealing with the ball. ;2 BNE DealWithLeft_3 ;Branch if not. ;2 CMP #$01 ;left of the screen boundry for the man ;2 BCC MovementReturnr ;Branch if not. ;2 LDA VSYNC,X ;Get the Ball's Room. ;4 CMP MagnetR ;Check the room of the Magnet. Same Room? ;3 BNE DealWithLeft_4 ;Branch if not. ;2 CMP #$63 ;Check low boundry ;2 BCC DealWithLeft_4 ;Branch if not. ;2 CMP #$6C ;Check high boundry ;2 BCS DealWithLeft_4 ;Branch if not. ;2 ;Manually change to dot's secret rooms SEC ;Set room to secret room. ;2 SBC #$08 ;Add 8 to get secret room number. ;2 STA VSYNC,X ;And make it current. ;4 LDA #$9E ;Set the next X coordinate. ;2 STA VBLANK,X ;Save new X ;4 MovementReturn: RTS ;6 DealWithLeft_4: LDA #$9E ;Set the next X coordinate. ;2 .byte $2C ;skip next 2 bytes ;4 DealWithLeft_3: LDA #$9A ;Set the next X coordinate. ;2 STA VBLANK,X ;Save new X ;4 LDY #$07 ;And get the direction wanted. ;2 BNE GetNewRoom ;Go and get new room. ;2 ;Check and Deal with Right. DealWithRight: CPX #PlayerRoom ;Are we dealing with the ball. ;2 BNE DealWithRight_2 ;Branch if not. ;2 CMP #$9F ;right of the screen boundry for the man ;2 BCC MovementReturn ;Branch if not. ;2 LDA VSYNC,X ;Get the Ball's Room. ;4 CMP DotR ;Check the room of the black dot. Same Room? ;3 BNE DealWithRight_3 ;Branch if not. ;2 CMP #$67 ;Check low boundry ;2 BCC DealWithRight_3 ;Branch if not. ;2 CMP #$70 ;Check high boundry ;2 BCS DealWithRight_3 ;Branch if not. ;2 ;Manually change to dot's secret rooms CLC ;Set room to secret room. ;2 ADC #$08 ;Add 8 to get secret room number. ;2 STA VSYNC,X ;And make it current. ;4 LDA #$03 ;Set the next X coordinate. ;2 STA VBLANK,X ;Save new X ;4 RTS ;6 DealWithRight_2: CMP #$9B ;Has the object reached the right of the screen? ;2 BCC MovementReturn ;Branch if not (no room change) ;2 DealWithRight_3: LDA #$03 ;Set the next X coordinate. ;2 STA VBLANK,X ;Save new X ;4 LDY #$05 ;And get the direction wanted. ;2 ;Get new room ...and here's the data table for all of those rooms... (in the room matrix) ;secret rooms when moving left using magnet (8) .byte <Room5C,>Room5C,$96,$21,$76,$64,$76,$6F;5C U/L secret room .byte <Room5D,>Room5D,$86,$21,$69,$65,$3B,$69;5D L/L secret room .byte <Room5E,>Room5E,$0C,$21,$5E,$66,$5E,$75;5E Grail room/red dragon .byte <Room5F,>Room5F,$E6,$21,$00,$00,$00,$00;5F .byte <Room60,>Room60,$F6,$21,$60,$68,$60,$60;60 desert 1 .byte <Room61,>Room61,$16,$21,$61,$69,$61,$61;61 desert 2 .byte <Room62,>Room62,$26,$21,$1A,$6A,$62,$39;62 left secret room - yellow maze .byte <Room63,>Room63,$26,$21,$12,$6B,$63,$3C;63 warp room above white castle L ;left secret panel only (4) .byte <Room64,>Room64,$D8,$A1,$08,$02,$80,$6F;64 below blue maze .byte <Room65,>Room65,$B8,$A1,WC0,$0B,$0E,$6E;65 below white castle .byte <Room66,>Room66,$00,$A1,$0E,$1E,$0A,$02;66 left of invisible maze .byte <Room67,>Room67,$66,$21,$00,$00,$00,$00;67 ;both secret panels (4) .byte <Room68,>Room68,$A6,$E1,$3B,$37,$68,$37;68 2 screens below L/L secret .byte <Room69,>Room69,$08,$E5,$20,$5D,$20,$69;69 lower room of red castle .byte <Room6A,>Room6A,$0A,$E1,$65,$64,$0C,$6F;6A above yellow maze- 2 exits .byte <Room6B,>Room6B,$04,$E1,$0E,$6B,$38,$6B;6B above white debris ;right secret panel only (4) .byte <Room6C,>Room6C,$B6,$21,$00,$00,$00,$00;6C .byte <Room6D,>Room6D,$00,$61,$1D,$02,$0A,$1E;6D right of invisible maze .byte <Room6E,>Room6E,$98,$61,$1C,$65,$1D,$0B;6E right of catacombs .byte <Room6F,>Room6F,$E8,$61,$06,$64,$86,$02;6F above catacombs ;secret rooms when moving right using dot (8) .byte <Room70,>Room70,$F6,$21,$70,$70,$70,$68;70 desert 3 .byte <Room71,>Room71,$16,$21,$71,$71,$71,$69;71 desert 4 .byte <Room72,>Room72,$26,$21,$1F,$39,$72,$6A;72 right secret room - yellow maze .byte <Room73,>Room73,$26,$21,$1B,$3C,$73,$6B;73 warp room above white castle R .byte <Room74,>Room74,$36,$21,$00,$00,$00,$00;74 .byte <Room75,>Room75,$02,$21,$75,$38,$75,$6D;75 opposite of grail room .byte <Room76,>Room76,$86,$21,$5C,$65,$5C,$6E;76 L/R secret room .byte <Room77,>Room77,$66,$21,RC0,$64,RC0,$6F;77 U/R secret room Note the control value used for the panels...they begin with $2 if no panels are there...$A if a left panel exists...$6 if the right panel exists...and $E if both of them do. Then you just add in the low nybble (+1 if the GFX are normal, and +4 if the room is dark). Quote Link to comment Share on other sites More sharing options...
EarthQuake Posted September 20, 2004 Share Posted September 20, 2004 I couldn't use your new MoveObjectDelta routines - they drove all my objects into utter chaos (moving barriers, creatures starting in wrong positions, etc. Also, I amazingly had to revert back to the old portal routine to get the portals working. All of this was true for me as well. All my items started were very close to the edges of the screen, the dragons were appearing in strange places, dragons would sometimes pause in their "attack" state, and the bat would not cycle through it's states. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 20, 2004 Author Share Posted September 20, 2004 I dunno...it worked fine in the binary up top Maybe it's some kind of page fault error...possibly corrected by adding in a few bytes just above this routine? Like cutting the surround routine (that appears near the end of the program) and pasting it just above this one? But you should at least use the routine that works for atwwong...that gets rid of the time-consuming loop. Quote Link to comment Share on other sites More sharing options...
EarthQuake Posted September 21, 2004 Share Posted September 21, 2004 Although I no longer get screen rumbles, there are still a few issues I need to work out. I am using your most recent MoveObjectDelta routines and I have also followed your instructions to add a fourth dragon. The dragon functions perfectly. The object locations do not reflect the locations specified in the Room Bounds Matrix nor the Game1Objects or Game2Objects matrices. Some examples: The magnet always starts at 0,0 on screen $00 on game one. All of the items appear to be near the very bottom of the screen, the black key being the highest. The problems with the items did not arise until after I added the dragon, so I think I may have adjusted the objects' locations incorrectly or forgot to do something. Anyways, here's some info: ;object variables... SurroundR = $B1;(3 bytes) DotR = $B4;(3 bytes) ;all dragons must be consecutive RDragonR = $B7;(5 bytes) YDragonR = $BC;(5 bytes) GDragonR = $C1;(5 bytes) BDragonR = $C6;(5 bytes) MagnetR = $C9;(3 bytes) SwordR = $CC;(3 bytes) ChaliseR = $CF;(3 bytes) BridgeR = $D2;(3 bytes) ;all keys must be consecutive YKeyR = $D5;(3 bytes) WKeyR = $D8;(3 bytes) BKeyR = $DB;(3 bytes) ;all gates must be consecutive YGateR = $DE WGateR = $DF BGateR = $E0 BatR = $E1;(7 bytes) MainGameLoop_2: LDY #$00 ;Allow joystick read - all movement. ;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR MoveCarriedObject ;Move the Carried Object ;6 JSR DoVSYNC ;Wait for VSYNC ;6 JSR SetupRoomPrint ;Setup the room and objects for display. ;6 JSR PrintDisplay ;Display the room and objects. ;6 JSR PickupPutdown ;Deal with object pickup and putdown. ;6 LDY #$01 ;Disallow joystick read - move vertically only.;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR Surround ;Deal With Invisible Surround Moving. ;6 JSR DoVSYNC ;Wait for VSYNC ;6 JSR MoveBat ;Move and deal with bat. ;6 LDY #Gates ;For Each Portcullis. ;2 JSR Portals_2 ;Move and deal with portcullises. ;6 JSR PrintDisplay ;Display the room and objects. ;6 JSR MoveGreenDragon ;Move and deal with the green dragon. ;6 JSR MoveYellowDragon ;Move and deal with the yellow dragon. ;6 JSR DoVSYNC ;Wait for VSYNC. ;6 LDY #$02 ;Disallow stick read/bridge check-move hor.only;2 JSR BallMovement ;Check ball collisions and move ball. ;6 JSR MoveRedDragon ;Move and deal with red dragon. ;6 ;added line: JSR MoveBlackDragon ;Move and deal with black dragon. ;6 JSR Mag_1 ;Deal with the magnet. ;6 JSR PrintDisplay ;Display the room and objects. ;6 BNE MainGameLoop ;always branch ;2 Loc_1: .byte ChaliseR ; Loc_2: .byte $01 ;Chalise Loc_3: .byte $02 ; .byte RDragonR,$01,$2A ;Red Dragon .byte YDragonR,$01,$2A ;Yellow Dragon .byte GDragonR,$01,$2A ;Green Dragon .byte BDragonR,$01,$2A ;Black Dragon .byte SwordR,$01,$2A ;Sword .byte BridgeR,$01,$2A ;Bridge .byte YKeyR,$01,$16 ;Yellow Key .byte WKeyR,$12,$2A ;White Key .byte BKeyR,$08,$2A ;Black Key .byte BatR,$01,$2A ;Bat .byte MagnetR,$01,$2A ;Magnet Loc_4: .byte <Game1Objects ;objects game 01. Loc_5: .byte >Game1Objects ; --continued. .byte <Game2Objects,>Game2Objects ;objects game 02. .byte <Game2Objects,>Game2Objects ;objects game 03. Also, my white and yellow portcullises start open. The black doesn't. ;Object locations (room and coordinate) for game 01. Game1Objects: .byte $15,$51,$12 ;Black dot (Room, X, Y) .byte $0E,$50,$20,$00,$00 ;Red Dragon (Room, X, Y, Movement, State) .byte $01,$50,$20,$00,$00 ;Yellow Dragon (Room, X, Y, Movement, State) .byte $1D,$50,$20,$00,$00 ;Green Dragon (Room, X, Y, Movement, State) .byte $10,$50,$20,$00,$00 ;Black Dragon (Room, X, Y, Movement, State) .byte $1B,$80,$20 ;Magnet (Room,X,Y) .byte $12,$20,$20 ;Sword (Room,X,Y) .byte $1C,$30,$20 ;Challise (Room,X,Y) .byte $04,$29,$37 ;Bridge (Room,X,Y) .byte $11,$20,$40 ;Yellow Key (Room,X,Y) .byte $0E,$20,$40 ;White Key (Room,X,Y) .byte $1D,$20,$40 ;Black Key (Room,X,Y) .byte $1C ;Portcullis State .byte $1C ;Portcullis State .byte $1C ;Portcullis State .byte $1A,$20,$20,$00,$00 ;Bat (Room, X, Y, Movement, State) .byte $78,$00 ;Bat (Carrying, Fed-Up) ;Object locations (room and coordinate) for Games 02 and 03. Game2Objects: .byte $15,$51,$12 ;Black Dot (Room,X,Y) .byte $14,$50,$20,$A0,$00 ;Red Dragon (Room,X,Y,Movement,State) .byte $19,$50,$20,$A0,$00 ;Yellow Dragon (Room,X,Y,Movement,State) .byte $04,$50,$20,$A0,$00 ;Green Dragon (Room,X,Y,Movement,State) .byte $10,$50,$20,$A0,$00 ;Black Dragon (Room,X,Y,Movement,State) .byte $0E,$80,$20 ;Magnet (Room,X,Y) .byte $11,$20,$20 ;Sword (Room,X,Y) .byte $14,$30,$20 ;Chalise (Room,X,Y) .byte $0B,$40,$40 ;Bridge (Room,X,Y) .byte $09,$20,$40 ;Yellow Key (Room,X,Y) .byte $06,$20,$40 ;White Key (Room,X,Y) .byte $19,$20,$40 ;Black Key (Room,X,Y) .byte $1C ;Portcullis State .byte $1C ;Portcullis State .byte $1C ;Portcullis State .byte $02,$20,$20,$90,$00 ;Bat (Room,X,Y,Movement,State) .byte $78,$00 ;Bat (Carrying, Fed-Up) As you can see, all 3 portcullises have thier state set to closed. Now that I've mentioned a bunch of things that are totally unrelated, I'll go ahead and say that the last time i checked, the magnet was attracting itself. It would slowly work across the screen until it wrapped around and stopped when both sides were visible from opposite screens. Sorry for all the source code, just wanted to see if you could help me troubleshoot this, Nukey Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.