Beginner's Sprite Tutorial

The place for codemasters or beginners to talk about programming any language for the Spectrum.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Beginner's Sprite Tutorial

Post by R-Tape »

dfzx wrote: Sun Dec 24, 2017 6:20 pm Use a hollow box graphic, not a filled one. That black smear going down your first image isn't at all clear. Maybe add a grid on 8 pixel boundaries so it's clearer that there's 3 bytes of width, not 2. It took me a while to work out why the bottom block of the graphic has a white line down the right edge.
Agreed, I was tempted to show a walking sprite but a hollow box it is.
dfzx wrote: Sun Dec 24, 2017 6:20 pm You should probably define the term "preshifted" rather than just using it as if the reader is expected to know what it means.
Yep, and compared to rotated.
dfzx wrote: Sun Dec 24, 2017 6:20 pm The term "therefore each sprite is 48 bytes" might be better as "therefore each preshifted position of the sprite is 48 bytes".
Yup.
dfzx wrote: Sun Dec 24, 2017 6:20 pm Use more meaningful labels. I presume "xcor" is an abbreviation of "X coordinate"? Make it, say, "x_position". I don't know what "delp" might be an abbreviation of.
I think most will get xcor as x coordinate, but no harm in hammering it home. "delp" is delete loop,, and would be better described as such (or loop1, loop2 etc), I fell into my regular shorthand there.
dfzx wrote: Sun Dec 24, 2017 6:20 pm I don't think the LD BC,(xcor) is helpful at this level, even with the comment. Load B and C separately.
I almost did that. Agreed.
dfzx wrote: Sun Dec 24, 2017 6:20 pm Otherwise, very good. I think a better graphic which more clearly describes how the preshifted sprite gets put into the bytes of the display would help. If someone hasn't grasped the concept of what you're doing I don't think reading that code will help them. Once they have grasped it, I think it should be clear.
Cheers.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Beginner's Sprite Tutorial

Post by R-Tape »

bob_fossil wrote: Sun Dec 24, 2017 5:50 pm Been playing around with R-Tape's posted source today and managed to knock this up with z88dk. The main loop is in C but the sprite erasing and drawing is all in assembly.

Image

All the graphics I've done so far have been basic block printing so having some example code to work from has been helpful to see how animated sprites works with the 'interesting' Spectrum screen layout - so thanks again for doing this!
That warms me cockles bob!
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Beginner's Sprite Tutorial

Post by RMartins »

I believe the only thinkg missing, is a graphical schema of what is going on, before actually diving into the code.

People like to see an overview, that prepares them for what comes next. Makes it easier to grasp.

Also, the concept of animation, and how it works in consecutive frames, might be worth a small intro.
Last edited by RMartins on Mon Dec 25, 2017 9:42 pm, edited 1 time in total.
dfzx
Manic Miner
Posts: 673
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Re: Beginner's Sprite Tutorial

Post by dfzx »

Having thought about it a bit more, what you could do is split it into 2 lessons. The first could use a sprite one pixel high, which would allow the focus to remain solely on how the horizontal preshifting works. Then make the second lesson add the other 15 rows of the sprite, which is what you have now.
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Beginner's Sprite Tutorial

Post by RMartins »

Something that I would change/add, would be to split the several shifted sprite versions, into actual distinct sprites.
i.e. having the 8 sprite versions, in order in memory is an optimization that might not be clear for a beginner.

If instead, we had a simple table, with the address of all those 8 pre-shifted sprites, we can still mutiple A by 2, and the get the Sprite address from the table.

