Computer Science Canada

It just wont hit!

Author:

Remm [ Wed May 24, 2006 3:33 pm ]

Post subject:

It just wont hit!

Alright - i have a little problem here in my process:

code:

process jetspawn
View.Set ("offscreenonly")
delay (500)
loop
chance := 0
chance := Rand.Int (1, 2)
if (chance = 1) then
jx1 := maxx + 6
jy1 := maxy - Rand.Int (60, 150)
for jetmove : 1 .. 70
chance := Rand.Int (1, 20)
Pic.ScreenLoad ("bigjet.left.bmp", jx1, jy1, picMerge)
delay (55)
Pic.ScreenLoad ("removejet.bmp", jx1, jy1, picCopy)
exit when (tmovex > jx1) and (tmovey > jy1) and (tmovex < jx1 + 80) and (tmovey < jy1 + 32)
jx1 := jx1 - 5
end for
Pic.ScreenLoad ("explosion.bmp", jx1, jy1 - 17, picMerge)
delay (700)
cls
delay (2000)
elsif (chance = 2) then
jx1 := 0 - 16
jy1 := maxy - Rand.Int (60, 150)
for jetmove : 1 .. 70
chance := Rand.Int (1, 20)
Pic.ScreenLoad ("bigjet.right.bmp", jx1, jy1, picMerge)
delay (55)
Pic.ScreenLoad ("removejet.bmp", jx1, jy1, picCopy)
exit when (tmovex > jx1) and (tmovey > jy1) and (tmovex < jx1 + 80) and (tmovey < jy1 + 32)
jx1 := jx1 + 5
end for
Pic.ScreenLoad ("explosion.bmp", jx1, jy1 - 17, picMerge)
delay (700)
cls
delay (2000)
end if
end loop
end jetspawn

The problem is, the exit when statement is prone to not working. I can gun down... about 1/3 of the ones i shoot at and others will just take the bullets as if it was nothing >.<. Any ideas?

Author:	Remm [ Wed May 24, 2006 3:35 pm ]
Post subject:
erm, sorry to double-post but also, when the ship is above my gunner tower, it explodes automatically. Would that just be a problem with my variables or..?

Author:	upthescale [ Wed May 24, 2006 3:59 pm ]
Post subject:
y ru using a process?

