How to move a sprite while updating greyscale???

[Link]

So, I understand grey-scale, and physics and so on, So I decided to make some sort of simple game. Except I don't get how to make a sprite move around using getkey or whatever, and still not pause the actual gray-scale updating? Can someone tell me how, to say make a small gray-scale box move around the screen? Just need an idea for the loop structure, that's all.

[Yeong]

simple.

Repeat getKey(15) //make sure the program quits when you press {Clear}
ClrDrawrr
your greyscale sprite goes here
DispGraphrr
your sprite movement control goes here
End

I know that it's not optimized, but it'll do.

[Link]

simple.

Repeat getKey(15) //make sure the program quits when you press {Clear}
ClrDrawrr
your greyscale sprite goes here
DispGraphrr
your sprite movement control goes here
End

I know that it's not optimized, but it'll do.

Okay, thanks, and one more question, why is most sprite movement multiplied by 256? it it for some specific reason?

[Yeong]

I'm not sure but I think they were usually related to gravity or something.

[parserp]

Yes, *256 inflation is used for physics, which allows the player to move at 1/256 of a pixel at a time.

[Link]

Yes, *256 inflation is used for physics, which allows the player to move at 1/256 of a pixel at a time.

How does that work, say you have to move 2, then *256, it becomes 512, doesn't that go over the limit of 96 px?

[parserp]

No, when you display it, you do /256, which means that you have to add 512 to the value in order to move 2 pixels. It's kind of hard to explain it in a condensed form, I'd try looking at some of the many physics tutorials.

[Link]

No, when you display it, you do /256, which means that you have to add 512 to the value in order to move 2 pixels. It's kind of hard to explain it in a condensed form, I'd try looking at some of the many physics tutorials.

K, and this is used in pretty much all physics right?

[leafy]

No, when you display it, you do /256, which means that you have to add 512 to the value in order to move 2 pixels. It's kind of hard to explain it in a condensed form, I'd try looking at some of the many physics tutorials.

K, and this is used in pretty much all physics right?

It's certainly the most optimized number for position inflation. In fact, since Axe is big-endian, instead of doing VAR/256, you can do {°VAR+1}. This method also has a lot of uses outside of physics, too.

[calc84maniac]

No, when you display it, you do /256, which means that you have to add 512 to the value in order to move 2 pixels. It's kind of hard to explain it in a condensed form, I'd try looking at some of the many physics tutorials.

K, and this is used in pretty much all physics right?

It's certainly the most optimized number for position inflation. In fact, since Axe is big-endian, instead of doing VAR/256, you can do {°VAR+1}. This method also has a lot of uses outside of physics, too.

It's actually little-endian, but yes, that is the correct method.

[leafy]

Wait, if you use +1 to access the high byte, why isn't it big endian? I've been deceived

[calc84maniac]

Big endian means that the highest byte comes first. Little endian means the lowest byte comes first.

[leafy]

Ugh, I got big endian and little endian mixed up Big endian sounds like the big byte should be at the end, that's my justification.

* leafy runs

[Link]

Hmm, well I tried this according to what yeong said: but it isn't working? Whats wrong >.>

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

:.A :AsmComp(SPEEDKEY) :[7E81BD817E18183C]→Pic1 :[7EFFC3FF7E18183C]→Pic2 :ClrDraw{^r}{^r} :0→X→Y :While 1 :Zoom Out→A :Pt-Off(X/256,Y/256,Pic1) :Pt-Off(X/256,Y/256,Pic2){^r} :DispGraphClrDraw{^r}{^r} :If A=1 :Y-- :End :If A=2 :X-- :End :If A=3 :X++ :End :If A=4 :Y++ :End :EndIf getKey(15)

[leafy]

Hmm, well I tried this according to what yeong said: but it isn't working? Whats wrong >.>

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

:.A :AsmComp(SPEEDKEY) :[7E81BD817E18183C]→Pic1 :[7EFFC3FF7E18183C]→Pic2 :ClrDraw{^r}{^r} :0→X→Y :While 1 :Zoom Out→A :Pt-Off(X/256,Y/256,Pic1) :Pt-Off(X/256,Y/256,Pic2){^r} :DispGraphClrDraw{^r}{^r} :If A=1 :Y-- :End :If A=2 :X-- :End :If A=3 :X++ :End :If A=4 :Y++ :End :EndIf getKey(15)

I'm assuming that when you press the enter keys, the sprite doesn't appear to move. That's totally normal, because you're only subtracting or adding one to each variable, and it takes 256 such adds or subtracts to move one pixel. To mitigate this, you might try Y-25->Y instead of Y-- and see if that makes a difference.