Jump to content

Photo

Session 24: Some nice code


36 replies to this topic

#26 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,471 posts
  • begin 644 contest

Posted Wed Feb 16, 2005 1:07 PM

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.

#27 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,756 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Wed Feb 16, 2005 1:17 PM

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

Maybe, but then we did also only discuss again what other guys already had dicussed many years before. ;)

#28 CabaretVoltaire OFFLINE  

CabaretVoltaire

    Space Invader

  • 44 posts

Posted Tue Oct 25, 2005 5:02 AM

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..

#29 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,756 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Tue Oct 25, 2005 5:20 AM

Do do
 sta WSYNC
  sta HMOVE
after that code?

#30 CabaretVoltaire OFFLINE  

CabaretVoltaire

    Space Invader

  • 44 posts

Posted Tue Oct 25, 2005 5:50 AM

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

[code=auto:0]
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.

#31 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,756 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Tue Oct 25, 2005 11:47 AM

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

  [code=auto:0]
  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.

View Post

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

#32 grafixbmp OFFLINE  

grafixbmp

    Dragonstomper

  • 667 posts
  • Location:South Central US

Posted Sun Nov 2, 2008 10:29 AM

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.

#33 grafixbmp OFFLINE  

grafixbmp

    Dragonstomper

  • 667 posts
  • Location:South Central US

Posted Sun Nov 2, 2008 10:56 AM

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, Sun Nov 2, 2008 10:58 AM.


#34 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 24,837 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Apr 20, 2011 8:14 AM

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.

#35 bogax ONLINE  

bogax

    Moonsweeper

  • 487 posts

Posted Wed Apr 20, 2011 10:12 AM

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,'

#36 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 24,837 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Apr 20, 2011 2:22 PM

There's a typo. . .

Thanks. :thumbsup:

#37 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,756 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Wed Apr 20, 2011 3:03 PM

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, Wed Apr 20, 2011 3:25 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users