Thanks Tricky
OR'ing onto the background. Its all complicated by double buffering and software scrolling which means I have to erase and re-draw each frame. So:
1. Remove all the sprites
2. Draw the 'scrolled' canyon walls
3. Draw the sprites OR'ing over any background
The double buffering means I have to remember 2 drawn locations for each sprite so that I only ever erase the previous 'buffer' version. I had a wonderful bug which involved using the wrong pointers for buffer/screen and resulted in some very strange looking graphics for a while!
I can't use the self undrawing trick due to the double buffering either.
The Electron memory layout is the same as the Beeb![:)]( "Smile")
My player sprite, which doesn't move vertically has its own plot routine. All other sprites have to move up/down so a 16 pixel high sprite can end up being drawn in 3 different vertical 8 pixel lines. <- Not explaining this very well![:)]( "Smile")
I'm using a mixture of self-modifying pointers/zero page indirect based on calculating what the relative cycle counts are for looping & setting everything up.
My 'enemy' sprite plot setup code currently takes 189 cycles just to calculate the source sprite location + 3 destination locations. The draw loop which is just 3 lots of:
repeated 16 times is another 768 cycles (worst case) The difference if I use self modifying for the source & destination was only 96 cycles and the changes necessary to the setup/next line code meant that it was more cycles to do it that way. Of course I might have got my cycle counts wrong so I will go back and re-check ![:)]( "Smile")
I keep trying to come up with a lookup table mechanism to avoid the add/subtract when jumping across lines as I'm sure there's some time to be gained in there in multiple places but each attempt I've made so far hasn't helped. It feels tantalisingly close though. If I can get this working then I can switch back to a fully self modifying pointer version too.
Have just bookmarked and read your sprite drawing link - thanks for sharing![:)]( "Smile")
One thing I need to look into is setting my origin as the bottom left of the screen rather than the top left like you describe in that link as I'm fairly sure this will help with at least one of the issues I'm seeing.
20000 cycles per frame just isn't enough![:(]( "Sad")
OR'ing onto the background. Its all complicated by double buffering and software scrolling which means I have to erase and re-draw each frame. So:
1. Remove all the sprites
2. Draw the 'scrolled' canyon walls
3. Draw the sprites OR'ing over any background
The double buffering means I have to remember 2 drawn locations for each sprite so that I only ever erase the previous 'buffer' version. I had a wonderful bug which involved using the wrong pointers for buffer/screen and resulted in some very strange looking graphics for a while!
I can't use the self undrawing trick due to the double buffering either.
The Electron memory layout is the same as the Beeb
My player sprite, which doesn't move vertically has its own plot routine. All other sprites have to move up/down so a 16 pixel high sprite can end up being drawn in 3 different vertical 8 pixel lines. <- Not explaining this very well
I'm using a mixture of self-modifying pointers/zero page indirect based on calculating what the relative cycle counts are for looping & setting everything up.
My 'enemy' sprite plot setup code currently takes 189 cycles just to calculate the source sprite location + 3 destination locations. The draw loop which is just 3 lots of:
Code:
.sprite_1_ptr_smc lda &ffff,x ; 4 ora (sprite_dest_1), y ; 6 sta (sprite_dest_1), y ; 6I keep trying to come up with a lookup table mechanism to avoid the add/subtract when jumping across lines as I'm sure there's some time to be gained in there in multiple places but each attempt I've made so far hasn't helped. It feels tantalisingly close though. If I can get this working then I can switch back to a fully self modifying pointer version too.
Have just bookmarked and read your sprite drawing link - thanks for sharing
One thing I need to look into is setting my origin as the bottom left of the screen rather than the top left like you describe in that link as I'm fairly sure this will help with at least one of the issues I'm seeing.20000 cycles per frame just isn't enough
Statistics: Posted by rasto1968 — Fri Aug 30, 2024 6:49 pm