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 |
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.
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 . 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". |
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:
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:
|
Author: | NikG [ Tue Jun 27, 2006 10:15 pm ] | ||
Post subject: | |||
Wow, that really makes me scratch my head. |