From a beginners perspective, it's easier to grasp that we have a table of sprites (8 in this case), and we get one from there using an index.
(Coincidently, it's also faster, but that is not the point here)

Getting the sprite we want by multiplying the index by 48 (sprite total length in bytes), and then add the base address, because they are in sequence in memory, is not immediate to understand for a beginner.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Beginner's Sprite Tutorial

Post by R-Tape »

The following is an updated example that I hope addresses everyone's suggestions (even the ones I ignored :-p).
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Beginner's Sprite Tutorial

Post by R-Tape »

This is a relatively simple and unoptimised routine to draw one sprite on the screen. For the purposes of this exercise, the routines nextlinedown, yx2pix and getsprite do not need to be understood yet.

This assumes the beginner already knows how to assemble the code (though do ask if not sure), and knows the rudiments of the language.

Image

In this example we draw the same sprite (a 16 x 16 pixel blob on legs) stored in memory, shifted in all 8 possible positions (that's why we call these 'preshifted' sprites), moving left to right, like this:

Image

As the sprite moves sideways it straddles more than 16 pixels, so we need to store the graphic with a space for it to move into. For this reason each sprite position is 3 bytes wide and 16 pixels high, therefore each sprite position is 48 bytes.

Also notice that the sprite graphic is slightly different in each position, to give a walking animation.

If you assemble the code and RANDOMIZE USR 32768 you should see this:

Image

And for additional info, in this slowed down animation below, see how the lowest 3 bits of the x coordinate cycles 0 - 7 (decimal). So whatever the x coordinate is, we can grab the lowest 3 bits and get the correct sprite graphic.

Image


And finally, here's the code:

Code: Select all

org 32768			;we can ORG (or assemble) this code anywhere really
				;a beginner's, unoptimised sprite routine
main:	halt			;this stops the program until the Spectrum is about to refresh the TV screen
				;the HALT is important to avoid sprite flicker, and it slows down the program
	call deletesprite	;we need to delete the old position of the sprite
	call movesprite		;move the sprite! Could be based on player key input or baddy AI
	call drawsprite		;get correct preshifted graphic, and draw it on the screen
	jr main			;loop!
	;
deletesprite:			;we need to delete the old sprite before we draw the new one.  The sprite is 3 bytes wide & 16 pixels high
	ld a,(x_coordinate)		;make C=xcor and B=ycor
	ld c,a
	ld a,(y_coordinate)
	ld b,a
	call yx2pix		;point DE at the corresponding screen address
	ld b,16			;sprite is 16 lines high
deleteloop:
	ld a,0			;empty A to delete
	ld (de),a		;repeat a total of 3 times
	inc e			;next column along
	ld (de),a
	inc e
	ld (de),a
	dec e
	dec e			;move DE back to start of line
	call nextlinedown	;move DE down one line
	djnz deleteloop		;repeat 16 times
	ret
	;
movesprite:			;very simple routine that just increases the x coordinate
	ld a,(x_coordinate)
	inc a
	ld (x_coordinate),a
	cp 232			;check if the sprite has moved all the way to the right (256-24)
	ret c			;return if not
	ld a,0			;if yes then back to left
	ld (x_coordinate),a
	ret
	;
drawsprite:
	ld a,(x_coordinate)		;make C=xcor and B=ycor
	ld c,a
	ld a,(y_coordinate)
	ld b,a
	call yx2pix		;point DE at corresponding screen position
	ld a,(x_coordinate)	;but we still need to find which preshifted sprite to draw
	and 00000111b		;we have 8 preshifted graphics to choose from, cycled 0-7 in the right hand 3 bits of the x coordinate
	call getsprite		;point HL at the correct graphic
	ld b,16			;sprite is 16 lines high
drawloop:
	ld a,(hl)		;take a byte of graphic
	ld (de),a		;and put it on the screen
	inc hl			;next byte of graphic
	inc e			;next column on screen
	ld a,(hl)		;repeat for 3 bytes across
	ld (de),a
	inc hl
	inc e
	ld a,(hl)
	ld (de),a
	inc hl
	dec e
	dec e			;move DE back to left hand side of sprite
	call nextlinedown
	djnz drawloop		;repeat for all 16 lines
	ret
	;
x_coordinate:	db	0
y_coordinate:	db	0
	;
nextlinedown:			;don't worry about how this works yet!
	inc d			;just arrive with DE in the display file
	ld a,d			;and it gets moved down one line
	and 7
	ret nz
	ld a,e
	add a,32
	ld e,a
	ret c
	ld a,d
	sub 8
	ld d,a
	ret
	;
yx2pix:		;don't worry about how this works yet! just arrive with arrive with B=y 0-192, C=x 0-255
	ld a,b	;return with DE at corresponding place on the screen
	rra
	rra
	rra
	and 24
	or 64
	ld d,a
	ld a,b
	and 7
	or d
	ld d,a
	ld a,b
	rla
	rla
	and 224
	ld e,a
	ld a,c
	rra
	rra
	rra
	and 31
	or e
	ld e,a
	ret
	;
getsprite:		;don't worry much about how this works!  for an alternative method that
			;uses a table see 'getsprite_alternativemethod'
			;Arrive A holding which pixel within a byte (0-7), point HL at correct graphic
	ld h,0		;we need to multiply A by 48, do it in HL
	ld l,a
	add hl,hl	;x2
	add hl,hl	;x4
	add hl,hl	;x8
	add hl,hl	;x16
	ld b,h
	ld c,l		;BC = x 16
	add hl,hl	;x32
	add hl,bc	;x48
	ld bc,spritegraphic0
	add hl,bc	;HL now pointing at correct sprite frame
	ret
	;
getsprite_alternativemethod:	
			;arrive A holding which sprite position 0 - 7
			;this method uses a table to find the correct graphic
	add a,a		;multiplay a by 2, this converts a single byte number 0-7 into a 2 byte table entry
	ld h,0
	ld l,a
	ld bc,sprite_table_addresses
	add hl,bc	;HL is now pointing at the correct table entry
	ld c,(hl)
	inc hl
	ld b,(hl)	;get table address spritegraphic0, spritegraphic1 etc in BC
	ld l,c
	ld h,b		;now HL is pointing at the correct sprite graphic
	ret
	;
sprite_table_addresses:
	dw	spritegraphic0
	dw	spritegraphic1
	dw	spritegraphic2
	dw	spritegraphic3
	dw	spritegraphic4
	dw	spritegraphic5
	dw	spritegraphic6
	dw	spritegraphic7
	;
spritegraphic0:		;8 preshifted graphics, each one 3 bytes wide and 16 pixels high, this one a simple square
	db 0, 0, 0		;frame 0
	db 7, 224, 0
	db 31, 248, 0
	db 127, 254, 0
	db 127, 214, 0
	db 255, 215, 0
	db 255, 255, 0
	db 255, 255, 0
	db 255, 187, 0
	db 127, 198, 0
	db 127, 254, 0
	db 31, 248, 0
	db 7, 224, 0
	db 0, 0, 0
	db 7, 96, 0
	db 15, 176, 0
	;
spritegraphic1:
	db 0, 0, 0		;frame 1
	db 3, 240, 0
	db 15, 252, 0
	db 63, 255, 0
	db 63, 235, 0
	db 127, 235, 128
	db 127, 255, 128
	db 127, 255, 128
	db 127, 221, 128
	db 63, 227, 0
	db 63, 255, 0
	db 15, 252, 0
	db 3, 240, 0
	db 0, 0, 0
	db 3, 176, 0
	db 7, 216, 0
	;
spritegraphic2:
	db 0, 0, 0		;frame 2
	db 1, 248, 0
	db 7, 254, 0
	db 31, 255, 128
	db 31, 245, 128
	db 63, 245, 192
	db 63, 255, 192
	db 63, 255, 192
	db 63, 238, 192
	db 31, 241, 128
	db 31, 255, 128
	db 7, 254, 0
	db 1, 248, 0
	db 0, 0, 0
	db 7, 158, 0
	db 3, 204, 0
	;
spritegraphic3:
	db 0, 0, 0		;frame 3
	db 0, 252, 0
	db 3, 255, 0
	db 15, 255, 192
	db 15, 250, 192
	db 31, 250, 224
	db 31, 255, 224
	db 31, 255, 224
	db 31, 247, 96
	db 15, 248, 192
	db 15, 255, 192
	db 3, 255, 0
	db 0, 252, 0
	db 0, 0, 0
	db 3, 207, 0
	db 1, 230, 0
	;
spritegraphic4:
	db 0, 126, 0		;frame 4
	db 1, 255, 128
	db 7, 255, 224
	db 7, 253, 96
	db 15, 253, 112
	db 15, 255, 240
	db 15, 255, 240
	db 15, 251, 176
	db 7, 252, 96
	db 7, 255, 224
	db 1, 255, 128
	db 0, 126, 0
	db 1, 128, 192
	db 1, 195, 192
	db 0, 225, 128
	db 0, 0, 0
	;
spritegraphic5:
	db 0, 63, 0		;frame 5
	db 0, 255, 192
	db 3, 255, 240
	db 3, 254, 176
	db 7, 254, 184
	db 7, 255, 248
	db 7, 255, 248	
	db 7, 253, 216
	db 3, 254, 48
	db 3, 255, 240
	db 0, 255, 192
	db 0, 63, 0
	db 0, 192, 96
	db 0, 225, 224
	db 0, 112, 192
	db 0, 0, 0
	;
spritegraphic6:
	db 0, 0, 0		;frame 6
	db 0, 31, 128
	db 0, 127, 224
	db 1, 255, 248
	db 1, 255, 88
	db 3, 255, 92
	db 3, 255, 252
	db 3, 255, 252
	db 3, 254, 236
	db 1, 255, 24
	db 1, 255, 248
	db 0, 127, 224
	db 0, 31, 128
	db 0, 0, 0
	db 0, 14, 128
	db 0, 31, 64
	;
spritegraphic7:
	db 0, 0, 0		;frame 7
	db 0, 15, 192
	db 0, 63, 240
	db 0, 255, 252
	db 0, 255, 172
	db 1, 255, 174
	db 1, 255, 254
	db 1, 255, 254
	db 1, 255, 118
	db 0, 255, 140
	db 0, 255, 252
	db 0, 63, 240
	db 0, 15, 192
	db 0, 0, 0
	db 0, 7, 64
	db 0, 15, 160
	;
;
dfzx
Manic Miner
Posts: 673
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Re: Beginner's Sprite Tutorial

Post by dfzx »

Vast improvement. :D

I need to look at the code more carefully, but the graphical content is immediately understandable.
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Beginner's Sprite Tutorial

Post by RMartins »

Just a small tip on the animation frames, since t looks a bit odd.

Either you are trying to make it look, like the character is jumping, but then a single pixel is not enough.
Or you are doing a regular walk, but the vertical movement is reversed.

i.e. when legs are wide spread apart (doing a large step), it's when we go lower in height on our walk cycle.
When both feet are together, it's when height is highest.
Phytagoras theorem ? :)

You can also benefit the character, by adding more positions on legs, since they mostly seem to be paired each 2 frames.
If possible take into account feet position, while moving, so that character doesn't seem to be sliding.

with 8 frames, walk can look a lot nicer.

P.S.
The bits gif animation, looks great, and simple.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Beginner's Sprite Tutorial

Post by R-Tape »

I agree the walk looks weird, it's my usual animation for a 4 frame, 2 pixel walk hastily doubled up. At twice the speed I usually get away with it.

Does anyone have a decent 8 frame 16px walking sprite I could use? Ideally the sprite needs to fill most of the box.

Or even better, could someone improve the animation of this blob? I like the idea of showing how a walking animation can be done simply.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Beginner's Sprite Tutorial

Post by RMartins »

I'm assuming you want an 8px char.
Does it need to be 16px width ?

I have 2 simple ones, with 16px character, in 24px width.
Image
and
Image

Interested ?
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Beginner's Sprite Tutorial

Post by R-Tape »

They look a bit too good for purposes here! They are 2 sexy looking sprites.

Could you post the frames here and perhaps I can modify the blob?
redballoon
Manic Miner
Posts: 390
Joined: Sun Nov 12, 2017 3:54 pm

Re: Beginner's Sprite Tutorial

Post by redballoon »

Yeah is it possible to see the frames for the 2nd one?
The 1st looks sound but the right leg in the 2nd one looks a bit weird at times. It could just be trying to view a small image in my phone, though.
User avatar
Rorthron
Dynamite Dan
Posts: 1644
Joined: Sun Nov 12, 2017 10:35 pm

Re: Beginner's Sprite Tutorial

Post by Rorthron »

R-Tape wrote: Fri Dec 29, 2017 4:44 am I agree the walk looks weird.
I think it is because of the first (standing) frame and the frame after it.

In the standing frame the two legs do not fully overlap, and in the following frame the two feet are drawn differently, so that the forward foot is the left one. It creates the impression that only the left leg makes forwards steps. If both feet overlapped in the middle frame, so they looked like only one foot, and the stepping frames made the left and right feet look the same, the steps would look a little better (though it would then be inconsistent with the perspective on the face).
RMartins wrote: Fri Dec 29, 2017 4:58 am I'm assuming you want an 8px char.
Does it need to be 16px width ?

I have 2 simple ones, with 16px character, in 24px width.
Image
and
Image

Interested ?
Nice sprites!
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Beginner's Sprite Tutorial

Post by RMartins »

Here are Zoom versions of them.

Image

And
Image

I also have the SevenUp Editor .SEV files somewhere in my drive, I'll have a look and post them when found.
R-Tape wrote: Fri Dec 29, 2017 4:44 am ...
Or even better, could someone improve the animation of this blob? I like the idea of showing how a walking animation can be done simply.
I could try that, when I have a half an hour or so free. :)
redballoon wrote: Fri Dec 29, 2017 10:41 am ...
The 1st looks sound but the right leg in the 2nd one looks a bit weird at times. It could just be trying to view a small image in my phone, though.
There is something there yes, but I believe there isn't much that can be done about it, without looking funny, or having to change the whole sprite.

