MrFariator's random things

Anonymous asked: How do you optimize colliders of your maps? From one gif I've seen it looks like if you for example place 9 tiles in square shape one by one they will be merged into 1 collider rather than stay as 9, or a T shape will be optimized into 2 rectangles, how is it done?

When tiles get placed into the editor, it does these basic steps:

• Check which regions of the map were affected, defined as “map cells” (in GC’s case it’s 25x15 tiles, a tile being 16x16 pixels).
  
• Starting from top-left of an affected map cell, pick a tile that is not empty. Lets call this tile X. 
• Check the tile to the right of X: if that tile contains the same collision properties, then mark it “consumed” and increase the width of X’s collision mask.
• Continue doing this width-check until the right edge of the map cell, an empty tile or a tile with different properties (eq. maybe a damaging tile as opposed to a solid one) is reached.
• Now, start comparing tiles below X’s entire width and see if for that entire width the collision properties are the same, and there are no empty gaps. If yes, mark all of those tiles consumed, and increase X’s height.
• Continue doing this height-check until a gap, different tile or the map cell’s bottom edge has been reached. 
• Store resulting X’s width and height, and put the resulting rectangle into a table.
• Pick an unconsumed tile and repeat steps above for any tiles that remain unconsumed in the map cell, going from left-to-right, top-to-bottom.
• After all tiles have been consumed in the map cell, take the table with the rectangles, and populate the physical world with it. Replace the original collision mask table for that map cell, if one existed previously.

(gif for visualizing what’s happening to anyone who might be reading; the red is the collision mask being generated)

That’s the basic overview, and the algorithm is basically akin to something like breadth-first check, or I guess more accurately width-first-and-then-height rectangle check. Of course, I’m glossing over a few details (when the collision mask generation is effectively done, tiles are simple FFI structs and do not contain any collision data by themselves, some corner cases, etc), but you should get the idea.

For physics themselves, I used kikito’s bump.lua for collisions, and rolled my own physics code since I don’t need all that intricate behavior. 

Anonymous asked: I saw some of your stuff on love2d forum, your gifs are really smooth, how do you record them?

The gifs I have posted on love2d forums were recorded using LICEcap. However, gifs recorded with LICEcap do not play nice with Discord’s compression (You need to click on the gif and “Open original”, otherwise the gifs may appear like epileptic messes), and it can really struggle along to maintain 60fps, usually hovering around 30~40fps. It’s still a nice and tiny program that works on both Windows and Mac, so if you don’t care about Discord or recording audio then you can use it just fine.

Because I want that smoother 60fps and occasional audio recording though, I have since moved to ShareX.

Have a good one, chaps.

Anonymous asked: I can not get over how fun your game looks. Seriously, both the mechanics and aesthetics are absolutely MUAH. Can't wait to play it. ♥