Mike Owens

Renaissance Hacker Extraordinaire (look at the ego on this one)

Filespanker LLC

September 21

Ratform

I’ve been playing with the idea of a platform game for a few weeks now. I’ve been posting daily screenshots to stay motivated at imgur, but seriously, imgur sorta sucks. I’m gonna go back (now) and import them here. Stay tuned.

September 19
Day 16: Rubygame, Audio, Cleanups If you’re using SDL/OpenGL with Ruby, just use Rubygame. It brings in sdl-ffi (which apparently Nice-FFI was written for), and in general just uncomplicates things. I had almost converted to Glut a few days ago to get rid of my SDL dependency, but now I’m glad I didn’t. I was only using SDL for events and getting a GL context. Swapping over to Rubygame let me do both of those things, but with a MUCH nicer interface, add sound/background music trivially, and I finally fixed my game loop timestep. Realizing where the next few steps were headed, I took out a bunch of “works for now” hacks and put a lot of things where they needed to be. Ruby’s “require” is seriously deficient vs. Python’s “import”. The lack of an __init__.rb makes a bunch of “proxy requires” necessary for libs, and INSIDE the lib, you end up with Rails-style File.dirname(__FILE__) cruft. I have four goals over the next few days: A) Get a real hold on the camera. The time for glOrtho has passed, because I need parallax layers. B) Tighten up the controls for the player. I’m tired of him skating everywhere. C) Get the dude animated. How I do this depends on… D) Decide how I handle getting large SVG objects on the screen. My GeometryRender can handle simple objects (solid fill, no stroke), but I’ll have to introduce the concept of a “stacked mesh” to get them on screen. My CairoRender can render damn near anything, except the texture sizes would be unreal for things like the tree to the left. I’d have to splice them even across single objects, and get into the texture-virtual-memory game, which I don’t look forward to.

Day 16: Rubygame, Audio, Cleanups

If you’re using SDL/OpenGL with Ruby, just use Rubygame. It brings in sdl-ffi (which apparently Nice-FFI was written for), and in general just uncomplicates things. I had almost converted to Glut a few days ago to get rid of my SDL dependency, but now I’m glad I didn’t. I was only using SDL for events and getting a GL context. Swapping over to Rubygame let me do both of those things, but with a MUCH nicer interface, add sound/background music trivially, and I finally fixed my game loop timestep. Realizing where the next few steps were headed, I took out a bunch of “works for now” hacks and put a lot of things where they needed to be.

Ruby’s “require” is seriously deficient vs. Python’s “import”. The lack of an __init__.rb makes a bunch of “proxy requires” necessary for libs, and INSIDE the lib, you end up with Rails-style File.dirname(__FILE__) cruft.

I have four goals over the next few days:
A) Get a real hold on the camera. The time for glOrtho has passed, because I need parallax layers.
B) Tighten up the controls for the player. I’m tired of him skating everywhere.
C) Get the dude animated. How I do this depends on…
D) Decide how I handle getting large SVG objects on the screen.

My GeometryRender can handle simple objects (solid fill, no stroke), but I’ll have to introduce the concept of a “stacked mesh” to get them on screen. My CairoRender can render damn near anything, except the texture sizes would be unreal for things like the tree to the left. I’d have to splice them even across single objects, and get into the texture-virtual-memory game, which I don’t look forward to.

+
Day 16: 2D Mesh Loading 2D mesh loading works. Going to spend the rest of the day on huge cleanups, because this is about to get complicated.

Day 16: 2D Mesh Loading

2D mesh loading works. Going to spend the rest of the day on huge cleanups, because this is about to get complicated.

September 18
Day 15: Texture Mapping Failure I’m having a hell of a time getting all my texture mapping stuff working. For some reason I’m getting REALLY strange results for poly bounding-rects. The larger box in the top left is supposed to be similar in size to the smaller one. Tracing this down. Probably yet another CTM bug.

Day 15: Texture Mapping Failure

I’m having a hell of a time getting all my texture mapping stuff working. For some reason I’m getting REALLY strange results for poly bounding-rects. The larger box in the top left is supposed to be similar in size to the smaller one. Tracing this down. Probably yet another CTM bug.

September 17
Day 14: Transforms and Arcs I pretty much lost a day tracing down a bug that I thought was going on somewhere in the CTM, but turned out to be an ordering fuck-up in turning an SVG curve into a polygon via the Bézier approximation code. Was translating via the CTM before converting the SVG arc’s coordinates from relative to absolute. Total mess. This was hard to nail down WITH ruby-debug. I can’t imagine what it would’ve been like without it. No idea why this particular screenshot ended up some blurry.

Day 14: Transforms and Arcs

