Fixing An Incorrectly Coded Drawing Function

[Rehnrald]

My problem is, I don't see a way to make it so certain things don't draw. Love.draw() draws everything at once, in my mind at least. I am still kinda new :/.

[Rehnrald]

Thanks very much though, David. I will check out the .LOVE file tonight.

[Davidobot]

My problem is, I don't see a way to make it so certain things don't draw. Love.draw() draws everything at once, in my mind at least. I am still kinda new :/.

Love.draw only draws what you tell it to draw. Use ifs to tell the program what to draw.

[Bobbias]

I can't guarantee any code here will work. This is just to explain what is wrong and give you an idea of how to fix it.
And please, for the love of god, use consistent indentation. I don't care about the specifics, but make sure everything is indented when it's inside a block of code (if statements, loops, functions, etc. should all have the code inside them indented, and indented the same amount.)

You don't seem to understand how the love.load, love.update, and love.draw functions work. I'm going to try to give you examples of how to fix your stuff, but PLEASE go read some tutorials on game states and game loops. It's very clear from reading your code that you don't understand how they work (or how love works exactly). It's possible to write a game without understanding this stuff properly, but if you try to make something a bit more complicated than a really really basic game, it will be much easier if you've got a good understanding of game loops and game states. I'd also suggest looking at how other people handle game states in their games, because that can be very informative.

love.load is called once, in the very beginning of your game. If you define it twice, like you did (line 16, and then line 43) only one of those will ever run. In this case, because your if statement on line 14 is true, it will call the love.load on line 16, and NEVER call the love.load on line 43, where you define background, Bleft and Bright. None of those will exist, because that code will never run.

What you need to do is put ALL your loading code in one single love.load() function which should look something like this:

Code: Select all

function love.load()
    -- All this is from your first love.load
    local newGame = loveframes.Create("button")
    newGame:SetSize(TITLE.size.w, TITLE.size.h)
    newGame:SetPos(TITLE.optionsX, TITLE.optionsY)
    newGame:SetText("New Game")
    newGame.OnClick = TITLE.newGame


    local loadGame = loveframes.Create("button")
    loadGame:SetSize(TITLE.size.w, TITLE.size.h)
    loadGame:SetPos(TITLE.optionsX, TITLE.optionsY + TITLE.spacing)
    loadGame:SetText("Load Game")
    loadGame.OnClick = TITLE.loadGame

    local exit = loveframes.Create("button")
    exit:SetSize(TITLE.size.w, TITLE.size.h)
    exit:SetPos(TITLE.optionsX, TITLE.optionsY + TITLE.spacing * 2)
    exit:SetText("Exit")
    exit.OnClick = TITLE.exit

    TITLE.newGame = newGame
    TITLE.loadGame = loadGame
    TITLE.exit = exit
    --all this is from your second love.load()
    local background = love.graphics.newImage("Graphics/seven.jpg")
    Bleft = love.graphics.newImage("Graphics/Bleft.png")
    Bright = love.graphics.newImage("Graphics/Bright.png")
end

You also can't define love.update twice like you did (lines 66 and 107). The reason your loveframes buttons work is because the second love.update definition is the only one being called. It replaced the first one. Delete the second definition of love.update, and move the loveframes.update call onto the bottom of your first love.update. It should look like this:

Code: Select all

function love.update(dt)
    -- you should probably put these inside an if statement to check if you're actually playing the game
    if love.keyboard.isDown("down") then
        y = y + (speed * dt)
    end

    if love.keyboard.isDown("up") then
        y = y - (speed * dt)
    end
	
    if love.keyboard.isDown("right") then
        x = x + (speed * dt)
        Bunchie = Bleft
    end

    if love.keyboard.isDown("left") then
        x = x - (speed * dt)
        Bunchie = Bright
    end

    if love.keyboard.isDown("escape") then
        love.event.push('quit')
    end
    loveframes.update(dt)
end

Please note that you should add an if statement around the section of ifs here to check your game state. You don't want to let a player change stuff when you're in the main menu!
love.update() is where most of your game logic should probably be.

