Frame Position Velocity Acceleration
0 0 -3 1
1 -3 -2 1
2 -5 -1 1
3 -6 0 1
4 -6 1 1
5 -5 2 1
6 -3 3 1
7 0 4 1
8 4 5 1
9 9 6 1
10 15 7 10->X
-3->V
1->A
While 1
Output(1,1,X)
X+V->X
V+A->V
EndZStandard
ZInteger
AxesOff
Clrdraw
0->X
0->Z
0->A
0->B
While 1
PtOff(X,Z,2
X+A->X
Z+B->Z
PtOn(X,Z,2
getKey->K
A+(K=26)-(K=24)->A
B+(K=25)-(K=34)->B
EndI sometimes have a hard time taking real life concepts and converting them to code effectively.Yeah that can be a very hard challenge. Especially when talking about really complicated things like rebound angles and the like D:
This is interesting. It might be more suitable in animations or very simple games, though, since extreme gravity calculations can take a while in TI-BASIC. Otherwise, maybe Axe Parser. Maybe it could also help other kind of programmers too. Maybe it could help for a Sonic game too :P (since the one on UTI seems to never be going anywhere...)Yeah, one thing thats hard about implementing physics well is that it often times takes a lot of processing time.
What would you even use though for your gravity acceleration? I mean gravity in real life is 9.81... m/s2 (and 32... ft/s2 but I don't think that would work very well on the graph/home screen. But I don't know.Well in Portal i believe i used 1/64 pxl per frame per frame, but it depends heavily on your frame-rate. The best way to find a good acceleration is just to run some tests. As a general rule you don't want your player moving too fast because that makes collision very difficult.
Well in Portal i believe i used 1/64 pxl per frame per frame, but it depends heavily on your frame-rate. The best way to find a good acceleration is just to run some tests. As a general rule you don't want your player moving too fast because that makes collision very difficult.
As a general rule you don't want your player moving too fast because that makes collision very difficult.True, else stuff like this (http://www.youtube.com/watch?v=tx061196cvI) happens :P
|\
| \
a | \ C (hypotenuse)
(leg) | \
| \
+-----
b (leg) B
/|
/ | The distance from A to B is the hypotenuse of a right triangle, with X and Y
/ | as the legs.
/ | Y
/ | Distance^2 = X^2 + Y^2 Take the square root, and we have:
/ |
A------+ Distance = SQRT(X^2 + Y^2)
X
|
| \ /
| \ /
| \ /
| 90 degrees \ 135 degrees / 45 degrees
| \ /
+--------- -------- ---------ZStandard
ZInteger
AxesOff
ClrDraw
For(F,0,360,5
Pt-On(29cos(F),29sin(F
End |\ Sin of an angle equals the opposite leg over the hypotenuse
| \ Sin(BC) = A/C Sin(AC) = B/C
a | \ C (hypotenuse) Cos of an angle equals the adjecent leg over the hypotenuse
(leg) | \ Cos(BC) = B/C Sin(AC) = A/C
| \ Tan of an angle equals the opposite over the adjecent
+----- Tan(BC) = A/B Tan(AC) = B/A
b (leg) B
/|
/ |
/ |
/ | Y
/ |
/ |
A------+
XZStandard
ZInteger
AxesOff
ClrDraw
Degree
0->F
Circle(0,0,30
While 1
Line(0,0,A,B,0 //hypotenuse
Line(0,0,A,0,0 //right leg
Line(A,0,A,B,0 //left leg
29Cos(F)->A //find the coordinates of the next point on the circle
29Sin(F)->B
Line(0,0,A,B
Line(0,0,A,0
Line(A,0,A,B
F+5->F
End
Well I'm glad to hear work is going great then :)Me too. I really like all of your projects, and I can't wait for more progress on them all. ;D
Rule # Condition Action
1 Space below empty Move down
2 Spaces to the sides empty Move either left or right
3 Single empty space to a side Move into that empty spaceRule # Condition Action
1 Space below empty Move down
2 Space to the bottom-right/left empty Move to that empty spaceRule # Condition Action
1 Space above is empty Move up
2 Space above is filled Move left/right
3 rand<.05 End life of this pixelRule # Condition Action
1 Space below is not Acid Move down
2 Spaces to the sides is not acid Move either left or right
3 Single non-Acid space to a side Move into that empty spaceFor(F,0,N For N+1 Pixels
D*2+L1->L Find their location in L1
{L}->X X location in first Byte
{L+1}->Y Y location in second bytes
Pxl-Off(X,Y
If Pxl-Test(X,Y+1) If ground below is solid
Rand^2*2-1->A Choose a random direction
!If Pxl-Test(X+A,Y If that direction is empty
X+A->X Move there
Else!If Pxl-Test(X-A,Y Else, if the opposite direction is empty
X-A->X Move there instead
End
Else
Y+1->Y If all else fails and ground below is empty, move down
End
Pxl-On(X,Y
X->{L}
Y->{L+1}
End
Note that this code won’t work by itself; you still need a way to put the pixels into L1, and to remove them. You will also need to create the environment and everything, but this I leave up to you.Lbl TST
{r2/8*W + (r1/8)+L1}
ReturnLbl TST
{r2/8*W + (r1/8)+L1}<N
Return-------O
------OO
-----O-O
----O--O
---OOOOO
--O----O
-O-----O
OOOOOOOO-------O
------OO
-----OOO
----OOOO
---OOOOO
--OOOOOO
-OOOOOOO
OOOOOOOOLbl MSK
{{r2/8*W+(r1/8)+L1}*8+(r2^8)+Str1}e r1
ReturnGood idea, I think i'll move it. Some of the ideas are applicable, but its really only for Axe and Asm. Do you think I should sticky it?Definitely sticky it.
O.o great explanation!! The screenie is amazing too. I'll be sure to remember this whenever I want to do something physics based XDMaybe I'll try and make a powdertoy....sorry qwerty :Pnah I don't know the chem behind the he interactions of substances... Meh idk
loop
{
[refresh position]
[position+velocity]
}
{N*4+GDB0+A}N is actual player, and A is byte we want modify (1st, 2nd, 3rd or 4th).:Lbl G
:For(Θ,0,M)
:For(r3,0,{Θ*4+GDB0→r5+3}
:If sub(GN,5+{r5},4+{r5+1}+1)=0
{r5+1}+1→{r5+1}
:End
:End
:If sub(GN,5+{r5},4+{r5+1}+1)=0
:{r5+3}+A→{r5+3}
:Else
:0→{r5+3}
:End
:End
:ReturnSubroutine GN extract byte from tilemap ::Lbl GN
:r2*102+r1→r1
:{r1/2+D}→r2
:If r1^2
:r2^16
:Else
:r2/16
:End
:ReturnGN is not the problem, it return the good tile (D point appvars Data).
My problem is hard to explain (at least with my bad english), I want use your phisic in a multi-player game. How can I affect every players in same time I'm moving in a tilemap ?
:Lbl G
:For(?,0,M)
:If sub(GN,5+{?*3+GDB0},5+{?*3+GDB0+1})=0 and (getKey(4)=0
:{?*3+GDB0+1}+1?{?*3+GDB0+1}
:End
:End
:ReturnYour phisic system could be usefull to do some jump like here ::Lbl G
:Θ*3+GDB0->r5
:If {r5+3}>>-7
:{r5+3}+1->{r5+3}
:End
:
:{r5+1}+{r5+3}->{r5+1}
:While sub(GN,{r5}+5,{r5+1}+5
:If {r5+3}>>0
:{r5+1}-1->{r5+1}
:Else
:{r5+1}+1->{r5+1}
:End
:End
:
:If sub(GN,{r5}+5,{r5+1}+5)=0 && getKey(4)
:-7->{r5+3}
:End
:ReturnWell first off, if you want realistic pysics, you might want to consider switching to x256 format. This is where every time you add 256 to your position variables, your character moves 1 pixel. This will allow you to have more precision and possibly get the gravity effects you are looking for.Your code don't work, no gravity affect my worms, and I don't understand what does it mean. :/
However, If you do not want to use x256 format and stick with what you have, you can try this simple physics piece of code:Code: [Select]:Lbl G
:Θ*3+GDB0->r5
:If {r5+3}>>-7
:{r5+3}+1->{r5+3}
:End
:
:{r5+1}+{r5+3}->{r5+1}
:While sub(GN,{r5}+5,{r5+1}+5
:If {r5+3}>>0
:{r5+1}-1->{r5+1}
:Else
:{r5+1}+1->{r5+1}
:End
:End
:
:If sub(GN,{r5}+5,{r5+1}+5)=0 && getKey(4)
:-7->{r5+3}
:End
:Return
This piece of code *should* give you some realistic gravity and jumping in your game
Pt-Change(X/256,Y/256,Pic0)
Well first off, if you want realistic pysics, you might want to consider switching to x256 format. This is where every time you add 256 to your position variables, your character moves 1 pixel. This will allow you to have more precision and possibly get the gravity effects you are looking for.Your code don't work, no gravity affect my worms, and I don't understand what does it mean. :/
However, If you do not want to use x256 format and stick with what you have, you can try this simple physics piece of code:Code: [Select]:Lbl G
:Θ*3+GDB0->r5
:If {r5+3}>>-7
:{r5+3}+1->{r5+3}
:End
:
:{r5+1}+{r5+3}->{r5+1}
:While sub(GN,{r5}+5,{r5+1}+5
:If {r5+3}>>0
:{r5+1}-1->{r5+1}
:Else
:{r5+1}+1->{r5+1}
:End
:End
:
:If sub(GN,{r5}+5,{r5+1}+5)=0 && getKey(4)
:-7->{r5+3}
:End
:Return
This piece of code *should* give you some realistic gravity and jumping in your game
It's basically where your X and Y values are inflated (multiplied) by 256 for greater accuracy. In other words, when you actually display it, you'd useCode: (Axe) [Select]Pt-Change(X/256,Y/256,Pic0)
To move one pixel, then, you'd add 256 to either X or Y.
The point here is to simulate "half-pixels" and other fractions for the motion to seem smoother. For example, you could have the character move 1.5 pixels every frame by adding 384 to X instead of 256.
Sqrt((X-I)^2+(Y-J)^2)=D(X-I)^2+(Y-J)^2=D^2abs(X-I)->r1*^r1+(abs(Y-J)->r1*^r1)->DIf K<<0K**N+A->A
K**O+B->BK**N*3//2+A->A
K**O*3//2+B->BIf abs(X-I)->r1*^r1+(abs(Y-J)->r1*^r1)<M
I-X//L->N
J-Y//L->O
A**N+(B**O)*-1->K
If K<<0
K**N*3//2+A->A
K**O*3//2+B->B
End
EndCode:
Lbl MSK
{r2^8+{r2/8*W+(r1/8)+L1}+Str1}e r1
Return
Where r1 is your X position, r2 is your Y position, W is the width of your tilemap (in tiles), L1 is the location of your matrix data buffer, and Str1 is the start of your Mask Sprite table.
How do you use tile masking with 5 by 5 tiles rather than 8 by 8 tiles?
Where r1 is your X position, r2 is your Y position, W is the width of your tilemap (in tiles), L1 is the location of your matrix data buffer, and Str1 is the start of your Mask Sprite table.Just change W, afaict ;)
{{r2/8*W+ // get tile row, multiply by width
(r1/8)+ //get tile column
L1}*8+ // now we have the value of the tile you are in, then multiply by 8 because 8 bytes per sprite
(r2^8)+ //get pixel row # with respect to the tile you are in
Str1} //we add this to the pointer to the mask table, thus returning the exact byte of the sprite mask
e r1 // and now we check if the appropriate pixel is lit or not in the given row
Return
Where r1 is your X position, r2 is your Y position, W is the width of your tilemap (in tiles), L1 is the location of your matrix data buffer, and Str1 is the start of your Mask Sprite table.
Wait, Builderboy might've messed something up...let me give my (i think) fixed code with explanationSo, do I need a masked sprite for everything or just the one tile? I'm guessing a tile value (from L1) of 0 is the first sprite, 1, second sprite, etc?Code: [Select]{{r2/8*W+ // get tile row, multiply by width
(r1/8)+ //get tile column
L1}*8+ // now we have the value of the tile you are in, then multiply by 8 because 8 bytes per sprite
(r2^8)+ //get pixel row # with respect to the tile you are in
Str1} //we add this to the pointer to the mask table, thus returning the exact byte of the sprite mask
e r1 // and now we check if the appropriate pixel is lit or not in the given row
Return
Where r1 is your X position, r2 is your Y position, W is the width of your tilemap (in tiles), L1 is the location of your matrix data buffer, and Str1 is the start of your Mask Sprite table.