The issue you see is related with a bunch of pixels that are together on the left leg, when it's up in front.
It comes out as a brighter spot due to that, and that's what makes it feel a bit odd.

But if we remove those pixels, it seems the leg never crossed over, or the right leg might seem too bulky.

Maybe there are better solutions, but it's not easy at this size, in my opinion.
but feel free to change or update them, they can always be improved.

Thank you for all the positive comments, for my first walk animation studies, done quite a few months ago. ;)
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Beginner's Sprite Tutorial

Post by RMartins »

OK here are the SevenUp .SEV files.

WalkAnim-Study.sev

WalkAnim-Study3F.sev

You know the drill, after loading the files, just use cursor keys to animate the frames.

You can move the first anim sprites to be centered on a char boundary, since currently it's centered between 2 chars.

After taking a new look on the second anim, I'm sure it can be improved, by making the first stance after center position, to have a slighter larger gap between both legs.
You can also notice that both do not have arms yet.

Well, they were my first walk anims, what can I say, not perfect. :shock:

The one in my Avatar is a lot better, but also easier, with more pixels to shuffle :D
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Beginner's Sprite Tutorial

Post by Ast A. Moore »

Code: Select all

	ld b,(hl)	;get table address spritegraphic0, spritegraphic1 etc in BC
	ld l,c
	ld h,b