Author:	Anonymous [ Wed May 24, 2006 4:04 pm ]
Post subject:
Processes are the simplest way to do multiple things at once. Say you have a shooter and want to shoot more than one thing at a time before it hits an object while determining if it hits the object, best way is to use a process =) Or for example playing Music while other code is excecuting. Most people on these forums are against processes though because they do not run concurrently =( But in some cases they run fine.

Author:	Delos [ Wed May 24, 2006 4:19 pm ]
Post subject:
vahnx wrote: Processes are the simplest way to do multiple things at once. Erm...I'm going to challenge you on that one. I really don't like the use of the word "simplest" in there. Concurrency is, essentially, an optical illusion. We all know that a computer is only ever capable of doing one task at a time - and that it creates concurrency by switching between groups of tasks at extremely high speeds. This, to the human eye, is concurrency. Processes in Turing take its already ineffcient memory management and divvies it up between tasks. The reason it is so widely disliked is that Turing is not particularly good at giving equal screen-time to the processes. A work around that most people use is to rely on the fact that computers can do things far faster than humans can perceive, an as such can create those illusions I mentioned earlier. In this spirit, one would usually create a number of methods, each of which would be called within a main loop. The key here is to ensure that each method doesn't do too much. Thusways, it will return from it in good time, and move on to the next one. These all moving as fast as they do would resemble concurrency as well as using processes would - and even better in that you would have more control over them. As Tony has demonstrated in the tuts section, Processes do work, but it takes a lot of know-how and theoretical knowledge to get them there. This, I would assert, is by no means "easy".

Author:

Remm [ Wed May 24, 2006 4:20 pm ]

Post subject:

Vahnx....
Um, The best way to shoot multiple bullets is NOT a process, i know that for a fact after acually trying it. Processes are bad and evil, since if you have multiple processes, they all run at basically random intervals. (the reason, i forget.)

code:

process a
for c : 1..80
put "Fuzzy"
end for
end a

process b
for d : 1..80
put "Cow"
end for
end b

fork a
fork b

run that and you'll see what I mean. I'm using a process because i already have a procedure going; cant do two of those at once...

Author:

HellblazerX [ Wed May 24, 2006 4:47 pm ]

Post subject:

Remm wrote:

erm, sorry to double-post but also, when the ship is above my gunner tower, it explodes automatically. Would that just be a problem with my variables or..?

code:

exit when (tmovex > jx1) and (tmovey > jy1) and (tmovex < jx1

From the looks of it, the exit conditions are when the jet is just above the your tower, and when you exit the for loop, you reach the code where the explosion is drawn. Thus, your jet explodes when its over your tower. The question about you not hitting the planes, well, you'll have to check the portion of your code where you did the collision detection, and this doesn't look like collision detection.

Author:

Anonymous [ Wed May 24, 2006 4:52 pm ]

Post subject:

Convert This

Here is a small shooter the teacher made using processes. Can you convert it so you don't use a process?

code:

%This program fires bullets

var x : int := 30
var y : int := 30
var badx : int := 500
var bady : int := 300

var keys : array char of boolean

var reload : int := 5

View.Set ("offscreenonly")

Draw.FillBox (0, 0, maxx, maxy, black)
Draw.FillBox (badx, bady, badx + 30, bady + 100, 78)

%This process moves one bullet across the screen
process bullet (x : int, y : int)
var bulletx : int := x %the position of the bullet
var bullety := y

loop
Draw.FillOval (bulletx, bullety, 2, 2, red) %draw the bullet
Draw.FillOval (bulletx, bullety, 2, 2, black) %erase the bullet
Draw.FillOval (bulletx + 3, bullety, 2, 2, red)
bulletx += 3 %move the bullet forward
%exit the loop when the bullet hits the bad guy or is off the screen
exit when (bulletx > maxx or (bulletx > badx and (bullety > bady and bullety < bady + 100)))
end loop

%IF there was a hit, make an exposion!
if (bulletx > badx and (bullety > bady and bullety < bady + 100)) then
Draw.FillOval (bulletx, bullety, 10, 20, red)
end if

end bullet %end of the process

%main program
loop
Input.KeyDown (keys) %get info from the keys (or joystick)

if (keys (KEY_UP_ARROW)) then
y += 1
end if
if (keys (KEY_DOWN_ARROW)) then
y -= 1
end if
if (keys (KEY_ENTER) and reload >= 10) then %reload makes sure not too many bullets are
reload := 0 %fired at once.
fork bullet (x, y)
end if

reload += 1
Draw.FillOval (x, y, 20, 20, green) %draw the good guy
View.Update %update the screen
Draw.FillOval (x, y, 20, 20, black) %erase the good guy
end loop

Author:	Delos [ Wed May 24, 2006 7:33 pm ]
Post subject:
Replicate...? Nah. I did, however, a while back make this. No processes at all used - though at the same time I didn't use Classes. This was before I was introduced to that beautiful world in full force by Cervantes' 3-part epic. But again, no processes.

Author:

HellblazerX [ Wed May 24, 2006 8:09 pm ]

Post subject:

code:

%This program fires bullets

type bullet :
record
x : int
y : int
alive : boolean
end record

var MAX_B := 0
var b : flexible array 1 .. MAX_B of bullet
var x : int := 30
var y : int := 30
var badx : int := 500
var bady : int := 300

var keys : array char of boolean

var reload : int := 5

View.Set ("offscreenonly")

Draw.FillBox (0, 0, maxx, maxy, black)
Draw.FillBox (badx, bady, badx + 30, bady + 100, 78)

procedure bullets
if MAX_B > 0 then
for i : 1 .. MAX_B
if b (i).alive then
Draw.FillOval (b (i).x, b (i).y, 2, 2, black)
b (i).x += 3
Draw.FillOval (b (i).x, b (i).y, 2, 2, red)
if b (i).x > badx and (b (i).y > bady and b (i).y < bady + 100) then
b (i).alive := false
Draw.FillOval (b (i).x, b (i).y, 10, 20, red)
end if
end if
end for
end if
end bullets

%main program
loop
Input.KeyDown (keys) %get info from the keys (or joystick)

if (keys (KEY_UP_ARROW)) then
y += 1
end if
if (keys (KEY_DOWN_ARROW)) then
y -= 1
end if
if (keys (KEY_ENTER) and reload >= 20) then %reload makes sure not too many bullets are
reload := 0 %fired at once.
MAX_B += 1
new b, MAX_B
b (MAX_B).x := x
b (MAX_B).y := y
b (MAX_B).alive := true
end if

reload += 1
bullets
Draw.FillOval (x, y, 20, 20, green) %draw the good guy
View.Update %update the screen
Draw.FillOval (x, y, 20, 20, black) %erase the good guy
end loop

See, no processes. Also, you'll notice my bullets shoot at a regular interval, whereas yours do not.

Author:	TheOneTrueGod [ Wed May 24, 2006 9:39 pm ]
Post subject:
Heres one: http://www.compsci.ca/v2/viewtopic.php?t=11927 Made by me a couple weeks ago. Theres gotta be like 15 on this site (I'm probably exaggurating by 10, but eh) that are better than that, all without processes. When I say better, I mean they run at "optimal" speed throughout execution. (In mine there are periods of lag as you reach higher levels, but eh) In your teachers, your character slows down immensly as you have more bullets on the screen, and bullets don't fire at an even rate. Generally, unless you REALLY know what you are doing, processes should be avoided. Something you COULD use processes for is a constant display thing, like a clock, in the lower left hand corner of the screen. But I digress.

Author:	Anonymous [ Wed May 24, 2006 10:13 pm ]
Post subject:	Differences
Removing all spaces and comments, Process took 40 lines, Procedure took 54. Process : -smaller ammount of code -runs while other statments excecute -less control Procedure: -more code -waits until procedure excecutes -more control Both games act the same pretty much, except the process shoots more randomly, and the procedure shoots at a fixed rate.

Author:	Clayton [ Wed May 24, 2006 10:21 pm ]
Post subject:
also, if you, for whatever reason, dont have Music.PlayFileReturn on your version of turing you can use processes for music

Author:	Remm [ Thu May 25, 2006 7:04 am ]
Post subject:
Quote: From the looks of it, the exit conditions are when the jet is just above the your tower, and when you exit the for loop, you reach the code where the explosion is drawn. Thus, your jet explodes when its over your tower. The question about you not hitting the planes, well, you'll have to check the portion of your code where you did the collision detection, and this doesn't look like collision detection. Well i have no idea what else to use as collision detection Any ides? And btw, revert from your process-procedure rants and answer the question at hand. Processes are bad, evil, and messy. End of story.

Author:	Remm [ Thu May 25, 2006 7:45 am ]
Post subject:
Ok; the colision works fine now, it was the delay between the exit when and such. Every time i shot, there was a good chance i'd pass over the ship whilst it was delaying. So, i devised a code that checks if it should exit for EVERY delay of 1 (a milisecond i think) Its like 200 lines of repedative nonsense put into a procedure, but it works damn well. Now, about the invisible wall...

Author:	NikG [ Thu Jun 01, 2006 11:26 pm ]
Post subject:	Re: Differences
vahnx wrote: Both games act the same pretty much, except the process shoots more randomly, and the procedure shoots at a fixed rate. Remm wrote: revert from your process-procedure rants and answer the question at hand. Sorry Remm, last one. vahnx, you act as if that random shooting is a minor thing. The control you get from using procedures more than offsets the advantages from using processes. Processes are an unneccessary (and as Remm put it: evil) coding shortcut.

Author:	Clayton [ Thu Jun 01, 2006 11:49 pm ]
Post subject:
the only real and true use for processes would be for use in a network program where each client had to send data seperately apart from the other.

Author:	Remm [ Fri Jun 02, 2006 9:28 am ]
Post subject:
!? this thread is still active? gotta love those Procedure VRS Process debates Anyways, as said in my other topic, its all done and over with - im on to new coding in the program - like different jets Now, back to the debate Quote: the only real and true use for processes would be for use in a network program where each client had to send data seperately apart from the other. I must disagree. My Final Gunner program has about as many processes as procedures, due to the fact that I need so many things running at the same time. Although it is random, that doesnt matter in some cases due to the liniar-ness and how much the code is stand-alone from other parts of the program. with gun movement as my procedure and gun firing, two jet spawns that drop para-bombs(another process), all with more processes and procedures inside, it runs flawlessly. I guess its all how you use it. trying to get two lines of text to output one after the other every time - and MANY MANY more situations - you will NOT use processes ----However, in some cases they can work great. ------A nessicery evil?

Author:

HellblazerX [ Fri Jun 02, 2006 10:28 am ]

Post subject:

Remm wrote:

I must disagree. My Final Gunner program has about as many processes as procedures, due to the fact that I need so many things running at the same time.

You're still not understanding why processes are used. Processes should only be used when you running two things that need to be separate of each other, like SuperFreak said, in a network. See, your program shouldn't have parts that are separate of each other. The planes and bullets must be in sync for proper collision detection, your keyboard input and gun turret movements should be in sync for proper control. A basic layout for any game should be like this:

Pseudo:

loop
get user input
make changes to game
render the images
end loop

Remm wrote:

it runs flawlessly

Really, what about efficiently? You realize that Turing processes are inefficient and poorly implemented. A good program should run not only flawlessly, but efficiently too.

Author:	NikG [ Sat Jun 03, 2006 12:05 am ]
Post subject:
Looks like the debate is picking up again.

Author:	Remm [ Sun Jun 04, 2006 12:17 pm ]
Post subject:
Well on my school computers it runs at full speed with no glitches, errors or such, but since i have so much going at once and a good number of infinate loops, on good computers it will run slowly. Not much i can do about that, but yes everything works well. The shoot and collision detc are both processes and they work fine

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

Terms of Use | Privacy Policy