Category: c#

TL;DR: I did something stupid and realised my mistake – what follows is mainly for future reference and for those that are making the same mistake.

Win2D is great! So is the concept of UWP and the Windows Store. It means you can write a game for the Windows Store (for Windows 10), and with some minimal work, it can run on the XBox One (since that’s based on Windows 10 too).

Here’s the opening screen – note the text looks naff and the sprites have lost their intentionally pixelly look:

… compared to the TypeScript version:

I spent quite some time trying to fix this – thinking it was some nuance of Win2D and offscreen bitmaps. I didn’t get anywhere, so I set out to create a small reproducible project that I could use in a StackOverflow question (as an aside, I often find that just typing a StackOverflow question creates enough clarity of the problem that the answer just magically appears – as was the case here!). So with just a few lines of code, I had this monstrosity:

Even though I know how tolerant the StackOverflow community is (</sarcasm>), for completeness and to show that I did my homework before asking, I tried the same drawing (DrawImage) with multiple overloads and included a screen-shot for each.

So, I’m about 45 minutes into writing the StackOverflow question, and then it struck me:

I’m only scaling the main drawing session; what I really wanted to do is scale the off-screen drawing session too: in Win2D, when drawing, each instruction is queued and then blitted to the GPU asynchronously, so my flow is:

1. Scale up the main DrawingSession to make things looks bigger
2. Create an offscreen DrawingSession
3. Draw text and a line to the offscreen session
4. Draw the offscreen session to the main drawing session
5. Draw text and a line to the main session

Essentially, the offscreen canvas created in step 2 has its instructions drawn at 1x scale but blitted at 4x scale, rather than the instructions being drawn at 4x scale and blitted at 1x scale.

Probably of no interest to anybody (apart from my son who I did it for), but here’s a timelapse video converting Pac-Man from TypeScript (play it here) to C# for the Windows 10 Store. When it’s finished, I’ll put the source up and describe what I learnt during the process. Watch it here.

I’ve been working with C# for many years now and the new additions to the language are very exciting. They’re focused on immutability. Well, actually, the Microsoft documentation seem to suggest they’re more focused on Performance, but they go hand-in-hand; the less you can modify, the faster things are.

The benefits of immutability are often overlooked especially by those who have only experienced programming in C#. But coming from a C++ background, I long for the immutability that C++ has. For example, In C++, you can:

Declare a method as const, meaning the method cannot modify any fields of the class (or call any other non-const method)

Declare a parameter as const, meaning the parameter can’t be modified in that method, and if you passed that parameter around to other methods, those methods would also have to declare that parameter as const and follow by the same rules

Declare a return type as const, meaning that you can’t change what you’re given

Declare a field as const, meaning that only the constructor can set the field

(these bullet points are generalisations)

const is great. There’s even been 80’s pop songs written on the virtues of const:

The new features in C# 7.2 are losely related to the above. This post describes one of them; in parameters

We called Conculate, which we know mutates the state (by setting Id to 42), but it turns out that a copy was made and the ID was set on that copy.

Here’s an excerpt from the Microsoft page on reference semantics with value types:

So, it turns out that readonly parameters aren’t as powerful as C++ const parameters. They are, technically, read-only (you can’t mutate them), but they’re not const as in C++ const.

I also don’t like the fact that you can legally call methods that mutate the instance, but don’t know about it. If const methods existed in C#, the compiler would’ve disallowed the call to Conculate because it couldn’t be declared as const (as it mutates a field).

Perhaps in a future version of C#, we’ll get const methods…

But there’s more…

Even though readonly parameters are a step in the right direction, I was disappointed. I was dissapointed because when I read about readonly parameters, I wanted to immediately jump into every single method I’ve ever written and splash in keywords on every parameter. But the majority of things passed around are classes and not structs. Notice in the earlier example that Thing was a struct. In time, with the performance benefits of reference semantics with value types, I’m sure struct will be the go-to type instead of class.

Anyway, in parameters can be either struct or class. Here’s what happens when you change Thing to be a class rather than a struct; remember the earlier example where the compiler stopped you setting a property? Well, now it lets you do whatever you want:

Oh the disappointment!

Here’s another excerpt from the documentation:

‘The benefits are minimal‘. I personally think minimal is being generous. I would’ve use the word Dangerous. If Thing is a class rather than a struct, then what is passed is a reference to a reference. This means that the value that the method is dealing with can be changed to point to something else at any time! (even from outside of that method)

Here, we start off a task to do something with a Thing. We wait 1 second and set the reference to null. Assuming the user hasn’t pressed Enter yet, a NullReferenceException will happen when they do. This is because we’re passing a reference to a reference and then setting the reference to null.

I can only imagine all the subtle bugs that this will cause if spread throughout a codebase.

ReSharper to the rescue?

I don’t even know if it’s possible, but I’d have liked the compiler to disallow in parameters that aren’t value types. I’m sure the ReSharper team are working on a new code-inspection to warn when passing in references.

I’ve spent some time over the Summer and Autumn of 2011 rewriting the Gleed 2D tool. This is a tool for editing levels for 2D games and is a very popular tool in the XNA community for games running on XBox and Windows Phone.

Most of the changes in the new version are under-the-hood. The biggest change has been to make it have a plug-in architecture. There has also been a few UI changes though; here’s some screen-shots.

The original tool before being re-written:

and here’s the new version:

The main reason for rewriting the tool was that I wanted to add more features to it but found that it wasn’t easy. It wasn’t easy because it was originally written to just handle the basics needed for creating and editing levels.

The features that I wanted to add were for the next version of my game (video here). I wanted to include lighting and shadows and I wanted to design these on the canvas.

Instead of shoe-horning my changes into the original Gleed 2D source, I decided it’d be best to rewrite it and change it to a plug-in based tool.

So, now everything is a plug-in. The basic shapes (rectangle, circle, path) and textures are now plug-ins. Lighting (lights and shadows) is now a plug-in. There’s also a plug-in for simple ‘behaviour’.

Here’s a quick video showing how to use the basic shapes and textures:

Basic shapes and textures

Here’s a short video showing lighting:

Lights and shadows

and lastly, here’s a short video showing simple behaviours:

Simple behaviours

The tool is still currently a bit rough. There’s various bugs that need to be fixed, but none of them stop the tool from doing what it was designed to do. The project is now quick big, so I’m hoping that the community will jump in and add/fix stuff. I’d like to see plug-ins for physics and particle systems.