36 replies to this topic

[batari]

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.

[Thomas Jentzsch]

batari said:

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.

[CabaretVoltaire]

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

[Thomas Jentzsch]

Do do

  sta WSYNC
  sta HMOVE

after that code?

[CabaretVoltaire]

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

  [code]
  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.

[Thomas Jentzsch]

CabaretVoltaire, on Tue Oct 25, 2005 1:50 PM, said:

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

  [code]
  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.

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

[grafixbmp]

Nukey Shay, on Mon Feb 14, 2005 3:31 PM, said:

Quote

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

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.

[grafixbmp]

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.

[Random Terrain]

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.

[bogax]

Random Terrain, on Wed Apr 20, 2011 8:14 AM, said:

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

...

Quote

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

[Random Terrain]

bogax, on Wed Apr 20, 2011 10:12 AM, said:

There's a typo. . .

Thanks.

[Thomas Jentzsch]

grafixbmp, on Sun Nov 2, 2008 10:56 AM, said:

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.