LÖVE • Community Blogs - The official community LÖVE blogs.

Lövely Interviews - Midipixel on Warlock's Tower

Sheepolution — Tue, 31 Jan 2017 19:13:48 +0000

Blog Terms:

In Lövely Interviews, I interview developers of LÖVE and LÖVE games. Today the LÖVE game Warlock's Tower by Midipixel was released on Steam. I interviewed Ygor and Werther from Midipixel on the development of Steam's newest LÖVE game.

Tell us a bit about yourself. Who are you and what do you do?

We're Werther and Ygor, two guys in their thirties, a musician/artist and a programmer, respectively. With our powers combined we make Midipixel, a Brazilian indie game company now existing for three years in a row. We make indie games, obviously, although we've done client work in the past. We participate in game jams as well (GBJam is our favorite) and the occasional experiment here and there. We're also part of a Rio de Janeiro collective of indie game developers called RING.

How did you learn about LÖVE, and what was it that made you start using it?

I first heard about it while I was doing my Computer Science M.Sc. at PUC-Rio. PUC-Rio is where Lua was created, and having fell in love with the language there, LÖVE seemed a pretty easy to get into framework. I started doing some prototypes while working at my previous company (Nano Studio, which Werther was also a part of) and things always moved fast. I quickly discovered to be really productive using Lua and LÖVE.

Congratulations on releasing Warlock's Tower! Where did it all begin, and how long did it take you to make it?

Thank you! By the time of this writing, Warlock's Tower is not yet released, so here's hoping nothing bad happens until then! It all began in October, 2014. Having just been released from a two-month hospital stay and feeling like life is short, I decided to use some of my recovery time to hack one of our old ideas. The first prototype was done in a week, I guess. We were pretty happy with it, sent it around to friends and family and everyone seemed to be having fun solving its puzzles. During 2015, however, we started doubting the project's potential and almost dropped it for another prototype of ours, but then November came and Warlock's Tower won two SBGames awards, one of Brazil's major game development festivals, one for "Best Game Design" and another for "Best Developing Game". That was the sign we needed. We resumed working on the game and 2016 came and went as we spent most of it dealing with publishers (we talked to two of them before signing with Whippering, who currently publishes us), finishing the game's content, mobile ports and adding a Twitch integrated play mode. Whew!

What is the most important thing you've learned when creating Warlock's Tower?

Jeez, there are a lot of important things I learned while making this game! But I guess the most important one is: be an active part of the whole. I used to foolishly think that just by making something I was entitled to receive attention and praise for it. That by the sheer amazingness (if only!) of the thing I was creating, people would discover my work and recognize my effort and throw money at me. People will pay you attention, they will give you their time, but you need to reach out to them. Share screenshots, show how your game is evolving. Go to events and festivals, be a part of your local game developer gatherings (or start one yourself.) All the opportunities that came our way started with us making some sort of reaching out. If we hadn't submitted Warlock's Tower for the SBGames, we wouldn't have won. If we hadn't being posting screenshots of the game on Twitter, we wouldn't have been found by publishers, and pretty much no one would know about our game by now.

Was there a part/feature you really struggled with when creating Warlock's Tower?

Sure. One of the big ones was making the controls work for the mobile platforms. At first we tried a touch and drag approach, but the game's so movement focused that we couldn't avoid adding an onscreen directional pad. We also struggled to make our players understand the game's rules through the GUI. Warlock's Tower's interface was overhauled twice during development. A single (but very important!) rule regarding how gems restore your character's health was the sole reason for the second remake. We do have an incredibly better GUI today, but the sad part is that, honestly, we haven't felt that it particularly improved player's comprehension. It's a tough rule to explain through the GUI without having it heavily interfering with the game's experience.

Warlock's Tower is your biggest game yet. Did the scale of the project change your approach on programming or design?

Yes! Maybe every new project should challenge one's old, tested approaches, be it in programming or design. Warlock's Tower evolved in a more organic fashion, as I imagine happens in some way or another for every larger software project. Programming-wise, maybe due to LÖVE's lightweight, more library receptive architecture, I included more external libs in this project than I'm used to, which wasn't so much a deliberate change of approach but a production necessity. However, this proved fruitful, and I'd feel inclined to do this again working with LÖVE. Using Lua for a longer project certainly changed the way I code and think about code, somehow, and I'm sure many of its cool features will be sorely missed as soon as we start working again with more constrictive technology. In the end, it seems that Warlock's Tower changed me more than I changed for Warlock's Tower.

Do you already have plans for your next game, and if so what can you tell us about it?

All game developers (all creatives, really) have piles of ideas towering around, and we're no different in this sense. We have a favorite idea which we have been discussing for some time, but since it would lead us to another longer project, we most likely aren't going to be able to tackle it right away. We also need to evaluate Warlock's Tower's response, learn from its release before we can decide on where to go next. We have several jam games which certainly could become full projects in the future. We also had an interesting time implementing Warlock's Tower's Twitch features, and both Werther and I fondly consider making our next game a stream first game.

Is there anything you really wish would be added/changed to LÖVE?

When I talk to people about LÖVE I usually say that its two weaknesses are 3D and cross-platform support. The first one is obviously not a weakness (since the framework is also called Love2d), but the second one really makes a difference nowadays when selecting a framework/engine. I'd love if making mobile LÖVE games were easier and if there were console ports available.

Thanks for answering all the questions, is there anything you would like to tell the readers?

Well, if any of you want to contact us, feel free to do it! Check out Warlock's Tower's website if you wanna know more about the game. Oh, and we're really active on Twitter, so if you wanna keep in touch, follow us there: @ysperanza and @w_midipixel. We're constantly talking about games and we'll love to meet you there!

Lövely Interviews - bartbes

Sheepolution — Wed, 26 Oct 2016 13:55:55 +0000

Blog Terms:

In Lövely Interviews I interview developers of LÖVE and LÖVE games. And this time we interview bartbes. Together with slime he is one of the main developers of the LÖVE framework.

Tell us a bit about yourself. Who are you and what do you do?

Starting off with the hardest question, I see. I'm Bart, a long-time LÖVE
developer — since 0.6.0, if memory serves — and otherwise boring student.

How did you learn about LÖVE?

I'm not really sure, but I think this happened as a result of the game Crysis. See, Crysis came with an editor for the CryENGINE 2, which used Lua. After playing around with the existing code, tweaking it a bit, and generally messing around with the editor, I googled for game engines using Lua. Yes, it was that simple.

I should probably mention that it wasn't my first foray into programming, I started with QBasic on MS-DOS, and then later went on to (primarily) C++ programming. Using LÖVE was like a breath of fresh air, since all "games" I had made until then were text-based, and in 3 lines of Lua I had a window displaying "Hello, world".

Together with slime you're the biggest contributor to the LÖVE framework. Why did you start contributing and what kept you going?

I started contributing because... I'm not sure, actually. I think I heard rude and/or mike saying they were looking for help coding, and considering I knew C++, LÖVE was (and is) written in C++, and I was a cocky teenager, I volunteered. And it worked, I guess.

As for what kept me going, I'd say it was probably a combination of free time (I was in high school at the time), fun and necessity. It was quite interesting to go from knowing how to get a compiler to accept your C++ code to knowing how a game engine works, I suddenly got to see everything from graphics to input to audio on a clean, readable codebase. I feel like these days I'm familiar with what goes on in most of LÖVE, but I've read ahead and will go into that in the next question. I also mentioned necessity, which I'm using fairly loosely here, but that was about the time that mike stopped contributing, and when rude had less and less time to work on LÖVE. I'm sure LÖVE would have been fine without me, but knowing I could easily become a driving force behind the project was a good motivator.

Are you and slime both specialized in certain modules/features or can you find your way through the whole codebase?

I'd say I could probably read and modify everything, and I have probably read most code at some point. Partially this is because I have modified or authored a decent part of it, or have worked on code that interacted with it, partially it's because I've been doing this for years, and LÖVE's codebase isn't actually that big. That said, I know slime knows OpenGL much, much better than I do, so I'd say I know love.graphics the least, and I usually leave graphics-related things to her. Don't tell her, but it's also because I'm lazy.

From what I can tell, slime feels the same, she's had her fingers in a lot of pies too, including the SDL pie. I'm not sure how she feels about modules I've written from scratch, like love.thread and love.video, but she is not someone to back away from a challenge.

Does LÖVE still have lots of work left or are you at the point where you really have to seek for what you could work on next? What are you currently working on?

