Primordial Ooze Posted October 20, 2012 Share Posted October 20, 2012 (edited) I am getting a wierd effect when the player1 sprite is on the left side of the screen. For some reason the bottom is bumped up a bit on the bottom. I can't figure out why it's doing it. I am posting my code in hopes of someone figuring this out. Any assistance would be greatly appreciated. Sincerely, Primordial Ooze Edited October 20, 2012 by Primordial Ooze Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 20, 2012 Share Posted October 20, 2012 It would be better if you posted a binary demonstrating the issue, but it sounds like shearing or tearing. It's caused by updating your player in the visible portion of the scanline. Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted October 20, 2012 Author Share Posted October 20, 2012 It would be better if you posted a binary demonstrating the issue, but it sounds like shearing or tearing. It's caused by updating your player in the visible portion of the scanline. Here you go, hope this helps. Sincerely, Primordial Ooze Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 20, 2012 Share Posted October 20, 2012 Yup, your Player1 is tearing because its being updated during on-screen cycles. Your choices to fix this are either to update it during horizontal blank cycles or look at using VDELP1. Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted October 20, 2012 Author Share Posted October 20, 2012 Yup, your Player1 is tearing because its being updated during on-screen cycles. Your choices to fix this are either to update it during horizontal blank cycles or look at using VDELP1. If that is the case then why isn't the duck tearing as well? Sincerely, Primordial Ooze Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 20, 2012 Share Posted October 20, 2012 According to your comments, GRP1 (the crosshairs) is updated on cycle 29 and GRP0 (the duck) is updated at cycle 12. The visible screen starts a bit after cycle 22. Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted October 20, 2012 Author Share Posted October 20, 2012 (edited) According to your comments, GRP1 (the crosshairs) is updated on cycle 29 and GRP0 (the duck) is updated at cycle 12. The visible screen starts a bit after cycle 22. What if i moved stuff a bit so: sta WSYNC ; (3 3) Wait for the previous line to finish lda pf0data,y ; (4 7)load pf0 data into the acumulator sta PF0 ; (3 10) and store it lda pf1data,y ; (5 15) load pf1 data into the acumulator sta PF1 ; (3 18) and store it lda pf2data,y ; (5 23) load pf2 data into the acumulator sta PF2 ; (3 26) and store it lda CrosshairBuffer ; (3 29) buffer was set during last scanline sta GRP1 ; (3 32) put it as graphics now cpy CrosshairY ; (3 35) compare crosshair's y position bne SkipActivateCrosshair ; (3 38) if it isn't 0 then jump to SkipActiveCrosshair lda #5 ; (2 40) otherwise load our accumulatior with the number of lines to draw sta VisibleCrosshairLine ; (3 43) and store it SkipActivateCrosshair Was: sta WSYNC ; (3 3) Wait for the previous line to finish lda CrosshairBuffer ; (3 6) buffer was set during last scanline sta GRP1 ; (3 9) put it as graphics now cpy CrosshairY ; (3 12) compare crosshair's y position bne SkipActivateCrosshair ; (3 15) if it isn't 0 then jump to SkipActiveCrosshair lda #5 ; (2 17) otherwise load our accumulatior with the number of lines to draw sta VisibleCrosshairLine ; (3 20) and store it SkipActivateCrosshair lda pf0data,y ; (4 24)load pf0 data into the acumulator sta PF0 ; (3 27) and store it lda pf1data,y ; (5 32) load pf1 data into the acumulator sta PF1 ; (3 35) and store it lda pf2data,y ; (5 40) load pf2 data into the acumulator sta PF2 ; (3 43) and store it Would that work? Sincerely, Primordial Ooze Edited October 20, 2012 by Primordial Ooze Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 20, 2012 Share Posted October 20, 2012 That will work for the players. I think you're writing PF0 too late, but that depends on what you're displaying there and if it really matters to your display if part of it is pushed down a line. Really the best thing to do is move things around and try it out in Stella. Then rinse and repeat until you're happy with the results. Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted October 20, 2012 Author Share Posted October 20, 2012 That will work for the players. I think you're writing PF0 too late, but that depends on what you're displaying there and if it really matters to your display if part of it is pushed down a line. Really the best thing to do is move things around and try it out in Stella. Then rinse and repeat until you're happy with the results. Well the top portion is unused at the moment so it doesn't matter for now. An artifact is showing though. When I move the crosshair to the top small blocks are being shown in an ooze like pattern. Not a big deal though as right now I'm trying to get stuff working. Sincerely, Primordial Ooze Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted October 21, 2012 Share Posted October 21, 2012 According to your comments, GRP1 (the crosshairs) is updated on cycle 29 and GRP0 (the duck) is updated at cycle 12.The comments had the cycle counts wrong...GRP1 was really hit on cycle 26 in the original post (which is still a little late). PO: When you perform WSYNC, the cycle count for the scanline begins at cycle 0, not 3. And $Absolute,Y addressing uses 4 cycles, not 5 (unless a page was crossed when accessing the data). Also keep in mind that branching instructions only use 2 cycles when they are not taken. Since you have a little time left when bne ScanLoop occurs, you could move the initial LDA pf0data,y to happen before you do the WSYNC. That will shave off the 4 cycles needed to hit at 22 when GRP1 is stored. Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted October 21, 2012 Author Share Posted October 21, 2012 (edited) The comments had the cycle counts wrong...GRP1 was really hit on cycle 26 in the original post (which is still a little late). PO: When you perform WSYNC, the cycle count for the scanline begins at cycle 0, not 3. And $Absolute,Y addressing uses 4 cycles, not 5 (unless a page was crossed when accessing the data). Also keep in mind that branching instructions only use 2 cycles when they are not taken. Since you have a little time left when bne ScanLoop occurs, you could move the initial LDA pf0data,y to happen before you do the WSYNC. That will shave off the 4 cycles needed to hit at 22 when GRP1 is stored. Thanks, by the way i'm running into another problem trying to move the duck towards the right: lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity cmp #$98 ; does it intersect the right boundry? bcs SkipReverseDuckVX ; if it does then don't reverse it's x velocity ldx 256-DuckVX ; otherwise reverse it's x velocity SkipReverseDuckVX sta DuckX ; store duck's new x position stx DuckVX ; store duck's new x velocity Seems the duck doesn't want to budge. I have attached the latest source code and bin file for reference. Sincerely, Primordial Ooze Edited October 21, 2012 by Primordial Ooze Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted October 21, 2012 Share Posted October 21, 2012 (edited) You can't subtract a variable from a constant in the same instruction (ldx 256-DuckVX). Also, the result was stored (stx DuckVX) whether or not the branch was taken...leading to problems if X was not already loaded beforehand. I suggest moving sta DuckX to happen before the BCS, so you can use the accumulator to update velocity... lda DuckVX eor #$FF sta DuckVX ...and having the branch destination right at the bottom so no update occurs when velocity is not being changed. Edited October 21, 2012 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted October 21, 2012 Author Share Posted October 21, 2012 (edited) You can't subtract a variable from a constant in the same instruction (ldx 256-DuckVX). Also, the result was stored (stx DuckVX) whether or not the branch was taken...leading to problems if X was not already loaded beforehand. Still Can't get it to work on both sides: lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity sta DuckX bne SkipReverseDuckVX ; does it intersect the left boundry? lda DuckVX ; load the duck's x velocity eor #$00 ; negate it cmp #$98 ; does it intersect the right boundry? bcc SkipReverseDuckVX ; if it doesn't then don't reverse it's x velocity lda DuckVX ; load the duck's v velocity eor #$FF ; negate it sta DuckVX ; store it SkipReverseDuckVX Any assistance would be greatly appreciated. Sincerely, Primordial Ooze Edited October 21, 2012 by Primordial Ooze Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted October 21, 2012 Share Posted October 21, 2012 (edited) lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity sta DuckX beq DoReverseDuckDX cmp #$98 ; does it intersect the right boundry? bcc SkipRightDuckVX ; if it doesn't then don't reverse it's x velocity DoReverseDuckDX lda DuckVX ; load the duck's v velocity eor #$FF ; reverse it sta DuckVX ; store it SkipRightDuckVX Edited October 21, 2012 by Nukey Shay Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted October 21, 2012 Share Posted October 21, 2012 One more thing about inversion: The 6502 uses a two's complement respresentation for signed numbers. This means just doing an EOR $FF ist not enough (e.g., 0 EOR $FF equals $FF, which is -1), you addtionally have to add 1 to invert a number. You can also do: sec lda #0 sbc DuckVX sta DuckVX Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted October 21, 2012 Share Posted October 21, 2012 Oops...thanks for that. Those lines will work as a replacement for DoReverseDuckDX. It should also be mentioned that ram could be saved if velocity is always between -1 and 1 (no need to waste a full byte for DuckDX if you are only moving a pixel at a time)...but that is outside the original question. Quote Link to comment Share on other sites More sharing options...
Primordial Ooze Posted October 21, 2012 Author Share Posted October 21, 2012 lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity sta DuckX beq DoReverseDuckDX cmp #$98 ; does it intersect the right boundry? bcc SkipRightDuckVX ; if it doesn't then don't reverse it's x velocity DoReverseDuckDX lda DuckVX ; load the duck's v velocity eor #$FF ; reverse it sta DuckVX ; store it SkipRightDuckVX Thanks Nukey Shay, i amaged to get it working with your code! Sincerely, Primordial Ooze Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted October 21, 2012 Share Posted October 21, 2012 The EOR won't work properly (as mentioned above). The BEQ may also fail if velocity is anything above a single pixel. lda DuckX ; load the ducks position clc ; clear carry adc DuckVX ; increment duck's x position by it's x velocity sta DuckX cmp #LEFT_BOUNDRY ; does it intersect the left boundry? bcc DoReverseDuckDX ;branch if so cmp #$98 ; does it intersect the right boundry? bcc SkipRightDuckVX ; if it doesn't then don't reverse it's x velocity DoReverseDuckDX sec lda #$00 ; sbc DuckVX ; reverse the duck's x velocity sta DuckVX ; store it SkipRightDuckVX Constant #LEFT_BOUNDRY should at least be equal to the maximum number of pixels that DuckVX is allowed to be by the program. 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.