H (and L, incidentally) can be loaded directly from (HL):

Code: Select all

	ld h,(hl)
	ld l,c
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
Morkin
Bugaboo
Posts: 3250
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol, UK

Re: Beginner's Sprite Tutorial

Post by Morkin »

Nice thread this. Finally got round to having a decent look at this as I still haven't managed to write a decent pixel-based sprite routine.

In the Balachor games the sprite moved 4 pixels at a time, so I thought I may as well store X & Y co-ordinates as character co-ordinates 0-31, or 0-22. I did that mainly because I had previously been used to PRINT AT in BASIC.

I did a bit of experimentation with smoother movement, so it made sense for the Y-coordinate (vertical) to be a pixel co-ordinate of 0-192. But I still had the X-coordinate (horizontal) as 0-31, as I figured this was the only precision needed for horizontal screen addresses.

I didn't even consider storing the X co-ordinate as 0-255, and getting both the screen address and the sprite animation frame from that. I guess that's a more standard (and probably more sensible!) approach. I had the sprite animation frame as a separate variable.
My Speccy site: thirdharmoniser.com
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Beginner's Sprite Tutorial

Post by Ast A. Moore »

Morkin wrote: Fri Dec 29, 2017 2:59 pm it made sense for the Y-coordinate (vertical) to be a pixel co-ordinate of 0-192. But I still had the X-coordinate (horizontal) as 0-31, as I figured this was the only precision needed for horizontal screen addresses.