I pretty much lost a day tracing down a bug that I thought was going on somewhere in the CTM, but turned out to be an ordering fuck-up in turning an SVG curve into a polygon via the Bézier approximation code. Was translating via the CTM before converting the SVG arc’s coordinates from relative to absolute. Total mess. This was hard to nail down WITH ruby-debug. I can’t imagine what it would’ve been like without it.

No idea why this particular screenshot ended up some blurry.

September 16
Day 13: Vector Geometry Screw all that marching squares and tiling and Douglas-Peucker raster stuff. Resolution independence, ease of editing. SVG-based physics are go. Now it’s just a little matter of doing to get vector visuals up. Working on a scheme that only rasterizes textures when required.

Day 13: Vector Geometry

Screw all that marching squares and tiling and Douglas-Peucker raster stuff. Resolution independence, ease of editing. SVG-based physics are go. Now it’s just a little matter of doing to get vector visuals up. Working on a scheme that only rasterizes textures when required.

+
Day 13: Damn SVG Lost three days rigging Cairo and my SVG parser to the physics engine. Don’t want to talk about it. Moving forward.

Day 13: Damn SVG

Lost three days rigging Cairo and my SVG parser to the physics engine. Don’t want to talk about it. Moving forward.

September 13
Day 10: “Fuck it, We’re Going Vector” I kept playing with the level designs, and noticed a common pattern: Draw an object in Inkscape, paste it into a tileset, drop that tileset into a level once. I realized that, for the type of levels I want to have, tiling is mostly a waste because too many tiles are only used once. And in that case, there’s no point in having it used up as bitmap data. From here on out, Ratform levels are SVGs. Not in that toy “draw a rope and now it has physics!” way, but particularly structured Inkscape SVGs. The W3C really fucked up on the SVG format. For a casual implementation (the type of hack implementations that get a format entrenched), the totally blew it with Elliptical Arcs. You go through, adding features as you need, until you hit Elliptical Arc (A/a). Look at this, and tell me how you’d BEGIN to implement it: http://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands I ported Raphael.js’ implementation to Ruby, and it’s 116 lines of heavy trig. 116 lines of Ruby is saying a lot. Anyway, pictured here is my mostly-working SVG renderer. Not rigged to anything yet, plan to implement gradients and shadows and call it done.

Day 10: “Fuck it, We’re Going Vector”

I kept playing with the level designs, and noticed a common pattern: Draw an object in Inkscape, paste it into a tileset, drop that tileset into a level once. I realized that, for the type of levels I want to have, tiling is mostly a waste because too many tiles are only used once. And in that case, there’s no point in having it used up as bitmap data. From here on out, Ratform levels are SVGs. Not in that toy “draw a rope and now it has physics!” way, but particularly structured Inkscape SVGs. The W3C really fucked up on the SVG format. For a casual implementation (the type of hack implementations that get a format entrenched), the totally blew it with Elliptical Arcs. You go through, adding features as you need, until you hit Elliptical Arc (A/a). Look at this, and tell me how you’d BEGIN to implement it: http://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands

I ported Raphael.js’ implementation to Ruby, and it’s 116 lines of heavy trig. 116 lines of Ruby is saying a lot. Anyway, pictured here is my mostly-working SVG renderer. Not rigged to anything yet, plan to implement gradients and shadows and call it done.

September 12
Day 09: Layers Got the camera elastic, and the layers working as expected. People, you cannot replace the Douglas-Peucker algorithm with a 8-line “quick pass”. Thinking “I don’t need all that” has probably cost me three of these 9 days. Geometry is solid now that I’m using an algorithm that was actually thought out. I can stop fucking with it and move on without hitting edge cases. Too tired for for more images now. Everything from here on out looks like a game, though not a wireworld.

Day 09: Layers

Got the camera elastic, and the layers working as expected. People, you cannot replace the Douglas-Peucker algorithm with a 8-line “quick pass”. Thinking “I don’t need all that” has probably cost me three of these 9 days. Geometry is solid now that I’m using an algorithm that was actually thought out. I can stop fucking with it and move on without hitting edge cases. Too tired for for more images now. Everything from here on out looks like a game, though not a wireworld.

+
Day 09: Elastic Camera Trying to find the perfect (physics) constraints for an elastic camera. The idea is, instead of perfectly centering the camera on the character, we have a camera object that TRIES to be centered on the character, but is connected to the camera via a pretty stiff spring. I’m getting close, but there are some joint parameters I’m having an issue with.

Day 09: Elastic Camera

Trying to find the perfect (physics) constraints for an elastic camera. The idea is, instead of perfectly centering the camera on the character, we have a camera object that TRIES to be centered on the character, but is connected to the camera via a pretty stiff spring. I’m getting close, but there are some joint parameters I’m having an issue with.