That's a hard question. As most people know, it feels like your work is never done, it's just "good enough". Though with love.video, and the upcoming microphone input (see raidho's pull request for more information), there's nothing major that comes to mind.

I never have to look for what to do next, since I don't think the bug tracker has been empty in years, and in the limited time I spend on coding, I try to tackle whatever bug seems interesting at the time.

Is there a feature that is currently not in LÖVE simply because none of the developers so far have an understanding on how to implement it? Have you ever searched for help to get a feature made?

Audio input has (had) that problem: if I remember correctly bmelts had a working prototype a few years ago, but it turned out it only worked on his machine.

I think love.video used to be a prime example, but we've persevered! I don't think Twitch still has them archived, but I did a lot of research and experimentation for love.video on twitch.tv. I didn't necessarily reach out to a person, but I ended up looking at a lot of example code, bad documentation and even library source code to get that working. Most of the time when I can't solve something myself, there's two resources that help: Google and slime.

That's not to say it has never happened, ports are a good example. meric (then appleide) ported LÖVE to OSX, and I'm sure that played a role in asking him to join, though that was before my time. Similarly, fysx' android port was something we probably wouldn't have done ourselves, and he too was asked to join. Come to think of it, maybe that's the secret to joining… I'm sure those rituals had nothing to do with it.

When working on LÖVE, was there a bug that you had a special grudge on?

No specific ones, but garbage collections or race conditions are always fun. Especially garbage collection race conditions! Any bugs we can't reproduce are also up there.

Interestingly, I kind of like the extremely specific bugs, the weird edge cases. Those usually expose some flaw in your logic, where you were sure that value can't have been 3 at that point, but your tests undeniably prove it can.

Is there a LÖVE feature that you are extra proud of?

When I read this question, love.video was my first thought, but I've talked about that enough and there's something else that I think is actually really cool: love.run.

Why love.run? Because it shows the simple and customisable nature of LÖVE. If you use the default love.run, you get a hello world in 3 lines. But there's no reason you need to use the callbacks as we defined them. There's no reason you need to handle events in the main thread. You can change LÖVE's main loop without a problem. boot.lua — which is the file love.run lives in in the repository — shows to me that in essence LÖVE is a library. You can pick and choose, modules are fairly loosely coupled, and you can load it into an existing lua program. And somehow we tie this together into a coherent framework/engine using lua, rather than C++.

Do you have any plans or hopes for the future of LÖVE?

"Plans? Where we're going, we don't need plans!" pretty accurately describe LÖVE development. There are bugs, intentions and release dates.

What I would like to see is more users. It still feels wrong that media and industry seems to ignore us. Obviously I live in a LÖVE bubble, and it's probably fair, but I'd like to be at the point where LÖVE is well-known. Something completely unrelated: if you work for a big games company, and you like LÖVE, spread the word!

Anything you would like to tell all lovers (LÖVE users)?

Don't fall in the engine-making trap, you'll never release games again!

Lövely Interviews - Maurice from Stabyourself.net

Sheepolution — Thu, 08 Sep 2016 16:05:32 +0000

Blog Terms:

In Lövely Interviews, I interview developers of LÖVE and LÖVE games. This time I'm interviewing Maurice from Stabyourself.net, who is known for creating the Mario/Portal mashup: Mari0.

Tell us a bit about yourself. Who are you and what do you do?

We are a two-man developer team, that is Sašo and me, Maurice. Sašo does anything website and hosting related while I program all the games. He also helps me with bouncing off ideas.

We make games for fun that you can download from our website for free. It's not about making money but instead creating something that people will enjoy and maybe be surprised by.

Mari0 was actually how I learned about LÖVE! How did you learn about LÖVE, and what was it that made you start using it?

I think someone in the Facepunch programming forums, which I used to frequent, was making a project with LÖVE, and I was looking for a more capable game engine than AutoIt3 or the Warcraft 3 Map Editor at the time. A good friend of mine was a very skilled Lua programmer working a lot with Garry's Mod so I figured it might be a good idea to learn more about LÖVE and Lua.

Mari0 might be the most popular LÖVE game to date. Where did it all begin, and how long did it take you to make it?

It began like a lot of prototypes, where you go "Hey, I wonder if I can program a platformer". I started programming away in January 2011 on it using Super Mario Bros as a base because historically it was one of the first games to really nail the movement mechanics.

After some time when the game was starting to resemble SMB, I started looking into what can be made out of it, thinking of making a multiplayer game like the recent .io games (agar.io and slither.io) or turning it into an HD port like Sonic 2 HD.

Neither really got anywhere because of my inexperience with netcode and unsuccessful attempts at finding an artist.

But then Dorkly made a video about SMB with a portal gun and I thought "Hey I can actually make that!". That was in April 2011.

A couple of months later in March 2012 Mari0 was released, so it took just over a year of on-and-off programming.

What is the most important thing you've learned when creating Mari0?

It's difficult to please everyone, especially when you make the development process as open as we did. People have different ideas of what should be in the game and you have to be able to maintain your own vision.

If I had listened to every idea we got, Mari0 would be an mmo with guns and Sonic side characters.

Was there a part/feature you really struggled with when creating Mari0?

Probably the most requested feature, partly due to my fault of showing an unfinished version of it, online multiplayer. Combining a lack of experience with netcode and an already far into development game made adding network play a real pain for us. Someone I know actually offered to write the online part into the game but ultimately failed due to the client heavy way the game was written. In the end we had to completely abandon the idea, much to the dismay of youtube commenters.

I think online play in a complex game such as a platformer has to be included from the very beginning, otherwise you set yourself up for rewriting half your game.

You have a Modding board on your forums. Was Mari0 programmed to be mod-friendly? And if so what did you do different to achieve this?

There's nothing in Mari0's code that makes it particularly mod friendly. It's just the openness of the code and engine that inspired people to mod the game.

There was going to be an update to Mari0 which included moddable enemies and entities which was actually pretty cool (There's a short blogpost about it here).

I think the best idea is to program things as modular as possible and then allow elements to be loaded from a folder. Anyone interested in modding will figure out how to use it to their advantage.

For more advanced types of modding, I assume you'd have to put hooks into your game like Garry's Mod does it, but I have no experience with that. It's definitely something that's worth looking into though.

With LÖVE you also created Ortho Robot, a game where you "bridge the gap between 2D and 3D games". Wouldn't it have been easier to create this game with a 3D framework/engine?

Probably. It would also add more features; my crudely programmed 3D engine allows no roll-rotation on the blocks and I had issues with the draw order when the player moves between blocks. Like many of my games it was a "Can I program something like that?" thing.

I'd love to get into a new "more serious" engine such as Unreal or Unity, but I just can't find the time or motivation to do so.

Is there anything you really wish would be added/changed to LÖVE?

I think with the recent Android and iOS ports, the only platform left for LÖVE to support is web. It would be really cool if I could upload quick prototypes (or full games) on the internet and allow people to play them without any installation or download.

Other than that I'm very happy with the way the LÖVE-team is handling development of the engine.

In my interview with rude he talked about one of your games, Trosh. Is there a story behind this explosive game?

Trosh is actually one of the users from our forums, and at some point I got into a kind of exchange with him where he'd send me something in the mail, I'd send something back and so forth. At some point I decided to send him a link to a game that I was gonna program while the mail was underway, which put me under some time pressure but I think the game came out alright. And that's how Trosh was made.

Are you working on a new game at the moment, and if so what can you tell us about it?

I have one project that I think has potential, but I'm not nearly far enough to show anything. I'm trying to get back into actively making games because making Mari0 and the other games was a lot of fun, but it's hard to find the motivation to do so next to my regular programming job.

The past few months I've also been working on a game we showcased at our yearly Gamescom appearance, Super Battle Arcade. You can watch a video of an older version here.

Thanks for answering all the questions, is there anything you would like to tell the readers?

I think games are something really special, as there's no other hobby I can think of that allows you to share your work as easily and accessible as game programming. So don't be afraid to show what you've made and don't be afraid to try out new things.

Lövely Interviews - slime

Sheepolution — Thu, 01 Sep 2016 12:32:10 +0000

Blog Terms:

In Lövely Interviews I interview developers of LÖVE and LÖVE games. And this time we interview slime, who is the biggest contributor of LÖVE, with over 1300 commits.

Tell us a bit about yourself. Who are you and what do you do?

Hello! I’m Sasha. I’m a software developer currently working in the games industry in Nova Scotia, Canada. I’ve been contributing to LÖVE’s development in my free time since around the end of 2012. I’ve also made a few games using LÖVE, and I’m a regular contributor to the SDL library, which is used extensively by LÖVE.

How did you learn about LÖVE?

I first heard about LÖVE back in 2010. I believe there was a post on the programming subreddit about LÖVE 0.6.2, which caught my interest because at the time Lua was the only programming language I knew. I had been making Lua addons / scripts for Vendetta Online, an indie space MMORPG.

I actually knew the LÖVE developer bmelts from the Vendetta Online community before I knew about LÖVE, but I didn’t know he was one of LÖVE’s developers until after I joined the LÖVE IRC channel!

I hadn’t done any sort of game development or real programming outside of my Vendetta addons before starting with LÖVE. The first thing I made with it was a Pong clone which wasn’t very visually impressive, but I had a lot of fun learning about the basics of games when making it.

With over 1300 commits you've become the biggest contributor to the LÖVE framework. Why did you start contributing and what kept you going?

I wanted to learn C++ and I had an interest in OpenGL, and I was also very active in the LÖVE IRC channel at the time. I had some ideas about feature and performance improvements that I wanted to see in LÖVE, so I learned bits and pieces of the LÖVE codebase and submitted a few patches and pull requests… and now here we are.

I ended up really enjoying the combination of several things that contributing to LÖVE’s codebase provides: learning and writing code that interacts with system-level APIs such as OpenGL and SDL (and OS APIs since I also contribute to SDL’s development now), designing functionality that fits in with LÖVE’s preexisting philosophy, working with graphics APIs like OpenGL, and working on something which gets feedback and use from a large community.

That last point is probably the most important to me. I definitely would not have put so much time into LÖVE if it weren’t for the community, so, thank you!

When working on LÖVE, was there a bug that you had a special grudge on?

I think bugs inside graphics drivers have been the most frustrating for me, since I have practically no control over when (or if) they’re fixed, I can’t rely on them being fixed on a user’s machine even if a new driver comes out, they’re usually annoying to debug, and they generally require ugly workarounds in LÖVE’s code... if a workaround is possible at all.

Here’s one example of a graphics driver bug which I had to figure out a workaround for.

The issue of stutters when in windowed mode on some systems (especially when using Windows) is also annoying, since I don’t know of a way to solve or work around it in LÖVE’s or SDL’s code. You’re probably seeing a pattern in my frustrations by now. :)

Is there a LÖVE feature that you are extra proud of?

The OpenGL ES 2 graphics backend code I wrote unofficially for 0.9 and officially for 0.10 ended up enabling a lot of other people to port LÖVE to other platforms, which has been really cool to see.

Some examples of LÖVE ports that rely on it are LÖVELINESS (a now-defunct NaCl / Chrome port of 0.8.0 created by a Google employee), fysx’ unofficial Android port of 0.9 which is now part of 0.10, my iOS port of 0.9 which is also now part of 0.10, T-Bone’s port to Metro / WinRT / Windows Phone, and Tanner’s web port of 0.10 via Emscripten.

You seem like a very skilled programmer. Do you have any advice for people who want to become a programmer, or programmers who want to improve?

There are many different ways to learn and improve at programming. I think it’s important to figure out the most enjoyable and best way for you (the reader) to do that, which may be different from someone else’s preferred way. Some people thrive by seeking out information and experimenting completely on their own. Others learn best within the type of environment that schools and universities provide. Or anything in between those two extremes.

A lot of people, myself included, have a hard time committing to and following through on a completely self-developed project - whether it be for learning or otherwise. As I mentioned earlier I started contributing to LÖVE partly to learn, and I think finding an open source project, preferably one you already know about as a user, and figuring out ways you can contribute to that is a very good way to improve your programming skills.

You’ll have an existing codebase written by others you can look to, there will often be plenty of opportunities to tackle small problems in order to get your feet wet, and most importantly an active open source project will have other people who can help you and whose own goals are similar to yours.

All that said, following a self-developed project through to completion is a skill of its own. There is a lot to be learned after the first 90% of a project’s development… when you’ll be doing the final 90%. ;)

Do you expect to see LÖVE 1.0.0 happen in your lifetime?

Personally the “1.0” version tag doesn’t actually mean a whole lot to me, it’s all pretty arbitrary. 0.10.0 could have been labelled 1.0, or 2.0, or 10.0 if we had decided – and maybe a future major release will skip 1.0 entirely and/or change versioning schemes, who knows!

I consider LÖVE to have been ready for use in complex 2D commercial games since around 0.8.0 or so, and 0.10 has been very stable so far. All of the minor (0.X.0) version releases in the past few years have had breaking changes but not complete overhauls of LÖVE at a fundamental level, and I don’t see that changing in the future.

Do you have any plans or hopes for the future of LÖVE?

I have outlined some of my ideas on the forums and on the Bitbucket issue tracker, plus I have some more far-fetched and less fleshed out ideas knocking around in my head – I often think about how various APIs (especially in love.graphics) might be changed to provide better performance or to make them more powerful or more intuitive to use. Only some of those thoughts ever come to fruition or end up being worthwhile ideas, though.

Beyond that, It would be super awesome to see more people contribute to LÖVE’s development. Since I currently have a full-time job in the games industry, I have a lot less free time than I used to that I can spend programming (and I usually split that time between LÖVE and SDL too). I also consider my own thoughts on LÖVE’s features and code pretty limited in terms of perspective, so having more people from different backgrounds working on LÖVE could only improve it in my opinion.

I think LÖVE has already been extremely successful at carving out a niche for itself that isn’t filled to the same degree by anything else, but it still has room to grow and improve and I hope there are more people out there who want to help make that happen.

Anything you would like to tell all lovers (LÖVE users)?

Don’t forget to like, subscribe, and comment… wait a minute.

Seriously though, thank you for using LÖVE and being a part of this community! I hope everyone enjoys using it as much as I enjoy working on it.

The forums are a great place to ask questions and post about what you’re working on. I and many other knowledgeable folks are active in the IRC channel at #love on irc.oftc.net as well - don’t be afraid to hang out there and chat about LÖVE things. I bounce ideas for new features off of other people there all the time!

Garbage Collection in LÖVE

bartbes — Sat, 16 Jul 2016 19:18:54 +0000

Blog Terms:

technical lua gc

I recently got a message on the forums asking me about the way LÖVE does garbage collection on its objects, and I figured they probably aren't the only ones interested, so here's an expanded answer.

As some of you may know, LÖVE is written in C++, which features manual memory management, and Lua has garbage collection. How do we solve this mismatch? Why, with another way to manage memory, of course! I'll start off by explaining the Lua GC (Garbage Collector), then quickly discuss C++'s model, followed by LÖVE's solution.

Lua's GC

As you may have realised if you've ever used another language, in Lua you don't need to worry about allocating and freeing memory. You create an object, and it stays available as long as you can refer to it. If you remove all references, it gets freed transparently. So how does this work?

I'll try to give a high-level overview of the Lua GC, to spare you reading a few books' worth of academic papers. First of all, the GC can be tweaked, the manual has some more information about the subject, but for the most part we can assume the GC runs automatically, at regular intervals. It stores a list of all objects, and by finding all reachable objects, it can then delete the rest, the unreachable objects. To determine which objects are reachable, it has a couple of starting points: the global environment, and any running functions. And yes, I mean functions, or really, coroutines.

Let's consider a simple example, we have some globals, a suspended coroutine and, of course, the main "coroutine". This means we have 3 places to start looking for values. Now, we can obviously reach all globals, we can reach the locals of the function we're currently running, and we can reach all values they contain. So if we can reach the math table, we can also reach math.sqrt. Similarly, if we can reach the suspended coroutine, we can also reach anything its locals can reach. Additionally, if we are currently in a function g, that was called from f, then we can also reach anything f can reach, and so on. Needless to say, there are usually quite a lot of values you can reach.

Thankfully, the GC doesn't need to run it all at once, since that would introduce significant delays. Instead, it's an incremental garbage collector, which means it can divide the work into multiple smaller steps.

As a final piece of the puzzle, in Lua all external objects are classified as userdata. There is both lightuserdata, and what is sometimes referred to as "full userdata", but Lua calls it userdata. As LÖVE uses an unmodified Lua (or LuaJIT), all of LÖVE's objects, in Lua, are userdata. Whereas in Lua you can't do cleanup when an object gets collected, the Lua developers know that this would cause all kinds of issues if the same were to happen with userdata. To circumvent this, Lua calls the __gc metamethod on userdata when it is garbage collected. As you can imagine, LÖVE then uses this metamethod to determine when to free its objects, but we'll see that later.

