A question from the Dev Night ABUG zoom meeting re how I draw sprites in DigDug and games in general.
![:)]( "Smile")
How a sprite moves, or where it appears on screen will affect how I store the data and how the sprite routine works.
For a sprite that isn't always aligned to a character row, I usually store the data in vertical stripes a byte wide.
I then have the X register index the sprite and mask if used and the Y register index into the character byte.
X gets decremented and the routine quits when it gets to 0, starting at sprite hight - 1.
Y starts on the bottom pixel row and decrements until it goes negative, it the reloads with 7 and decrements the high bytes of the screen addresses twice (I make the screen narrower so that a character row is 512 bytes as I usually use MODE 1).
I usually do this 4 columns in parallel for a sprite that is 13x16 pixels or something like that.
The 13 is because I have a copy of the sprite for each offset within a byte meaning that all sprites are 4 bytes wide.
For a game where the original sprite was 16x16, I would usually have two versions of the code with 4 columns for when the sprite is byte aligned and 5 columns wide when it is not.
Feel free to ask anything here and I'll try to answer.
It probably take me more time to work out how to do the sprite drawing for a game as I enjoy it and so, over optimise itOhh i see! Thank you for the answer! Thats very clever- I was thinking and didn't think of eor/xor, my thinking was just to redraw each sprite individually, which would be hugely inefficient. i can only imagine how long it would take with BASIC. Does it take a long time to work out how to get it functional/program the sprite function? How exactly do you define said sprites? I'm assuming its not using the inbuilt 8x8 def chrs.
Yeah no worriesToo many questions!
Too many questions!
How a sprite moves, or where it appears on screen will affect how I store the data and how the sprite routine works.
For a sprite that isn't always aligned to a character row, I usually store the data in vertical stripes a byte wide.
I then have the X register index the sprite and mask if used and the Y register index into the character byte.
X gets decremented and the routine quits when it gets to 0, starting at sprite hight - 1.
Y starts on the bottom pixel row and decrements until it goes negative, it the reloads with 7 and decrements the high bytes of the screen addresses twice (I make the screen narrower so that a character row is 512 bytes as I usually use MODE 1).
I usually do this 4 columns in parallel for a sprite that is 13x16 pixels or something like that.
The 13 is because I have a copy of the sprite for each offset within a byte meaning that all sprites are 4 bytes wide.
For a game where the original sprite was 16x16, I would usually have two versions of the code with 4 columns for when the sprite is byte aligned and 5 columns wide when it is not.
Feel free to ask anything here and I'll try to answer.
Statistics: Posted by tricky — Thu Jan 16, 2025 8:59 pm