Computer Science Canada :: View topic - Why You Should Avoid Processes

Computer Science Canada

Why You Should Avoid Processes

Author:

Cervantes [ Sat Feb 19, 2005 11:29 am ]

Post subject:

Why You Should Avoid Processes

For the somewhat new programmer, using processes may seem almost manditory. You may want to do two things simultaneously and immediately think, "I can use a process for that!" But when you think that, you're making a big mistake.
In Turing, processes are terrible. They should be avoided at all costs (really, the only time they should be used is for playing music, but Turing 4.0.5 makes it so we don't even need them for that).
"Why are processes so terrible," you ask? Well, take a look at the example in the help file:

Turing:

process greetings (word : string)
loop
put word
end loop
end greetings

fork greetings ("Hi")
fork greetings ("Ho")

Run it. After a second, stop it. You should see a very inconsistant pattern on the screen. This is because the processes execute at different (almost random, it seems) speeds. It's not as though greetings ("Hi") executes once, then greetings ("Ho") once, then once again for greetings ("Hi"), etc. No, Turing's processes don't work the way you want them to.
"But I don't care if they work at different rates!", you yell.
Aah, you should. Lets say we've got two objects, and we want to move them across the screen. object1 has a speed of 1, and object2 has a speed of 2. Both must travel the same distance. Using processes, object 2 will likely not reach its destination twice as fast as object1. Rather, it will reach its destination approximately twice as fast as object1. This may not seem like a big issue, but it is. You never know how your program is going to behave, because the processes run in a random fashion.

Actually I just discovered another bad thing about processes: you can't use "var" parameters. ie. you can't go

code:

process move (var foo : string)

We'll let Hacker Dan finish this for us:

Hacker Dan wrote:

Process can be good but you have to understand how they work and turing has limited conortl over them. Since turing has no way to set proity of a process all you know is that the code may run at some time. So baliky unless you got a dual CPU system a process will run lines of code in it at basicly random times durning the excution of your progame. If it dose not mater when they run then it could be good to use them but it gives you less conortl over things.

In conclusion, don't use processes. They are evil. If you choose to use them, fine, but you are only hurting your own program. You'll probably end up spending hours down the line reworking everything to eliminate the processes.

I'm no expert on this matter, but so many people have been trying to/using processes lately I felt something had to be done. Any elaboration on this matter, or more convincing/moral support, is welcome.

-Cervantes

Author:	cycro1234 [ Sat Feb 19, 2005 12:21 pm ]
Post subject:
Wow, thanks for that tutorial! But If I shouldn't use processes to make 2 things run at the same time, I use instead? Like, what if I'm making a game and I want the person to shoot and move at the same time. How will I work that out? Or what If i want to animate 2 objects at the same time doing different actions unrelated to each other.

Author:

Martin [ Sat Feb 19, 2005 1:04 pm ]

Post subject:

No. Your main loop should look like this:

code:

loop
if up arrow pressed then
playery += 1
end if
if left arrow pressed then
playerx += 1
end if
if ...
...
end if
for i : 1 .. numBullets
updatebulletposition(i)
end for
drawScene %player, bullets, etc.
end loop

The absolute only time that you should ever use a process is when you are doing sound.

Author:	cycro1234 [ Sat Feb 19, 2005 1:08 pm ]
Post subject:
Ok. Thanks.

Author:

Cervantes [ Sat Feb 19, 2005 1:31 pm ]

Post subject:

Basically, you stick it all in the same loop. As to how to do it (well, it's really easy, but if you're stuck thinking in terms of processes, it might be a little difficult), the easiest way to show you how is with examples.

cycro1234 wrote:

Like, what if I'm making a game and I want the person to shoot and move at the same time.

There's an easy one. Shooting and moving is the same, in that both rely on input from the keyboard (or mouse).

Turing:

var x, y := 100

var keys : array char of boolean

proc fire
%code
end fire
loop

Input.KeyDown (keys)
if keys (KEY_CTRL) then
fire
end if
if keys (KEY_UP_ARROW) then
y += 1
end if
if keys (KEY_DOWN_ARROW) then
y -= 1
end if
if keys (KEY_RIGHT_ARROW) then
x += 1
end if
if keys (KEY_LEFT_ARROW) then
x -= 1
end if

cls
drawfilloval (x, y, 5, 5, black)
delay (10)

end loop

All you have to do is make your fire procedure. How you do that is related to your second question.

cycro1234 wrote:

Or what If i want to animate 2 objects at the same time doing different actions unrelated to each other.

There is always something that is related. Always. What is related is time. Just as my fingers move to type this, our solar system is hurtling around the Milky Way at 900 000km/h. We have two objects (my fingers, and the solar system) whose motions pretty well don't affect one another, but are nonetheless related through time. Every hour that my fingers move, the solar system travels 900 000km. Or, every hour that my fingers don't move, the solar system travels 900 000km. No matter what, the motions of the two objects are joined by time.
Because the motions are joined by time, we want to avoid using a process. Using a process would be like randomly accelerating time for one object, and slowing time for another. By using just one loop, however, we can keep time going at a constant pace.
Below you'll find three programs. The first is really all that I need to show how you do this without using processes. The second program is the same code, but much neater. The last uses many objects. Smile

Turing:

View.Set ("offscreenonly")
var ballx := 0.0
var bally := 50.0
var ballvx := 2
var ballvy := 0.6

var starx := 50.0
var stary := 150.0
var starvx := 2.5
var starvy := -0.3

loop
ballx += ballvx
bally += ballvy
starx += starvx
stary += starvy

cls
Draw.FillOval (round (ballx), round (bally), 15, 15, brightred)
Draw.FillStar (round (starx - 15), round (stary - 15), round (starx + 15), round (stary + 15), brightblue)
%the 15 is half the width and half the height. Remember the star is drawn with x1, y1, x2, y2
View.Update
delay (15)
end loop

Here's the same thing, but neater. Types are always nice for keeping things organized.

Turing:

View.Set ("offscreenonly")
type obj :
record
x : real
y : real
vx : real
vy : real
end record

var ball : obj
ball.x := 0
ball.y := 50
ball.vx := 2
ball.vy := 0.6

var star : obj
star.x := 50
star.y := 150
star.vx := 2.5
star.vy := -0.3

loop
ball.x += ball.vx
ball.y += ball.vy
star.x += star.vx
star.y += star.vy

cls
Draw.FillOval (round (ball.x), round (ball.y), 15, 15, brightred)
Draw.FillStar (round (star.x - 15), round (star.y - 15), round (star.x + 15), round (star.y + 15), brightblue)
%the 15 is half the width and half the height. Remember the star is drawn with x1, y1, x2, y2
View.Update
delay (15)
end loop

The next code takes the motion section (the ball.x += ball.vx etc. part) and sticks it into a procedure. Then it uses that procedure many times, for there are many more objects in this one. Smile

Turing:

View.Set ("offscreenonly")
type obj :
record
x : real
y : real
vx : real
vy : real
end record

var ball : array 1 .. 30 of obj
for i : 1 .. upper (ball)
ball (i).x := Rand.Int (0, maxx)
ball (i).y := Rand.Int (0, maxy)
ball (i).vx := Rand.Int (-3, 3)
ball (i).vy := Rand.Int (-3, 3)
end for

procedure moveObj (var obj : obj)
obj.x += obj.vx
obj.y += obj.vy
end moveObj

loop

%Move all the balls
for i : 1 .. upper (ball)
moveObj (ball (i))
end for

cls

%Draw all the balls
for i : 1 .. upper (ball)
Draw.FillOval (round (ball (i).x), round (ball (i).y), 15, 15, brightred)
end for
View.Update
delay (15)
end loop

Hopefully that wasn't hard to get through.

To recap: don't use processes, because doing so means you're screwing with time. Use a single main loop. The concept is no different than using processes. You just have to keep your main loop structured nicely. (ie. keep all your drawing at the end, all your input at the beginning, and all your variable manipulation in the middle).

-Cervantes

Author:	Tony [ Sat Feb 19, 2005 1:31 pm ]
Post subject:
I'd like to add that if both processes use the same global variable, the results will be disastrous. You essensially throw your code flow into a blender, mix it up and say. "Here I have a bunch of lines of code. They are in no particular order. If the computer happens to pick the right order - the results will be as expected. Otherwise I have no idea what might happen"

Author:	cycro1234 [ Sat Feb 19, 2005 1:45 pm ]
Post subject:
Ok, thanks a lot for that guys! I get it a lot more now. But if processes are so useless, why were they added in Turing? Only to make music run?

Author:	Cervantes [ Sat Feb 19, 2005 3:33 pm ]
Post subject:
Processes (threads?) are not a feature of Turing alone. Many other languages have them, though I believe their processes actually work orderly, not randomly. I can only assume Holtsoft tried to give Turing what those other languages have. Boy did they fail...

Author:	Flikerator [ Sat Feb 19, 2005 6:00 pm ]
Post subject:
For my final project (Pong) I used like 6 forks. Ai, paddle, paddle2 (2 player), music, lives, and ball. I wouldn't do anything like that cause now I am not so nubish anymore. I pulled a 90 out of my first year with that sort of programming lolz. Quote: the only time they should be used is for playing music, but Turing 4.0.5 makes it so we don't even need them for that What do you mean, how do we play music without using a process? This will help greatly in Zombie Mass'Acres

Author:	rizzix [ Sun Feb 20, 2005 12:40 am ]
Post subject:
hmm i dont get it.. what do u guys mean by random? the lines of code executed with the process code-block is random? (quite impossible) if so, never use processes. if not.. there is nothing wrong with the processes. they are just fine, just that you guys are not used to concurrent programming.

Author:	md [ Sun Feb 20, 2005 1:17 am ]
Post subject:
Cervantes wrote: Processes (threads?) are not a feature of Turing alone. Many other languages have them, though I believe their processes actually work orderly, not randomly. I can only assume Holtsoft tried to give Turing what those other languages have. Boy did they fail... Threads (as processes are really known) are actually a feature of the OS (windows), or very low level code (linux can use kernel threads and user threads [i think], basically their only different in what does the schedualing). However your wrong in your assumption that they are run in an orderly fasion. Say we have two threads, A and B. Thread A will be run for a given time (a very small ammount of time...), then thread B will be given a chance. The problem is when unshedualed things happen, say a keystroke. The OS must then switch from the thread to the keyboard handling process which will then run until it is done or something else interupts it. Once the keyboard process is done the OS returns execution back to the next ready process (not nessarilly ours). The next time it gets arround to running our process it will probably run the next thread in the queue (which, again, will probably not be the one that was interupted). Thus something as trivial as an interupt can cause any thread to lose some of it's execution time. And since interupts are generated by almost all hardware and at a fairly high rate, execution times are not perfectly balanced. Of course modern threads can be prioritized, or blocked (set not to run), so in practice threads are actually are very usefull tool. Although I wouldn't recomend creating a lot of threads, as each thread adds overhead, and creating one for such a simple task as an animation is frivilous.

Author:

cycro1234 [ Tue Feb 22, 2005 4:55 pm ]

Post subject:

I have this code to shoot and move, but it's not working:

code:

View.Set ("offscreenonly")

var chars : array char of boolean
var x, y : int := 100
forward proc movement

proc shoot (var y : int)
loop
y := y + 1
drawoval (x+35,y-1,10,10,0)
drawoval (x+35,y,10,10,7)
drawoval (x-35,y-1,10,10,0)
drawoval (x-35,y,10,10,7)
View.Update
exit when y + 20 > maxy
movement
end loop
end shoot

body proc movement
loop
Input.KeyDown (chars)
if chars (KEY_UP_ARROW) and y + 64 < maxy then
y := y + 1
elsif chars (KEY_DOWN_ARROW) and y > 0 then
y := y - 1
elsif chars (KEY_LEFT_ARROW) and x > 0 then
x := x - 1
elsif chars (KEY_RIGHT_ARROW) and x + 64 < maxx then
x := x + 1
elsif chars (KEY_CTRL) then
shoot (y)
end if
cls
drawfilloval (x,y,20,20,7)
View.Update
end loop
end movement

loop
movement
end loop

Hold ctrl to shoot and move with arrow keys.

I thought that if I called movement in the procedure shoot then I could shoot and move at the same time. It doesn't work! The y value that I need for the bullet interferes wit the y value of the position of the circle. After shooting the bullets, the y value of them is stored and is used to draw the cirle in a place i do not need. Any ideas how to fix?

Author:

jamonathin [ Tue Feb 22, 2005 8:13 pm ]

Post subject:

You have to give the bullet's their own variables. 'x' and 'y' are already used by the "shooter" and so by adding to the y-value, you're changing where the shooter is. This is what i came up with. .

code:

View.Set ("offscreenonly")

var chars : array char of boolean
var x, y, bullety, bulletx : int := 100
var shot : int := 0
forward proc movement

proc shoot
loop
shot := 1
bullety += 1
exit when bullety + 20 > maxy
movement
end loop
shot := 0
end shoot

body proc movement
Input.KeyDown (chars)
if chars (KEY_UP_ARROW) and y + 64 < maxy then
y := y + 1
elsif chars (KEY_DOWN_ARROW) and y > 0 then
y := y - 1
elsif chars (KEY_LEFT_ARROW) and x > 0 then
x := x - 1
elsif chars (KEY_RIGHT_ARROW) and x + 64 < maxx then
x := x + 1
end if
if chars (KEY_CTRL) and shot = 0 then
bullety := y
bulletx := x
shoot
end if
cls
if shot = 1 then
drawoval (bulletx + 35, bullety - 1, 10, 10, 0)
drawoval (bulletx + 35, bullety, 10, 10, 7)
drawoval (bulletx - 35, bullety - 1, 10, 10, 0)
drawoval (bulletx - 35, bullety, 10, 10, 7)
end if
drawfilloval (x, y, 20, 20, 7)
View.Update
end movement

loop
movement
end loop

The shooter moves a little slower while the bullets are being fired however. If you want, you can have a variable represent the displacement of the shoot (y + 1 to y + dif), and when the ball is being fired, dif will equal 2, but outside the loop, dif will equal 1, your choice. Confused

Author:	cycro1234 [ Tue Feb 22, 2005 10:06 pm ]
Post subject:
K got it. Thx.

Author:	HyperFlexed [ Wed Feb 23, 2005 10:04 pm ]
Post subject:
Never looked into it but I believe Turing has a way to set the priorities of processes. I must agree though, many people failed my compsci class because they used them innapropriately. One guy made this game where red and black blocks float across the screen and you gotta hit the red and avoid the black. Not only did he use processes, he made one process for each block rather than passsing in the values (I suppose it'd be redundant eather way). The biggest thing to understand is a computer goes so fast, you don't have to worry to much about the order of how things are done. And if you are using View.Update and getting everything at once, your user won't get screwed, and your program will be alot faster for it. that reminds me, I should post my final project. I made tetris, hehe.

Author:	Martin [ Tue Mar 01, 2005 2:45 pm ]
Post subject:
No. No processes, ever (except for music). I don't care what you are making: processes will only make your code junky.

Author:	StarGateSG-1 [ Tue Mar 01, 2005 4:34 pm ]
Post subject:
I am Sick and tried of all you people bashing processes becasue they are random, with that said they are. But if you are trying to save lines in a program and say you have a guiclear that you don't wnat to have to call again and again and alos not call ina procedure becasue they run by themselves and not with other parts. So yes procedures are good for like moving a character and stuff, but if you have the same command 400 times in your program make a process of it. For example if you have a press any key, which is 100's of times bigger youi don't wnat to have to right the 5 or 6 lines again and again. Now you say well their is copy and paste. How long do you think it takes to compile a program with 500++ extra lines??

Author:	[Gandalf] [ Tue Mar 01, 2005 5:10 pm ]
Post subject:
Quote: Now you say well their is copy and paste. I don't think anyone would say that . Personally, I have never had to use proccess' except for music - just stick to procedures.

Author:	Bacchus [ Tue Mar 01, 2005 6:38 pm ]
Post subject:
processes are random and dont go in the order you specify. using them will make you a monkey, which is accually unfair to monkeys b/c thier really smart but they dont speak english, the speak monkey language (lol). ne who procedure are much better and even if your calling the proc many many times its still better (and what did you even mean by that, use a process?! it would run continuasly (im assuming u meant in a loop, if not it would still be like a proc) and then how would you nat have it run when you wanted to) the point of a proc is to save space you could do that very efficiently with parameters while a process is meant to just run at the same time as the main program. and who even cares if the proc doesnt run the same time as the main program? i mean cmon do you really notice the delay it takes to go completly thu a proc?

Author:	person [ Tue Mar 01, 2005 7:10 pm ]
Post subject:
Quote: processes are random and dont go in the order you specify. using them will make you a monkey, which is accually unfair to monkeys b/c thier really smart but they dont speak english, the speak monkey language (lol). omg!...lol u got that off of CCC Quote: I am Sick and tried of all you people bashing processes becasue they are random, with that said they are. But if you are trying to save lines in a program and say you have a guiclear that you don't wnat to have to call again and again and alos not call ina procedure becasue they run by themselves and not with other parts. So yes procedures are good for like moving a character and stuff, but if you have the same command 400 times in your program make a process of it. For example if you have a press any key, which is 100's of times bigger youi don't wnat to have to right the 5 or 6 lines again and again. Now you say well their is copy and paste. How long do you think it takes to compile a program with 500++ extra lines?? i dont understand y u cant use a procedure instead i mean who cares if it runs on its own...like the user is gonna notice

Author:	Bacchus [ Tue Mar 01, 2005 7:32 pm ]
Post subject:
yes exacly and yes it did come from CCC lol that was a funny question and had me confused for a bit. funny thing was i screwed up question 3 sooo much. i was like over thinking it and started to use flexible arrays and more complex things and completly lost my train of thought redid it a couple times to no avail came close started to go crazy and twitchy (i do that quite often) and went to the next question lol

Author:	person [ Tue Mar 01, 2005 8:46 pm ]
Post subject:
just wondering did u get q4?

Author:	Bacchus [ Tue Mar 01, 2005 9:17 pm ]
Post subject:
we're not really suposed to be talking about this but i wont reviel much. i was spacing out and kept reading the same thing over and over so i got fed up and just made the accual picture and had a guy walk around till he stopped and i could figure out where he was lol

Author:	Martin [ Wed Mar 02, 2005 10:42 am ]
Post subject:
Here's a challenge, open for anyone. Write a program using processes that I can't improve by getting rid of the processes. If you can do this, I'll give you 1000 bits. Go. Only rule is no music.

Author:	StarGateSG-1 [ Wed Mar 02, 2005 12:28 pm ]
Post subject:
I will take your challenge and I will beat you. But one questions who's is to say what is better obvious you nor me can decide and i don't think this is a impartial person on this forum. But we will deal witht that later.

Author:	Tony [ Wed Mar 02, 2005 1:26 pm ]
Post subject:
StarGateSG-1 wrote: But one questions who's is to say what is better We'll run both programs though tests. Execution times, glitches, etc. Btw, Martin: F10 Turing Reference wrote: Music.PlayFileReturn ( fileName : string ) Unlike Music.PlayFile, the Music.PlayFileReturn procedure should not be called in a separate process. Instead, the procedure returns immediately. This makes Music.PlayFileReturn easier to use, but makes it unsuitable for playing a set of files sequentially.

Author:	Martin [ Wed Mar 02, 2005 2:14 pm ]
Post subject:
Yeah, I haven't used turing in a while suffice to say.

Author:	Mazer [ Wed Mar 02, 2005 3:14 pm ]
Post subject:
What's wrong with what Martin said? Music.PlayFileReturn just calls a process, so it makes sense not to allow music in the competition.

Author:

person [ Wed Mar 02, 2005 3:37 pm ]

Post subject:

code:

process a
put "hi"
end a
process b
fork a
put "ho"
end b
loop
fork b
end loop

puts random hi and ho (dont know if it counts though)

Author:

Tony [ Wed Mar 02, 2005 4:45 pm ]

Post subject:

Damn it, processes are so freaking hard to benchmark Confused

Here're the two programs with benchmarks incorporated. I hope everybody finds them fair.

processes

Turing:

var bench : int := 0
process a
put "hi"
bench += 1
end a
process b
fork a
put "ho"
bench += 1
end b
loop
fork b
exit when bench >= 100
end loop
put ""
put "Bench :: ", bench
put Time.Elapsed

Results:: 100 outputs in ~1800

no processes

Turing:

var bench : int := 0
loop
if (Rand.Real > 0.5) then
put "hi"
else
put "ho"
end if
bench += 1
exit when bench >= 100
end loop
put ""
put "Bench :: ", bench
put Time.Elapsed

Result:: 100 outputs in ~855..

Results of this case study... vertually identical output, but processes take up twice as long. Also notice that in processes, even after the benchmark has been reached and loop exited, "hi/ho" output still went in between the results. Glitches are not undocumented features.

so.. ~1800 milliseconds for processes vs. ~850 without.

Anyone else?

Author:	StarGateSG-1 [ Wed Mar 02, 2005 5:20 pm ]
Post subject:
I am not going to do this not becaus ei can't but because you guys don't see were i am coming from. A process is like a method in java or C++ not the way you guys are using it. All a process is the same hard code for a C++ method but made simple for learning! It is nothing more ! That is were i'm cming from every one else is doing something the first program in topic.

Author:	Cervantes [ Wed Mar 02, 2005 7:00 pm ]
Post subject:
StarGateSG-1 wrote: I am not going to do this not becaus ei can't but because you guys don't see were i am coming from. Then do it, and show us where you are coming from. I'd like to see it done.

Author:	Andy [ Wed Mar 02, 2005 7:04 pm ]
Post subject:
StarGateSG-1 wrote: I am not going to do this not becaus ei can't but because you guys don't see were i am coming from. A process is like a method in java or C++ not the way you guys are using it. All a process is the same hard code for a C++ method but made simple for learning! It is nothing more ! That is were i'm cming from every one else is doing something the first program in topic. o really.. show us some c code? cuz well im a c programmer and right now, you're making absolutely no sense... in java a method is just simply a member function of the class

Author:	Martin [ Wed Mar 02, 2005 9:00 pm ]
Post subject:
1000 bits.... :p

Author:	StarGateSG-1 [ Thu Mar 03, 2005 8:27 am ]
Post subject:
I guess I should have mentioned this but i kinda gave up programing for lent so I can only post source for programs I have and i don't have any ones right now. (I delete most of them to make room for C++) but i can tell you that look up processes in turing help and look at priroties!

Author:	Tony [ Thu Mar 03, 2005 9:47 am ]
Post subject:
StarGateSG-1 wrote: look up processes in turing help and look at priroties! priorities appear to be interesting.. I'd have to think a bit more about their proper implemintation and will most likely be writing a tutorial this week.

Author:	Martin [ Thu Mar 03, 2005 10:54 am ]
Post subject:
So does this mean that I win?

Author:	Tony [ Thu Mar 03, 2005 11:00 am ]
Post subject:
I'll tell you that after I revisit processes in detail.

Author:	StarGateSG-1 [ Thu Mar 03, 2005 12:05 pm ]
Post subject:
I glad to see you aleats listen to me and are looking in to it. I really am sry i can't give you any source code i take lent very seriously. lol even thos i drew it out of a hat with everyhing i could give up. I guess it was luck of the draw.

Author:	person [ Thu Mar 03, 2005 6:21 pm ]
Post subject:
how about animating 2 things at the same time with different speeds? wouldnt u need a process for that?

Author:	ssr [ Thu Mar 03, 2005 6:29 pm ]
Post subject:
not really put them all in a same loop and then set different speed ... 8)

Author:	Martin [ Thu Mar 03, 2005 6:33 pm ]
Post subject:
Yeah. Delays are another bad thing...I'll get into that later though.

Author:	Bacchus [ Thu Mar 03, 2005 6:39 pm ]
Post subject:
cooldowns work quite well, do a search for that with author Cervantes, he posted an example b4 and it works quite well

Author:	Tony [ Fri Mar 04, 2005 3:45 pm ]
Post subject:
martin wrote: Processes still suck. Hmm.. I think I'll take on your challange. Martin -- get your Turing reference book out, you're going to need to relearn a language

Author:	Martin [ Fri Mar 04, 2005 6:47 pm ]
Post subject:
tony wrote: martin wrote: Processes still suck. Hmm.. I think I'll take on your challange. Martin -- get your Turing reference book out, you're going to need to relearn a language Bring it on.

Author:	[Gandalf] [ Fri Mar 04, 2005 7:34 pm ]
Post subject:
Quote: Delays are another bad thing...I'll get into that later though. Why are delays bad? Why don't you get on that some time soon, they only pause the code - whats bad about that?

Author:	ssr [ Fri Mar 04, 2005 8:34 pm ]
Post subject:
I donno but I think that I've heard delays are not really accurate use Time.Elapse 8)

Author:	person [ Fri Mar 04, 2005 9:30 pm ]
Post subject:
u can actually read about how bad delays are in F10 but frankly it doesnt matter much for me

Author:

Martin [ Fri Mar 04, 2005 9:52 pm ]

Post subject:

I'll write up a bit about delays later. Basically, they're bad because you've got your program structured like so:

code:

loop
<some unfixed amount of time passes processing stuff>
<a fixed time is delayed>
end loop

What this means is that the speed of the game is directly dependant upon the speed of the client computer.

Author:	person [ Fri Mar 04, 2005 9:54 pm ]
Post subject:
isnt it always dependant on the clients computer (processing speeds and etc.) ??

Author:	Tony [ Fri Mar 04, 2005 11:18 pm ]
Post subject:
The idea is to control frame-rate, and pause for less on slower machines and during calculation heavy moments. In practice, you don't want a Counter-Strike player to shoot twice as fast as the next guy just because one has liquid cooling installed.

Author:	Martin [ Sat Mar 05, 2005 10:01 am ]
Post subject:
person wrote: isnt it always dependant on the clients computer (processing speeds and etc.) ?? No. Yes, on a faster computer, the animation will be smoother, but a player shouldn't be put at a disadvantage because they have a slower processor. Similarly, people with faster computers shouldn't be able to shoot 5 times faster than everyone else. Let's say that you want each frame of animation to take 20 milliseconds. Suppose on your computer it takes 10 ms to do all of the crunching, so you delay(10) at the end. Works exactly how you wanted it to on your computer. You bring it over to your buddy's computer, who has a slower processor, so it takes 15 seconds to do the number crunching, but you still are delaying 10 at the end of each frame. So the game runs slower on his computer. Now, the quick solution to this is to: 1. Determine the total time, GoalTime, you want the frame to last (in the above example, the total time was 20). 2. In each iteration of the loop, determine how long the number crunching took with Time.Elapsed. 3. Delay for the GoalTime - Time.Elapsed. Now, what happens if the number crunching is longer than GoalTime? This is where time based movement comes into play, which I'll explain later.

Author:	Bacchus [ Sat Mar 05, 2005 7:19 pm ]
Post subject:
1 simple thing that is fixed in 4.0.5 Time.DelaySinceLast()

Author:	Martin [ Thu Mar 10, 2005 10:34 am ]
Post subject:
Nobody has taken me up on this 1000 bit challenge. So I'm raising the stakes. 2000 bits. I still don't think it can be done.

Author:

StarGateSG-1 [ Thu Mar 10, 2005 12:26 pm ]

Post subject:

This program comes form the top!

code:

monitor controller
export observe, report

var counter : int := 0

procedure observe
counter := counter + 1
end observe

procedure report (var n : int )
n := counter
counter := 0
end report
end controller
process observer
loop
% "¦ observe one event "¦
controller . observe
end loop
end observer

process reporter
var n : int
loop
controller.report ( n )
% "¦ report n events "¦
end loop
end reporter

fork observer % Activate the observer
fork reporter % Activate the reporter

This is form deep in the Documentation of turing and I even contacted Tom West to make sure.

Author:	Martin [ Thu Mar 10, 2005 1:10 pm ]
Post subject:
And umm...what is that supposed to be doing?

Author:	Tony [ Thu Mar 10, 2005 1:44 pm ]
Post subject:
StarGateSG-1 wrote: This program comes form the top! ... This is form deep in the Documentation of turing and I even contacted Tom West to make sure. And we all know that the said top thinks at a highschool level. Martin : Your turn

Author:	StarGateSG-1 [ Fri Mar 11, 2005 7:14 am ]
Post subject:
The program runs 2 processes at the same time. Quote: And we all know that the said top thinks at a highschool level. What do you mean by this

Author:	Martin [ Fri Mar 11, 2005 8:05 am ]
Post subject:
StarGateSG-1 wrote: The program runs 2 processes at the same time. Quote: And we all know that the said top thinks at a highschool level. What do you mean by this Umm, that's easy enough to do without processes, although the above code seems somewhat abstract for me to provide a solid counter arguement. And Tony, it's on. I'll have the processless code posted by the end of the weekend hopefully.

Author:	StarGateSG-1 [ Fri Mar 11, 2005 8:29 am ]
Post subject:
Quote: Umm, that's easy enough to do without processes, although the above code seems somewhat abstract for me to provide a solid counter arguement. Well if it is so easy do it. If works exaclty the same as anyone other way. The coed is not abstract, it is right out of the help file.

Author:	Martin [ Fri Mar 11, 2005 8:46 am ]
Post subject:
Oh, it's easy enough to fix, but it's still abstract. It doesn't actually do anything.

Author:	Tony [ Fri Mar 11, 2005 9:24 am ]
Post subject:
StarGateSG-1 : the code you posted was to demonstrate the monitor, not processes. The abstract consept is that two processes access the same variable and a monitor class queries their requests.

Author:	StarGateSG-1 [ Fri Mar 11, 2005 12:00 pm ]
Post subject:
It demostrates that two processes can be run at the same time as well though, and that was the point. I believe all the challege was was to right (or find a program that couldn't be written better without porcesses. This meets those req.

Author:	Martin [ Fri Mar 11, 2005 2:54 pm ]
Post subject:
Not yet, I definately see where I can improve this. However, like I said, it would be much easier if you were to post code that actually did something.

Author:	StarGateSG-1 [ Fri Mar 11, 2005 3:50 pm ]
Post subject:
It does do something it just has no output!

Author:	Bacchus [ Fri Mar 11, 2005 4:02 pm ]
Post subject:
just stick a put statment to output the counter variable after one gets added to it, it should never reach 2, but it does lol

Author:	McKenzie [ Fri Mar 18, 2005 2:00 am ]
Post subject:
Silly Conest, and silly judging. OK, don't touch processes until you know what you are doing. (this is about one year after you think you know what you are doing, for some never ) Better or worse is not measured simply be execution time. Better, for the most part, is if it makes the program easier without sacrificing efficiency. The reality is processes can make the program more efficient, but this only happens with advanced programs (e.g. A chess program when the IA is doing it's work while waiting for the player to do his move.) There is no program that is written with processes that can't be written without. The question is "does this program lend itself to processes?" The same can can be said of recursion or even subroutines. You can always do without them, but the real issue is WHEN SHOULD THEY BE USED. For the record, I would be a happy man if no grade 11 ever used a process (they mostly mess it up)

Author:

Tony [ Fri Mar 18, 2005 9:18 am ]

Post subject:

good point by McKenzie; though I'm still waiting for Martin's code Laughing

But yes -- processes are justified to be used only when one knows what he's doing. Oftentimes I saw people do something like

Turing:

process foo
loop
%program
end loop
end foo

fork foo

The reasoning behind such is simply beyond me.

Author:	McKenzie [ Fri Mar 18, 2005 10:07 am ]
Post subject:
I know, I see those programs too. I don't know if they think they're being 1337 or if they think that they own a machine with massively parrallel processors. If they come from accross the hall (there are two computer teachers at massey) I'm gently explain how they are adding complexity for no good reason. If they're my student I shake my head in disgust, talk about how I've failed them as a teacher and maybe I should go back to driving taxi. They get the Idea that they may have done something wrong. (It's kinda like Holt's message about "it's not your fault" ... don't kid yourself ... it's your fault)

Author:	Bacchus [ Fri Mar 18, 2005 10:33 am ]
Post subject:
lol send them on a guilt trip

Author:	StarGateSG-1 [ Fri Mar 18, 2005 10:48 am ]
Post subject:
I am Glad to see this topic is warped up with common sense, people finally see it my way as my old singature said.

Author:	StarGateSG-1 [ Fri Mar 18, 2005 10:52 am ]
Post subject:	One last thing
Quote: For the record, I would be a happy man if no grade 11 ever used a process (they mostly mess it up) You need to make this say forst or second year, not all school start up in grade 11, me I started, way back in grade nine soon to be 5 years.

Author:	McKenzie [ Fri Mar 18, 2005 3:08 pm ]
Post subject:
There is a certain amount of mental maturity that is seperate from years of programming experience. Some of this maturinty is physical and some has to with other educational experience (mainly math)

Author:	Martin [ Fri Mar 18, 2005 3:32 pm ]
Post subject:
Sorry I haven't posted anything yet, I've been working 11 hour days lately, and haven't been up to it. Soon I promise. I've already written myself a stack and a queue class Damn turing's lack of an STL.

Author:	StarGateSG-1 [ Sat Mar 19, 2005 11:39 am ]
Post subject:
Quote: There is a certain amount of mental maturity that is seperate from years of programming experience. Some of this maturinty is physical and some has to with other educational experience (mainly math) I only said that becasue at my school we have a great teacher, and he is buddy with Tom West, so even comes and visit , and we always get like the newest version before the board. Our school it a trade school so we have a lot of programing courses not just a few bits and pieces. On top of that our school has well trained programers because all of the higher grades peer-tutor the lower ones, Always. I just got a little ticked off because you lumped all grades people together.

Author:	TokenHerbz [ Wed Oct 26, 2005 4:13 am ]
Post subject:
O M F G ??? i use mass proc's?? is that bad?

Author:	[Gandalf] [ Wed Oct 26, 2005 4:40 am ]
Post subject:
Matters what you mean by proc. In Turing procedure = proc, process = process.

Author:

beard0 [ Wed Oct 26, 2005 11:13 am ]

Post subject:

Martin, I know I'm somewhat late, but a perfect example of a program that requires a process:

code:

var connected := false
var userString := ""
var ch : string (1)
var stream : int
var inAddr : string

process GetConnect
stream := Net.WaitForConnection (3942, inAddr)
connected := true
end GetConnect

fork GetConnect

loop
if hasch then
getch (ch)
userString += ch
end if
exit when connected
end loop

if stream > 0 then
if userString = "" then
put : stream, "The user did not enter anything."
else
put : stream, userString
end if
end if

Otherwise, I agree that processes should not be used - Net.WaitForConnection is the only legitimate use I see for them.

Author:	[Gandalf] [ Wed Oct 26, 2005 11:30 am ]
Post subject:
Or if you want to play Turing's music (ie. play()) in the background. If you are playing it from a file, anything like Music.PlayFileLoop() will work without a process.

Author:

beard0 [ Wed Oct 26, 2005 11:57 am ]

Post subject:

For my high scool programming class we used the old DOS Turing. I wanted to have background music in my final project which meant, in the DOS version, using play("abcd") etc. The problem was that the play command returned as it began to play the last note only. Thankfully, we were graced with a function playdone, which allowed me to do this:

code:

var music : string := ">8gf+fe-4e8<g+a>4c8ac4d<"
var place := 1
proc background
if playdone then
play (music (place))
place += 1
if place > length (music) then
place := 1
end if
background
end if
end background

And then I placed a call to background all throughout my code. This way, I only ever played one note at a time, so the call returned instantly.

Note: this does not work under windows turing - it executes, yes, but doesn't sound right. Under the old DOS Turing though, it gave my program great background music.

Author:	[Gandalf] [ Wed Oct 26, 2005 2:01 pm ]
Post subject:
Interesting, good old DOS Turing . The reason why it doesn't sound correctly is because when OOT plays a sound, the last note is always cut off. Overall, Turing's music capabilities suck as much as or more than it does in all aspects .

Author:

beard0 [ Wed Oct 26, 2005 2:50 pm ]

Post subject:

Yeah, I know about the last note cut-off. It also cuts off the last note before a rest ("p"). In DOS it cuts off the last note played in the program. Such that somehow, only the final c of the second scale would be cut off in the program below. I have no idea how it managed to accomplish that. :shock:

code:

play("cdefg>abc<")
play("cdefg>abc<")

Author:	jrblast [ Wed Jan 18, 2006 9:56 pm ]
Post subject:
[Gandalf] wrote: Personally, I have never had to use proccess' except for music - just stick to procedures. Same ...But till now i didnt really know there was a difference I guess thats what happens when you rush through everything skipping the unnescessary basics... Oh, and I used to think fork is supposed to do that o.O

Author:

Anonymous [ Tue May 30, 2006 9:14 pm ]

Post subject:

Well one thing that helps a process is a delay. Look what this does compared to Cervantes program on the first page:

code:

process greetings (word : string)
loop
put word
delay(1)
end loop
end greetings

fork greetings ("Hi")
fork greetings ("Ho")

[/code]

Author:	Tony [ Tue May 30, 2006 9:24 pm ]
Post subject:
something a bit more interesting on processes

Author:	Bored [ Tue Jun 13, 2006 2:40 pm ]
Post subject:
Well I just finished reading this argument and would like to offer to you a program I recently made that I actually felt justified in using a process (not the process DrawVariables, that was just lazyness and I'll be fixing that). Martin if you are still dead set againsts proceces I would like you to try and make this program without them yet allow for the capabilities that mine has, the ease of adding into another program, and the ability to run in parrallel with any runtime program without having to alter either program. although it is not yet finished I do beleive it is a great example of the correct use of processes.

Author:	isaiahk9 [ Thu May 01, 2008 6:29 pm ]
Post subject:	Re: Why You Should Avoid Processes
Wait a minute! Processes being evil would explain why my main menu in my game is still malfunctioning. But I have 2 questions on how to avoid processes : 1. What if I need a ) music playing b ) a random integer is called (in an infinite loop) and according to the number between 1 and six, one of six animations will run. One animation has sound. c ) an infinite loop asking the user to click whichever button he wants on the menu 2. And, a larger problem for my game, I need going : a ) two processes things for people controlling their avatars b ) gravity simultaneously going c ) items to randomly appear from the sky d ) music to play e ) background to load over and over again (its animated) Whoever has player Super Smash Brothers, or fighter games in general would get the picture. If anybody could help me it would be much appreciated. If you do help me, your name will be listed in the credits and so will anyone you reference. Thanx

