Monthly Archives: December 2014

Simple tricks for faking dynamic 2d lighting

  • Notice: You can get Jumpsmith here

    For many years, lighting effects have been almost standard in games. There are many tricks that developers have used over the years. If you play Super Meat Boy, you’ll see shadows change as platforms in the level appear, disappear, and move. In Monaco, they used ray tracing to shade all the areas that are not in a player’s line of sight. In Limbo, there are layers of fog that partially obfuscate the silhouettes of the game. These methods are awesome, and they can make a game look very polished and professional. However, they tend to require certain capabilities from your graphics library. Today’s blog post is about how to fake some 2d lighting with very simple tricks- no shaders, no raytracing, no alpha blending. Just pure, solid, pixels.

    4 players in a dark room

    4 players in a dark room

    If you think about it, a perfectly dark room would be… well…. black. While making a playable game with a 100% black screen might be a fun challenge, we’ll probably want to make the players and the space around the players have lighting. It would be possible to do this Dragon Warrior 1 style, where the player would be at the center of a 100% lit rectangle, and the rest of the area on the screen is black. The problem with this method is that it looks pretty unnatural to have a perfectly straight line between lit and dark areas.


    Dragon Warrior 1 had lighting!

    Lucky for us, there’s an old pixel art method that we can use to “smooth out” transitions. It’s called dithering. Wikipedia defines dither as “an intentionally applied form of noise used to randomize quantization error, perventing large-scale patterns such as color banding in images.” Yikes. In the context of this post, think of dithering as gradually increasing the number of black pixels. This is what dithering looks like:


    Dithering Example

    If we make the screen all black except for the area around the player, and then use dithering to smooth the transition of the visible area, we’re most of the way there. This is pretty much what I did in the underground levels in Super Pooper, only I had an alpha-blended border instead of a dithered border:


    However, how are we supposed to handle multiple light sources in the same room? The lighting is not very dynamic if you are just drawing the exact same black rectangle with the exact same dithered hole all the time. Also, if we just pasted two of those rectangles on top of each other, the illusion would be quite broken when they intersected.


    This is the wrong way to do fake lighting!

    Never fear, though. I found a sweet way to fake this and make it look awesome. Every frame, make a black rectangle. Next, you’ll need a dither pattern that you can draw onto the black rectangle. The pattern needs to be made up of solid pixels, and they need to all be the same color. Any color is fine, EXCEPT black. I use an ugly pinkish color, with the RGB value of 255, 0, 255. Every frame, draw the “visibility holes”, i.e. dither patterns, onto the black surface in the appropriate areas.


    Overlapping Visibility Areas

    At this point you should have a big rectangle of pixels. Each pixel should be either black, or the other color. Now, tell your game to not draw the pixels of the non-black color on that surface of pixels. In SDL and SDL2, this is called a “Color Key”. Bam! Now, you can have cleanly interconnecting visibility holes in your black room.


    Pink becomes clear.

    You can take it another step further if you use a few different sized dither patterns. This gives you a bit of a flickering effect. In Jumpsmith, I have 5 slightly different dither patterns that the game cycles through every frame.


    These circles get slightly smaller, left to right.

    But…. what if you don’t want the whole room to be dark? What if you want the room to be relatively lit, but with some dark corners? Of course, it is possible to just draw a layer of darkness over everything, but there is one more trick that I used in Jumpsmith that is simple and easy to emulate.

    The game has a feature that I call “Doodads”. These are animated things that can be put in a room. The players cannot interact with them, they do not affect the gameplay, but they do add some visual ambience to the game, and they keep the rooms from looking super bland and static. They were really easy to implement, the game just grabs six 32×32 pixel squares from the tile sheet, and cycles through them. I used them to make little fluttering flags, waterfalls, and pistons.

    One day, I realized I could make a doodad that was just a dither pattern of black pixels. The pattern would just move up and down a few pixels each frame. When I want a room to feel semi-lit, I just put rows of dither doodads on the top and bottom of the screen.


    Semi-lit Room, using dither doodads on the top and bottom.

    So, if you want to have some neat lighting in a 2d game and you don’t want to bother learning shader languages, you can do a few lighting effects with a basic 2d software renderer. Dithering, color mods, and simple animation can make a basic game look pretty awesome.

    If you have any questions or comments, you can leave a reply here or contact me on Twitter @foundtimegames or email me at

    Notice: You can get Jumpsmith here ….You can troll your friends in local multiplayer, create levels with your controller, use custom tilesets and characters, and play levels created by the community.


    Joysticks and Wrapper Classes

  • joystick_you_want_to_map

     Notice: You can get Jumpsmith here

    It’s really important to me that Jumpsmith works with multiple joystick models, and remembers the button configuration of those models. I’m programming with SDL2, which does have its own struct for joystick data. However, I’ve found it is best in the long run to create what is called a “Wrapper Class” which has an SDL joystick struct as an attribute. This way, you can add more methods and attributes to your joysticks as your game develops. Using these wrapper classes, I was able to whip up a button mapping UI in about an hour. Here’s my story:

    A few nights ago, my Logitech Xbox controller started to fail. The OS was suddenly sending the game “Unplugged” and “Plugged In” events for the joystick, even though the USB was firmly plugged into the side of my old trusty laptop. My other gamepads were working fine… it was time to run to the store.


    Jumpsmith only requires 2 buttons to play, but if you want to make levels with a controller, you want 8 buttons. While I was looking around at Video Game Exchange in Augusta, I realized that an SNES controller had the exact right amount of buttons. They had one with a USB connector. Jackpot!

    Every joystick model that is manufactured has its own button configuration, name, and a unique GUID. The button assignments tend to be pretty random. For instance, if you press the A button on a Retrolink NES USB controller, it tells the game that button 1 was just pressed. If you press A on a Yobo SNES USB controller, it tells the game that button 2 was just pressed. On an Xbox contoller, A is button 0. A few months ago, I manually entered all of the data for the 3 joystick models I owned into a little sqlite3 database. With a new model in my arsenal, I figured it was time to suck it up and make a menu that allows players to configure their own joysticks.

    In the Jumpsmith engine, I have a wrapper class for joysticks, and a separate class for joystick models. When a player plugs in a controller, the game compares the joystick’s GUID to the models that it knows. If the GUID is known, the joystick object copies the attributes of the matching model. If the GUID is not found, it defaults to interpreting the new joystick as if it were an Xbox controller, and it creates a new joystick model object.

    The button mapping UI turned out to be really simple, since I had a healthy codebase. It just asks the player to press the button they want to use for jump, sprint, start, select, etc. Then it stores their choices in their joystick object and in the appropriate joystick model object. The models are saved whenever the game is closed.


    Custom button mapping!

    UPDATE: You can get Jumpsmith here

    Jumpsmith is in the late polishing stages right now. I’m planning on selling it on and submitting it to Steam Greenlight in January 2015. If you have any questions or comments, you can reach me at or on twitter @foundtimegames … also, you can leave a comment here.


    Fire. Smoke. Waterfalls. Customize your creations!

  • UPDATE: You can get Jumpsmith here

    I’m happy to announce a new feature I’ve added to the Jumpsmith engine – arbitrary particle systems. I’ve been doing some research and looking at a ton of games, art, and movies, and I was trying to think of some cool things that I could implement to provide a little more visual spice. The game already had particle systems, but they only were being used when something exploded or crumbled on the screen. So, I gave every room an array of 10 regenerating particle systems that could be activated and placed anywhere on the playable area of the screen, and they can be set to behave like fire, smoke, dripping water, sparks, dust, glowing dust, crumbling stone, or a water fountain.

    The blue particles on top of the waterfall make the room come alive when you're playing

    The blue particles on top of the waterfall make the room come alive when you’re playing

    If you aren’t familiar with particle systems, they are a kind of data structure that has been used in computer graphics for many years. Think of a particle system as a thing that has many little objects that move around on their own. For many effects, each particle has an x and y position, a velocity, and a lifespan, each of which are randomized within certain bounds.

    Example: You want to make a little puff of smoke on the screen. You could set up a particle system with 10 particles, and make all of them move either 1 or 2 pixels up towards the top the screen every time the screen updates. You could also make them come out of a random location within a 5 by 10 pixel rectangle on the screen, and make each particle disappear after 10-20 screen updates.

    We didn't start the fire. It's been burning since the world was loaded from that sqlite3 database.

    We didn’t start the fire. It’s been burning since the world was loaded from that sqlite3 database.

    Of course, it would take some programming to get that all to work, and to work efficiently. Luckily, if you’re making a level in Jumpsmith, you don’t have to think about those details. I made a slick user interface that lets you set up particle systems with your game controller or keyboard. Of course, if you’re trying to make your own game, I suggest checking out this book to learn about how to program your own particle systems.


    You can overlap the systems as you wish, and they do not have to stay on the tile grid.

    I’ll keep you posted every week with more updates about the game… I’m working many hours in hopes of releasing Jumpsmith within the next two months. Please let me know if you have any ideas or suggestions.

    UPDATE: You can get Jumpsmith here

    This treasure room looks pretty groovy with magic dust on the center platform.

    This treasure room looks pretty groovy with magic dust on the center platform.

    Create your own character!

  • TLDR: Get a blank character template here:

    UPDATE: You can get Jumpsmith here

    Hi folks,

    It’s been a busy week at Found Time Games… I’ve been working on the community website for Jumpsmith. Here’s a screenshot of what I have so far:


    You’ll be able to download, rate, and share game levels, characters, and tilesets. If you’d like to try your hand at making a character, you can use this blank character template and upload it once I add the upload functionality to the site. Please let me know if you have any questions. My email is

    On a side note:IMG_20141203_110427If your car gets stuck, you can connect two winches to a tree and turn your arm into a tow truck!