As an aside, if you've ever watched the memory usage of LÖVE whilst running the GC manually, you may have noticed something peculiar: The memory usage only goes down 2 cycles after userdata became unreachable. The reason for this is the aforementioned metamethod. If the metamethod somehow creates a new reference to the object, it can't be collected straight away. Rather than trying to solve this by trying to keep track of what it does, the GC does something simpler. On the first pass, it calls the metamethod, then "detaches" it. The next time it comes across the userdata, it knows the metamethod has already been called, and only then is it actually removed.

C++ memory management

There's very little to say on this point, since C++ memory management consists of the programmer doing it all by themselves. Specifically, if you want to allocate a new Image, you could write Image *image = new Image(file);, and when you're done with it, you delete it, using delete image;. Between those points the value of image is valid, after delete is isn't. So, if you refer to image after deleting it, your program could crash (or worse, it could not). Similarly, you are responsible for making sure you delete it exactly once, if you don't delete it, you won't notice you're leaking memory. If you delete it twice, you'll crash. Fun.

As may be obvious, this isn't the most programmer-friendly paradigm. The upside is that it is fast, and it allows you to do all sorts of crazy things. Even though that may include shooting yourself in the foot. Another benefit is that it's predictable. When dealing with Lua, if you remove all references to an object, it may live on for a very long time before it is finally removed. If you delete something in C++, it gets removed right then. Since removing objects takes time, you can thus plan when this happens. You could spread it out or you could delete batches of objects at a time. Even though Lua's GC can be tuned, you'll never get precise timing control. If you're creating lots of garbage, you could see lag spikes, and there's very little you can do about it, except create less garbage.

LÖVE's reference counting

We've seen two completely different ways to manage memory, Lua's fully automatic GC, and C++'s fully manual new/delete. This leaves LÖVE somehow having to reconcile these two worlds. The answer is clearly to introduce yet another model!

Now, not all LÖVE objects are the same, but we'll focus on those that you can use from Lua, which all derive from the love::Object base class. This base class supports (manual) reference counting. In our case, we use two methods for this, retain, which increases the reference count, and release, which decreases it. The basic concept behind these is simple: Once the reference count reaches 0, the object deletes itself! This also means that when the object is created (using new) it has a reference count of 1.

Unfortunately, this is still a manual system, if we ever forget to retain an object we store, or release an object when we stop storing it, we will still run into issues. Thankfully, it's usually fairly easy to know when to call retain, and when to call release, and C++ allows us to write helpers to manage it for us in a lot of cases.

I've now explained how LÖVE deals with those objects internally, and how it relates to C++ model of new and delete, but that still doesn't explain how it cooperates with Lua's GC. This is where the __gc metamethod comes into play again. Whenever an object reaches Lua, which is roughly whenever a function returns it, the LÖVE wrapper code calls retain. Then, when the __gc metamethod gets called, it calls release. What this means is that Lua holds 1 reference for every "copy" of the object it has. When one becomes unreachable, the GC will collect it, and the reference will be released.

If you're now wondering why it has to be this complex, that's because object lifetimes are complex in LÖVE! Say you create a blank ImageData in your code. At that point Lua holds 1 reference, and nothing else does. Then you fill it with some data and call love.graphics.newImage on it. At that point Lua holds 1 reference, and the newly created Image holds another. If you then remove all references to the ImageData, Lua will no longer hold its reference, and the only reference will be the one from the Image. If you then remove all references to the Image, both the Image and the associated ImageData will get deleted, which is exactly what we'd expect. If we were to simply trust the Lua GC, we'd have deleted the ImageData whilst the Image was still using it. If we had "trusted" C++, we'd have deleted it when we LÖVE longer held it, but when Lua still did. This reference counting solution allows both models to work together, without leaking memory, nor deleting it prematurely.

Similarly, this also works across threads. Since love.thread gives every thread its own separate Lua state, they also run independent GCs. Using this reference counting mechanism, this means each thread can have their own reference, and an object only gets deleted when all threads are done with it.

Want more?

In this article I've tried to give a glimpse into the LÖVE internals, if you want to know more about memory management, if anything was unclear, or if you would like to see more posts on other subjects, let us know!

Of course, since LÖVE is open-source software, you can look at the implementation yourself, if you're interested. The 0.9.0 version of love::Object is a simple, straight-forward implementation of the retain and release primitives. The current, 0.10.0 version is more thread-safe, at the cost of readability.

Lövely Interviews - rude

Sheepolution — Thu, 16 Jun 2016 10:52:34 +0000

Blog Terms:

In Lövely Interviews I interview developers of LÖVE and LÖVE games. We start off this series with rude, the creator of LÖVE.

Tell us a bit about yourself. Who are you and what do you do?

Yes, well, I am rude, the original creator LÖVE. These days I don't actually work on the code anymore (though I might resume at some point), but I still do all the design related work, e.g. the new icons, the no-game screens (e.g. Super Toast), the website design, etc. At least I do that eventually, after I get enough harassment from bartbes and slime.

I do definitely exist in real life as well, but I prefer not to talk about that. I must remain shadowy and mysterious. The menace must remain phantom.

Can you tell us about how LÖVE came to exist?

Actually, I don't remember how it started. Possibly it was just a challenge to myself. If someone forced me to make up a story, however, it could be something like:

Well, I was looking for a free 2D-centric game framework that was easy to get up and running, and that would work on all platforms without too much hassle, but I couldn't find any. There were many engines and frameworks available, but they were too focused on 3D, which made the API unattractive for use in 2D games. So I began to work on my own API; a glorious world blissfully ignorant of the z-axis, where the children could finally laugh and play freely, both as in beer, and as in freedom. *single tear*

And so forth.

What was Mike's role, and why did he leave?

Yes, he was (well, is, since he's not dead) the co-author of the original code. He worked on lots of stuff all over the place, like fonts (ImageFonts were his idea), ParticleSystem, and other stuff. He also worked on the love.gui module, which ultimately wasn't released.

He didn't exactly "leave" in some dramatic incident, his interest just faded I guess. Or his interest faded because I was too bossy. Although you should probably ask Mike about that.

How did you decide on the name LÖVE?

Software at the time (2006-ish) seemed either very serious (Visual Studio Professional), or attempted be all badass (UNREAL ENGINE). I hated that, so I wanted to come up with a very non-serious and anti-badass name that evoked fuzzy warm feelings of fun, happiness, etc.

After a brainstorming I no longer remember clearly, "Love" (umlautless) surfaced somehow, and thought it was a perfect fit right away. I assumed, of course, that there was already some game-related software called Love out there (because every name is already taken in every context, no matter how ridiculous), but I couldn't find any. There wasn't even a Debian package called "love", which amazed me.

When I understood that I could be the one responsible for making this a reality:

$ make love
$ man love
$ apt-get install love

There was of course no turning back.

Later, when I designed the logo (the curvy LÖVE text), I added the umlauts on a whim since I decided that something was missing from the logo. That's how it became LÖVE. I also added a sarcastic copyright symbol to the logo, although that is removed now.

Why did you choose Lua as the framework's language?

The main reason was that it was easy to embed the VM.

Initially, LÖVE used SWIG, which is a way to generate a scriting API from C/C++ code. There was a vague plan to allow multiple languages (i.e. generate multiple scripting APIs using SWIG), but that was dropped eventually, since the API produced by SWIG was too ugly. Today the API/bindings are made by hand.

I vaguely remember trying to embed some other JS-like scripting language, but I don't remember the name, and it doesn't seem to exist anymore. The name had "Monkey" in it, I think.

LÖVE doesn't have tilemaps, UI, Camera, etc. The Animation object was even removed. Why do you choose to keep LÖVE to the basics like that?

"High level" things are (for me) mostly just in the way, and never work quite the way I need for a specific case. It's really easy to create a high level component which seems nice, but in reality is too inflexible for many cases, leaving lovers to develop their own e.g. tilemap component anyway, feeling sad that the built-in component is just uselessly standing there. So it's better if such things are made as third-party Lua libraries, so they're easier to modify or extend.

Also, there is an unwritten "emergent" guideline, which says that things which can be easily done in pure Lua should be done in pure Lua. This is affecting the API a bit, I think.

By the way, I don't exactly closely oversee LÖVE development at the moment, so it's not like I vigilantly enforce some principle in the LÖVE API, like your question might imply. It's the consensus of the LÖVE-dev hivemind that takes care of that.

Your last code-related commit was in 2014. Why did you stop working on LÖVE?

Hmm ... I don't know!

You would perhaps expect me to answer that I don't have time anymore, but actually, I do have time. So I should totally get back into it.

Of course, I don't really need to, since dem young'uns (bartbes, slime, fysx and others) got it covered.

Do you have any plans or hopes for the future of LÖVE?

LÖVE is already way more popular than I ever thought it would be. And also 'apt-get install love' is a reality now, so I don't see where we could possibly go from here.

Is there anything you would like to tell all lovers (LÖVE users)?

I regularly lurk the Games and Creations (formerly Projects and Demos) subforum (and other places), and it's so cool and impressive to see what people are making. I often think: "what?! I didn't know that was possible in LÖVE!".

Some games also really make me laugh, like that game where you are first flying horizontally, battling unicorns or something, then flying vertically battling your way through stuff until you get to space, and finally explosively landing (back on the ground) in a cinematic pose, wearing sunglasses. Unfortunately I don't remember the name of this game (if anyone does, please post a link in the comments).

So, definitely keep it coming, lovers.

In the making - have a look at running LÖVE projects

Sheepolution — Sat, 28 May 2016 22:56:13 +0000

I asked on Twitter "Are you making a game with LÖVE? Show us what you're making!"

And these are the replies I got:

Wanderer by @wanderer_game

A 2D adventure game blending cinematic platformer and RPG, and LÖVE is perfect for it!

When asked why LÖVE is so perfect for it, the developer responded

Lua power and flexibility + great documented API + multi platform + warm community = development going very fast!

Wanderer had both a succesful Kickstarter and Steam Greenlight campain!

You can check out their devlog here.

ZombieGame by @Jeffrey_W23

I'm building a game called ZombieGame (I'm told I'm good with names).

DOS by @Ulydev

A psychedelic rhythm runner

"An ASCII XCOM-Like game" by @rm_code

Still very early WIP though

"A game about cats and stuff" by @enemyspeak

"A game where you're walking around in the dark" by @foodshipnine

And there are some trees i guess. and a buggy map editor!

Traveler by @Sheepolution (me!)

A game where you fly through space, meeting and fighting interesting creatures

Really cool games! But surely there's more out there, right? If you're making a game, send a tweet to @obey_love or place it in the comments here, and I'll include your game the next time I'll make one of these. Whenever that is.

Thanks for reading and I hope you have a lövely day!

A Beginner's Guide to Shaders

OmarShehata — Sun, 29 Jun 2014 12:45:53 +0000

Ever since shaders were introduced in Löve (previously called Pixel Effects) they have been shrouded in mystery and myth. The only way to learn these mystical black arts was to scour the examples others have made in hopes of learning by tweaking enough code.

Hopefully, we can change that! By providing a straightforward guide, more people can learn and integrate shaders into their own projects!

This tutorial will teach you how to set up a basic pixel shader as well as attempt to explain what everything does.

What is a shader? (background info)

All the code you normally write runs on the CPU. As a general purpose unit, that works great for most things. The problem with your CPU is that it is sequential. It runs the instructions it''s given in the order they are written. Even with multi-core computers and multi-threaded applications, you have a limited number of cores and if they are processing the same data, they have to wait until the other is finished with it anyway.

Your GPU on the other hand has thousands of cores. It''s built specifically to be able to run instructions thousands or millions of times in parallel. The catch is, it can only run the same piece of code on all these cores at any one time. (This isn''t exactly how it works, but for all intents and purposes, it''s a good way to think about it)

What can I do with shaders?

Shaders can be immensely useful when making games or any sort of graphics work. You only need to look through the Share A Shader thread for a few moments to see all the impressive work.

If you want to do any sort of realistic/dynamic lighting, you''ll need shaders.

Screens taken from PriorBlue''s Love vs Shadow engine

Learning how to use shaders in Löve will also teach you how to use them in any other application/platform, since the fundamentals are the same. Just look at all the stuff you can do!

Not only that, but you can potentially leverage the awesome parallel processing power of GPU''s to crunch more than just graphical data, but we''ll discuss that later on.

Let''s make a shader!

There are two kinds of shaders. A pixel shader (sometimes referred to as a fragment shader) whose code runs on all the pixels, and a vertex shader which runs on the vertices of your primitives. We''ll start with the pixel shader.

To set everything up, here''s a standard main.lua you can use.

function love.load()
  myShader = love.graphics.newShader[[
    vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
      vec4 pixel = Texel(texture, texture_coords );//This is the current pixel color
      return pixel * color;
    }
  ]]
end
function love.draw()
  love.graphics.setShader(myShader) --draw something here
  love.graphics.setShader()
end

Now let''s step through this.