Author:	r691175002 [ Thu May 01, 2008 6:47 pm ]
Post subject:	Re: Why You Should Avoid Processes
I have yet to find a situation where a process is justified other than for blocking IO or if you need to take advantage of multiple cores (And that should only be done if you know what you are doing). IMO It is a bad idea to start tossing threads at every problem if you don't even know what a mutex or race condition is, even if the language cleans up after you.

Author:	Vermette [ Fri May 02, 2008 10:43 am ]
Post subject:	RE:Why You Should Avoid Processes
Here's a good question to ask then: Does Turing support a built in mutex facility? If no explicitly, then what operations (if any) are atomic to create a semaphore or some other kind of interprocess communication?

Author:	hahd [ Fri Jan 28, 2011 5:24 pm ]
Post subject:	RE:Why You Should Avoid Processes
um processes arent tht bad, they worked out fine on my christmas card but terminating a process at the right time might be a bit trick for that in turing you are welcome to use the return command which immediately exits a process. But View.Update.Area works like a charm as well. I used a combination of both in my christmas card however if i were redo i would do it without process.

Author:	Insectoid [ Fri Jan 28, 2011 5:57 pm ]
Post subject:	RE:Why You Should Avoid Processes
Did you even read the thread? Turing's processes are purest evil, at least because it prevents students from learning consecutive programming.