I didn't even consider storing the X co-ordinate as 0-255, and getting both the screen address and the sprite animation frame from that. I guess that's a more standard (and probably more sensible!) approach.
Even that isn’t enough when you’re dealing with fractional coordinates and sprites moving smoothly beyond the edges of the screen. Some clever trickery is required for that.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Beginner's Sprite Tutorial

Post by RMartins »

Ok, I tried a couple of revisions ...

First I tried to add 2 steps instead of one, in 8 frames, which is doable, but since in this case we only want to advance 8 pixels, steps need to be small, which implies feet need to be small.

Image

But I did not like the outcome ... looks like "Miss Bob" in high heels :D

Hence I reverted back to a single step, which gave me a lot more control.
Image

Now I like this, but there is a catch.
If you repeat this, you will see that the back leg seems to drag, this is normal, because it's the animation of a single step, to a stop, so back leg has to slow down ... to a stop.

For 2 steps, we need the last 4 frames, to move the back leg a lot faster, since it's swinging to take the lead.
This is required, to make it look natural, i.e. we need to swap the last few frames to stop, or to keep walking.

I don't have more time now, to make the full walk version, 4 more frames.
The body movement, will be identical or similar, but the back leg, needs to speed up, and end half bent, to continue.

I hope it helps.

UPDATE:
Here is a longer repeating version, where it looks like he is limping, as I mentioned before.
Image
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Beginner's Sprite Tutorial

