Andrew Reece
This post is meant to provide a general overview of the code structure to contextualize later information.

As with Handmade Hero, I'm using a win32 layer that opens a dll with the platform-independent interaction and rendering code. The dll is watched and reloaded when it gets recompiled.

All the drawing is based on a large array of points, which shapes index into for their constituent components. This allows for easily moving points around both individually by the user and as a group when rotating/panning/zooming the canvas.
These are currently alongside a parallel array of bytes that comprise bit flags for the status of the points, e.g. whether it's an intersection and/or the centre of a circle.

The main shapes are line segments, circles and arcs. Rays and lines (infinitely long in one and two directions, respectively) might be added later. They are numeric indices into the points array.
  • Lines are simply 2 points that are drawn between.
  • Circles are also 2 points: one represents the centre/focus point, the other a point on the circumference. The distance between these points represents the radius.
  • Arcs are 3 points: a focus, a point on the circumference that indicates both radius and the start of the arc, and a point indicating the end of the arc.

Software Rendering
Everything is currently drawn with a software renderer with functions I wrote myself. This was partly just for the challenge, partly to learn better how it all works, and partly because I haven't yet learnt how to use OpenGL.

Debug Systems
I currently use 4 different methods for providing debug info:
  1. A print function at the end of my main loop for providing info on things that don't need a high resolution - mostly looking at mouse position, basis vectors, that sort of thing.
  2. A global debug text buffer that can be written to and cleared from anywhere in the code - this has been most useful for tracking things at a higher resolution than once per frame, often once per loop.
  3. A simple text logger - I put this in place after the program was crashing in a way that for some reason I couldn't debug in the VS debugger (I forget the details now). I clear it at the beginning of the frame, then use it to log the function, line, file and an additional string at various points. It meant I could check the log afterwards to see what section it was crashing in.
  4. Printing a list of all (well... the first 32 or so) points along with the shape points and point statuses.

Next post will get a bit more detailed, looking at how I draw lines.
Andrew Reece
No longer shall you be disoriented by rapid changes in the movement or rotation of the canvas. Be smoothly transported from one place to another as if guided by well-oiled bearings. Furthermore, do so under the 'G' banners proudly emblazoned on the taskbar and corner of your window.

Download directly or from the Geometer Github repo.
Andrew Reece
The shackles keeping your canvas in place have been cast off! Exercise your newfound freedom by moving around, looking at the world from different angles, and getting up close to really appreciate those pixelly curves.

Download v0.7 directly or the Geometer GitHub page.

  • Pan with the arrow keys or middle-click + drag or space + left-click + drag.
  • Return to the origin with Home.
  • Zoom with PgUp/PgDown or the scroll wheel.
  • Rotation is achieved by setting the (horizontal, right-facing) x-axis. After selecting a point, Alt + left-click to set the x-axis along the line that would have been drawn.
  • The canvas can now be resized.
  • Alt + Enter to enter and exit full-screen.
  • End toggles debug info.
Andrew Reece
Hi all, thanks for checking out my project. The software I'm making, 'Geometer', is a desktop application for drawing in a way that emulates traditional construction with compass and straightedge. There's more info on the impetus behind it on the main project page, so I'll try not to repeat myself too much here.

This is just to provide a brief introduction to me, the project, and what I'll be doing with this blog.


I'll get the self-aggrandizing part out of the way so we can focus on the important stuff.

I'm Andrew, I've just graduated with a BSc in Ergonomics (Human Factors Design) from Loughborough University. I started learning to program a few years ago, when I asked a comp-sci student I knew how I could get into making games. This was initially using Processing, which has the advantage that you can get into graphical content and interaction straight away. School, mediocre self-organisation, and making things in other mediums meant that I went for large stretches without writing any code. I've dabbled in blacksmithing, electronics, sewing and woodwork, and set up a small leatherwork business in my gap year (you can check out my portfolio if you're interested). When I was programming, I finished a few small projects while flitting between languages, looking for the Right One.

Coming back to the allure of the glowing screen, I remembered my brother tipping me off to Casey streaming the process of making a game from scratch. I was familiar with Casey from a few episodes of the Jeff and Casey Show, and immediately got absorbed in watching the 'Intro to C' videos and Handmade Hero proper. After briefly considering trying to follow along in Rust, I decided to just use C. I followed along directly to begin with, then branched out to rasterizing basic shapes and that sort of thing. Once I had just enough of an engine to make something, I set myself the challenge of creating a game in a day. I ended up with the 2-player version of Twinstick Sumo. The next day I made one important tweak and added some simple randomized AI behaviours, so you can play by yourself.

The Project

Motivated by successfully completed a basic (but surprisingly fun!) game, I set my sights a little higher... a little too high. I had some cool ideas for a more complicated game. I made a good start with it, but fairly soon I realised that I was going to have to implement a host of things that I hadn't learned about so far. It made sense to put it on the backburner and refocus on smaller projects that would build my skillset and hopefully be useful/fun in their own right. This is one of those projects.

I got into using a physical compass and straightedge for some woodwork, and tools for them as a design paradigm (not just maths) don't really exist digitally. I've enjoyed playing around with, which nails the line-circle intersection drawing, but there are key considerations for design that it ignores. For one thing, you can't draw arcs. For another, there is no way to draw anywhere but intersections. This is not to fault it at all, it obviously has a different objective from my project. I think that Geometer can provide 2 main benefits compared to your favourite fancy editing software:

  1. a restriction in tools that encourages you to learn about visual rhythms, flow, and balance of design.
  2. an efficient, uncluttered UI that can make using the few tools you do have very fast.

I'm coding the whole project in C (not a minimal C++ subset) for a similar reasons: the small language forces me to consider concepts rather than waste time obsessing over which language features to use (which I would be prone to do).

The Blog

My main plan for this blog is to explain:
  • my user-facing design choices (and hopefully elicit some useful feedback)
  • problems I've encountered (and how I've solved them)
  • details of my approach to some of the more technical parts (rasterizing circles, arc-line intersection...)
There'll probably be some more general project-related stuff as well, and possibly some comments on geometric construction.

I've got a list of blog titles in mind, but I think I'll be starting with a general overview of how I've laid out the program.

Until next time, if you're interested in learning about design with a compass and straightedge (and sometimes a sector), By Hound and Eye (a play on By Hand and Eye, another book by the authors) is a straightforward, practical, and lighthearted introduction to the topic.