The first thing we do is create a shader using the function love.graphics.newShader. This will return a Shader object.

To apply this shader, we call love.graphics.setShader in our draw function. Calling the same function with no arguments will disable any shaders. In the above code, only things drawn between the two function calls will be affected by our shader.

Try loading in a simple image and drawing it (or just draw a circle or anything).

This is the example image I''m using, and this is how it looks like when rendered.

You should see it exactly as if there was no shader. To understand, let''s look at the actual shader we wrote.

What language are shaders written in?

We can see that we''re passing a big string to the newShader function. It doesn''t look like Lua. Shaders in Löve are written in GLSL (OpenGL Shading Language) but with a slight variation. This is important to note because the resources you can look up don''t have to be Löve-specific (or you can try porting shaders from other platforms for practice!)

GLSL	LÖVE shader language
float	number
sampler2D	Image
uniform	extern
texture2D(tex, uv)	Texel(tex, uv)

These are the only differences. You can look up the documentation of GLSL (Löve uses version 1.20) to learn more about any function.

Now let''s look at the shader code in more detail:

vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
  vec4 pixel = Texel(texture, texture_coords );//This is the current pixel color
  return pixel * color;
}

We know that everything gets passed through this shader before it is drawn, and this code here will run on every pixel in parallel.

GLSL syntax is more akin to C/C++ than Lua, so don''t forget your semicolons!

The entire job of the pixel shader is to return the final color of this pixel. The return type is a vec4, which means it''s a vector with 4 values. These correspond to the red,green,blue and alpha channels, each taking a value from 0 to 1.

Let''s try something even simpler. Remove all that and just return a new, custom color.

vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
  return vec4(1.0,0.0,0.0,1.0);
}

Try to guess what this will look like before running the code.

It returns a red color with full alpha, so regardless of what you draw, or what color you set with love.graphics.setColor, it will appear red.

You might also notice that, if you try to draw any external image (as in, not a circle or polygon with the built in drawing API) it will come out as a red rectangle. This is because you''re also overriding the transparency of each pixel.

Each pixel will get this specific color.

So far, this isn''t very useful. It would be more benificial if we had access to information about each pixel so we can better manipulate the image. Let''s look at the arguments passed to us.

What do the arguments mean?

The first argument, a vec4, is the color set during love.graphics.setColor.

The second argument is the image itself being drawn.

The third is a vec2, of the normalized coordinates of the current pixel, relative to the image.

The fourth is a vec2, of the coordinates of the current pixel, relative to the screen.

Let''s try to make use of the last two coordinates to illustrate how they work.

Say we want to make a shader, that will turn the right half of the image red, and the left half blue.

vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
  if(texture_coords.x > 0.5){
    return vec4(1.0,0.0,0.0,1.0);//red
  }
  else
  {
    return vec4(0.0,0.0,1.0,1.0);//blue
  }
}

Since the texture_coords are normalized. This means that x=0 is the leftmost point, x=1 is the rightmost, and x = 0.5 is just at the center (you can see how convenient this is).

So regardless of where you draw your image, the right half will be red and the left half will be blue.

What if we wanted to do the same thing, but relative to the screen.

In other words, we want anything drawn on the right side of the screen to be red, and anything on the left to be blue.

vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
  if(screen_coords.x > 400){
    return vec4(1.0,0.0,0.0,1.0);//red
  }
  else
  {
    return vec4(0.0,0.0,1.0,1.0);//blue
  }
}

Given that the screen_coords are not normalized (and assuming your screen width is 800), this will make the image completely red if it''s drawn on the right side, vice versa for the blue, and between will work as expected.

How can I get the color of the current pixel before changing it?

This is probably the most useful information you can use. Let''s say we want to give our game a monochromatic feel. All you''d have to do is average out the 3 color channels. (Or something simpler, removing the blue channel from everything will also give it an interesting tinge)

These all sound simple, but how do you get the color of the current pixel?

That''s where the Texel function comes in.

It''s pretty straightforward, it takes the texture (image) and the coordinates of the pixel relative to that texture, and returns the color. You conveniently have both passed as ready arguments, so all you have to do is plug them in.

vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
  vec4 pixel = Texel(texture, texture_coords );//This is the current pixel color
  number average = (pixel.r+pixel.b+pixel.g)/3.0;
  pixel.r = average;
  pixel.g = average;
  pixel.b = average;
  return pixel;
}

And there you go! We just made a shader that transforms everything into black and white in real-time!

Combining our knowledge

Now let''s try making it gradually go from full color to black and white across its width. I''ll wait here if you want to try figuring this out yourself.

Go on, I''ll wait!

When the r,g and b all have the value of the average, it''s black and white. The farther away it is from the average, and the closer it is to its original value, the image becomes full colored. Given this, we can make these simple equations:

vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
  vec4 pixel = Texel(texture, texture_coords );//This is the current pixel color
  number average = (pixel.r+pixel.b+pixel.g)/3.0;
  number factor = texture_coords.x;
  pixel.r = pixel.r + (average-pixel.r) * factor;
  pixel.g = pixel.g + (average-pixel.g) * factor;
  pixel.b = pixel.b + (average-pixel.b) * factor;
  return pixel;
}

We use the normalized x coordinate as our gradient factor, and we get a gradual black and white image!

It should be very easy to make it go to black and white gradually over the entire screen instead of per-image, we''ll just change the factor into screen_coords.x divided by however wide our screen is.

This sounds annoying though. Do we really have to hardcode in the width of the screen in our shader?

How do I send variables to my shader?

Of course there''s a way! And that is, Shader:send

The first thing is to set up the shader to receive the variable. In this case, it''s our screen width. So it''s only 1 number. External variables need the prefix "extern" (note: in normal GLSL, that would be "uniform")

extern number screenWidth;
vec4 effect( vec4 color, Image texture, vec2 texture_coords, vec2 screen_coords ){
  vec4 pixel = Texel(texture, texture_coords );//This is the current pixel color
  number average = (pixel.r+pixel.b+pixel.g)/3.0;
  number factor = screen_coords.x/screenWidth;
  pixel.r = pixel.r + (average-pixel.r) * factor;
  pixel.g = pixel.g + (average-pixel.g) * factor;
  pixel.b = pixel.b + (average-pixel.b) * factor;
  return pixel;
}

External variables are declared outside the function, as you can see in the above example.

Then you can run the command

 myShader:send("screenWidth",800)

From anywhere in the code. (I''m using 800 for simplicity but you can of course get the width dynamically through love.window.getWidth )

It is worth noting two things about the send technique:

Communication between CPU and GPU is generally expensive. You don''t want to be sending hundreds of variables per frame
What goes to the GPU, stays in the GPU. This is very convenient because it means you don''t have to send everything every frame. You can send the screen width once when you create the shader, and again if it ever changes.

And you''ve just made a snazzy gradient monochromatic shader!

Built-in variables

There''s a special note about the screen size. Since it''s such a common thing to use, Löve has provided it as a built in variable. You can use it by accessing love_ScreenSize.x or love_ScreenSize.y at any time in your shader. This is only available since 0.9.1

Another common thing to send to a shader is a time variable. Let''s say you want your image to slowly become black and white over time. It''s the same idea, except the factor will be an extern time variable instead of x or y coordinate.

Here's a .love of the effect I just mentioned.

Parting Thoughts

I hope you''ve enjoyed this guide! That should be everything you need to know to have a basic grasp of how shaders work, and get started. Please let me know what parts were helpful and what were confusing so we could improve this guide.

There''s a lot of other things we could discuss in future tutorials, such as vertex shaders, ways to send larger amounts of data to the GPU (or using it for general purpose calculations as we hinted at earlier), live-updating your shader code so you don''t have to recompile to see changes.

One of the biggest challenges for me in shaders was figuring out how to do self-propagating shaders. By that I mean, all the manipulations that you do to the screen are not saved. What if you wanted to make something that continually distorted an image, building onto its previous iterations?

A very common use for this is a smoke/fluid shader

These are all things we could discuss in future posts, but for the time being, you can see the code for the smoke shader here.

Let it glow! - Dynamically adding outlines to characters

Germanunkol — Sat, 05 Apr 2014 17:43:07 +0000

Blog Terms:

Hello everyone,

I'm Micha, aka "Germanunkol". I recently took a course at university on image manipulation and was thrilled by the possibilities - fourier and hugh transformations, filters, noise - there are so many ways to make graphics look better. At the same time, so few Löve projects use shaders - and I want to contribute to changing that.

I decided to try implementing some of the algorithms in Löve and noticed that many of them were quite simple to write and made for great effects in a game.

So this article aims to do two things:

The first part will give an introduction to some outline-filters and some of the maths behind them.
The second part is more of a tutorial on how to actually create an outline shader, with the goal to get people deeper into shader programming.
If you want to skip it all, you can download the final example from here.

For the second part you should have some basic experience with Löve and Lua. Having used a shader before won't hurt either. I will try to cover everything you need to know about shaders in this post, but your reading the introduction to shaders would be a good thing as well.

I go into a lot of detail - but don't be scared off! The final shader is relatively simple and very short.

So let's get started!

Outlines? Outlines!

Remember when Age Of Empires II introduced unit-outlines? It was one of those great new features - being able to see your units when they're behind buildings, or behind other units.

But there's other great uses for outlines as well: You could display an outline when the mouse is hovering over a unit, showing that the player can now select this unit. Or display an outline to highlight an important UI feature. Or you could outline a power-up when the player gets close to it. You could even use it to create a hit-effect for your space ship - the number of possibilities is endless.
So how could we go about creating outlines?

The first method that might come to mind is what I'd like to call the "traditional" way:

Fire up the GIMP, open your "skeleton.png" spritesheet or similar (which should have an alpha channel), duplicate the layer.
Add a blur to one layer: (Filters->Blur->Gaussian Blur - choose a blur size of 5 by 5 pixels and blur the layer)
Change the color: With the blurred layer selected, go to Colors->Curves. Play with the red, green and blue channels until you have the color you'd like for your outline. Then go to the alpha channel and increase alpha in the middle range (see image below).
Move the outline layer below your normal layer and you have an outline!
Save as "skeleton_outline.png"

This is neat and pretty fast. But there are major disadvantages:

You'll need to do this for every image which you want to have an outline
"Combining" outlines will never work this way. For example: If you give the skeleton a weapon (or a bunch of flowers, for that matter), the attached object's oultine will cover parts of the skeleton - instead, what I'd like is a combined outline for the two.
Changing color for the outline dynamically only works if you store it in a seperate image.
Growing/Blinking/fading of the outline won't work.

So - the traditional method won't cut it. Let's use shaders instead!

Part 1. The Theory

First of all: What is an outline, really? Drawing a rectangle around a rectangular image is trivial in Löve. That's not what we want to do. Instead, we want to highlight the area where there's a transition from "transparent" to "non-transparent". This area can have all kinds of shapes and will very rarely resemble a primitive which we can draw using the love.graphics functions.
Since we want to highlight the changes of the transparency (or alpha value), we'll ignore the red, green and blue channels for now - changes in color should not affect our outline.*

* Using the filters on the color channels can have some neat effects as well, try it!

Now, to get these "changes in alpha", consider the following image:

The left image shows some object being drawn on the screen. If we move from left to right through the image, following the red line, and note down the alpha value of every pixel we pass, then we get the plot on the right - the alpha is first 0 (transparent) and then jumps to a high value, stays at that high value while we're moving through the image and then falls back down to zero. There's two areas where the function on the right changes - these are the two areas we're interested in. Now, remember how to get the changes in a function? Exactly - we simply need to calculate the derivative:

The plot on the right shows the derivative. It's zero where there are no changes in the function and non-zero where there are changes - just what we wanted.

When working with images, we only have descrete coordinates, so we don't need to worry about actually calculating the derivative. Instead, there's a neat trick:
For every pixel, take the alpha value of the pixel to the right and subtract from it the alpha value of the pixel to the left. Consider these two examples:

In the left image, subtracting the alpha value at 9 from the alpha value at 11 yields (1-0) = 1. In the right image, (1-1) = 0. So we have a high value (1) when there's a change and a low value (0) when the alpha stays the same.
The next thing we'll do is represent this equation as a filter kernel.

Kernels

A kernel is a grid, or matrix of (often 3x3) values. It is used when doing a convolution over the image.

To calculate the convolution, you place the kernel onto the image and line it up with the pixels. Then you multiply the values which the pixels hold (in our case, only the alpha values are considered, but others can be used as well) by the values written in the kernel entries right above them, and add the results together:

Green is the pixel we're currently looking at. The filter-kernel has an entry for each pixel surrounding our current pixel, and for the current pixel as well - so 9 altogether. For the simple derivative, we'll only need two entries, the ones to the left and the right of the current pixel. All the others will be set to zero.
Each entry in the kernel tells us by how much we need to multiply the corresponding pixel before we add the results together - in our case we need to multiply the left and right neighbouring pixels by -1 and 1, respectively, and then add them together.
Let's try this in the GIMP.

