David Computer @dthompson@toot.cat

it's not often that I make the most of my weekend but I feel like I did that this time. put a huge dent in my outside to-do list.

can't believe I've missed out on this for the 5 years I've lived here.

scoped out a new biking spot that is owned by the massachusetts wildlife dept. as soon as we got there we saw a swamp with a great blue heron in it. yup it's a good spot.

should probably work out the issues with scrolling smoothness first, though.

scrolling is not particularly smooth right now but seeing the animated water is nice. making a side-scrolling map next could be fun because then I could add parallax scrolling support.

building the second half of my stone and creeping thyme walkway

it's a beautiful day, my life isn't on fire at the moment, so maybe I will actually get some stuff done in the garden/yard today.

tile map loading/rendering rewrite complete. now includes support for tiling flipping and animations and generally feels more usable.

imagine voting against unionization

hell yeah I figured it out! chunk based tile map rendering works! next up is adding support for animations, tile rotations, and dynamic map edits... but that's for tomorrow.

gotta love graphics programming. staring at a blank screen wondering "why does nothing show up?" for hours.

a small patch of overwintered claytonia. really great in a mixed salad.

if maps were truly static, it would be easy to generate sparse vertex buffers, but I'd like to support animated tiles and map modification at runtime. a naive solution could be to just completely rebuild the geometry every time there is a new animation frame or modification. it will still be a win over sprite batches because it's very unlikely that the geometry will have to rebuild every frame.

the solution is to divide each map layer up into chunks (32x32 tiles, for example) and render the chunks that are visible each frame. excluding animations, that means that all the vertex data can be generated when the map is loaded and rendering becomes very cheap. the issues I'm still trying to deal with are: 1) maps that use multiple tilesets mean multiple opengl textures, so each chunk needs a separate vertex buffer for each tileset that is used in the chunk, and 2) besides the background layer, most layers are very sparse, so naively creating vertex data for the whole chunk area is a waste of gpu time, and the problem is further compounded when considering the previous issue.

with each new graphics programming challenge I face, I feel like I spend a couple of days staring blankly at emacs before I can write something that is close to a working solution. now that I solved the 9-patch issue, I want to improve Tiled map rendering. right now I just use sprite batching to fill up a big ol' buffer of vertex data each frame, but that's a lot of CPU overhead. map data is *mostly* static (animated tiles need to be updated every so often, etc.) so using a tool meant for data that is likely to be different every frame is a waste.

it even supports two types of scaling for the sides and middle: stretched or tiled.

first significant change to chickadee in awhile. 9-patch rendering via shader magic. the final shader code ended up being really simple.

https://git.dthompson.us/chickadee.git/tree/chickadee/graphics/9-patch.scm

hehehe I figured it out

I kinda suck at writing gpu shaders. I know that it's possible for me to write a shader that renders a 9-patch (a bitmap that is scalable with some constraints, often used for UI elements like button backgrounds) using 2 triangles and some shader magic, but I haven't figured it out yet. my current, naive implementation of 9-patches draws 9 sprites, so reducing draw calls by 88% would be a nice win.