Nukey Shay Posted February 8, 2011 Share Posted February 8, 2011 Hmm...you're right The branch was taken because of the equal status (tho it escapes me why). Altering the comparison to read CPX #GDragonR+1 works, tho (the dragons use 5 bytes of ram, so there is no issue of an invalid object being chosen for up to +4). Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 8, 2011 Share Posted February 8, 2011 Hmm...you're right The branch was taken because of the equal status (tho it escapes me why). Altering the comparison to read CPX #GDragonR+1 works, tho (the dragons use 5 bytes of ram, so there is no issue of an invalid object being chosen for up to +4). Fabulous! Works now. Now to start redesigning everything. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 (edited) Nukey, I was trying to implement your code on the flippable dragons, but I'm not getting it to work and I'm wondering if I'm not understanding your statement in another post "Just place the dragon sprite on a different memory page than all of the rest." This is the code I have: OLD CODE DELETED Edited February 10, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 (edited) You might already know some of this. A "page" is a 256-byte stretch of memory in an 8-bit computer like the 2600. An 8-bit machine uses 16-bit addressing. Actually, it's only 13 for the 2600...but let's just call it 16 for the moment so this doesn't get too technical "Zero page" is addresses $00 to $FF. $100 to $1FF is page one, and so on. As the high byte (or MSB) of the 16-bit address changes, you are moving to different pages. The "Just place the dragon sprite on a different memory page than all of the rest." is a programming shortcut. Since the page (MSB) of the bitmap address was just loaded before the flipping patch above, all the program needed to do was check to see if it was the MSB of where the "chasing" dragon bitmap resides in ROM. If so, the reflect register is set based on whether the player is to the left or right of it. However...if an object bitmaps other than the dragon use the same MSB, that object would be flipping as well as you move around it. Just cut the chasing dragon bitmap and paste it away from all the other object bitmaps. I'd suggest sticking it in where playfield bitmaps exist. In this manner, you don't need to do comparisons all over the place to make sure the program is only flipping that specific bitmap. Don't be afraid about shuffling bitmaps around...the Adventure kernel is extremely flexible The only problem you are likely to encounter is if an object or playfield bitmap crosses a page (i.e. starts near the end of a 256-byte boundry in a way that causes the end of said bitmap to exist on the next page in line). Even that will not crash the game...but may lead to slight graphic "skewing" where it occurs - such as a pixel being misplaced. The program expects that the player is at a specific location in relation to a biting dragon...so you should not move the "biting" dragon bitmap to the same page you moved the "chasing" dragon bitmap to. Similarly, you probably won't want a "dead" dragon to be flipping around either...so just move the "chasing" dragon bitmap only to a unique page. Or, you can ignore all of this and just play around with the assembly You'll most likely reach the same conclusion on your own after a couple of experiments (and better understand what the program is doing in the process). Hack and rewrite everywhere! Just be sure to keep a running list of backup files. HD space is cheap. Trying to figure out where something messes up following multiple changes leads to migranes (and lost progress). Edited February 10, 2011 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 So other than my Dragon sprite not being in a good place, the rest of the code is solid? The game, although it compiled, would not bring up a number on the screen, which had me worried. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 Ah...I didn't see the goof. Funny tho...Dasm should have caught it The label NotReversable1 is being referenced for both sprites. This is incorrect. A mismatch comparison for the dragon on the first sprite would cause it to leap all the way down past the setup for the second sprite! In the lower section, rename the label (and the 2 branches above it) to NotReversable2. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 In keeping with this idea, is it possible to make the sword flip based on the direction of character movement (left or right)? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 Based on which side you carry it on...no problem. Just put the sword bitmap on the same page you paste the chasing dragon bitmap, and alter the bitmap so it's facing the opposite direction the chasing dragon does Direction you are currently moving would be a lot tougher. The program is coded to set CarriedX and CarriedY to the player's location + direction in the PickupObject routine. CarriedX & Y are then updated as the player is in the MoveObject routine...so it always moves alongside evenly no matter what side you picked it up. That would need to be altered to handle the sword object specially if it was to move around the carrier (you). Something optional would be to assign a byte of ram to the sword object so it could have a list of states...and have differing bitmaps for each of the 8 directions you can move. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 Here's an attempt at the first part. I'm doing this off the cuff...so I dunno if any bugs are present. You need to add lines here: ;Move the carried object MoveCarriedObject: LDX CarriedObj ;Get the object being carried CPX #NullNumber ;If nothing, return (Num Is (8*NumOfObj)- BEQ MoveCarriedObject_2 ; JSR GetObjectAddress ;Get it's dynamic information LDY #$00 ; LDA PlayerRoom ;Get the current room STA (CurrentObject),Y ; and stroe the object's current room INY ; ;================================== ;============ADDED CODE============ CPX #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 ; TAX ;...and give to an index register LDA CarryXtbl,X ;using a table, load the new position BEQ KeepOldCarryX ;if invalid, don't update STA CarriedX ;...or store as current KeepOldCarryX: LDA CarryYtbl,X ;do the same for vertical BEQ KeepOldCarryY ;if invalid, don't update STA CarriedY ; KeepOldCarryY: ;================================== ;================================== ;continue with original code (LDA PlayerX, etc.) Then add the data tables that indicate how many pixels away to hold the object (I just used 8 and negative 8 as a test...these might need fudging). Paste 'em in the same bank away from the program area: ;new data tables... CarryXtbl: .byte $00 ;invalid .byte $00 ;invalid .byte $00 ;invalid .byte $00 ;invalid .byte $00 ;invalid .byte $08 ;right+down .byte $08 ;right+up .byte $08 ;right .byte $00 ;invalid .byte $F8 ;left+down .byte $F8 ;left+up .byte $F8 ;left .byte $00 ;invalid .byte $00 ;down .byte $00 ;up .byte $00 ;not moving CarryYtbl: .byte $00 ;invalid .byte $00 ;invalid .byte $00 ;invalid .byte $00 ;invalid .byte $00 ;invalid .byte $F8 ;right+down .byte $08 ;right+up .byte $00 ;right .byte $00 ;invalid .byte $F8 ;left+down .byte $08 ;left+up .byte $00 ;left .byte $00 ;invalid .byte $F8 ;down .byte $08 ;up .byte $00 ;not moving Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 Ah...I didn't see the goof. Funny tho...Dasm should have caught it The label NotReversable1 is being referenced for both sprites. This is incorrect. A mismatch comparison for the dragon on the first sprite would cause it to leap all the way down past the setup for the second sprite! In the lower section, rename the label (and the 2 branches above it) to NotReversable2. Okay, I have edited the code and moved the Dragon (normal state) sprite to another area between two room layouts. The game will still not compile. Am I still in error in the following area? This is the code I have: LDA (CurrentObject),Y ;Get Object1's high graphic address ;5 STA Obj1Hi ;and store for print. ;3 LDY #$00 ;2 Set no reflect CMP #>GfxDrag0 ;2 is it a chasing dragon bitmap? BNE NotReversable1 ;2 skip ahead if not LDA Obj1X ;3 Get object's X location SEC ;2 SBC PlayerX ;3 Subtract player's location BMI NotReversable1 ;2 Branch if sprite is on the right LDY #$08 ;2 Set reflect NotReversable1: STY REFP0 ;3 store reflect for sprite 0 ;Colour LDA Store7,X ;Get Object1's Color. ;4 JSR ChangeColor ;Change if necessary. ;6 STA COLUP0 ;And set color luminance00. ;3 ;Object1 Size ResizeObject: LDA Store8,X ;Get Object1's Size ;4 ORA #$10 ;And set to larger size if necessary. ;2 STA NUSIZ0 ;(Used by bridge and invisible surround) ;3 ;Setup Object 2 to Print. LDX CurrentObject+3 ;Get Object 2 ;3 LDA Store1,X ; ;4 STA CurrentObject ;Get low pointer to it's dynamic information. ;3 LDA Store2,X ; ;4 STA CurrentObject+1 ;Get high pointer to it's dynamic information. ;3 LDY #$01 ; ;2 LDA (CurrentObject),Y ;Get Object2's X coordinate ;5 STA Obj2X ;and store for print. ;3 INY ; ;2 LDA (CurrentObject),Y ;Get Object2's Y coordinate ;5 STA Obj2Y ;and store for print. ;3 LDA Store3,X ;Get low pointer to state value. ;4 STA CurrentObject ; ;3 LDA Store4,X ;Get high pointer to state value. ;4 STA CurrentObject+1 ; ;3 LDY #$00 ; ;2 LDA (CurrentObject),Y ;Retrieve Object2's current state. ;5 STA State ; ;3 LDA Store5,X ;Get low pointer to state information. ;4 STA CurrentObject ; ;3 LDA Store6,X ;Get high pointer to state information. ;4 STA CurrentObject+1 ; ;3 JSR GetObjectState ;Find the current state in the state information;6 INY ;Index to state's corresponding graphic pointer ;2 LDA (CurrentObject),Y ; ;5 STA Obj2Lo ;Get Object2's low graphic address. ;3 INY ; ;2 LDA (CurrentObject),Y ;Get Object2's high graphic address. ;5 STA Obj2Hi ; ;3 LDY #$00 ;2 Set no reflect CMP #>GfxDrag0 ;2 is it a chasing dragon bitmap? BNE NotReversable2 ;2 skip ahead if not LDA Obj2X ;3 Get object's X location SEC ;2 SBC PlayerX ;3 Subtract player's location BMI NotReversable2 ;2 Branch if sprite is on the right LDY #$08 ;2 Set reflect NotReversable2: STY REFP1 ;3 store reflect for sprite 0 ;Color LDA Store7,X ;Get Object2's Color ;4 JSR ChangeColor ;Change if Necessary. ;6 STA COLUP1 ;and set color luminance01. ;3 ;Object2 Size ResizeObject2: LDA Store8,X ;Get Object2's Size ;4 ORA #$10 ;And set to larger size if necessary. ;2 STA NUSIZ1 ;(Used by bridge and invisible surround) ;3 RTS ; ;6 Quote Link to comment Share on other sites More sharing options...
accousticguitar Posted February 10, 2011 Share Posted February 10, 2011 When working with assembly language, the proper term is "assemble" instead of "compile." What text file are you using? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 (edited) What exactly is Dasm reporting? Be aware that you can select a higher level of verbosity using the -v# switch...and dump the results to a text file using the > character. If you want the contents of the new binary to be really clear, you can have it create a list file using the -1 switch (lower-case L). Example: Dasm Ad8k.asm -f3 -lList.txt -v4 -oAd8k.bin > Summary.txt ...should give you a detailed-enough report in text files. Edited February 10, 2011 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 (edited) Here's the contents of the Summary.txt DASM V2.20.10, Macro Assembler ©1988-2004 INFO DELETED Edited February 10, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
raskar42 Posted February 10, 2011 Share Posted February 10, 2011 you know - i was thinking about it - this might be a cool way to make a Daedalus game - with wings instread of a balloon and the labyrinth and a minotaur and other monsters. just a thought. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 (edited) FILE DELETED...NOTHING TO SEE HERE FOLKS Edited February 10, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 Just for clarification purposes, I am using the Adventure8 sourcefile, renamed cyoa just so I can use the "Create Binary" button in the CYOA editor rather than retype the command line every time I want to assemble. Make sense? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 (edited) Trying to stuff too many bytes in a page: 882 1c15 - address counter at $1C15 883 1c00 ORG $1C00 - error...already beyond it. NOTE: the dragon bitmap is short enough to stuff into the first page (ensuring that nothing else uses the same page). Just move the 28 bytes between RORG $D0E4 and ORG $1100 to below RORG $D100, then paste the dragon below RORG $D0E4 Edited February 10, 2011 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 (edited) Yes, I figured I had messed up on the bytes issue, so I switched it all the images back to their original order. I thought I could swap evenly with the portcullis image. Sorry, learning experience. I'm going to focus on the other changes I was going to make, then come back and visit the whole reverse thing later. The reverse code will not assemble with the dragon in its default location, so I took that code out for the time being. Edited February 10, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 (edited) If you are unsure how many bytes remain in a page...just add ECHO * (indented) at the spot you are checking. Dasm will show you the current address when you assemble. The assemblies I did usually had everything packed full in the last pages (so you need to use space higher up in the text or move stuff around). Edited February 10, 2011 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 Example: ORG $F000 bitmapofnothing: .byte 0 .byte 0 .byte 0 .byte 0 ECHO * If that was how an assembly of the rom portion began, the DOS window will show the address $F004 (it'll show it twice, because Dasm uses 2 passes by default). If bitmapofnothing was 256 or more bytes long, the ECHO address would be a different page than the ORG above it. F1 vs F0. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 (edited) Just in case you want to see the revised version of Adventure I've been tweaking, here's the file. The bat resurrects dead dragons upon pickup and there are some redesigns and color changes with several objects and rooms. UPDATED 02/11/11 AdventureResBat.bin Edited February 11, 2011 by keithbk Quote Link to comment Share on other sites More sharing options...
accousticguitar Posted February 10, 2011 Share Posted February 10, 2011 If you are unsure how many bytes remain in a page...just add ECHO * (indented) at the spot you are checking. Dasm will show you the current address when you assemble. Cool, that could come in handy! By the way Keithbk, Nukey's later assemblies have flipping dragons built in. Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 I should point out that this is NOT the version with the hot air balloon as originally posted in this thread...should I start a new thread now? Quote Link to comment Share on other sites More sharing options...
keithbk Posted February 10, 2011 Share Posted February 10, 2011 If you are unsure how many bytes remain in a page...just add ECHO * (indented) at the spot you are checking. Dasm will show you the current address when you assemble. Cool, that could come in handy! By the way Keithbk, Nukey's later assemblies have flipping dragons built in. ARRRGGGHHHH!!!! I though I had the latest assembly... Wow, could have saved a bit of time...where can I find this latest assembly? Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 10, 2011 Share Posted February 10, 2011 I lost track of stuff I did too. The latest 8k build is here It's from post #83 of the Adventure Playfield Manipulation Midscreen discussion. But talking about it again made me aware of some other improvements that could be done 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.