:.TENNIS
:#Icon(0000000000000000000000000000000003C00FF01FF83F9C7F9E7FFEFFFFFFFF)
:[030F1F3F7F7FFFFF]→Pic1
:[C0F0F89C9EFEFFFF]
:[030C1026464080FF]→Pic2
:[C0300804020201FF]
:0→X
:56→Y
:88→Z
:56→W
:0.1→G
:0→V
:Repeat getKey(15)
:ClrDraw
:G+V→V
:Pt-On(X,Y,Pic1
:Pt-On(X+8,Y,8+Pic1
:If Y≥56
:56→Y
:0→V
:End
:Y+V→Y
:If getKey(2) and (X>0)
:X-1→X
:End
:If getKey(3) and (X<80)
:X+1→X
:End
:If getKey(54) and (Y=56)
:-4→V
:Y+V→Y
:End
:DispGraph
:End
There was this game I used to play on the internet, and I don't remember what website it was on or what it was called. The gave was between two semi-circles with eyes. They hit a ball back and forth until one of them dropped it. If someone knows this game, I would appreciate if you'd tell me what it's called.
There was this game I used to play on the internet, and I don't remember what website it was on or what it was called. The gave was between two semi-circles with eyes. They hit a ball back and forth until one of them dropped it. If someone knows this game, I would appreciate if you'd tell me what it's called.
The game is called Slime tennis. Good luck with the game!
I can't help you with the bounce, but to make the jump slower (and with this method, it'll be more realistic too), you'll have to modify your code a bit :Thanks!
- Just use one variable that you will always add to Y for the gravity. Let's say that you use G.
- Add G to Y before testing if Y is outbounds. It'll prevent your sprite to go off the screen for a frame (which can be a bit strange for the eye).
- As an acceleration due to gravity, G is always increasing (making Y go up, and then your sprite fall). Each loop, just increase G, preferably after adding it to Y and before testing the bounds. If your sprite is on the floor, make G zero, so this way G will always be set to zero when you touch the ground, preventing your sprite to go off the screen.
- When you jump, make G (for example) -3. Then the next frame, Y will be Y+(-3) = Y - 3, making the sprite jump 3 pixels up. The next frame, G will be increased to -2. Then Y will be Y - 2 and the sprite will go up 2 pixels again. This will continue until G is greater than zero and make your sprite fall again to the ground, and until G is reset to zero after the sprite touches the ground. You'll probably have to test some values to set G to for the jump before getting the right one.
If you have any problem with it, please ask :)
This game has already been ported to the z80 series (http://www.ticalc.org/archives/files/fileinfo/290/29096.html) ;)
However, I'd be glad to see another version of it with more features and more graphics (the one I linked to doesn't have what we can call a menu) :D
Yep, pretty similar. Also glad you added smooth jumping Hayleia :PWell I just made it more obvious by adding inflation by 256 but I didn't add it, it is SpenceBoy's work ;)
What's inflation? ???I don't know what that word means (:P) but "inflation by Z" is somehow a programming technic. Basically, when your coordinate increases by one, you don't move of a pixel. You only move by a pixel when your coordinate increased by Z. And 256 is a good number because dividing by 256 is really optimized for Axe :)
Ah I see. I assume it's mostly for jumping precision?Yes, exactly this (I know, my explanations are always confusing, you should not have asked me but someone else :P)
Inflation means to expand or make larger. :)What's inflation? ???I don't know what that word means (:P) but "inflation by Z" is somehow a programming technic. Basically, when your coordinate increases by one, you don't move of a pixel. You only move by a pixel when your coordinate increased by Z. And 256 is a good number because dividing by 256 is really optimized for Axe :)
Ok, thanks. Yeah that makes sense with the fact all numbers are multiplied by 256 :)Inflation means to expand or make larger. :)What's inflation? ???I don't know what that word means (:P) but "inflation by Z" is somehow a programming technic. Basically, when your coordinate increases by one, you don't move of a pixel. You only move by a pixel when your coordinate increased by Z. And 256 is a good number because dividing by 256 is really optimized for Axe :)