Post by Seven.FFF »

I've now got as far as preshifting in my tutorial series, in a bit of a scattershod way.

Happy new year!
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
Wall_Axe
Manic Miner
Posts: 492
Joined: Mon Nov 13, 2017 11:13 pm

Re: Beginner's Sprite Tutorial

Post by Wall_Axe »

you seem to have gotten the multicolor sprite moving smoothly right to left as well as up and down
MrPixel
Microbot
Posts: 170
Joined: Sat Mar 24, 2018 7:42 pm

Re: Beginner's Sprite Tutorial

Post by MrPixel »

is this BASIC or Machine code. if it's the latter, would ZEUS be good?
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Beginner's Sprite Tutorial

Post by R-Tape »

MrPixel wrote: Sat Mar 24, 2018 10:29 pm is this BASIC or Machine code. if it's the latter, would ZEUS be good?
Which bit? The sprite code I posted on page 3 is assembly language that the ZX-Spin 0.666 assembler translates into machine code. There are no nobs & whistles so I think any assembler including ZEUS should be fine with it :-)
MrPixel
Microbot
Posts: 170
Joined: Sat Mar 24, 2018 7:42 pm

Re: Beginner's Sprite Tutorial

Post by MrPixel »

i get errors whenever i attempt to call a sprite.
Callsprite drawsprite and deletesprite all get errors

even with the call command
Post Reply