Computer Science Canada

[FP] - FPS

Author:  beforelast [ Wed Jun 21, 2006 8:00 am ]
Post subject:  [FP] - FPS

Herei s my final project. Not hte best but I like it Smile

Author:  Delos [ Wed Jun 21, 2006 9:15 am ]
Post subject: 

Pleaes provide a little more info in your description regarding your proggie - i.e., what language it was written in, some relevant background info, perhaps some screenies - just so people know what they're downloading.

Author:  Windsurfer [ Sat Jun 24, 2006 7:36 pm ]
Post subject:  Suggestion?

Nice Whak-a-mole game... but i was wondering if you could fork the sound effects to make it run smoothly. And maybe make the enemies appear faster from the begining? Otherwise, nice graphics. I really think you should do some sort of description for this game.

Author:  upthescale [ Mon Jun 26, 2006 12:37 pm ]
Post subject: 

Nice game man, good graphics. Get a voting poll, so i can vote awsome!

Author:  the_short1 [ Mon Jun 26, 2006 5:24 pm ]
Post subject:  Re: Suggestion?

Windsrufer wrote:
Nice Whak-a-mole game... but i was wondering if you could fork the sound effects


forking would be a bad idea, its very inneficient... upgrade to turing 4.0.5 and use Music.PlayFileReturn it plays a sound file while continueing a program.

good job otherwise, not very buggy like most of the other submissions.

Author:  Windsurfer [ Mon Jun 26, 2006 5:44 pm ]
Post subject:  Re: Suggestion?

the_short1 wrote:

forking would be a bad idea, its very inneficient... upgrade to turing 4.0.5 and use Music.PlayFileReturn it plays a sound file while continueing a program.


Using Music.PlayFileReturn actually just calls a procedure that forks the sound for you, so you don't have to mess with making processes and the such.

code:

process Play_String (this : string)
    Music.PlayFile (this)
end Play_String

procedure Play_Music (this : string)
    fork Play_String (this)
end Play_Music



Using the above code, calling Play_Music("sound.wav") will actually do the exact same thing (even performance wise) as calling Music.PlayFileReturn("sound.wav").
Actually, after testing a bit, the code above seems to perform slightly faster than Turing's built-in Music.PlayFileReturn... hmm...

Author:  Delos [ Mon Jun 26, 2006 6:20 pm ]
Post subject:  Re: Suggestion?

Windsrufer wrote:

Actually, after testing a bit, the code above seems to perform slightly faster than Turing's built-in Music.PlayFileReturn... hmm...


What do you mean by testing? Did you run a few times and compare some sample times? Keep in mind random variance - unaccountable noise. I would suggest running at least 30 trials on each before making any calls, but that's just me being statistically nitpicky Very Happy.

If you're wondering why I chose the number 30, it's quite simple. Basic stats can show that when n=30, from even somewhat skewed populations, one can get a sufficiently normal distribution upon which many statistical methods may be applied. Sure taking a mean is nothing intense, but if you did want to do any form of hypothesis testing (as you're thought-line indicates) you'd want to make sure your sample sizes are large enough and that you have a large enough n (i.e., enough Power!).

Author:  the_short1 [ Mon Jun 26, 2006 6:22 pm ]
Post subject: 

really.. thats .. . sad... .i used it in my pacman game wayy back when and i thought it improved the performance.... lol delos.. thats king..

Author:  Windsurfer [ Mon Jun 26, 2006 9:11 pm ]
Post subject:  Re: Suggestion?

Delos wrote:

What do you mean by testing? Did you run a few times and compare some sample times?


If you must know, Delos, I used a slightly modified version of my timing program found http://www.compsci.ca/v2/viewtopic.php?t=12502 except i tested it 100 times. For the particular sound i was playing, Turing got about 890, while my procedure got about 840. Of course, there was a lot of variance, but it was almost my own procedure that "won". Smile

Author:  [Gandalf] [ Tue Jun 27, 2006 2:00 am ]
Post subject: 

Turing is far from great when it comes to any efficiency test. There is always some arbitrary timing that skews the results. Take the following program for example:
code:
var timeA, timeB : int
var tempDist : real
var beginTime : int := Time.Elapsed
for i : 1 .. 10000
    tempDist := Math.Distance (1, 1, 5, 5)
end for
timeA := Time.Elapsed - beginTime
beginTime := Time.Elapsed
for i : 1 .. 10000
    tempDist := Math.Distance (1, 1, 5, 5)
end for
timeB := Time.Elapsed - beginTime
put "Time A: ", timeA, "\nTime B: ", timeB

One would think that the times outputted are either always equal or else that sometimes one takes a bit longer, and sometimes the other (about 50-50). Such is not the case. About 99% of the time the first test takes longer than or equal to the second:
code:
var beginTime : int
var timeA, timeB : array 1 .. 100 of int
var tempDist : real
for z : 1 .. 100
    beginTime := Time.Elapsed
    for i : 1 .. 10000
        tempDist := Math.Distance (1, 1, 5, 5)
    end for
    timeA (z) := Time.Elapsed - beginTime
    beginTime := Time.Elapsed
    for i : 1 .. 10000
        tempDist := Math.Distance (1, 1, 5, 5)
    end for
    timeB (z) := Time.Elapsed - beginTime
end for
put "Test finished..."
var timeALonger, timeBLonger, timesEqual : int := 0
for i : 1 .. upper (timeA)
    if timeA (i) > timeB (i) then
        timeALonger += 1
    elsif timeB (i) > timeB (i) then
        timeBLonger += 1
    else
        timesEqual += 1
    end if
end for
put "Time A longer: ", timeALonger / upper (timeA) * 100, "%"
put "Time B longer: ", timeBLonger / upper (timeB) * 100, "%"
put "Times equal: ", timesEqual / upper (timeA) * 100, "%"

Author:  NikG [ Tue Jun 27, 2006 10:15 pm ]
Post subject: 

Turing:
Test finished...
Time A longer: 42%
Time B longer: 0%
Times equal: 58%


Wow, that really makes me scratch my head.


: