Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Bug

edited October 2014 in Bugs Posts: 19

All the Astroids are disappearing, and all sorts of stuff happens. Could sombody tell me what I did wrong???

-- Galaga

-- Use this function to perform your initial setup
function setup()
--Astroid rsm
--x 
Astroid1X = math.random(0,WIDTH)
Astroid2X = math.random(0,WIDTH)
Astroid3X = math.random(0,WIDTH)
Astroid4X = math.random(0,WIDTH)
Astroid5X = math.random(0,WIDTH)
Astroid6X = math.random(0,WIDTH)


AstroidStartingY = HEIGHT --moves down,animation in draw function

Astroid1Speed = math.random(3,7)
Astroid2Speed = math.random(3,7)
Astroid3Speed = math.random(3,7)
Astroid4Speed = math.random(3,7)
Astroid5Speed = math.random(3,7)
Astroid6Speed = math.random(3,7)

Astroid1Y = AstroidStartingY
Astroid2Y = AstroidStartingY
Astroid3Y = AstroidStartingY
Astroid4Y = AstroidStartingY
Astroid5Y = AstroidStartingY
Astroid6Y = AstroidStartingY

end
function draw()

Astroid1Y = Astroid1Y-Astroid1Speed
Astroid2Y = Astroid2Y-Astroid2Speed
Astroid3Y = Astroid3Y-Astroid3Speed
Astroid4Y = Astroid4Y-Astroid4Speed
Astroid5Y = Astroid5Y-Astroid5Speed
Astroid6Y = Astroid6Y-Astroid6Speed

    if Astroid1Y == 0 then
        Astroid1Y = AstroidStartingY
        Astroid1X = math.random(0,WIDTH)
    end

        if Astroid2Y == 0 then
        Astroid2Y = AstroidStartingY
        Astroid2X = math.random(0,WIDTH)
    end

        if Astroid3Y == 0 then
        Astroid3Y = AstroidStartingY
        Astroid3X = math.random(0,WIDTH)
    end

        if Astroid4Y == 0 then
        Astroid4Y = AstroidStartingY
        Astroid4X = math.random(0,WIDTH)
    end

        if Astroid5Y == 0 then
        Astroid5Y = AstroidStartingY
        Astroid5X = math.random(0,WIDTH)
    end

        if Astroid6Y == 0 then
        Astroid6Y = AstroidStartingY
        Astroid6X = math.random(0,WIDTH)
    end


    -- This sets a dark background color 
    background(40, 40, 50)

    -- This sets the line thickness
    strokeWidth(5)

    -- Do your drawing here
    sprite("Space Art:Asteroid Small",Astroid1X,Astroid1Y)
    sprite("Space Art:Asteroid Small",Astroid2X,Astroid2Y)
    sprite("Space Art:Asteroid Small",Astroid3X,Astroid3Y)
    sprite("Space Art:Asteroid Small",Astroid4X,Astroid4Y)
    sprite("Space Art:Asteroid Small",Astroid5X,Astroid5Y)
    sprite("Space Art:Asteroid Small",Astroid6X,Astroid6Y)
end

Comments

  • dave1707dave1707 Mod
    Posts: 7,554

    @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
  • When I run my code, the astroids disapear and stop and all kinds of wierd stuff. I will try your's and see how it does. thanks!

  • try changing == 0 to <= 0. i think they are not coming out exactly 0

  • edited October 2014 Posts: 19

    It worked perfectly, Thanks sooooo much. @dave1707

  • @RonJeffries How could I not have noticed that!?! Thanks Again

  • edited October 2014 Posts: 343

    i note in the table example, dave typed <=. we would mostly do that automatically. that was the bug in the original.

    also in the table example, i'd recommend for _,b in pairs(tab) since the first value is not used. helps keep me from looking to see where it's used :)

  • IgnatzIgnatz Mod
    Posts: 5,396

    @RonJeffries, for formatting in line code, you can use the tick mark ` (under ~ on the keyboard). I fixed your comment above.

  • dave1707dave1707 Mod
    Posts: 7,554

    @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
  • edited October 2014 Posts: 343

    Of course the rot is screwed up because I've been working in radians all day, but rotate() is degrees. Grrr, sorry. Try


    self.rot = math.random(180) self.rotadd = math.random(20) - 10
  • IgnatzIgnatz Mod
    Posts: 5,396

    @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).

  • IgnatzIgnatz Mod
    Posts: 5,396

    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 ;)

  • Thanks on the sprite: didn't know that.

    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 :)

  • IgnatzIgnatz Mod
    Posts: 5,396

    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.

  • dave1707dave1707 Mod
    Posts: 7,554

    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.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Of course you'll use push and pop in a class, but there's not need for pushStyle if you're not changing any styles

    The FAQ is a good place for hints, about time it was updated with useful stuff

  • 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. :)

  • dave1707dave1707 Mod
    Posts: 7,554

    @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.

    What others do is up to them, entirely.

  • IgnatzIgnatz Mod
    Posts: 5,396

    I prefer to put the push/pop in the class draw functions, because otherwise one class may mess up the styles or matrix settings for the others.

    For example, if you translate, that is normally specific to one object or class, and you need to undo it before you go drawing other stuff elsewhere

    I think it's consistent with the principle of keeping scope as local as possible, that custom settings should also be kept as local as possible.

  • dave1707dave1707 Mod
    Posts: 7,554

    @RonJeffries You're going to be a big help to the new coders. They need a lot of explaining sometimes. As for me, I never commented my code as a professional and I don't comment my code here either. Only if someone asks for something specific. I always told my boss, the code is the comments.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Once your code gets past a page, though, comments begin to be important.

    I once saw advice that said comments are not there to explain what you're doing - clear code should make that obvious - but why you're doing it. To me, it's plain common sense that you comment anything that isn't obvious and which would be confusing otherwise.

  • dave1707dave1707 Mod
    Posts: 7,554

    @Ignatz I always coded things as simple as I could, that helped with updates. My function names said what the function was for along with the variable names.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Yes, but that doesn't always explain why you use the formula you did, where it came from, how a function is used elsewhere, how the code hangs together, etc

    If someone else has to read a pile of code, an "executive summary/outline" is extremely useful, just as it is in a report

    From my own experience, with Codea and previously, judicious comments are extremely helpful

  • I was taught that a comment is the code's way of asking to be made more clear. You can do a lot with intention-revealing names and good simple code. I try never to write anything that isn't obvious. Part of that is writing the same kind of thing the same way every time.

    Except, of course, that one tries different approaches, to learn new things, to try new styles, to hone and improve one's skills. Or just for fun. :)

  • dave1707dave1707 Mod
    Posts: 7,554

    I agree with you, comments are helpful. They explain what you're doing, and I think the new coders should use them. I just didn't use them. I managed to make it to retirement without them, that's all that matters.

  • Comments explaining the code are mostly evidence that the code is unclear, IMO. Explaining meta-decisions, or sources of algorithms, or the like, sure, that's another thing.

    I try to make the code tell as much of the story as it can. If it can't , and the story needs to be told, then one tells it some other way. Your articles, Ignatz, are good examples of how to do that.

    In the past, I've written long narratives explaining the development of a program from beginning to end. Adventures in C# is an entire book done that way. Way out of date now , sad to say. Maybe I'll do some like that as I push forward with Codea.

  • dave1707dave1707 Mod
    Posts: 7,554
  • Yes, the published book, all zillion pages.. Very obsolete now, though the thought process, how I learn a new language, is probably still good. But C# is quite different now. And M$ basically never pushed any of the books in that series. Ah well. :))

  • And all those articles are lost somewhere in a wordpress failure now. Just as well, perhaps.

  • IgnatzIgnatz Mod
    Posts: 5,396

    Code Complete is a pretty good resource for new programmers

  • Code Complete is good stuff but rather dated IMO. I'd suggest Clean Code by Bob Martin, I think.

  • dave1707dave1707 Mod
    Posts: 7,554

    @RonJeffries I looked up Clean Code and found a PDF version of it. I don't think a new coder is going to read 462 pages, especially when they don't want to read the tutorials we point out to them here. By the way, I saw the reference to you in the book.

  • @dave1707 — I agree, most people (such as myself) don't like reading long books to learn something (well, most teenagers don't).

  • Well, Dave, people can try to learn however they want. And if they're here just to have fun, it surely doesn't matter much. If they're interested in finding positions in industry, getting paid for programming, there are still lots of ways to get there.

    You and I have very different programming styles, it appears. Yet, I'll bet that we'd find some very significant similarities if we looked. They would probably revolve around using the power of the language well, around simplicity, around avoiding duplication, and so on. The things formalists call coupling and cohesion. We might approach those things differently but would still be doing similar kinds of things in similar ways ... because they work.

    To get good at programming, one needs to program -- a lot. Practice, practice, practice. But there's more. We need to see different ways of doing things. We need to learn better ways -- and we'll surely learn worse ways. And we need to learn to distinguish between the better and the worse.

    We learn a lot by reading code. When we read code, we can learn from the experience of the person or persons who wrote it. If we read only our own, we're always reading the code of someone no more experienced than we are. If we read lots of people's code, we see more options and many of them will be better than what we've discovered on our own, so far. (Many may not be: experienced programmers are not necessarily good ones. There's good money to be made in cleaning up old code messes if you can stand the smell.)

    We can read examples. Dave's examples here are great and they are many. Ignatz's as well. Probably there are others here whom I have just not found yet. Examples are nice because they can give us an isolated view of a clean solution to a single problem. That makes it much easier to learn.

    And we can learn from principles. I can usually explain why I do things the way I do, because I've spent years trying to help people learn to be better programmers. So I had to think about what I did, why I did it, why it worked -- or didn't work.

    My Adventures in C# book (not recommended here) is unique in that it is a huge book showing how I developed a large program, and it includes every single mistake I made. Try this, fail, try that. It tried to show what programming is really like, when you're learning as you go.

    To me, programming is full of lessons that come with the fun (and with the frustration). "Well, not gonna do THAT again," is the sign of learning. :)

    So, what's my point? Folks can read books on programming if they want to, and they'll learn a lot if they read good ones. Or they can find a friendly forum and separate the wheat from the chaff in the help. Or they can sit down with a pal. Or work on their own. Practice, study, pay attention.

    In the end, we get better when we learn what works well, what doesn't work so well, and why. We can get there on our own, or with help. I'm happy to have help. :)

    And yeah, I'm in some books. Including a few I wrote. And don't buy my new one, The Nature of Software Development expecting a programming book. It's way more abstract than that. Some people really like it. I like it fairly well, it nearly says what I was trying to say. :)

  • IgnatzIgnatz Mod
    Posts: 5,396

    Ron, I see you are expert in extreme and agile programming. I'm sure we can benefit from all that experience in this forum, especially in helping the younger users who are still at school and who haven't had the chance of any formal training.

  • Well, ignatz, I've been around a long time and have a bit of fame in this small pond. I try to help when I can. As you've already seen, you and Dave, among others, know more than I do about Codea and Lua. But I will in fact try to help. :)

    Formality ... well, I don't have none of that. :)

  • edited October 2014 Posts: 91

    Looks like my CODEA Enlightenment project will be useful by extracting info from the code into views easy to read.

    I just did this with CODEA Enlightenment :

    Class Overview for Cargo-Bot
    ABCMusic = class()
    BaseSelect = class(Screen)
    BaseStage = class(Panel)
    Button = class(SpriteObj)
    ChickenBox = class(Panel)
    Claw = class(Panel)
    Command = class(Button)
    Crate = class(Panel)
    CreditsScreen = class(Screen)
    Events = class()
    Goal = class(BaseStage)
    HowScreen = class(Screen)
    IO = class()
    Level = class(Screen)
    LevelItem = class(Panel)
    LevelItemStage = class(BaseStage)
    LevelSelect = class(BaseSelect)
    Music = class()
    PackItem = class(Panel)
    PackSelect = class(BaseSelect)
    Panel = class(PositionObj)
    Pile = class(Panel)
    Popover = class()
    PositionObj = class()
    Program = class(Panel)
    ProgressBar = class(Panel)
    RectObj = class(PositionObj)
    Register = class(Panel)
    Screen = class(Panel)
    ScrollingTexture = class(Panel)
    ShadowObj = class(SpriteObj)
    ShakeDetector = class()
    Smoke = class(Panel)
    Sounds = class()
    SplashScreen = class(Screen)
    SpriteObj = class(RectObj)
    Stack = class()
    Stage = class(BaseStage)
    StageWall = class(Panel)
    StartScreen = class(Screen)
    Table = class()
    Toolbox = class(Panel)
    TransitionScreen = class(Screen)
    Tweener = class()
    WinScreen = class(Screen)
    
  • dave1707dave1707 Mod
    Posts: 7,554

    @RonJeffries I agree with everything you say. When I started to learn something new, I always bought the biggest book I could find on the subject. Normally those were "the bible" type books (1000+ pages) that had everything you could ever want to know in them. They were used as a reference, because I wasn't going to read them. Anytime I got stuck, I would look thru the book and find what I needed. I learned by trying things. I would think of different things and write code to make it happen. That's how you learn to really program. But that's not what's happening now. I think a lot of the new coders want to write that app that's going to make them rich without having to learn how to program. They're looking for the app that will write the code for them, they just want to tell the app what they want. I'm just here to have fun and help when needed. If I want to get rich, that's what the lottery is for. Unfortunatly that isn't working.

  • I have the same problem with the lottery. I recently calculated that my chances of winning the lottery by finding the winning ticket are only slightly lower than the chances of winning by buying the winning ticket. So now I just watch the ground carefully.

  • IgnatzIgnatz Mod
    Posts: 5,396

    been reading Clean Code. It is good.

    I was surprised (but also pleased) to see the advice to keep functions extremely short. Very interesting.

  • All of us Agile guys are all about short functions. Glad you're liking the book. Bob is a bit militant, and does good work.

  • IgnatzIgnatz Mod
    Posts: 5,396

    I would be terrified of letting Bob see my code! :-S

  • He's kind to people and mean to code. We all are. :)

Sign In or Register to comment.