At this year’s Assembly I released my latest Windows demo.
The demo is written in C++ with a healthy dose of DirectX 11 and HLSL. You can find a link to the binary on Pouet. Keep an eye out on the configuration menu for the super secret ZX Spectrum rendering mode ;)
Here’s a bit of fun – a virtual CPU that’s so bad that it’s memory keeps getting corrupted. What’s the point of that? Well.. it’s perfect for glitch art!
So there’s a fictional computer that’s based around a fictional 8 bit CPU that has: – 256 bytes of memory (used to store the program code and also doubles as registers) – 29 different instructions (including drawing primitives like squares and circles) – 2 addressing modes (immediate and indirect) – 2 hardware (ie: not stored in main memory) registers (PC and SP)
I’ve never written a trainer or a cracktro for a game. Sure, I hacked games for fun when I was a kid, and I shared these cheats with friends – but I never packed them up into a trainer or a cracktro. So I decided to write one, and I decided to go back to my roots and do something retro. First I took one of my favourite old games (the awesome Ant Attack by Sandy White) and hacked it. Next I wrote a trainer menu and crafted a delivery method to get the hacks into the game. Finally (and.. ok.. this is a bit more contemporary) I presented a talk about it at this year’s Assembly demoparty:
ZeroMQ is great. The ZeroMQ guide is even greater – in fact it’s a great read even if you don’t plan on using ZeroMQ. But if you try to code something that isn’t covered in the guide then things can get a bit tricky. Sure, the guide teaches you how to run on your own but sometimes you can go so far out that you’re on your own. One of these “things” is authentication and encryption. ZeroMQ does support both of these out of the box since version 4, but it’s not in the guide. There are a couple of blog posts about it (exhibits one and two) but they cover a lot of ground quickly and, more annoyingly for me, they use CZMQ (a ZeroMQ extension library) and not just plain old ZeroMQ. Google for examples and.. well.. there’s nothing. And that’s why I’m writing about it now.
I’ve been thinking about “gamejams” lately, and how to change things slightly to make a “demojam” – a one or two day event where a bunch of people get together and make demos. One of the big problems I noticed when I ran gamejams in the past was that people often have no real idea of what they can actually achieve in such a short space of time. We would have people who worked at gamedev studios come along and spend the first half of the jam writing an engine before the realisation hit them that they were never going to get a game done. So.. no.. don’t do that. You need to hit the floor running. And if you want to work in a team then you can’t expect the other members to sit there twiddling their thumbs while you write the perfect render pipeline or asset system. You have to arrive at the jam with something that you can start creating content in from the moment you come up with your first idea.
At the recent Sundown demoparty I released two new Ate Bit demos – one for PC and one for ZX Spectrum.
First up is the PC demo, 0xAnniversary. The title is a pun on the the hexadecimal code for the number 10, which can be written as 0xa, and the fact that this year marks the 10 year anniversary of Ate Bit. To make it even more poignant, our first demo was released 10 years ago at the first ever Sundown.
0xAnniversary was written fairly quickly over a period of about five weeks. The demo was written mainly from scratch but borrowed a few key bits of code (mostly texture and shader loading) from AteBitVJ. Music is by 4mat.
Here’s a realtime audio-visual experiment that I made recently. It’s a bunch of glowing balls, synced to the majesty of 4Mat’s track, “Omega”.
A few people have asked me how I made it. The short answer is that the video was rendered in real-time in my AteBitVJ app and captured using Fraps. I thought I’d take things a bit further and explain how the scene is constructed by doing a shot breakdown on a layer by layer basis. Continue reading →
Demos We Care About is a daily feed of demos that someone, somewhere, cares about. The goal is to share the best, most interesting, most loveddemos to a wider audience. There are two in fact two main audiences for the feed – demosceners who want reminding of the best that the scene has to offer, and then there’s the wider audience of non-demosceners who might not normally get to see these works.