A robot may not injure humanity or, through inaction, allow humanity to come to harm.

A robot may not harm a human being.

A robot must obey the orders given it by human beings except where such orders would conflict with the First Law

A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

A robot must know it is a robot.

Isaac Asimov popularized the “Three Laws of Robotics” in his Robot series, starting in 1940. Asimov is a pillar of modern day science fiction. Not “just a writer”, he was a full on scientist, philosopher, and all around renaissance man. Asimov gave us the word “robotics”, and here we are!

It was 5 years ago when I wrote about my home automation efforts: Home Automation – Choosing Bulbs

Back then, I was enthusiastic about replacing the myriad halogen bulbs in my house with LED based bulbs, and while I was at it, ‘automating’ them as well. I installed Philips Hue, some Lutron dimmers, and hooked it all up to Alexa so I could say “downstairs lights on!”. So, 5 years on, how has it gone?

Well, aside from doing the occasional demo of turning the lights on and off by talking to the ever present speaker, we really don’t use the automation at all. Why not? It’s far easier to just flick the light switch on or off when you enter/exit a room, and we never really got into ‘automation’, like setting up on/off patterns when on vacation.

I am a tinkerer by birth. I’ve been fiddling about with stuff since I was old enough to take a screwdriver off my dad’s workbench. I’ve done mechanical things, home repair, wood working, gardening, 3d printing, lasering, just a little bit of everything over the years. While my main profession for about 40 years has been software development, I make the rounds through my various hobbies on a fairly regular basis.

The “AI” space writ large, covers an array of different topics. At this moment in time, the Large Language Models (LLMs) have captured everyone’s imagination, due to their uncanny ability to give seemingly good answers to a number of run of the mill questions. I have been using ChatGPT specifically for the past year or so, and have found it to be a useful companion for certain tasks. The combination I use is GitHub Copilot, in my Visual Studio development environment, and ChatGPT on the side. Copilot is great for doing very sophisticated copy and paste based on comments I type in my code. ChatGPT is good for exploring new areas I’m not familiar with, and making suggestions as to things I can try.

I can remember when in the 1980s and 90s, we programmers were talking about things such as SmallTalk, Lisp machines, the Prolog programming language, and this upstart C++. Lots of discussions around modularity, simulation, patterns of programming and whatnot. Back then, we even had the discussions around neural networks, back propagation, and even nano scale computers, driven by push rods…

We recently took a family vacation to Southern California. Some fun in the sun at the beaches, with a side trip to Disneyland to boot. We had first considered driving down from Seattle to Newport Beach, a drive we’ve actually done before, but we ultimately decided to fly down instead, and rent a car.

There is a common theme throughout life; “Should I build, or buy?” It doesn’t seem to matter which thing is under consideration, the process we used to make the decision should remain the same. This is a multi-part series on making the build vs buy decision for software projects.

It’s time to put the pieces together and get to rendering some SVG!

In the last couple of installments, we were looking at how to do some very low level scanning and parsing. We got through the basics of XML, and looked at some geometry with parsing of the SVG <path> ‘d’ element. The next step is to decide on how we’re going to represent an entire document in memory so that we can render the whole image. This is a pretty big subject, so we’ll start with some design constraints and goals.

In the last installment (It’s XML, How hard could it be?), we got as far as being able to scan XML, and generate a bunch of XmlElement objects. That’s a great first couple of steps, and now the really interesting parts begin. But, first, before we get knee deep into the seriousness of the rest of SVG, we need to deal with the graphics subsystem. It’s one thing to ‘parse’ SVG, and even build up a Document Object Model (DOM). It’s quite another to actually do the rendering of the same. To do both, in a compact form, with speed and agility, that’s what we’re after.

Let’s take a look at the SVG (XML) code that generates that image.

By the end of this post, we should be able to scan through the components of that, and generate the tokens necessary to begin rendering it as SVG. So, where to start?

Scalable Vector Graphics, is a XML based format. So, the first thing we want to do is create an XML ‘parser’. I put that in quotes because we don’t really need to create a full fledged conformant, validating, XML parser. This is the first design principle I’m going to be following. Here I want to create just enough to make things work, with an eye towards future proofing and extensibility, but not go so far as to make it absolutely bullet proof. So, I’ll be writing just enough code to scan some typical .svg files, while leaving room to swap out our quick and dirty parser for something that is more substantial in the future.

In the series I did last summer (Hello Scene), I walked through the fundamentals of creating a simple graphics system, from the ground up. Putting a window on the screen, setting pixels, drawing, text, visual effects, screen captures, and all that. Along the way, I discussed various design choices and tradeoffs that I made while creating the code.

As 2022 comes to a close, I am somewhat reflective, but, mostly looking ahead. This past year was certainly tumultuous on several fronts. Coming more solidly out of Covid protocols, kids firmly back in school, life contemplated, and perhaps most impactful personally, leaving Microsoft after 24 years of service.

I have been writing code since about 1978, when I first had access to a Commodore PET computer. For me, it’s always been about having fun, doing things with the machine that might not be obvious, and certainly not achievable on my own. Over the years, I’ve picked up some tips and tricks to help me get to the interesting parts sooner rather than later. During the 1980s-1990s, there was a ‘demo scene’ wherein coders such as myself, were engaged in trying to push our ‘personal computers’ to the limit in terms of what they could do visually, and with audio. This demo scene was often centered around computers such as the Commodore 64, or Apple II, or the venerable Commodore Amiga. The demo scene days are largely gone, and computers are a few orders of magnitude more powerful than those early personal computers.

And yet…

That’s a lot of fonts. But, it’s a relatively simple task to achieve once we’ve gained some understanding of how to deal with text. We’ll park this bit of code here (fontlist.cpp) while we gain some understanding.

I must say, dealing with fonts, and text rendering is one of the most challenging of the graphics disciplines. We could spend years and gigabytes of text explaining the intricacies of how fonts and text work. For our demo scene, we’re not going to get into all that though. We just want a little bit of text to be able to splash around here and there. So, I’m going to go the easy route, and explain how to use the system text rendering and incorporate it into the rest of our little demo framework.

Being able to capture the display screen opens up some interesting possibilities for our demo scenes.

In this particular case, my demo app is capturing a part of my screen, and using it as a ‘texture map’ on a trapezoid, and compositing that onto a perlin noise background. The capture is live, as we’ll see shortly, but first, the code that does this little demo (sampmania.cpp).

If there’s no recording, did it happen? One of the most useful features of the demo scene is the ability to record what’s being generated on the screen. There are plenty of ways to do that, external to the program. At the very least though, you need to be able to save individual frames.

But, I’m getting slightly ahead of myself.

First, we need to revisit the main event loop and see how it is that we get regularly timed ‘frames’ in the first place.