Open up the GIMP, load any image file you want to process (make sure it has an alpha channel).
Go to Filters->Generic->Convolution Matrix. If you enter our kernel into the pop up, you'll get the derivative (in horizontal direction) of the image. Make sure only the alpha channel is checked to get the same results as I do.

Result:

There is a horizontal and a vertical version for this filter:

These kernels are often used to get to the so-called "Sobel Filter" for edge detection. All we need to do is blur this matrix, which I might explain in another post one day.

While this filter works, there's are a few drawbacks...

You'll notice that only the edges on the left side are being shown. That's something I didn't mention before: If you go back to the above image of the alpha-function, you'll notice that at the right edge, when applying our formula, you'll get (0-1) = -1. Since this value is negative, the GIMP will ignore it (or clamp it to zero). This can be fixed by simply taking the absolute value of the derivative instead:

However, even when having done that we still don't have any of the edges in vertical direction - and this is where this method fails. The only way to fix this is to also calculate the derivative in y direction and then add the two together.
There is, however, a better method: The Laplace-Filter
Before, we calculated the derivative, a'(x). Now, we'll consider the second derivative instead, a''(x). This looks approximately like this:

(A note of caution here: Our original function was piecewise linear. Off course this means that the second derivative is technically zero throughout the whole image, with the exception of a few infinitifely high spikes where there are jumps in the derivative. However, the way we're calculating it makes the whole principle work, because of the way we're approximating it.)
The Laplacian can be approximated by using the kernels (horizontal and vertical again):

To get the final Laplacian, we'll add the two kernels together into one. This results in the image on the left here. There's another approximation which is commonly used, which also takes into account the diagonal values, that's the kernel on the right:

Trying both of these in the GIMP again gives us some nice results:

This looks good. So this will be the filter we'll use.
Enough theory, let's get coding...

Part 2: The Shader

Tutorial Framework

To speed things up, I've created a quick n' dirty tutorial framework. It creates two animated characters and lets them walk in an endless loop.

Download the framework from here.

Alternatively, you can also clone the repository on your command line using:

git clone https://github.com/Germanunkol/ShaderTutorialFramework.git

The Shader:

We'll need a new file called "outline.glsl". Create the file in the same folder as main.lua.
Into this file, put the following code:

vec4 effect( vec4 col, Image texture, vec2 texturePos, vec2 screenPos )
{
    // simply return the color at the current coordinates:
    return texture2D( texture, texturePos );
}

Short explanation:

Whenever the shader is active, the "effect" function will be called once for every pixel which is drawn. So if we draw a 32x32 pixel image, it'll run for each of the 32*32 = 1024 pixels.
The "col" argument gives us the currently set color, which we won't need for this shader.
The second argument is the image being drawn.
The third argument holds the coordinates for the pixel we're currently drawing - in texture-space (i.e. "Which pixel of the texture are we drawing"), ranging from 0 to 1.
The last argument holds the coordinates of the pixel on the screen (i.e. "Where on the screen are we drawing the pixel") - again something we won't need for this shader.

Inside the function, all we do for now is a texture-lookup: texture2D is a function that simply returns the color of the pixel in the given texture, at the given coordinates. So the shader does not modify anything at the moment - it simply draws the image.
To make sure it's all working, though, let's try setting the shader:
Open up character.lua and add this to the Character:new() function (before the "return o"):

    o.shader = love.graphics.newShader( "outline.glsl" )

This creates a new shader for every character which is created.**
Go down to Character:draw() and modify it to look like this:

function Character:draw()
    love.graphics.setShader( self.shader )
    love.graphics.draw( self.img, quads[self.frame], self.x, self.y )
    love.graphics.setShader()
end

This enabled the shader before drawing the character, and disables the shader again after drawing it.
Run the project (using "love ." or similar) to test if it's working. You should see two characters walking side by side.

** This is probably not an ideal solution if you have loads and loads of characters or units. In that case, you should create only one shader, globally, and then re-use it whenever you need it. That's not really more difficult, but if you want to assign custom values to the shader for your different units (green outlines for friendly units, red for enemies and blue for drunk skeletons?) you'll need to send them every frame before using the shader - that's why I didn't choose this method here.

To see if the shader is working, modify your outline.glsl to this:

vec4 resultCol;
vec4 textureCol;

vec4 effect( vec4 col, Image texture, vec2 texturePos, vec2 screenPos )
{
    textureCol = texture2D( texture, texturePos );
    resultCol = vec4( 1.0f, 1.0f, 1.0f, textureCol.a );
    return resultCol;
}

We perform the texture lookup as before, but then instead of returning that color, we return a modified color where the red, green and blue channels are set to white and only the alpha channel is perserved (textureCol.a gives the alpha of the textureCol color, textureCol.r would give the red value and so on). Run the code - what you should see now is the two characters walking, but they should be plain white. That's what the 1.0, 1.0, 1.0 does.

Now let's create the outline!

The outline should be composed of two things:

The alpha of the outline (i.e. where it is showing) should be given by the second derivative (more precisely the laplacian) of the input image.
The color of the outline should be a fixed color for now.

Let's focus on the first point for now.
Remember, what we need to do is: For every pixel we add together the alpha of the 4 nearest surrounding pixels. Then we subtract the result from 4 times the alpha of the current pixel.
The math is simple. Imagine the function alpha(x, y) can get the alpha of the pixel which is found at an offset of x and y from the current pixel (alpha(0,0) being the alpha of the current pixel) then we can calculate the new alpha as:

alpha = 4*alpha(0,0) - ( alpha(-1,0) + alpha(0,-1) + alpha(1,0) + alpha(0,1) )

In GLSL, we can do this by adding to the texture coordinates, before we do the texture-lookup:

...
{
    number alpha = 4*texture2D( texture, texturePos ).a;
    alpha -= texture2D( texture, texturePos + vec2( 0.001f, 0.0f ) ).a;
    alpha -= texture2D( texture, texturePos + vec2( -0.001f, 0.0f ) ).a;
    alpha -= texture2D( texture, texturePos + vec2( 0.0f, 0.001f ) ).a;
    alpha -= texture2D( texture, texturePos + vec2( 0.0f, -0.001f ) ).a;

Note that we're adding small values like 0.001 to the position for now - this is because the texturePos values range from 0 to 1 (not from 0 to 64 as in our image). If we'd add 1 (or subtract 1, for that matter), we'd move the coordinates not by one pixel, but by the width of the whole image!
Now let's calculate the final color:

    // calculate resulting color
    resultCol = vec4( 1.0f, 1.0f, 1.0f, alpha );
    // return color for current pixel
    return resultCol;
}
...

If we run the game now, we'll see our first outline - hooray!

However if you look closely, you'll see that the outline is a bit thicker at the top and bottom than it is at the right and left - why is that?
Well, to get the coordinates of the "neighbouring pixels", we used a very naive approach: we just added "0.001" to the coordinates, both in x and y direction. Since these are texture coordinates, what that means is "go 0.001 of the image width into the x direction and 0.001 of the image height into the y direction". Since image width and image height of the spritesheet image we're using are not the same (open up skeleton_3.png and you'll see), we're actually moving further up and down than right and left when we try to get "neighbouring" pixels. This effect would be even more noticable if the width and height of our image went more into the extreme - a 20x400 image, for example, would not look good any more.
Instead, we should try to go exactly one pixel left and right.
To do that, let's add a new variable, called "stepSize". This variable will tell us how much we should go left and right, or up and down, in order to move by exactly one pixel. Since we need two different values for horizontal or vertical movement, we make it a "vec2", which holds two values. Add this line at the beginning of the shader (outside the effect funtion):

    extern vec2 stepSize;

We add the keyword "extern" to make sure this variable can be modified from within our Lua code.
Now, instead of the previous fixed value of 0.001, let's use stepSize in our code:

    number alpha = 4*texture2D( texture, texturePos ).a;
    alpha -= texture2D( texture, texturePos + vec2( stepSize.x, 0.0f ) ).a;
    alpha -= texture2D( texture, texturePos + vec2( -stepSize.x, 0.0f ) ).a;
    alpha -= texture2D( texture, texturePos + vec2( 0.0f, stepSize.y ) ).a;
    alpha -= texture2D( texture, texturePos + vec2( 0.0f, -stepSize.y ) ).a;

But how do we calculate the correct step size?
Open up characters.lua again, and jump, once again, to the Character:new() function. After the creation of the shader, add this line:

    o.shader:send( "stepSize",{1/o.img:getWidth(),1/o.img:getHeight()} )