Author:

goroyoshi [ Wed May 11, 2011 6:45 pm ]

Post subject:

jamonathin @ Tue Feb 22, 2005 8:13 pm wrote:

You have to give the bullet's their own variables. 'x' and 'y' are already used by the "shooter" and so by adding to the y-value, you're changing where the shooter is. This is what i came up with. .

code:

I see a problem with this code, if you want to put a delay in it then all gets slowed (prove me wrong, I tried to to that) what if the bullets are supposed to be faster than the person shooting them

Author:	Tony [ Wed May 11, 2011 6:57 pm ]
Post subject:
goroyoshi @ Wed May 11, 2011 6:45 pm wrote: what if the bullets are supposed to be faster than the person shooting them Then you set a faster per-frame velocity.

Author:	goroyoshi [ Sun Jun 19, 2011 9:24 am ]
Post subject:	RE:Why You Should Avoid Processes
my friend's ISP for grade 9 (actually a grade 10 course) was a jigsaw puzzle, he told me that he had to use processes

Author:	Insectoid [ Sun Jun 19, 2011 10:43 am ]
Post subject:	RE:Why You Should Avoid Processes
He did it wrong then.

Author:	Raknarg [ Thu Jun 23, 2011 10:27 am ]
Post subject:	RE:Why You Should Avoid Processes
This has probably been said already, but i don't want to read.... Procedures can do the literally the EXACT SAME THING as processes, but without all the unpredictability.

