One other small thing. You don’t need pushStyle and popStyle unless you are changing things like colours, line widths etc. I guess you could say pushMatrix takes care of physical movements like translation and rotation, and pushStyle takes care of your makeup
@RonJeffries Yes, the <= is automatic, just like a bunch of other things that I do. The “a,b” in the for statement is also automatic. I don’t think I’ve ever used the _ for a variable name in anything I’ve ever coded. I think my coding now is more out of habit than thinking about what I do.
Just for fun, here is an object-oriented version. I added some random rotation.
--# Asteroid
Asteroid = class()
function Asteroid:init(x)
self:prime()
end
function Asteroid:prime()
self.x = math.random(0,WIDTH)
self.y = HEIGHT
self.speed = math.random(3,7)
self.rot = math.random()*2*math.pi
self.rotadd = math.rad(math.random(30,90) - 60)
end
function Asteroid:draw()
pushMatrix()
pushStyle()
translate(self.x,self.y)
rotate(self.rot)
sprite("Space Art:Asteroid Small",0,0)
popStyle()
popMatrix()
self.y = self.y - self.speed
self.rot = self.rot + self.rotadd
if self.y <= 0 then
self:prime()
end
end
--# Main
-- Galaga
function setup()
asteroids = {}
for i = 1,6 do
table.insert(asteroids, Asteroid())
end
end
function draw()
background(40, 40, 50)
for _,asteroid in pairs(asteroids) do
asteroid:draw()
end
end
@RonJeffries - a small thing, but if you write sprite("imagename"..), Codea has to load the image from disk 60 times a second. It’s better to readImage into a variable as part of setup, and sprite that (from memory instead of disk).
@infiltration265 I’m not sure what you think is wrong with your code. The asteroids move down the screen and when they reach 0, another one is created at the top in a random x position. Here is the same code using a table. What is you code not doing that you think it should.
displayMode(FULLSCREEN)
function setup()
tab={}
for z=1,6 do
table.insert(tab,vec3(math.random(0,WIDTH),HEIGHT,math.random(3,7)))
end
end
function draw()
background(40,40,50)
for a,b in pairs(tab) do
sprite("Space Art:Asteroid Small",b.x,b.y)
b.y=b.y-b.z
if b.y<=0 then
b.x=math.random(0,WIDTH)
b.y=HEIGHT
end
end
end
On the pushStyle() I do know that but do them as a matter of standard practice. I debated with myself whether to leave them in so that Infiltration would know about them or leave them out as unnecessary in this case. One side lost
As an extension of my image comment, if you have a scene where several images (or shapes) never change position, it pays to draw them all to an image in memory (using setContext), and just sprite that image in draw. Works nicely for custom backgrounds.
My opinion is that if you’re going to write a class for others to use, then you should use push and pop so that your draw function isn’t affected by the settings made outside of your class. There are a lot of interesting little hints that people share every now and then. I wonder if a discussion should be started to list these as we go along. I looked in the Wiki and didn’t see anything unless I missed it. For example use an _ for a non used variable, readImage into a variable instead of sprite(“imagename”), etc. No big explanations, just small hints that people come across.
I agree on its not being needed. I’m developing the habit of doing both, for a reason:
Suppose we have our “coding standard” be always to use both. Then no matter how we may change our actual draw, nothing can ever screw up the other guys. We pay a tiny performance penalty, perhaps even measurable if you are a god of metrics.
If, on the other hand, we put in only the one we need, and we subsequently change the drawing code (which I do frequently as a program evolves) then we must, on each edit, decide whether we need to add the calls. If we get it wrong … bad stuff happens.
My style is to develop safe habits that require me to think as little as possible. As my colleague Chet Hendrickson says “A mind is a terrible thing to waste – so use yours sparingly.”
Other styles are certainly possible. Everyone gets to make their own tradeoffs.
One more thing. Many of my programs are turning out to have a main draw: either in Main or in some Universe class, that has all the objects and draws them. The example Dave did above, as well as mine, are examples. In that case, I am leaning in the direction of putting the pushes and pops in that master loop, so that the convention is that the individual draws do not have to do them (unless they want yet another push for some reason). That will make the coding of the individual draws simpler and reliable. So I think that’ll be a good habit to develop. We’ll see. Of course if it isn’t, I’ll stop doing it.
@RonJeffries We don’t have any coding standards. It’s up to each person to code correctly if they’re going to release an app. As for our examples here, just about anything goes as long as it works.
I expect that everyone has their own coding standard. When people are beginners, their standard is usually a bit weak, because they do not as yet know what works for them and what does not. Thus it is my practice to show people what I do and explain why I do it.