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.

There are some design principles I’m after with my little demo scene library. Staring at that picture is enough to make your eyes hurt, but we’ll explore when it’s time to call it quits on your own home brew drawing library, and rely on the professionals. We’re also going to explore the whole eventing model, because this is where a lot of fun can come into the picture.

What is eventing then? Mouse, keyboard, touch, pen, all those ways the user can give input to a program. At times, the thing I’m trying to explore is the eventing model itself, so I need some flexibility in how the various mouse and keyboard events are percolated through the system. I don’t want to be forced into a single model designated by the operating system, so I build up a structure that gives me that flexibility.

First things first though. On Windows, and any other system, I need to actually capture the mouse and keyboard stuff, typically decode it, and then deal with it in my world. That code looks like this in the appmain.cpp file.

Yes, what is a Window? How do I draw, how do I handle the user’s mouse/keyboard/joystick/touch/gestures?

As a commenter pointed out on the my last post, I’ve actually covered these topics before. Back then, the operative framework was ‘drawproc’. The design center for drawproc was being able to create ‘modules’, which were .dll files, and then load them dynamically with drawproc at runtime. I was essentially showing people how something like an internet browser might be able to work.

Things have evolved since then, and what I’m presenting here goes more into the design choices I’ve made along the way. So, what’s in a “Window”?

It’s about a couple of things. Surely it’s about displaying things on the screen. In most applications, the keyboard, mouse, and other ‘events’, are also handled by the Window, or at least strongly related to it. This has been true in the Windows environment from day one, and still persists to this day. For my demo scene apps, I want to make things are easy as possible. Simply, I want a pointer to some kind of frame buffer, where I can just manipulate the values of individual pixels. That’s first and foremost.

How to put random pixels on the screen? In minwe, there are some global variables created as part of the runtime construction. So, let’s look at a fairly simple application and walk through the bits and pieces available.

My style of software coding involves a lot of quick and dirty prototyping. Sometimes I’m simply checking out the API of some library, other times I’m trying to hash out the details of some routine I myself am writing. Whatever the case, I want to get the boilerplate code out of the way. On Windows, I don’t want to worry about whatever startup code is involved, I just want to put a window on the screen (or not), and start writing my code.

I first started programming around 1978. Way back then, the machines were Commodore PET, RadioShack TRS-80, and later Apple I and the like. The literal birth of ‘personal’ computing. A spreadsheet (VisiCalc) was the talk of the town, transforming mainframe work, and thus ‘do at office’ into “do at home”, work. That was, I think, the original impetus for “work from home”. And here we are again…

I joined Microsoft in November of 1998. During black history month in 2022, I sent out an email to my friends and colleagues giving a brief summary of my time at the company, my own personal “black history”. Over the past year, I’ve been engaged in some personal brand evolution, and I thought blogging is good for long form communications. So here, I’m going to repeat some of that Microsoft history as a way to set the stage for the future. So, here, almost unedited, is the missive I shared with various people as a reflection on black history month, 2022.

I saw reference to this while browsing through some Teams channels, and I thought, Oh, ok, one of those shaky cell phone productions, let’s see…

Oh boy was I wrong. This is full on “ready for broadway” style musical entertainment. My takeaways: We have cool interns, look at that diverse bunch, they can sing, they can produce, they did this as a passion project while still maintaining their day jobs…

It’s been about 3 years since I built a monster of a desktop machine with water cooling, fans, LEDs and all that. Long time readers will remember the disastrous outcome of that adventure as the liquid leaked, drown my electronics, and caused me to essentially abandon the thing. I somewhat recovered from the fiasco by purchasing a new motherboard, and trying to limp along with various of the components from that original build. Recently, I decided to throw in the towel and start from scratch. This time around, I decided to go with an AMD build, because AMD seems to be doing some good stuff with their Ryzen and beyond chippery. So, I put together a rig around a Ryzen 7, 32Gb RAM, same old nVidia 1060 video card. Upgraded the SSD to the latest Samsung 980? or whatever it is.

I joined the Office of the CTO at Microsoft just over two years ago. I was a ‘founding member’ as Kevin Scott was a new CTO for Microsoft. I have now moved on to another job, in a different CTO Office (Mark Russinovich in Azure).

I noticed one thing while I was in OCTO, I essentially stopped blogging. Why was that? Well, probably the main reason is the fact that when your in that particular office, you’re privy to all sorts of stuff, most of it very private, either to Microsoft, or other partners in the industry. Not really the kind of stuff you want to write about in a loud way. My colleague Mat Velosso managed to maintain a public voice while in the office, but I didn’t find I could do it. Now as it turns out, my new job is all about having a voice, and helping to make Engineering at Microsoft that much better.

Dr. Martin Luther King Junior was assassinated April 4th, 1968. That was 51 years ago today. In order to commemorate his passing, I penned the following and shared it with my coworkers at Microsoft.

On this very important day in history, I am contemplative. As we consider the importance of naming our ERG, I am reflective upon how we got here.