Session 24: Some nice code

[+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]

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

 

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]

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.

[+grafixbmp]

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 November 2, 2008 by grafixbmp

[+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]

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

[+Random Terrain]

There's a typo. . .

Thanks.

[Thomas Jentzsch]

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 April 20, 2011 by Thomas Jentzsch