keithbk Posted February 14, 2011 Share Posted February 14, 2011 (edited) A couple of issues fixed above (8K/16K selectable option & player collision glitch) I started playing around with your new assembly, and I don't know if I did something wierd or not, but the "created by Warren Robinett" graphic appears below the number "3" in the game select. I did change up the first room (the number select), giving it an $04 in each scanline amount and developing 25 lines. Originally, this room had nothing, so it pulled the information from the first room (inside Gold Castle). Now it has its own information information (my attempts at a dragon head). Oh, out of curiosity, can the background color be changed based on the room? AdventureRevision.txt Edited February 14, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 14, 2011 Share Posted February 14, 2011 I started playing around with your new assembly, and I don't know if I did something wierd or not, but the "created by Warren Robinett" graphic appears below the number "3" in the game select.This is because the end of the "3" digit runs over a page break...as you can see from a list file: 327 11f9 GfxNum3 328 11f9 70 .byte.b %01110000 329 11fa 88 .byte.b %10001000 330 11fb 08 .byte.b 001000 331 11fc 30 .byte.b 110000 332 11fd 08 .byte.b 001000 333 11fe 88 .byte.b %10001000 334 11ff 70 .byte.b %01110000 335 1200 bd .byte.b GFX_DELIMITER 336 1201 337 1300 00 00 00 00* ALIGN 256 The GFX starts at $11F9, and doesn't reach the delimiter until $1200. That's a perfect example of page crossing...and because only the LSB is updated when drawing sprites, it goes all the way back to the beginning of the page (where the signature graphic exists). You can fix this problem easily by moving that ALIGN 256 text to between the "2" and "3" graphics The leftover bytes below "2" will be filled in, and the "3" digit will begin at $1200 instead. I did change up the first room (the number select), giving it an $04 in each scanline amount and developing 25 lines. Originally, this room had nothing, so it pulled the information from the first room (inside Gold Castle). Now it has its own information information (my attempts at a dragon head).That's a pretty nice image. Kinda "paganistic". Oh, out of curiosity, can the background color be changed based on the room? Yeah, you'd need to add a new data table that has as many bytes as there are rooms. The label name RoomDataTable3 was left unused for that very purpose Scroll down to this area to alter the line from loading #$08 to read from the data table instead: lda RoomDataTable2,y ;4 Get the room's foreground color jsr ChangeColor ;6 Change if necessary sta COLUPF ;3 Put in Playfield color register ;erase this line: ; lda #$08 ;2 Get light grey background (all rooms) ;and replace it with this: lda RoomDataTable3,y ;4 Get the room's background color jsr ChangeColor ;6 Change if necessary sta COLUBK ;3 Put it in the Background color register Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 14, 2011 Share Posted February 14, 2011 All the changes worked great. Everything is looking better now. Thanks for the compliment on the picture. I wasn't really going for "paganistic" as much as a front-on view of a dragon head...lol Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 14, 2011 Share Posted February 14, 2011 The switching sword is kinda strange, because it switches when you walk by it, rather than when you are carrying it and going different directions. Would this work better as a subroutine in the character movement, based on horizontal (rather than vertical) movement? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 14, 2011 Share Posted February 14, 2011 Flipping it from side to side was just a cheat. You could assign a new variable to it (burn a byte of ram). If that new "sword state" variable is zero, it uses the first state's gfx. Just an unchanging bitmap on the screen. When you are carrying it, alter the state variable to be the value from the joystick (LDA CurrentStick -> STA SwordState)...and add state gfx for each of the directions. There's already a spot that checks if the player is carrying the sword, so it's state variable could be updated there. However, the remaining problem would be how to get the sword object to circle the player realistically (which I tried addressing unsuccessfully earlier in the thread). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 14, 2011 Share Posted February 14, 2011 Here's some steps to make the sword face the direction that the player is. Note that it still doesn't move to the correct spot in relation to the player...it just animates in place. First, add a state variable for the sword in RAM memory up top... SwordState DS 1 ;sword rotation ;Object variables...(etc) Next...move the sword bitmap away from the page used for the chasing dragon. Just cut the sword bitmap out, then add 8 new ones someplace else (like below the bat and key objects...plenty of space on that page)... GfxSwordL: ;6 bytes, sword left bitmap .byte $04 ; X .byte $05 ; X X .byte $FF ;XXXXXXXX .byte $04 ; X .byte $04 ; X .byte GFX_DELIMITER ;end GfxSwordUL: ;6 bytes, sword up + left bitmap .byte $80 ; .byte $40 ; .byte $22 ; .byte $14 ; .byte $08 ; .byte $14 ; .byte $22 ; .byte $04 ; .byte GFX_DELIMITER ;end GfxSwordU: ;6 bytes, sword up bitmap .byte $10 ; .byte $10 ; .byte $10 ; .byte $10 ; .byte $10 ; .byte $7C ; .byte $10 ; .byte $30 ; .byte GFX_DELIMITER ;end GfxSwordUR: ;6 bytes, sword up + right bitmap .byte $01 ; .byte $02 ; .byte $44 ; .byte $28 ; .byte $10 ; .byte $A8 ; .byte $44 ; .byte GFX_DELIMITER ;end GfxSwordR: ;6 bytes, sword right bitmap .byte $20 ; X .byte $A0 ;X X .byte $FF ;XXXXXXXX .byte $20 ; X .byte $20 ; X .byte GFX_DELIMITER ;end GfxSwordDR: ;6 bytes, sword down + right bitmap .byte $44 ; .byte $A8 ; .byte $10 ; .byte $28 ; .byte $44 ; .byte $02 ; .byte $01 ; .byte GFX_DELIMITER ;end GfxSwordD: ;6 bytes, sword down bitmap .byte $30 ; .byte $10 ; .byte $7C ; .byte $10 ; .byte $10 ; .byte $10 ; .byte $10 ; .byte $10 ; .byte GFX_DELIMITER ;end GfxSwordDL: ;6 bytes, sword down + left bitmap .byte $04 ; .byte $22 ; .byte $14 ; .byte $08 ; .byte $14 ; .byte $22 ; .byte $40 ; .byte $80 ; .byte GFX_DELIMITER ;end That is all you need to do for the upper part of the assembly. The next edits take place in the last bank. First, add a new data table for the list of states the sword is allowed to animate in... SwordStateTb: ;24 bytes, sword's list of states (joystick value, bitmap used) .byte %01010000 ;State down + right .word GfxSwordDR .byte %01100000 ;State up + right .word GfxSwordUR .byte %01110000 ;State right .word GfxSwordR .byte %10010000 ;State down + left .word GfxSwordDL .byte %10100000 ;State up + left .word GfxSwordUL .byte %10110000 ;State left .word GfxSwordL .byte %11010000 ;State down .word GfxSwordD .byte %11100000 ;State up .word GfxSwordU ...then alter the existing lines for the sword object to include this new animation table. Just comment them out and put new lines below them. From Store3: ; .byte <GfxSword ;$09 Sword's state (LSB) .byte <SwordState ;$09 Sword's state (LSB) - now in RAM Store4: ; .byte >GfxSword ;$09 Sword's state (MSB) .byte $00 ;$09 Sword's state (MSB) - MSB of ram is zero Store5: ; .byte $00 ;$09 Sword's list of states (LSB) .byte <SwordStateTb ;$09 Sword's list of states (LSB) And Store6: ; .byte $00 ;$09 Sword's list of states (MSB) .byte >SwordStateTb ;$09 Sword's list of states (MSB) That takes care of the data tables. Now you need to find a spot to update the sword's state variable. I suggest right in the joystick-reading subroutine (ReadStick). Scroll down to where SWCHA is loaded and then trimmed... ReadStick: ;Read Sticks tya ;2 Check for zero (all movement) bne ReadStick_2 ;2 If not, don't bother with joystick read lda CurrentStick ;3 and #$0F ;2 sta CurrentStick ;3 lda SWCHA ;4 Read joysticks and #$F0 ;2 Trim to use left stick only ;added lines cmp #$F0 ;2 Check for movement beq Not_the_sword ;2 Not moving...skip update ldx CarriedObj ;3 Check object being carried using X cpx #SwordNumber ;2 Is it the sword? bne Not_the_sword ;2 If not, branch sta SwordState ;3 ...or update the sword's rotation based on movement Not_the_sword: ;continue with original lines... And that's all. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 14, 2011 Share Posted February 14, 2011 (edited) Works great. Edited February 15, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
KevinMos3 Posted February 15, 2011 Share Posted February 15, 2011 I like where you're going with it. I'm glad to see someone else using Nukey's updated kernel & assembly. Quote Link to comment Share on other sites More sharing options...
accousticguitar Posted February 15, 2011 Share Posted February 15, 2011 Are you using osc1 to make the room bitmaps or are you doing them by hand? I'm liking the different colored backgrounds for each room. Now to make a game with 128 rooms, one for each background color. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 15, 2011 Share Posted February 15, 2011 I'm taking concept photos, putting them in photoshop, then laying a grid over them and estimating the "on/off" value for each square as a two color image (background/foreground). Earlier rooms I did were all simple, using the old code. Now with the updated kernal, I'm going through each room and making it more to how I envisioned each room. For example, the room beneath the Yellow castle is the fountain room. I've been working on a re-draw tonight that makes it more in line conceptually with a fountain (the version I posted previously will not be in use). The room above the catacombs is a "cavernous cliff face," which opens up to the dark cavernous maze. Conceptually, that room is close to what I want, but I want to tweak it and make it more thematic. Quote Link to comment Share on other sites More sharing options...
accousticguitar Posted February 15, 2011 Share Posted February 15, 2011 (edited) Check out posts #64 and #70 in this thread: http://www.atariage.com/forums/topic/134439-adventure-playfield-manipulation-midscreen/page__st__50__p__1630845__fromsearch__1#entry1630845 The tool that Earthquake made for making room bitmaps is not perfectly aligned to this assembly. If you want a missile to the right of the room you have to put that in manually (to the playfield0 number) by adding in $08 to each line of the room bitmap (playfield0) where you desire it. (Note, you have to do your math in hex code. For example, $04 + $08 = $0C, not $12.) (Edited due to the original post being incorrect. See Nukey's post below) At first, I was confused by the code at the end of the bitmaps in Nukey's assembly file until I realized it was in hex (which was obvious if I had paid attention to the $ signs). Edited February 15, 2011 by accousticguitar Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 15, 2011 Share Posted February 15, 2011 (edited) You can manipulate the numbers to get the desired look as long as they all add up to 96. No, this is not a requirement You can define as many lines as you want to...but the kernel will only use the first 96 of whatever it finds from the label. I wanted to make sure that the ability to share upper and lower lines of screens was still intact, so the kernel keeps track on it's own much like the original game did. Keeping careful track was abandoned some time ago...in addition to the old requirement of making sure that the lower line was defined at 8 double scanlines more than what was displayed (the original game's old co-ordinate values were higher than they needed to be). So if a screen definition has data on it's top line that matches what you need for another screen's lower line, you can share the pattern between them...even if the scanline count value is higher than what you need for the lower line of the latter screen. Aside from screens that look totally identical (since all that is involved there is to move the label around), I didn't do any byte sharing for graphics in the assembly just to make things easier to edit. About the only thing lacking is the ability to do asymmetrical displays, but I can't find a way of doing that without sacrificing additional ram and the mix modes Edited February 15, 2011 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
accousticguitar Posted February 15, 2011 Share Posted February 15, 2011 You can manipulate the numbers to get the desired look as long as they all add up to 96. No, this is not a requirement You can define as many lines as you want to...but the kernel will only use the first 96 of whatever it finds from the label. Well now, that makes things easier. I can put my calculator away. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 15, 2011 Share Posted February 15, 2011 This code to move the sword around the player works a little better...still might need a bit of tweaking (esp. if you alter the sword gfx). Use with the SwordState changes listed above. MoveCarriedObject: ;Move the carried object (replacement code) ldy CarriedObj ;3 Get the object being carried cpy #NullNumber ;2 Check if nothing beq MoveCarriedObject_2 ;2 if so, return lda Store1,y ;4 Get and store the low address tax ;2 transfer to the X register lda PlayerRoom ;3 Get the current room sta $00,x ;4 ...and store the object's current room cpy #SwordNumber ;Check if carried object is the sword bne KeepOldCarryY ;if not, skip this lda CurrentStick ;get current direction moving lsr ;move to low nybble... lsr ; lsr ; lsr ; tay ;...and give to an index register lda CarryXtbl,y ;using a table, load the new position bmi KeepOldCarryX ;if invalid, don't update asl ; sta CarriedX ;...or store as current KeepOldCarryX: lda CarryYtbl,y ;do the same for vertical bmi KeepOldCarryY ;if invalid, don't update asl ; sta CarriedY ; KeepOldCarryY: lda PlayerX ;3 Get the ball's X coordinate clc ;2 adc CarriedX ;3 Add the X difference sta $01,x ;4 ...and store as the object's X coordinate lda PlayerY ;3 Get the ball's Y coordinate clc ;2 adc CarriedY ;3 Add the Y difference jmp MoveObjectDelta ;3 ...And jump to store ;new data tables... CarryXtbl: .byte $FF ;invalid .byte $FF ;invalid .byte $FF ;invalid .byte $FF ;invalid .byte $FF ;invalid .byte $03 ;right+down .byte $03 ;right+up .byte $03 ;right .byte $FF ;invalid .byte $7B ;left+down .byte $7B ;left+up .byte $7B ;left .byte $FF ;invalid .byte $00 ;down .byte $00 ;up .byte $FF ;not moving CarryYtbl: .byte $FF ;invalid .byte $FF ;invalid .byte $FF ;invalid .byte $FF ;invalid .byte $FF ;invalid .byte $7D ;right+down .byte $05 ;right+up .byte $00 ;right .byte $FF ;invalid .byte $7D ;left+down .byte $05 ;left+up .byte $00 ;left .byte $FF ;invalid .byte $7D ;down .byte $05 ;up .byte $FF ;not moving Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 15, 2011 Share Posted February 15, 2011 (edited) Love it...the sword works perfect now. Also, redesigned the yellow castle and the fountain room. Got lots to do now. Here's the revised file. REVISED 2/15/2011, 4:12 PM EST cyoa.bin Edited February 15, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 16, 2011 Share Posted February 16, 2011 I'm excited...the game is turning out better than I expected. Hopefully I can share some cool stuff in a day or so. Quote Link to comment Share on other sites More sharing options...
accousticguitar Posted February 16, 2011 Share Posted February 16, 2011 I'm excited...the game is turning out better than I expected. Hopefully I can share some cool stuff in a day or so. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 18, 2011 Share Posted February 18, 2011 (edited) Nukey, Is it possible to convert this assembled .bin file of your 16k program back to .txt? I need some information from this earlier edit. Edited February 18, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 18, 2011 Share Posted February 18, 2011 Not without the very slow and tedius process of disassembly and reverse-engineering (this stresses the importance of always making a backup whenever saving). Can you be more specific? It's not necessary to rework the whole thing if I know what to look for. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 18, 2011 Share Posted February 18, 2011 Not to worry, I'm just going to keep on going with what I have worked on and skip the stuff from the previous edit. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 21, 2011 Share Posted February 21, 2011 (edited) Nukey, I'm encountering a problem with Game 3; Games 1 and 2 will load, but not so with Game 3. I have added a new key and tried to put it in the random room field, but I must be missing something somewhere. Edited February 22, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 21, 2011 Share Posted February 21, 2011 (edited) Dang...hit edit instead of reply. Anyway...RndMax...should be $3F instead of $28...yadda yadda BTW additional problems with resetting object bounds to higher values is the signature room (unless you want the possibility of randomly placing them there), and castle interiors. If you alter bounds to go along with the RndMax change...you should start relocating room numbers to group the rooms you don't want to pick (i.e. the signature room) at the end of your tables, and castle interiors just below that and/or just above the number room (so you can tweak the bounds values to avoid certian castles for certian keys). Do you want me to reorganize them? It's pretty simple if you change all the #'s in the map direction tables to be labels instead. Edited February 21, 2011 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 22, 2011 Share Posted February 22, 2011 Dang...hit edit instead of reply. Anyway...RndMax...should be $3F instead of $28...yadda yadda BTW additional problems with resetting object bounds to higher values is the signature room (unless you want the possibility of randomly placing them there), and castle interiors. If you alter bounds to go along with the RndMax change...you should start relocating room numbers to group the rooms you don't want to pick (i.e. the signature room) at the end of your tables, and castle interiors just below that and/or just above the number room (so you can tweak the bounds values to avoid certian castles for certian keys). Do you want me to reorganize them? It's pretty simple if you change all the #'s in the map direction tables to be labels instead. Would you please? That would be great! Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 22, 2011 Share Posted February 22, 2011 Here ya go. It might be kind of confusing (for example, the label Rm12 for the inside of the yellow castle is now room #$01 in the revised files cyoa2 & 3). So I kept everything in their original spots in cyoa1...just in case you don't like the changes. The revised file cyoa2 mixes up the room numbers to group interiors and exteriors...but there's no chance of a random game being unwinnable - unless you do something intentional like lock a key inside a castle All I did was grab the room data in question and move it up or down RoomDataTable0, then did the same change for every table that followed. By labelling everything, you don't need to edit the map directions for every change you make...it will recalculate them on it's own. Anyway, cyoa3 includes the current options and kernels that I'd been working on. You can call any one of them in each bank. Monocolor_Display_Kernel is basically the same as the one you had...but with free cycles grouped at the top in case you discover a use for them. Multicolor_Display_Kernel expects 1 byte of color data to precede each line of playfield data...and you can recolor every other scanline by including odd-numbered values below the data line. The number of recolors you can do is the number of scanlines-1. Files.zip Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 22, 2011 Share Posted February 22, 2011 Thanks, Nukey... Now, how can we get the Dragon from Dragonfire into Adventure? 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.