Category: xbox-live-indie-games

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.

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.