Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Tgooseman on April 23, 2011, 03:49:30 pm
-
So I am making a helicopter-like game using Axe, and since it is my first game I some help! I am currently stuck making it scroll sideways. Would this involve using two buffers? Maybe like drawing the bricks there and shifting pixels left? This would be my guess (although I could be way wrong :D )!
For those of you that don't know what the helicopter game is, it is the game where you move your helicopter to avoid the incoming bricks.
-
You mean a tunnel game ?
This is simple actually, you just have to scroll the screen to the left ( using Horizontal - ) and make bricks appear at a random Y position on the right of the screen.
-
You mean a tunnel game ?
This is simple actually, you just have to scroll the screen to the left ( using Horizontal - ) and make bricks appear at a random Y position on the right of the screen.
No, he really means a helicopter game, in a copter game there's gravity you have to keep press UP to go UP or gravity will kill you. But the engine is pretty much the same.
-
I used two variables for my game nFighter (in Lua) offsetX and offsetY if the user used the up arrow, the code would be
offsetY = offsetY - whateverthepixeloffsethere then that value is added onto the background image making it look like the helicopter goes up.
The game your talking about is pretty fun, if diffucult. I look forward to seeing what you come up with!
Cheers
Ingalls
-
Alright, thanks for the suggestions. The reason I thought I would need two buffers is because when I update the screen for my Helicopter sprite, I use ClrDraw, which would end up wiping out the brick moving across the screen. Any ideas to counter this?
-
Pt-Change(X,Y,[yoursprite]) will erase the sprite ( if it is at the same position )
-
If you don't min the background of the game moving up and down the position of the helicopter never has to change, you want the helecopter to be in the center of the Y plane and in the first quarter of the X plane based on the versions of the game that I have see. So on a 10x10 grid you would want to draw the helicopter at (x,y) (2.5,5) The helicopter would then be redrawn at that set of coordinates every time.
For the background you would draw out the level and then have an Yoffset value that can be added on, is drawRect(1,1+offsetY)
That way if the user goes up then a negative y value will be added on, making the background go down, and giving the illusion that the helicopter went up. The opposite would be true for the user pressing the down key.
If you want to see the method I have just described in action and you are comfortable looking at the code of a porgramming language that you don't necessarily know, have a look at my nFighter code. All of the background objects have both X and Y offset values so the crosshairs appear to move when in face only the background does.
Cheers
Ingalls
-
The idea Fast Crash suggested above would be even better. It would allow you to keep the map stationary and only move the helecopter... That's basically my suggestion except in reverse, move the object instead of the background
. I haven't programmed in Axe before so I'm not sure of the power of the language...
-
Axe can easily handle both, although using Pt-Change would be much more easier to implement (and would probably run faster, at the cost of not being able to move around much).
-
I have a problem with making a tunnel game/helicoter game too...
...
Repeat getKey(15)
...
Horizontal -
DispGraph
ClrDraw
The screen doesn't really go left...
-
You erase it with ClrDraw, this is probably the problem :D
-
You erase it with ClrDraw, this is probably the problem :D
But I also have the player which goes up and down and I need to ClrDraw so that his previous positions disappear.
-
All you need to add to the code is a timer statement. That way you can establish fps
-
Here is what i would do :
Repeat getkey(15)
... <Tests for players's position>
... <Tunnel/Blocks' display>
Pt-On(X,Y,[sprite])
Dispgraph
Pt-Change(X,Y,[sprite])
Horizontal -
End
-
Fast crash's code is a lot easier to implement than what I was suggesting... The only problem with it is that the backgound is going to need to be moving as well so your probably going to want to add the timer statement that I was talking about.
-
@Fast_Crash: Thanks much. I'll try that.
-
Add the Pixels-Test after the "Dispgraph" too ( if the player hits a wall )
-
.HELI
DiagnosticOff
29->Y
Repeat getkey(15)
If getKey(1)
Y-2->Y
End
Y-1->Y
.I always decrease Y by 1 because a helicopter has to fall
Pt-On(X,Y,[sprite])
Dispgraph
Pt-Change(X,Y,[80C0E0F0E0C08000
.LOSING CODE
If pxl-Test(X,Y+7)
Return
End
If pxl-Test(X,Y-1)
Return
End
.END OF LOSING CODE
Horizontal -
End
I guess all I have left is displaying the tunnel.
-
More optimized :
...
.LOSING CODE
If Pxl-Test(X,Y+7)+Pxl-Test(X,Y-1)
Return
End
.END OF LOSING CODE
...
-
More optimized :
...
.LOSING CODE
If Pxl-Test(X,Y+7)+Pxl-Test(X,Y-1)
Return
End
.END OF LOSING CODE
...
Good idea.
-
More optimized :
...
.LOSING CODE
If Pxl-Test(X,Y+7)+Pxl-Test(X,Y-1)
Return
End
.END OF LOSING CODE
...
is + smaller than OR? I never even thought about that comparison...If so, then I may have some optimizing to do (I needed a LOT of conditions)
-
More optimized :
...
.LOSING CODE
If Pxl-Test(X,Y+7)+Pxl-Test(X,Y-1)
Return
End
.END OF LOSING CODE
...
is + smaller than OR? I never even thought about that comparison...If so, then I may have some optimizing to do (I needed a LOT of conditions)
+ doesn't mean or remember.
However, here's my study:
Size of program with +: 723bytes
Size of program with or: 725 bytes
Size of program with two if blocks: 726 byes
-
More optimized :
...
.LOSING CODE
If Pxl-Test(X,Y+7)+Pxl-Test(X,Y-1)
Return
End
.END OF LOSING CODE
...
is + smaller than OR? I never even thought about that comparison...If so, then I may have some optimizing to do (I needed a LOT of conditions)
+ doesn't mean or remember.
However, here's my study:
Size of program with +: 723bytes
Size of program with or: 725 bytes
Size of program with two if blocks: 726 byes
I am aware that + doesn't mean or, but it works just fine for the purposes I have. I had always just assumed or was smaller. It's good to know that there are more optimizations to be done :D
-
So now that track is finally done I could actually work on my first game some more. I even made a screen shot .gif thing. It is pretty crappy but you get the basic idea. I plan on adding difficulties (higher brick frequency, faster) and making it look a lot better.
-
The image provided by that emulator is not very good, perhaps you could use Wabbitemu (Windows and Mac only though).
Either way, nice to see you managed to make it.
-
I tried using calc capture but with a wabbitemu configuration. Maybe I just didn't do it right?
-
You don't need to use calccapture because WabbitEmu can take recordings itself :D
It's configurable in the options, and you can start it by right-clicking on the screen and choosing the appropriate option or by pressing the backspace key (hopefully).
-
Well that is great to know for future use. Thanks!
-
Always willing to help :)
Also, by the screenshot it seems to work rather well, so congrats on your game! ;D
-
Looks nice. I like how this one has blocks instead of just a tunnel. It makes it different from all other helicopter games. Congrats on your first game. :)
-
Looks nice. I like how this one has blocks instead of just a tunnel. It makes it different from all other helicopter games. Congrats on your first game. :)
Well mine has blocks too :P
Either way, as calcdude said Wabbitemu records GIFs itself :)