let say I have my hero at (50,50)-(60,70) is the second screen of screen 5
is this a good way to make my hero move, or, is there a way which goes faster and uses less memory?:

100 copy(50,50)-(60,70),1 to (x,y),0
110 d=stick(0)
120 if d=1 then y=y-1
130 if d=2 then y=y-1:x=x+1
..
..
.
.
190 if d=8 then y=y-1:x=x-1
200 goto 100

thanx for all your advice about memory problems in basic and software sprite.
You all been a great help so far !!

Msx lives on!

Just try this and see what happens.

This will work, but has a couple of draw-backs tho. The most important one being that your sprite will probably leave a trail. If it doesn't leave a trail, it will at least corrupt any background you may have. Try something like this instead:

10 SCREEN 5
20 SET PAGE 0,1:BLOAD "BACKGRND.SC5",S: COLOR=RESTORE
30 SET PAGE 1,0:COPY (0,0)-(255,211),1 TO (0,0),0
40 SET PAGE 0,2:COPY (0,0)-(255,211),1 TO (0,0),2
50 SET PAGE 0,3:BLOAD "GRAPHICS.SC5",S: PX=128: PY=104: GOTO 190

100 D=STICK(0): IF D=0 THEN GOTO 100
110 IF D=1 THEN PY=PY-2
120 IF D=2 THEN PY=PY-2: PX=PX+2
...
...
180 IF D=8 THEN PY=PY-2: PX=PX-2
190 BP=AP XOR 1
200 COPY (0,0)-(15,15),3 TO (PX,PY),BP,TPSET: ' TPSET doesn't copy COLOR0
210 SET PAGE BP,AP
220 COPY (OX,OY)-(OX+15,OY+15),2 TO (OX,OY),AP: ' Clear old sprite
230 OX=PX: OY=PY: AP=AP XOR 1: GOTO 100

Just a small example. It's not particularly well-programmed, but it should work. Didn't test it tho Anyhoo, this little example has a background picture which is copied to the first 3 pages. This can be done more efficiently, but should be enough to show the idea. The last page, page 3, has your sprite data. This example assumes you have a 16x16 pixel sprite on position 0,0 of page 3. It uses a TPSET copy, so any pixels that have color 0 in this sprite will not be copied. It uses two variables, AP (active page) and BP (back page). Active page is the visible page (0 at first) and back page is the page we are drawing on. It will COPY the sprite from page 3 to the PlayerX and PlayerY coordinate of the back page. Then the back page is made visible and a square of 16x16 pixels from coordinates OX and OY (old X, old Y) is copied to what used to be the active page, thus erasing the sprite on the previous coordinates. Last, the current coordinates PX and PY are stored in the OX and OY variables. Finally the ActivePage variable is updated and the whole thing loops again. It could be that I made a mistake somewhere, but this is generally an easy way to use software sprites. With some small tricks tho, you don't need to store the whole original background but can just 'backup' the parts you are going to copy a sprite to right before you actually do it. This way you can save yourself almost an entine page and allow for more graphics, I'm sure you can figure that out youself tho... Notice however, I'm moving the player sprite per 2 pixels instead of per pixel. I do this, since the VDP can do byte copies faster than logical copies. This means that restoring the background can be done almost 3 times as fast if you move per 2 pixels than if you move per pixel. Unfortunately MSX-BASIC doesn't take advantage of this, but many 'super' BASICs like NestorBASIC do use this trick. You should see a significant improvement there if you have various sprites. But anyways, take a look at it, it shouldn't be too hard to modify this idea into a smoother little 'sprite engine'. Good luck

Toby

I noticed btw, that I didn't limit the coordinates of the sprites. Be sure to add the usual IF X<0 THEN X=0 crap...

If you move your hero over a (parallax) background, this thing won't work. In that case, you should utilise double buffering, like this:

100 copy (x,y)-(x+10,y+20),0 to (0,0),2 ' Buffer space for your hero, it will be copied over this place
110 copy (50,50)-(60,70),1 to (x,y),0
120 d=stick(0)
...
...
...
200 if d=8 then y=y-1:x=x-1
210 copy (0,0)-(10,20),2 to (x,y),0 'Repair parallax screen
220 goto 100 'Save the next image and put the hero over it again

I hope you're helped with this Good luck!

Ehw, t00bs just beat me to it

Quote:

AP=AP XOR 1

AP=1-AP does the trick faster

Quote:

Quote: AP=AP XOR 1 AP=1-AP does the trick faster

I'm an assembly programmer; shoot me... I doubt it's much faster tho...

A little speedup on the direction determination:

10 DIM DX[8],DY[8]
20 DX[0]=0:DX[1]=0:DX[2]=1:DX[3]=1:DX[4]=1:DX[5]=0:DX[6]=-1:DX[7]=-1:DX[8]=-1
30 DY[0]=0:DY[1]=-1:DY[2]=-1:DY[3]=0:DY[4]=1:DY[5]=1:DY[6]=1:DY[7]=0:DY[8]=-1
: <other initialization>
100 D=STICK(0)
110 X=X+DX[D]: Y=Y+DY[D]
: <do boundary tests, copy stuff etc>
200 GOTO 100

And what about

5 DEFINT A-Z

It might help!

A bit more space saving version:

10 DEFINTA-Z:DIMDX(8),DY(8)
20 FORI=1TO8:DX(I)=SGN(I-5)*(I>1):DY(I)=-SGN((IAND7)-3)*(I<>7):NEXTI
30 D=STICK(0):X=X+DX(D):Y=Y+DY(D)

Freak!

Heh, I was too lazy to try and get the right formula.
/me wonders which of the two versions is faster (after including DEFINT A-Z in mine)

ps: what exactly does definta-z do?

Defines that variables A - Z are intergers. This speeds up the whole thing a litte... From what I read in the other thread prefixing vars with % seems to be faster tho...