Sacred Will Posted July 13, 2014 Share Posted July 13, 2014 (edited) Hi all, I recently posted something in Atari 2600 Hacks. I was hoping to get some help with an Adventure hack I'm working on. I'm a noob so i'm having a hell of a time trying to figure out this code. Going through the forums for the past couple months and a few tutorials here, I have learned quite a bit but I still have a long way to go. Any help would be greatly appreciated, or if you're just an Adventure fan check out what I have done so far. Let me know what you think. http://atariage.com/forums/topic/227598-need-help-with-my-adventure-hack/ Edited July 13, 2014 by Sacred Will Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 13, 2014 Share Posted July 13, 2014 It sounds like what you want to do has gone beyond a simple hack. If you're serious about keeping it a hack then you might check out SpiceWares new series on creating a simple 2k game: http://atariage.com/forums/topic/227629-tutorial-for-developing-a-game-from-scratch/ More work but a less steep learning curve would be to make your own engine in batari BASIC: http://atariage.com/forums/forum/65-batari-basic/ 1 Quote Link to comment Share on other sites More sharing options...
+SvOlli Posted July 15, 2014 Share Posted July 15, 2014 If you dig through the archives here, there's a Windows based editor for Adventure which lets you modify quite a lot in cases of graphics and layouts. Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted July 16, 2014 Share Posted July 16, 2014 Ha, yeah, that windows based editor is my old "Create your own adventure" tool. I wrote that about 10 years ago as an easy way to make extensive changes to the map, colors, sprites,and item locations in the original game, but you can't add any new features to the game with it. I've talked to Sacred Will and what he's doing is definitely a pure assembly hack and would require some expert help to make the changes he's trying to make. I'm going to take a look too but I think it's a bit beyond my skill level. Take a look at what he's already done, it is pretty cool. He's already added extra objects to the code and I really like his idea. It's definitely worthy of some help if someone has the time. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 20, 2014 Share Posted July 20, 2014 Object states: each of the 4 fragments could use a state table that has all 4 shapes listed (1/4,1/2,3/4,complete). Each fragment then uses the same byte of ram to determine which state it's in (1/4 at game start for each of them). When 2 objects collide, check if they are both a "fragment" object, and then (this is important) if one is held by the player. If so, increase the state byte and send both objects into hyperspace (just assign an invalid room number to them). The game engine will automatically correct the room number of the fragment object held by the player. When you want to know if the object has been fully assembled, just examine the state. Quote Link to comment Share on other sites More sharing options...
Sacred Will Posted July 22, 2014 Author Share Posted July 22, 2014 Thanks Nukey, I somewhat understand what you're saying but i'd have a hell of a time trying to write the code for this. I'm such a noob. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 22, 2014 Share Posted July 22, 2014 Nevermind, that won't work under certain circumstances. Somebody could potentially join 2 quarter pieces, and then drop it and join the other 2 quarter pieces (locking out the final quarter if the 2 halves are joined). It would be better to break it down fully...so that each quarter object has it's own state variable in ram - each one using a specific bit position in the state variable. So that when pieces are colliding, the state variables are merged instead of just being increased. Piece1 has a starting state value of %1, piece2 starts with %10, piece3 has %100, and piece4 has %1000. If piece1 hits piece4, the state would become %1001. That's altogether 15 individual states that need bitmaps...1 bitmap per combination. 4 bytes of ram needed for states, and 12 more for the room/x/y of each (16 bytes of ram total). How much did you have unused in your WIP? Quote Link to comment Share on other sites More sharing options...
Sacred Will Posted July 22, 2014 Author Share Posted July 22, 2014 This is what I'm using with the pieces added: ;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) MagnetR = $C6 ;(3 bytes) SwordR = $C9 ;(3 bytes) ChaliseR = $CC ;(3 bytes) BridgeR = $CF ;(3 bytes) ;all keys must be consecutive YKeyR = $D2 ;(3 bytes) WKeyR = $D5 ;(3 bytes) BKeyR = $D8 ;(3 bytes) RKeyR = $DB ;(3 bytes) AKeyR = $DE ;(3 bytes) ;Amulet Pieces Piece1R = $E1 ;(3 bytes) Piece2R = $E4 ;(3 bytes) Piece3R = $E7 ;(3 bytes) Piece4R = $EA ;(3 bytes) Piece5R = $ED ;(3 bytes) Piece6R = $F0 ;(3 bytes) ;all gates must be consecutive YGateR = $F3 WGateR = $F4 BGateR = $F5 RGateR = $F6 AGateR = $F7 ;------------------------------------------------------------------------------------ ;Ram locations E5-FA free (F9/FA -might- be used by the stack if JSR's nested further) ;------------------------------------------------------------------------------------ Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 24, 2014 Share Posted July 24, 2014 I thought you only had 4 amulet pieces to join? But the above method will work if the castle gate routine is altered so all of their states are combined into a single byte of ram (this is present in the most-recent 16/32 version...so it can be cut'n'pasted from there). The bad news is that you'd end up with 63 bitmap variations for the 6-section amulet...which might not work at all. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 24, 2014 Share Posted July 24, 2014 BTW you are still allocating 3 bytes for the Surround object, but your thread mentions not using it. Quote Link to comment Share on other sites More sharing options...
Sacred Will Posted July 24, 2014 Author Share Posted July 24, 2014 Object states: each of the 4 fragments could use a state table that has all 4 shapes listed (1/4,1/2,3/4,complete). Each fragment then uses the same byte of ram to determine which state it's in (1/4 at game start for each of them). When 2 objects collide, check if they are both a "fragment" object, and then (this is important) if one is held by the player. If so, increase the state byte and send both objects into hyperspace (just assign an invalid room number to them). The game engine will automatically correct the room number of the fragment object held by the player. When you want to know if the object has been fully assembled, just examine the state. I actually like this idea here even though there is the possibility of someone making the mistake of joining the other two pieces separately. That's just something i'd have to put in the instructions; to make sure not to do that or you will not be able to win the game. I have 6 different pieces: Each of the four 1/4 pieces is an individual object (I want them to look different) then the 1/2 piece, then the 3/4 piece = 6 The completed piece is actually a key that uses a different bitmap than the other keys. What I was thinking was at the start of the game, the 1/2 piece, the 3/4 piece and the completed piece would be assigned to an invalid room (inaccessible) and when you collide a 1/4 piece with another 1/4 piece they would both be replaced (exchanged) with the 1/2 piece. Collide another 1/4 piece with the 1/2 piece and they will be replaced (exchanged) with the 3/4 piece etc. Just wish I could figure out the code to make it work. I decided I'm still going to use the Surround in a secret room when I make some changes. Check out the three rooms just below the Yellow Castle. beyond.bin Beyond.asm Quote Link to comment Share on other sites More sharing options...
Sacred Will Posted July 26, 2014 Author Share Posted July 26, 2014 Object states: each of the 4 fragments could use a state table that has all 4 shapes listed (1/4,1/2,3/4,complete). Each fragment then uses the same byte of ram to determine which state it's in (1/4 at game start for each of them). When 2 objects collide, check if they are both a "fragment" object, and then (this is important) if one is held by the player. If so, increase the state byte and send both objects into hyperspace (just assign an invalid room number to them). The game engine will automatically correct the room number of the fragment object held by the player. When you want to know if the object has been fully assembled, just examine the state. Hey Nukey Shay, can you show me how to put together a "state table"? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 26, 2014 Share Posted July 26, 2014 Follow the rules in the Objects table. The first word (2 bytes) defines which address an objects base information is held at (room#, hpos, vpos). For anything movable, this would be the 1st ram address used for that object. The next word sets the address of where an object's state can be found. If this is anything that changes shape, you'd need to use a ram address. The 3rd word points to an object's rom list of states. As an object's state variable changes, the program compares the value to the ones in this list...and uses the corresponding bitmap address from the list. Take a look at RDragonData, for example. The DragonStates data table it points to holds the 4 states a dragon can be in and the bitmap to use: 0=roaming, 1=dead, 2=eaten player, and the last state value listed should be $FF so the program knows where the data table ends (in this case, the biting dragon bitmap). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 26, 2014 Share Posted July 26, 2014 To do the amulet, you only need 4 objects (not 6 + a key), and a state variable for each. Each of the 4 quarter pieces should point to it's own state variable in the Objects table, and a list of states in rom that has the 15 combinations listed: AmuletStates: .byte %0001, {bitmap address of 1st quarter} .byte %0010, {bitmap address of 2nd quarter} .byte %0011, {bitmap 1st + 2nd quarters} .byte %0100, {bitmap address of 3rd quarter} .byte %0101, {bitmap 1st + 3rd quarters} .byte %0110, {bitmap 2nd + 3rd quarters} .byte %0111, {bitmap 1st + 2nd + 3rd quarters} .byte %1000, {bitmap address of 4th quarter} .byte %1001, {etc...} .byte %1010, {etc...} .byte %1011, {etc...} .byte %1100, {etc...} .byte %1101, {etc...} .byte %1110, {etc...} .byte $FF, {amulet key bitmap} In the Game1Objects and Game2Objects data tables, assign the values 1, 2, 4, and 8 as the starting state values for the 4 pieces. In the Objects data table, assign the size value of 8 to the amulet pieces (bit 3 is ignored by the register, but this will be an easy way to check if 2 amulet pieces touch). A subroutine can then update the state of the carried object and banish the other one out of the game: Check_Amulet: BIT CXPPMM ;Get Player00-Player01 BPL Nothing_Hit ;If nothing, Branch LDX CurrentObject+2 ; LDY.wy CurrentObject+3 ; LDA Store8,X ; AND Store8,Y ; CMP #$08 ;2 amulet pieces hit? BNE Nothing_Hit ;No CPX CarriedObject ;Carried by player BEQ Amulet_Carried ;Yes CPY.wy CarriedObject ;Carried by player BNE Nothing_Hit ;No LDX CurrentObject+3 ;Switch the order LDY.wy CurrentObject+2 ; Amulet_Carried: LDA Store1,Y ;Get and store STA ObjAddress ; the vector of LDA Store2,Y ; the object STA ObjAddress+1 ; not carried LDA Store1,X ; STA CurrentObject ;Do the same LDA Store2,X ; for the STA CurrentObject+1 ; carried object LDY #$03 ; LDA (CurrentObject),Y ;Get the state ORA (ObjAddress),Y ;merge with the other STA (CurrentObject),Y ;Update State of carried object LDY #$00 ; LDA #$7F ;Set invalid room # STA (ObjAddress),Y ;And store to other object Nothing_Hit: RTS ;end Then all that is left is to alter the portcullis subroutine to recognize a completed amulet as a key. If this becomes too troublesome, you could check the state value after it was updated to see if it is equal to $0F...and manually assign a separate key as the carried object. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 27, 2014 Share Posted July 27, 2014 Added more code to the Portals subroutine (the first pass handles the amulet gate and opens for a completed one...so make sure it's always last on the list if you add castles). Removed the amulet key and the other 2 pieces...and you'll see where the states for each piece is set up. I didn't add or subtract any bitmaps...so combining 2 sets of pieces results in the same half-amulet bitmap for both (when combining them separately). Joining any 3 pieces also results in the same 3/4 image. You may choose to expand the number of bitmaps if you want them to look different for each of the 15 states. I added tags for each variation. Too much cycle time was being spent outside of the display...resulting in a screen jitter on some screens (taking an amulet to the black castle, for example). So I corrected this problem as well. NOTE: You really ought to be using a newer assembly file. There's still many optimizations (saving both time and ram) that are not present in this older one. But here ya go... Beyond.asm Quote Link to comment Share on other sites More sharing options...
Sacred Will Posted July 28, 2014 Author Share Posted July 28, 2014 Thanks Nukey!!! You are AWESOME!!! It's so cool to see my idea working just the way i envisioned. You were right, your way is definitely better than the way i was thinking. I tested it every way imaginable and it's perfect. Just need to do a few more things and I will upload the final version soon. Your help with this is very much appreciated Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted July 28, 2014 Share Posted July 28, 2014 BTW it's possible to "repurpose" the remaining 3 pieces (particularly since you can't gain entrance to that area without a completed amulet in the first place). Just change the key's state to $0F in the state table and add more states below it...then add some instructions to put them in that area instead of "banishing" them. You'd need to tweak the stuff I wrote so they couldn't be joined to the completed amulet, tho. Something else you might want to add is sound effects for joining amulet pieces. #'s 0 thru 5 are already in use, but you could add more. 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.