Next, you define love.draw twice. This is also a problem. love.draw is also only called once every frame, and defining it again replaces the first definition with the second. This means that the code from line 102 will never run.

To fix your drawing code, you need to do 2 things:
You need to move all your drawing code into a single definition for love.draw()
And you're going to need to check what game state you're in.

It should look something like this:

Code: Select all

function love.draw() -- friendly reminder: things are drawn in the order you actually tell it to, be careful, you can hide things by drawing on top of them.
    if gamestate == "menu" then
        love.graphics.draw(TITLE.background)
        loveframes.draw()  --if you only use loveframes in the title menu, this is ok, if you're going to use it in the rest of the game, you need to move it outside this if statement.
    end

    if gamestate == "game" then
        love.graphics.draw(background)
        love.graphics.draw(Bunchie, x, y)
    end
end

The basic idea of how love.draw() should work is that you have sections of code for every game state, using if statements to check which state you're in to determine what code should run.

You can also call other functions inside love.draw() In fact, my love.draw in something I've been working on looks like this right now:

Code: Select all

function love.draw()
    mapRenderer:update()
    -- spriteRenderer:update()
    -- hudRenderer:update()
end

I won't go into detail, but there's a whole lot more code that goes into drawing the map that you don't see here. This keeps things cleaner and easier to understand, and means I don't need to look at the code for drawing the map unless I actually need to.

[Rehnrald]

Wow, Bobbias. That is extremely informative, thanks a lot! I probably should have learned more before I pleaded for help, which I see now. I'm sorry for posting a thread asking for help when I could have easily done it myself had I studied and learned more. In the future, I will only make posts asking for help when there is something I can't see how to do anywhere else. I will work on learning more and creating cleaner code. Thanks again, everyone.

[Bobbias]

It's not a big deal. I hope I didn't come off as too harsh. It took me a good while to really grasp some of the same ideas when I was beginning to get into coding. Sometimes having those things hidden from you the way love does isn't actually helpful in the end (though it's very good that you're able to replace the love.run() any time you decide to). As long as you're willing to learn, and not just looking for something to hand you finished code for something, you're approaching programming right.

Personally, my approach to teaching myself to program involves searching for example code (whether it's from tutorials on the subject, or other things) and looking at the What, How, and Why. What I mean is that there are 3 main things you should understand when looking at someone else's code and trying to learn from it:

What the code does - A general overview of what the code actually does. For example, if you're looking at someone's code for gamestates, you'll want to know what approach they took, and what the gamestates are actually doing to the rest of the game.
How it does it - This is getting a bit deeper into things. Looking at how code does something means understanding more than just what each line of code means. It means understanding the structure of the code you're looking at, and how it actually does what it's supposed to do in it's context. Basically it means understanding how the example code would fit into the rest of the program (or does, if they have a fully working program).
Why they did it that way - This is something that might take some learning before you can really understand, but it's worth it. Being able to see why someone did something the way they did means that you probably understand the code pretty well. This is kinda optional, and doesn't always apply to things, but is really helpful to consider when it can apply to something. Sometimes the reason someone coded a certain way is just habit, but sometimes there's a good reason for they way they did something. When you can figure out the difference, it's a sign you're getting good at understanding how code can be used in alternate ways.

[Rehnrald]

I don't think you came across TOO harsh, but however harsh it was helped to get your point into my head. I have plenty of example .LOVE files, (actually my desktop is full of them) but I haven't really UNDERSTOOD the code. I have gone through/skimmed it to see how things can be done, but I never went in depth to look to see how things work, and why they work.

[Bobbias]

Yeah, when you first begin learning to code, it's hard to understand how to get better at it. In fact, when you start anything, it's hard to pick out what things about something are important to look at in order to use them to improve, so you often end up thinking too much about unimportant or irrelevant things that don't actually help. And this is perfectly natural, too. I just read a bunch of material on how the learning process itself seems to work, and this difficulty in picking out what is important from what isn't is something that they explicitly mentioned. You'll get better at knowing what to look for and such as you get better. Practice makes perfect.

[Rehnrald]

Thanks, Bobbias