Jump to content
Sign in to follow this  
Primordial Ooze

Sprite bumped on left side

Recommended Posts

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 by Primordial Ooze

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

post-23476-0-55777900-1350753285_thumb.png

Share this post


Link to post
Share on other sites

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.

 

post-23476-0-55777900-1350753285_thumb.png

If that is the case then why isn't the duck tearing as well?

 

Sincerely,

 

Primordial Ooze

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Primordial Ooze

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by Primordial Ooze

Share this post


Link to post
Share on other sites

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 by Nukey Shay

Share this post


Link to post
Share on other sites

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 by Primordial Ooze

Share this post


Link to post
Share on other sites
 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 by Nukey Shay

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...