Blipa "Ball bouncing game"

[petree08]

the point of this game is to bounce balls off your carachter into blips

was inspired by peggle ,well only the balls bouncing off of balls part, the rest is kinda like brick breaker

this is just a test run or beta (not finished) so there are glitches , some levels don't work

tell me what you think , anything i could improve on would be aprechiated

controls are in the readme

oh yeah and p pauses the game

[corriep]

Don't forget your friends with slower rigs, optimize.

I get 1 fps with this.

[petree08]

yeah i was actually just doing that now,

getting rid of the particle effect off the ball seems to speed things up but it is a very slow running game fer some reason apart from that ,

[DemonWasp]

In Angle_Calc, you have a line that does:

Turing:

Angle := arctand ((sqrt ((Y1 - Y2) ** 2)) / (sqrt ((X1 - X2) ** 2)))

Which is probably better done (and way faster) as either of:

Turing:

Angle := arctand ( abs ( Y1 - Y2 ) / abs ( X1 - X2 ) ) Angle := arctand ( abs ( ( Y1-Y2 ) / (X1-X2) ) )

Since all that the sqrt ( something ** 2 ) does is find the absolute value of "something".


There are also several locations where you call Angle_Calc several times with identical arguments; since the method has no side effects, you should probably just have a local variable that you use to store the value of the first call to Angle_Calc; you can then use that variable multiple times without re-running Angle_Calc each time.

[petree08]

Yeah, I swapped too what you suggested, it is effiecent yes but it didn't speed it up at all, so i figured there is either a problem with my Frame_Rate sub or i am just trying to draw too much on the screen at the same time,

[DemonWasp]

Err, yeah, probably. You call Frame_Rate ( TimeSinceLast, FRAME_RATE ). FRAME_RATE is always 3 and TimeSinceLast is initialized to 0 and changed by Frame_Rate.

Based on the logic in that method, the delay should only ever run if the run took less than 3ms (unlikely, that's about 333 frames per second). It's also wildly unlikely because Time.Elapsed is documented to be inaccurate by up to 55ms, which means that if each cycle occurs within 110ms, you could easily have a negative result for (Time.Elapsed - LastFrameTime) which would, of course, delay rather substantially.

One thing that could help is only calling Time.Elapsed once (it's a function!) and storing its value; then you're guaranteed to be dealing with a single inaccurate value rather than the three you currently have.

Better would be to skip Frame_Rate and just call Time.DelaySinceLast ( 10 ), which would lock to a maximum of 100FPS.

[petree08]

Yeah, Frame_Rate as it stands only causes a delay if the program is running too fast. I even removed it all together and there is still a lag going on,

so the issue is how much is being drawn on the screen,

but i am working around with
- the velocity of the ball
- the strength of gravity

speeding up the ball will make the game playfaster,

i know it is cheating but i may even scrap it alltogther, Being in college now i don't really have time for turing anymore. but i did get this going as a visual concept and i may attempt to d
o this in a more practical language later on