Author:	andrew. [ Thu Jun 23, 2011 6:49 pm ]
Post subject:	RE:Why You Should Avoid Processes
Not literally the exact same thing. Processes are supposed to work concurrently, while procedures are supposed to be...well..procedural. The implementation in Turing isn't that good though so processes are horrible and unpredictable.

Author:	Tony [ Thu Jun 23, 2011 7:35 pm ]
Post subject:	RE:Why You Should Avoid Processes
Of course you can't possibly get true concurrency on a single CPU; only switch between threads. In Turing, for the most part, you are better off writing your own "thread switching". It guarantees better scheduling, and much more importantly -- synchronization of cls and View.Update. The only problem are blocking calls; but those could be gotten around by using non-blocking I/O methods.

Author:

Gadd [ Thu Mar 15, 2012 11:33 am ]

Post subject:

RE:Why You Should Avoid Processes

Although... you can tell a procedure when to be used. So why not use a procedure instead?

code:

procedure p_input
%The input of the user
end p_input

procedure p_process
%The processing of the program
end p_process

procedure p_output
%All of the output in the program
%Just an example
end p_output

p_input
p_process
p_output
%where all of these are displayed in the order %you tell them to be

You can syndicate this boards posts using the file backend.php or view the topic map using sitemap.php.

Terms of Use | Privacy Policy