Jump to content
IGNORED

Session 24: Some nice code


Recommended Posts

Thanks for pointing out that SEC thing.

 

yeah, you can get 5 cycles by optimizing the table method. THe y-register thing was the deal-breaker for me. But looking at Manuel's code there, it could have worked with the EOR/ASL thing if not for the JMP at the end. Still, I'll have to remember this one if I have a need for 16-bit sprites.

 

It's starting to sound like you guys have already discussed everything a couple of years ago.

Link to comment
Share on other sites

  • 8 months later...

I cannot get these subroutines to work for more than one sprite.

 

I am doing:

 

sta HMCLR

 

ldx #0 ;-RESP0, HMP0

lda SpriteX

jsr PositionSprite

 

ldx #1 ;-RESP1, HMP1

lda SpriteX

jsr PositionSprite

 

 

 

So both sprites should have the same horizontal position.

 

The first sprite (doesn't matter which one I position first) will be positioned 100% fine.. The second one will be positioned roughly ok but the HMPx setting seems to be wrong as it jitters around whilst moving horizontally..

Link to comment
Share on other sites

I was writing to WSYNC at the end of the subroutine..

 

 

  sta WSYNC

  rts

 

and then writing to HMOVE after both subroutine calls.

 

I've changed it so that I do both writes after the subroutine calls and it works, thanks.

[right][snapback]953929[/snapback][/right]

It is important that you write to HMOVE *directly* after WSYNC. WSYNCs at the end of the subroutine are superfluous.

Link to comment
Share on other sites

  • 3 years later...
It is true that assuming the pixels on screen are numbered 0 to 159, then placing the corresponding value in A and calling this routine will not position object at the expected pixel.

 

My feeble mind had given up trying to figure out things like Xreal and K :lol:

 

Instead, I just use a table. 160 bytes of overhead, but simple enough to grasp. When you get involved with bankswitching, it's not like rom is scarce or anything ;)

I don't think its ROM amount per-se I think it is amount of cycles to acheive task. The less the better. The more elegant, the more you can do per scanline.

Link to comment
Share on other sites

There are usualy 2 basic types of h positioning code.

 

One that does it before the screeen start as in one for each sprite per screen and one that is able to do it multiple times during the screen if a sprite is reused. idealy both.

 

what are the best for both situations that take up less cycles when it is done (like overhead before the screen then call it up during the screen for multiple so that it takes just a few cycles.)? This way the bulk happens when cycles isn't an issue and when they are as when it is needed in the middle of the screen, the actual reposition happens.

Just curious.

Edited by grafixbmp
Link to comment
Share on other sites

  • 2 years later...

I'm putting adapted versions of these sessions on my web site. Does the information in the first post need to be updated with anything that has been posted in this thread? I know almost nothing about assembly language, so I can't tell.

 

 

Thanks.

Link to comment
Share on other sites

I'm putting adapted versions of these sessions on my web site. Does the information in the first post need to be updated with anything that has been posted in this thread? I know almost nothing about assembly language, so I can't tell.

 

 

Thanks.

 

There's a typo

 

       ldx #0 

       txa 

Clear   dex 

       txs 

       pha 

       bne Clear

 

...

 

since the tsx and pha don't affect the flags,

 

I believe that should be

 

'since the txs and pha don't affect the flags,'

  • Like 1
Link to comment
Share on other sites

There are usualy 2 basic types of h positioning code.

 

One that does it before the screeen start as in one for each sprite per screen and one that is able to do it multiple times during the screen if a sprite is reused. idealy both.

For repositioning outside the kernel usually the nice code rediscovered by Cybergoth in Battlezone code IMO is optimal.

 

Mid kernel repositioning is always very much depending on the kernel itself. So there is no fixed optimal solution. One often used trick is to split the position into two or more horizontal areas and write specialized code for each area. That way you can use the gained time for kernel updates even during repositioning. Without this trick, repositioning blocks the CPU almost completely for one whole scanline.

Edited by Thomas Jentzsch
  • Like 1
Link to comment
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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...