What we do is: We send two values to the "stepSize" variable of the shader. By using 1/width and 1/height, we get exactly distance between two pixels. (If you're confused by that, think of is this way: If the image is 4 pixels wide and 4 pixels high, then stepSize will now hold the values {1/4, 1/4}, or {0.25, 0.25}. Now imagine we're running the effect function for the pixel 1,2. In the effect function, the texturePos variable will now hold {0.25, 0.5}. So adding and subtracting the value 0.25 from it, we'll get the coordinates shown in the following picture:

These are exactly the neighbouring pixels which we want. So the 1/width, 1/height thing did just what we wanted - it calculated the distance in horizontal and vertical direction between pixels in GLSL's texture coordinates.)

Now run the program again - and voilà, we have a pretty outline!

Making it prettier:

To change the color of the outline, you can try changing the line which calculates the resultCol to something like:

    resultCol = vec4( 0.2f, 1.0f, 0.1f, alpha );

To add the outline ontop of the original image, simply draw the image twice, once without and once with outline shader applied:

function Character:draw()
    love.graphics.draw( self.img, quads[self.frame], self.x, self.y )
    love.graphics.setShader( self.shader )
    love.graphics.draw( self.img, quads[self.frame], self.x, self.y )
    love.graphics.setShader()
end

And, most importantly: To make it thicker, play with the stepSize values. Higher values create thicker lines:

    o.shader:send( "stepSize",{3/o.img:getWidth(),3/o.img:getHeight()} )

Closing remarks:

You can download the final example here.
If you want to display the outline even when the character is behind a wall or similar, simply draw the character first (without shader applied), then draw the walls and then draw the outlines above the walls.
We can make the outline shader even prettier if we blur the image using a shader before rendering the outline, or if we blur the outline after creation. I'll leave both of these methods for a possible future blog post, though.
If you have any questions or comments, feel free to write me a pm in the forums.

Sobel filter:

For completeness' sake, here's the approach mentioned above, using the plain derivative (in horizontal direction - it can easily be modified to the vertical direction). Here, no blur is being applied, but you can add that as well by using the Sobel filter kernels above.

vec4 resultCol;
extern number stepSize;

number alpha;

vec4 effect( vec4 col, Image texture, vec2 texturePos, vec2 screenPos )
{
    // get color of pixels:
    alpha = texture2D( texture, texturePos + vec2(0,-stepSize)).a;
    alpha -= texture2D( texture, texturePos + vec2(0,stepSize) ).a;

    // calculate resulting color
    resultCol = vec4( 1.0f, 1.0f, 1.0f, 0.5f*alpha );
    // return color for current pixel
    return resultCol;
}

The skeleton and spearman images used in this post come from OpenGameArt.org and are licensed under the creative commons license. See the following link for authors and copyright information. Thanks to the authors for making these accesible!

Lövely Code #01 - Ternary Operations

Lafolie — Mon, 15 Apr 2013 23:34:58 +0000

Blog Terms:

Hello world, err, lövers! My name is Dale James and I'm writing to introduce you to one of my favourite things you can do in Lua, which is called a Ternary Operation.

I grew up playing video games - my first gaming machine was a Commodore 64 (which I still have, somewhere, with a neat collection of tapes). The more games I played, the more I dreamed of being able to produce my own games. Still to this day whenever I play a game I consider how it was built, what works well and how I could improve it. I have no formal education in programming of any sort, except maybe those 2 lectures I attended for ActionScript, but I'm not sure they count as I remember correcting the lecturer several times. I spent countless hours after school messing with lots of (what I now consider to be) awful frameworks and engines, so you could imagine the rush I got when I first discovered the pure awesomeness that is Löve. No other 2D framework comes close to it in terms of elegance, ease of use, and documentation (oh, that documentation!).

This series of articles, dubbed Lövely Code, is intended to focus on the elegance that blossoms from Löve and Lua. Writing elegant code is very rewarding, fun, and it just looks so darn cool! So, on to Lövely Code #01:

This article assumes that you have a basic knowledge of Lua concepts, particularly data types and expressions.

Ternary?

Many readers may not be aware of the concept of a ternary operator or operation. In Lua we have access to several types of operation - unary, binary and ternary.

A unary operation is an expression with a single operand, or a single 'input value'. According to the Lua 5.1 Manual, Lua features three types of unary operators:

a = -1        --negation
b = not x     --logical negation
c = #"purple" --length, works with tables & strings

A binary operation is an expression with two operands. I bet you can see where this is going. There are lots of binary operators so I'll just list a few of them:

a = 1000 + 337 --need I explain this?
b = a or 1337  --if a is nil or false then b becomes 1337
c = b > 9000   --c becomes true if b is over 9000
d = a          --also binary!
e = "some" .. "thing" --concatenation is actually a binary operator

Now here's the fun part.

As you may have guessed, a ternary operation is one that has three operands. "Three?!" you say? "How does that work? ", you ask, or "Prey tell how this most elusive of operations achieves its resolution, old chap", if you're English like myself, of course I wrote this article whilst wearing my best top hat and monocle, curling my mustache, and eating a lime.

It's actually rather simple. A ternary operation is often used as a substitute for an if/then/else statement.

Delve Into the Secrets

In C-like languages there does exist an operator for ternary expressions, but Lua being Lua, we are treated to a much more elegant and human-readable method for creating these most wondrous of wonders; a combination of and / or operators makes for a beautifully simple ternary operation.

--a simple if/then/else...
if a then
    x = b
else
    x = c
end

--is equivalent to:

x = a and b or c --three operands!

Whoah! What's going on there?! It's actually pretty simple if you break the expression down and evaluate it in the same manner as the Lua VM. If we check the manual for order of precedence we find that and is always evaluated before or. We also know that an and statement outputs the rightmost operand if the left is true, and that or outputs the left unless is it false. Sound confusing? Let's look at this in a way we can all understand.

To The Terminalmobile!

I recommend opening up a Lua console and following along. Start a new Lua session and try each line in sequence.

x = a and b or c
print(x)

Our original statement. This would actually always evaluate to nil since we have not specified a, b or c, so let's give ourselves some sample values to work with.

a = 11
b = "variable b"
c = "variable c"

Now, we're going to use the same expression as above. Before you run the command, take a moment to consider what the output will be...

Ready? Then let's try it!

x = a and b or c
print(x)

You should see the output variable b. What happened is that we said "if a is true then x is equal to b, otherwise it is equal to c". We did a = 11, which in Lua means that if a then will evaluate to true. Just like a basic if/then/else!

So what happens if a is not true? Go ahead, try it:

x = not a and b or c
print(x)

This time you should see the output variable c. Similarly to before, this is because we said "if not a is true then x is equal to b, otherwise it is equal to c". This time, not a evaluates to false. Allow me to demonstrate what is going on here (there is no need to input this block into your terminal):

x = not a and b or c                         --equivalent to
x = false and "variable b" or "variable c"   --equivalent to
x = (false and "variable b") or "variable c" --equivalent to
x = false or "variable c"                    --equivalent to
x = "variable c"                             --tada!

Got it now? This is how a ternary expression works. As you can see, it's actually very simple once you understand the nature of and/or.

Let's try another example:

x = a < 10 and b or c

Oh my science. Just what is going on there?! Now we have a binary expression embedded in our ternary expression........! Don't be fooled: this is simple stuff. "How can you say that?!" you yell at me. Well, if we consider that our ternary expression is rather like an if/then/else we see that it is indeed simple stuff (no need to execute this block either):

if a < 10 then
    x = b
else
    x = c
end

That wasn't so painful was it? So now if we go back and output our new x, what would we see?

print(x)

You should see variable c again. This is because our value a is greater than 10: a < 10 = false. Go ahead and change the binary expression to use greater-than:

x = a > 10 and b or c

We are all over this now! We know what's going happen here! Our x is going to equal variable b, just like you expected.

The Cave(at)

One important thing to note when writing ternary operations is that the 'middle' operand cannot be false/nil (b in our example) ! This is because of the nature of and/or. Try it and see what happens.

x = nil and nil or true
x = nil or true
x = true
--or
x = true and nil or true
x = nil or true
x = true

However, if you need this type of operation, you can simply 'invert' the operands:

x = a == nil and b or a --solved.
x = a == nil and b == false or a --don't do this!

A Winner Is You

Congratulations, you just learned how to write ternary expressions!

Throughout this article I have repeatedly stated that this is a simple concept. In reality, it can be hard to understand at first, but once you get it, it becomes a beautifully simple, elegant way to form expressions in your code.

So where exactly should you be using these most excellent operations?

There is no universal answer. Fear not though, for there are guidelines! Try to avoid convoluted ternary statements, after all we write them for our own sake; use them to make your programs more readable, more elegant, more lövely. An interesting example could be for setting a variable based on whether another exists or not (or setting a default), the condition is also the 'middle' operand:

--if statement basis
if a then
    x = a
else
    x = b
end

--could also be
x = a and a or b --this can be further simplified to (and avoids the caveat!)
x = a or b --this binary operation tastes great with functions

Code to die for.

For further reading, as always I recommend lua-users.org which is where I learned how to write these, and many other Lua concepts. You may find there that more complex forms of the ternary operation can be written, but they truly are complex and are (waaaaay) beyond the scope of this document.

I hope you have enjoyed this article, the first in the Lövely Code series.

Using Noise in Pixel Shaders

Ragzouken — Tue, 02 Apr 2013 14:31:43 +0000

Blog Terms:

Note: this was written for LÖVE 0.8.0, since 0.9.0 the semantics for shaders have changed with the addition of vertex shaders. I have updated the code snippets so they hopefully with work in 0.9.0 but the downloadable examples will be incompatible.

My name is Mark Wonnacott and I’m a Computer Science student at the University of Bristol in the UK. I’m a hobbyist game developer and I am enamoured with the ease and accessibility of LÖVE and its accompanying libraries.

Like a lot of game development amateurs, I got into programming because I wanted to make games. I’m not an artist, game designer, or audio guy, but I like to have a go at it all. Lately I’ve been playing around with visual effects in LÖVE and having a lot of fun.

In this post I’m going to give a very practical start to playing with visual effects in LÖVE, especially using noise. So many things are possible and so much work has already been done, but hopefully this post will give you a starting point for your own exploration.

Pixel Effect Primer

Pixel effects are one of the most powerful features of LÖVE, allowing you to create advanced per-pixel visual effects that exploit hardware acceleration. They’re fairly simple to pick up, and are really fun to play around with.

Setting up a LÖVE pixel effect is really easy: compile the effect when you load, optionally send data to the effect when you update, and then turn the effect on before you draw things.

Download Example 1

function love.load()
    screen = love.graphics.newShader([[
        vec4 effect(vec4 colour, Image image, vec2 local, vec2 screen)
        {
            // red and green scale with proportion of screen coordinates
            vec4 screen_colour = vec4(screen.x / 512.0,
                                      screen.y / 512.0,
                                      0.0,
                                      1.0);

            return screen_colour;
        }
    ]])

    texture = love.graphics.newShader([[
        vec4 effect(vec4 colour, Image image, vec2 local, vec2 screen)
        {
            // red and green components scale with texture coordinates
            vec4 coord_colour = vec4(local.x, local.y, 0.0, 1.0);
            // use the appropriate pixel from the texture
            vec4 image_colour = Texel(image, local);
            // mix the two colours equally
            return mix(coord_colour, image_colour, 0.5);
        }
    ]])

    image = love.graphics.newImage("love-logo.png")
end

function love.draw()
    love.graphics.setShader(screen)
    love.graphics.triangle("fill", 0, 0, 0, 512, 512, 0)
    love.graphics.triangle("fill", 256, 256, 256, 512, 512, 256)
    love.graphics.triangle("fill", 384, 384, 384, 512, 512, 384)

    love.graphics.setShader(texture)
    love.graphics.draw(image, 256, 256, 0.5, 3, 3, 44.5, 44.5)
end

Left: A pixel effect that colourizes the image based on the texture coordinates; the closer x is to 1, the redder the pixel, the closer y is to 1, the greener the pixel. Right: Three triangles with colour entirely determined by screen coordinates; the closer x is to the screen width, the redder the pixel, the closer y is to the screen height, the greener the pixel (notice that screen coordinates count from the bottom in pixel effects).

In simple terms, a LÖVE pixel effect is a function for choosing the colour and transparency of each pixel of a polygon when it is drawn (when you draw an image, you are actually drawing a rectangle where the colour and transparency of pixels is determined from the image data as well as the draw colour). Effects can base that choice on the current draw colour, the screen coordinates of the pixel, and any data sent from the LÖVE program itself; if a sprite is being drawn, then the full image data and the texture coordinates of the pixel are also available. This might seem a little difficult to understand at first, but when you start playing around with effects based on these variables, you can quickly get a feel for how they work.

Pixel effects are written in a language called GLSL, and LÖVE adds some aliases to make things a little more friendly. It’s really not very difficult to learn, the syntax is a lot like C and there are many helpful functions to help you do common things.

Introduction to Noise

Noise is unpredictable data, and is used in computer graphics to generate natural looking structures, patterns and textures. By incorporating noise into pixel effects you can create visual effects that don’t have obvious repetition or geometric pattern but also don’t depend on pre-made textures and images; you can also very easily animate the effects.

Nearly all noise used in computer graphics is gradient noise, which is very different to value noise found in random number generators. Value noise is what you see in visual static; every pixel having a completely random brightness independent of any other. Gradient noise has inherent structure that makes neighbouring pixels similar, giving a smooth noise that is much more suited to creating interesting effects.

The most popular type of noise in computer graphics is Perlin; it is also often used in terrain generation because it has the appearance of random hills. Another type of noise is Worley noise, which is also known as cellular noise because it has the appearance of being divided into cells.

Left: Uniform value noise. Middle: Perlin gradient noise. Right: Worley gradient noise (also known as cellular noise).

Using Noise in Pixel Effects

Using noise in LÖVE pixel effects couldn’t be easier; there are some GLSL implementations of various types of noise online, but better yet I have collected a lot of them together for you. Using noise is as simple as loading the GLSL into a string, prepending it to your existing effect and then calling the noise function within the effect. The noise functions take a vector of inputs; typically spatial dimensions, but you can put in anything you like, and you can get some really great animation by using time as an extra dimension.

Download Example 2

function love.load()
    -- load the noise glsl as a string
    local perlin = love.filesystem.read("perlin2d.glsl")

    -- prepend the noise function definition to the effect definition
    noise = love.graphics.newShader(perlin .. [[
        vec4 effect(vec4 colour, Image image, vec2 local, vec2 screen)
        {
            // scale the screen coordinates to scale the noise
            number noise = perlin2d(screen / 128.0);

            // the noise is between -1 and 1, so scale it between 0 and 1
            noise = noise * 0.5 + 0.5;

            return vec4(noise, noise, noise, 1.0);
        }
    ]])
end

function love.draw()
    -- draw a full screen rectangle using the effect 
    love.graphics.setShader(noise)
    love.graphics.rectangle("fill", 0, 0, 512, 512)
end

Cool Things to Try

People have been using gradient noise to create cool effects for a long time and so there is a wealth of stuff to find online on the subject. I have put a little effect browser together using Quickie to make it easy to play around with different pixel effects.

Download Effect Browser (Zoom with the mouse wheel, pan with right click, press space to move to the next effect, press enter to toggle the stencils)

Left: Using Worley noise as the saturation for a blue hued surface to create a water effect (it looks great when animated in the time dimension). Middle: Stencils can be used to draw the effects onto polygons. Right: By continually adding scaled Perlin noise together you can create a smokey effect. This fractal noise is often used for terrain generation because of the varied scales of natural-looking detail. Bottom: I combine the first two techniques in a game I'm currently working on.

Conclusion

Pixel effects aren’t too difficult to learn, and noise can be easily used to detailed and interesting effects; the real magic is finding new ways to use it. Play with effects and see what you can come up with; my effects browser makes it easy to observe the of effect changing different variables, so modify it for your needs.

If you have any problems, questions comments, or make any cool effects: please comment!

LÖVE 1.0 "Moar Bacon" Released

josefnpat — Mon, 01 Apr 2013 13:32:28 +0000

Blog Terms:

LÖVE 1.0 "Moar Bacon" Released

The dev team, after months of secrecy, are proud to announce the newest release of LÖVE; "Moar Bacon". Here are some quotes that were recorded from #love-supersecretclub;

<Bartbes> I've been working day and night on this release, and it was totally worth dropping out of school to meet this deadline. I just love everyone that much!
<Slime> I am disappointed with everyone so far. I have been popping caffeine pills for the last two months, 24 hours a day, seven days a week to meet this deadline. In my free time, I've been preparing for love 0.9.0 as well.
<VRLD> I have decided to approach the 1.0 release like Grand Theft Auto. If I can kill everyone and get away with it, I know I will have won.
<Bmelts> ...
<Rude> My hands are bleeding! I can't take it any more! This is the end!

Some new features that are available to you right now!

Full sandboxing including mice and keyboard usage.
Complete 3D rendering.
Full iOS integration.
Renaming love.graphics to love.stuff to improve clarity.
Added --obfusicate flag to get rid of those pesky hackers!
Added full HTML rendering
Added in-game internet browser, Internet Explorer 5.5
Automatic facebook and twitter integration.
Updating the Lua 5.1 interpreter with PHP 5.4.13
Every single module available within the luarocks community.
MySQL, PostgreSQL, MariaDB and MSSQL.
Removed the illusive love.setColor
SVN, CVS and Mercurial integration.
All cute characters have now been replaced by occult lovecraftian artwork.
Three new networking libraries.
Moar bacon.
Apple Newton branch.
All that crappy 2D stuff has been removed.
Adding the Qt GUI framework.
love.filesystem now can use ImageData instead of file locations.
New exciting proprietary license.
Dropping support for crappy OS's like linux.
Added linux man page.

And to top things off, the developers have gone through the issue tracker, and added every single feature requested!

Get the source code now!: https://bitbucket.org/rude/love3d

UPDATE:

Upcoming changes that the love community administration has informed me about;

Replacing the forums with imageboard software.

Quick Snips: Delta Time

substitute541 — Fri, 29 Mar 2013 22:03:53 +0000

Blog Terms:

This is a new series I want to work on called "Quick Snips". These are articles that are short and quick, and covers mainly the small stuff that people mostly ignore and take for granted that it is a required thing to create good games.

In this article, we will talk about one (slightly mysterious) variable in love.update(), known as dt or Delta Time.

What is DT?

Delta Time, also known as dt, is how much time has passed between 2 frames, hence the "delta" part of the word. Delta Time is also approximately equal to the reciprocal of the current frames per second (FPS), and consequently, FPS is approximately equal to the reciprocal of Delta Time:

dt = 1/fps
fps = 1/dt

Let's look at one way to use DT.

Counting seconds

One way to use DT is to count time, as DT multiplied by FPS is approximately equal to 1 second. You can do that by adding a global timer variable and adding the DT variable to it.

Here's an implementation of a simple timer using love.update(dt).

timer = 0
function love.update(dt)
    -- this adds dt every frame, adding 1 every second
    timer = timer + dt
    -- this checks if timer is greater than the time interval (in seconds)
    if timer >= timeInterval then
        -- subtract timer by interval
        timer = timer - timeInterval
        -- event
    end
end

You can use this to fire events, for example, fire bullets every 1 second, or reload a gun every 5 seconds.

Note: Do not declare timer inside the love.update(dt) function! That will reset the timer every frame, which is not what we wanted.

Constant speed

Another way to use DT is to make objects move at constant speed. By constant I mean that it ideally looks the same at any framerate (I said ideally because DT isn't exact, but it's okay for most purposes). You can do that by multiplying the speed by DT. This has the effect of the object moving at that speed every second.

function love.update(dt)
    -- this has the effect of moving at a set speed every second, for example, 500 pixels every second
    object.x = object.x + speed*dt
end

Constant Acceleration

Another way to use DT is to add constant acceleration. Like before, by constant I mean it looks the same at any machine, slow or fast. You can do this by adding speed by acceleration multiplied by dt.

function love.update(dt)
    speed = speed + accel*dt
    object.x = object.x + speed*dt
end

Why use Delta Time?

So, why do you want to use DT? Well, here are the 2 main reasons:

So that the movement of your objects looks, ideally, the same at any machine, slow or fast.
Because it is easy to keep track of time using DT other than LÖVE's other timing functions.

Well, that's pretty much the reasons why you would want to use DT.

Alright, I'm done with this article, I hope you learned why many lovers (pretty much every non-beginner) use DT. Any typos or suggestions? Comment here, or send me a PM in the LÖVE Forums!

First-class Functions

MarekkPie — Wed, 20 Mar 2013 23:14:17 +0000

Blog Terms:

This is part one of a two-part blog post on taking advantage of first-class functions in Lua. Part one explains the inner workings of first-class functions from both a generic computer science perspective, and how you implement that within Lua. Part two puts all the theory together to create a lean version of an Entity Manager.

First-class boarding, now available!

Beyond the simplest of problems, a program needs variables in order to store, manipulate, and maintain some important value. Typically, we think of variables as some number value, or a string of characters. When dealing with programs of greater complexity, we begin to think about collections of these atomic units (in Lua, this is accomplished through the monolithic table). Part of being a variable usually requires that you must have some guarantees:

You must be able to be stored;
You must be able to be passed as a parameter to a subroutine (function);
You must be returnable by a subroutine;
You must be able to be created at runtime (during the actual execution of your program);
You must have an intrinsic identity (This is a bit harder to understand, but, philosophically, this means that you have an identity beyond some identifying characteristics. For example, am I, Michael Kosler, definable beyond my name, age, weight, etc.?).

If you are able to provide these guarantees, then you are considered a first-class citizen in programming parlance. All common variables in Lua, i.e. number, string, and table, are first-class citizens. Obviously, a number is stored as a variable, can be passed as an argument to a function, and can be returned from a function.

Functions themselves, however, often did not have this same status. In C, I cannot directly pass a function as a parameter to another function (I can fake it through a function pointer, but I am just passing through something that points to the function, rather than the function itself). In Java (until Java 8 comes out), I cannot store a function inside a variable.

Lua, and many other scripting languages, elevate functions to first-class citizen status. This means that anything I could do with a number, I can do with a function.

Storing a function in a variable

In Lua, we often create functions like this:

  local function foo(a)
    print(a)
  end

Turns out, when Lua interprets the code, it is kind of, but not exactly, looking at it like this:

  local foo = function (a)
    print(a)
  end

I can even re-assign foo to now be a new function.

  local foo = function(a)
    print(a)
  end

  foo = function(a, b)
    print(a, b)
  end

Passing a function as a parameter

Since I can store a function in a variable, I can just as easily pass a function as a parameter. Suppose I have a table of strings that I want to make all uppercase, print, and then make all lowercase.

  local function map(t, f)
    for i = 1, #t do
      t[i] = f(t[i])
    end
  end

  local text = { 'The', 'quick', 'brown', 'fox', 'jumps', 'over', 'the', 'lazy', 'dog.' }

  print(table.concat(text, ' '))
  map(text, string.upper)
  print(table.concat(text, ' '))
  map(text, string.lower)
  print(table.concat(text, ' '))

This map function is a powerful and widely used function in functional programming languages like Haskell, so much so that it is built into its core library.

Returning a function from another function

Since functions are first-class citizens, I have no problem returning them from other functions. Suppose I have an adder function, that rather than adding a bunch of numbers together, creates specialized adder functions.

  function add(n)
    return function (m)
      return m + n
    end
  end

  local addThree = add(3)
  print(addThree(5)) -- 8

Closuring us out

The first two examples are pretty straight-forward. The adder factory function is a bit weirder if you really pay attention to it. Try tracing the execution path, keeping in mind how scope works:

Lua identifies the function add and the variable addThree.
Lua calls the right-hand side of the assignment statement, add(3).
Lua creates a new, anonymous function that takes in a argument m, returning the expression m + n, and returns the anonymous function from add.
Lua calls print(addThree(5)), which calls addThree(5), which returns 8.

But why does it return 8? Once I have left add, the value of n (in our case 3) is out of scope. Furthermore, it looks like I have no guarantees that if I call add(4), that addThree(5) will not suddenly give me 9.

What Lua and other languages that have first-class functions do is create something know as a closure, which takes a snapshot of the variables that are not within the enclosing functions immediate local scope (i.e. the value of n in our example), and carries that state with it for later use. So, the value of n when I created addThree will, within addThree, will always and forever remain 3.

Scope within Lua

MarekkPie — Wed, 13 Mar 2013 17:14:30 +0000

Blog Terms:

Far too often, while opening up a LÖVE file that someone posts on the forums, I see the telltale signs of someone who does not understand the concept of scope. In their player.lua file, they will be referring directly to some variables inside their wall.lua file, which itself refers directly to some tables within the main.lua file.

Granted, there are some instances when polluting the global scope has a few benefits, but you need to truly understand what it means before you can safely do so.

About Me

My name is Michael Kosler, and I'm a college student currently attending Texas A&M University, earning a bachelor's in Computer Science. I previously got a BA in Mathematics from Texas A&M University, and taught high school mathematics for about four months (couldn't even last a year :)). I'm hoping to break into the game industry professionally, and have been using Lua and LÖVE since 2011 to help build out my online portfolio.

What is scope?

Ripped from Wikipedia:

In computer programming, a scope is a context within a computer program in which a variable name or other identifier is valid and can be used, or within which a declaration has effect.

While Wikipedia often gets the definition technically right, it also assumes you probably know what scope is before you begin reading up on scope - a backwards proposition.

Scope, in the most general case, can be distilled down to one question: "Who knows I exist?" This is an important question to ask in programming, because rarely does a program not need to communicate with either other programs or other parts of itself. If you share everything, then you might end up clashing with other parts of your program that need similarly named variables.

Globe Trekking

The global scope is probably the simplest to understand. If I have a variable within the global scope, then it is visible to the entire program. For example, consider two files: a.lua, and b.lua.

a.lua

    -- x is defined in the global scope
    x = 10

    -- foo is defined in the global scope
    function foo()
      -- Since x is global, the function foo can refer to it
      x = x + 5
      print(x)
    end

b.lua

    -- Bring the global scope from a.lua into b.lua
    require 'a'

    -- bar is defined in the global scope
    function bar()
      -- This x is still referring to the x we created in a.lua
      x = x + 10
      foo()
    end

    bar()

Running b.lua prints 25 onto the screen.

I only buy Local Scope

Local scope refers to pretty much all other situations of scoping. Generally, however, to be in the local scope usually means that a variable is visible only to those other variables that share the same scope. I will get to some examples on what local scope looks like in code in a bit, but first I have to steer you away from a common problem.

If you are familiar with other programming languages, then this so far has felt fairly familiar to you. Local scope, however, is where Lua starts acting differently. Consider the following program:

    x = 10

    function foo()
      y = 20
    end

    function bar()
      print(x, y)
    end

    foo()
    bar()

In most other languages, this will give you an error. Why? Because in most other languages, the variable y, defined within the function foo, is local to that function, so when bar tries to print y, it has no understanding as to what y is, and balks.

Lua, on the other hands, happily prints 10, 20. Why? Because, in Lua, all variables are, by default, global. Why would it do that? Ask Dr. Ierusalimschy. All we care about is how we take advantage of local scoping.

Turns out its fairly easy: just append local to any variable that you wish that be inside its local scope. Given that, let us fix the above code snippet to work like other programming languages:

    x = 10

    function foo()
      local y = 20
    end

    function bar()
      print(x, y)
    end

    foo()
    bar()

Now, while this does not quite give us the error we would get in many other programming languages, Lua prints 10, nil, showing that y has no current meaning within the scope of bar.

We can extend this idea of local scope between files as well. Suppose I have three files:

player.lua

    -- some other player functions

    function draw(o)
      love.graphics.setColor(o.color)
      love.graphics.rectangle('fill', o.x, o.y, o.width, o.height)
    end

enemy.lua

    -- some other enemy functions

    function draw(o)
      love.graphics.setColor(o.color)
      love.graphics.circle('fill', o.x, o.y, o.radius)
    end

main.lua

    require 'player'
    require 'enemy'

    local p = {
      x = 10,
      y = 10,
      width = 20,
      height = 50,
      color = { 0, 255, 0 },
    }

    local e = {
      x = 50,
      y = 50,
      radius = 15,
      color = { 255, 0, 0 },
    }

    function love.draw()
      -- Which one is which?
      draw(p)
      draw(e)
    end

Clearly, I want different functions for drawing my player and my enemies. But, both the draw function in player.lua and the draw function in enemy.lua pollute the global scope. So, which draw was used? It actually depends on the order of the require statements, so in our case, the draw in enemy.lua is the draw within the main.lua, so we get an error when we call draw(p), since p does not have radius.

The fix is fairly easy:

player.lua

    -- declare draw as local
    local function draw(o)
      love.graphics.setColor(o.color)
      love.graphics.rectangle('fill', o.x, o.y, o.width, o.height)
    end

    -- return the local version of draw
    return draw

enemy.lua

    -- declare draw as local
    local function draw(o)
      love.graphics.setColor(o.color)
      love.graphics.circle('fill', o.x, o.y, o.radius)
    end

    return draw

main.lua

    -- Assign the return value of the two files to variables
    local playerDraw = require 'player'
    local enemyDraw = require 'enemy'

    local p = {
      x = 10,
      y = 10,
      width = 20,
      height = 50,
      color = { 0, 255, 0 },
    }

    local e = {
      x = 50,
      y = 50,
      radius = 15,
      color = { 255, 0, 0 },
    }

    function love.draw()
      playerDraw(p)
      enemyDraw(e)
    end

Why should I care?

Think of scope as a directory or folder inside your computer. If you exclusively use the global scope, then your computer has simple one directory, with all files shoved inside. In this flat structure, anytime you attempt to save a new file, you would have to be on guard against accidentally overwriting a previously saved file. Luckily, most modern operating systems warn you before you accidentally save over some previous work. Lua, and most other programming languages, do not give you that extra level of protection.

What are you leaving out?

Lua provides quite a few interesting tricks to meddle with the scope of the language. If you are interested, here are a few advanced topics on scope within Lua:

Lexical scoping
Closures
The require function
The Environment NOTE: as of Lua 5.2, this topic has changed significantly

Circle Collisions

substitute541 — Mon, 11 Mar 2013 06:11:13 +0000

Blog Terms:

Hello I'm Phoenix Enero, and in this article (also my first) we will talk about Circular Collisions. But first, let me introduce myself.

I am a programmer in the Philippines. I originally programmed in a programming language called ActionScript 3.0, the programming language used in Flash, and made some pretty cool stuff with it, like a plotting program. After that, I stumbled on LÖVE through a ROBLOX (google it) group called "Love2D Fans". It was a great game engine, partly because it uses a simple programming language called Lua, and I made some games that I, erm, never finished. Okay, I think that's all I need to say about that. So anyways, let's get on with it!

And, before you comment here about that the code is not working, notice that I fixed most of my careless typos. If you have some problems, re-copy-and-paste the code.

Detecting Circular Collisions

First we need to find a way to detect circular collisions. The best way is to use distance checking. It checks if the distance between two circles' centers are less than the sum of their radii (plural of radius). The code will look like this.

function checkDistColl(circleA, circleB)
    local dist = math.sqrt((circleA.x - circleB.x)^2 + (circleA.x - circleB.x)^2)
    return dist <= circleA.radius + circleB.radius
end

However, if you want to optimize your code, you can square both sides, thus getting rid of the math.sqrt function on the left side, and squaring the sum of the radii on the right side.

function checkDistColl(circleA, circleB)
    local dist = (circleA.x - circleB.x)^2 + (circleA.y - circleB.y)^2
    return dist <= (circleA.radius + circleB.radius)^2
end

Collision Resolution

Now we want to know what will happen if they actually collide. But first, let's take a detour and find where the collisions occur.

Calculating the point of collision

This isn't really required for the collisions, but it can have some uses, for example, you can add an explosion effect at the point of the collision.

There are two ways to find the point, the right and the wrong way.

The wrong way, which many tutorials use, is averaging the two center points.

collPointX = (circleA.x + circleB.x)/2
collPointY = (circleA.y + circleB.y)/2

That works only if the circles have the same radius.

The right way that we want to use is a bit more complicated, but it works for circles of any radius:

collPointX  ((circleA.x * circleB.radius) + (circleB.x * circleA.radius))/(circleA.radius + circleB.radius)
collPointY  ((circleA.y * circleB.radius) + (circleB.y * circleA.radius))/(circleA.radius + circleB.radius)

This gives the true x/y coordinates for the collision point. If you don't bother finding the collision point, try finding the midpoint of both circles, as it will be needed later on.

Bouncing Apart

Now, we know when our circles collide into each other, and we know their velocity and their x/y coordinates. How do we work out where they travel next?

There are two ways to do collisions; elastic collisions and inelastic collisions. Elastic collisions, in layman's terms, are collisions in which the objects do not "stick". Think billard balls colliding. Inelastic collisions are when they "stick". Think a bullet penetrating a block of wood. We will do elastic collisions here.

Explaining it in words can be difficult, so I'll add a gif image from Wikipedia. If you would like to learn, in detail, how the formula is derived, click the link in the caption of the image.

Image taken from http://en.wikipedia.org/wiki/Elastic_Collision, was created by Simon Steinmann

Usually, there are a lot of factors that influence collision, such as spin, mass, mass distribution, etc. but in this collision reaction, we will only use the mass factor. If you don't need that much realism, you can substitute mass for the radius of the circle.

The formula has something to do with the conservation of momentum. Momentum is expressed as this:

In words: momentum is mass times the velocity. The conservation of momentum says that, the sum of the momentum of 2 objects before the collision is equal to the sum of the momentum of the 2 objects after the collision. Assuming that the initial velocities are u, and the final velocities are v, the equation of the conservation of momentum is this:

Now you have an equation with two unknowns, v₁ and v₂. To solve an equation with two unknowns, you need to find another equation with the same two unknowns in it. That happens to be dealing with kinetic energy. Kinetic energy is half of the mass times the magnitude of the velocity squared.

Now, it just so happens that, the sum of the kinetic energies of 2 objects before and after the collision remains the same. I have seen no equation-style image for that yet, so I'll just express it in code.

KE1 + KE3 = KE1Final + KE2Final

Expanding it, and factoring out the 1/2's in the kinetic energies (by multiplying both sides by 2) yelds:

(m1 * v1^2) + (m1 * v2^2) =
(m1 * v1Final^2) + (m1 * v2Final^2)

Now you have a different equation with the same two unknowns. If you like algebra quite a bit, I invite you to sit down and try to solve both equations for both unknowns. In the mean time, I'll add Newton's Cradle here.

Incidentally, that represents the conservation of momentum. Haven't I hypnotized you yet?

You done? The equations, solved for both unknowns, is this:

In code, that will look like this, after adding both fractions in each equation:

local newVelX1 = (circleA.vx * (circleA.mass - circleB.mass) + (2 * circleB.mass * circleB.vx)) / (circleA.mass + circleB.mass)
local newVelY1 = (circleA.vy * (circleA.mass - circleB.mass) + (2 * circleB.mass * circleB.vy)) / (circleA.mass + circleB.mass)
local newVelX2 = (circleB.vx * (circleB.mass - circleA.mass) + (2 * circleA.mass * circleA.vx)) / (circleA.mass + circleB.mass)
local newVelY2 = (circleB.vy * (circleB.mass - circleA.mass) + (2 * circleA.mass * circleA.vy)) / (circleA.mass + circleB.mass)

But, if you have seen it, those values for newVelX1/Y1 and newVelX2/Y2, almost have the same fractions. Is there some way to optimize it? Yes there is. I won't explain the solution in detail, but basically, you find the total velocities of both objects. After getting the final velocity of objectA, you then add the total velocity and the final velocity of objectA to find the final velocity of objectB.

You can actually find the total velocity by subtracting both of the initial velocities. That may seem weird but think of it in the viewpoint of the system. Suppose you have a 40kph and 50 kph cars in a freeway, moving in the same direction. Depending on which car you are at, you can see one going at 10kph, or going at -10kph. In other words, it's either going away from you, or falling behind you.

So first, you find the total velocity before the collision. In code, for both axes, it will look like this:

local vxTotal = circleA.vx - circleB.vx
local vyTotal = circleA.vy - circleB.vy

Then, you find the final velocity of circleA:

local newVelX1 = (circleA.vx * (circleA.mass - circleB.mass) + (2 * circleB.mass * circleB.vx)) / (circleA.mass + circleB.mass)
local newVelY1 = (circleA.vy * (circleA.mass - circleB.mass) + (2 * circleB.mass * circleB.vy)) / (circleA.mass + circleB.mass)

Now, you find the final velocity of circleB, using the method I told earlier:

local newVelX2 = vxTotal + newVelX1
local newVelY2 = vyTotal + newVelY1

Well that's better than the double formula. You can actually make this more optimized by using the normal vector, but I won't cover it here.

So now, are we done yet? Hmm, not quite.

Earlier, we made some position updates to our circles and then we check for collisions. Because of that, there is a chance that the two overlap and the velocity is not enough to seperate the two. A solution to that is to do some more math.

Find the midpoint of the 2 circles (or the collision point, if both circles have the same radius). Now set the centers of the two circles to be radius R away from the midpoint, but along the "line of collision". The code will look like this:

midpointX = (circleA.x + circleB.x)/2
midpointY = (circleA.y + circleA.y)/2
dist = math.sqrt((circleA.x - circleB.x)^2 + (circleA.y - circleB.y)^2)
circleA.x = midpointX + circleA.radius * (circleA.x - circleB.x)/dist
circleA.y = midpointY + circleA.radius * (circleA.y - circleB.y)/dist
circleB.x = midpointX + circleB.radius * (circleB.x - circleA.x)/dist
circleB.y = midpointY + circleB.radius * (circleB.y - circleA.y)/dist

That (circleA.x - circleB.x)/dist there is a "normal" vector, that is, a vector with a direction, but with a magnitude of 1, and that is used here to move the circles along the line of collision.

Now, our complete code for the collision resolution function is this:

function circleResolution(circleA, circleB)
    if checkCircleColl(circleA, circleB) then
        -- Find the new velocities
        local vxTotal = circleA.vx - circleB.vx
        local vyTotal = circleA.vy - circleB.vy        
        local newVelX1 = (circleA.vx * (circleA.mass - circleB.mass) + (2 * circleB.mass * circleB.vx)) / (circleA.mass + circleB.mass)
        local newVelY1 = (circleA.vy * (circleA.mass - circleB.mass) + (2 * circleB.mass * circleB.vy)) / (circleA.mass + circleB.mass)
        local newVelX2 = vxTotal + newVelX1
        local newVelY2 = vyTotal + newVelY1        
        
        -- Move the circles so that they don't overlap
        local midpointX = (circleA.x + circleB.x)/2
        local midpointY = (circleA.y + circleA.y)/2
        local dist = math.sqrt((circleA.x - circleB.x)^2 + (circleA.y - circleB.y)^2)
        circleA.x = midpointX + circleA.radius * (circleA.x - circleB.x)/dist
        circleA.y = midpointY + circleA.radius * (circleA.y - circleB.y)/dist
        circleB.x = midpointX + circleB.radius * (circleB.x - circleA.x)/dist
        circleB.y = midpointY + circleB.radius * (circleB.y - circleA.y)/dist
        
        -- Update the velocities
        circleA.vx = newVelX1
        circleA.vy = newVelY1
        circleB.vx = newVelX2
        circleB.vy = newVelY2
    end
end

More than Two

That's good enough for two circles, but what about 3 or more? You need to use a double for-loop for that. The unoptimized way would be this:

for i=1, #objects do
    local partA = objects[i]
    for j=1, #objects do
        local partB = objects[j]
        if i ~= j then
            -- check collision between partA and partB
        end
    end
end

I said that's unoptimized because, it checks for collisions that are already checked. Here's what it will look like for 4 objects.

object1 to object2, object3, object4
object2 to object1, object3, object4
object3 to object1, object2, object4
object4 to object1, object2, object3

If you look carefully, the first statement checks for collisions for object1 and object2. But in the next statement, you are checking for object2 and object1! Certainly, if object1 doesn't collide with the object2, then object2 is also not colliding to object1. A better, more optimized loop, will look like this:

for i=1, #objects-1 do
    local partA = objects[i]
    for j=i+1, #objects do
        local partB = objects[j]
        -- check collision between partA and partB
    end
end

Now what the collision checking for 4 objects will look like this:

object1 to object2, object3, object4
object2 to object3, object4
object3 to object4
object4 to none

Object4 (or the last object in an object array) checks to none, because all of the others are checking for it. So you see that if you use the unoptimized way, it turns out that you checking the collisions 2 times as much.

Download the .love file (typos fixed by the way): circle-collision.love. As always, you can view the source code by either changing the extension to .zip and opening it, or opening it in an archive program like 7-zip.

And we are done!

Alright, now we are done with the collision resolution. I hope you learned something here, and if you have any questions or suggestions, please comment below!

Also, a credit goes to vrld for posting some suggestions too :).

Hello World

josefnpat — Thu, 31 Jan 2013 10:46:19 +0000

Blog Terms:

Welcome

Welcome to the official community blogs!

Firstly, I'd like to say, welcome!

About a month ago, there was a lot of chatter about blogging in the love community, not only on IRC but also the forums. At this point, with the blessings of bartbes, I took it upon myself, not only as a challenge, but a way to contribute to the LÖVE community, a multi-user community based blogging platform. After a lot of hard work, I am happy to present the community blogs!

You'll notice that there is an application process, and this provides two benefits to the community;

It will ensure that content posted to the blog will be of high quality
The posts will have relatable community members that will be dedicated.
The sub-community will be able to manage and monitor itself.

Please see the about page for more information!

Due to this application process, there may not be much content as first, as the first applications that will be processed are the Board Members.

If you have comments or suggestions, or just want to chill, feel free to join our IRC channel, #love-blogs@OFTC!