Simulating the VIC-II Saturday 28 April 2012 at 10:03 pm

So let me share a bit about myself. While other kids my age grew up in the console generation, with the NES, Gameboy, SNES, and Genesis all being significant consoles in the market during the first ten years of my life, I didn't grow up that way so much. While I had friends with NES and Gameboy that I could play sometimes, we didn't have it in my own household. Instead, we had a MS-DOS computer with a 386 processor (which the successor for came out in 1989), and the Commodore 64. In fact I had my own Commodore 64 for a while, having been given one of my own for Christmas when I was 4, and lasting unitl I was somewhere around 8 or 9 before it finally gave up the ghost. Those I can directly attribute to why I am today as a programmer and game developer. That's what I grew up with. 

I also grew up with arcade games, which were also on the way out in the US at that time. Between the waning pizza/arcade resturaunts, remaining arcade units in grocery stores, and machines at hotels and campgrounds, I played old arcade games, and have fond memories of many. And it's always been an ambition of mine to actually own an arcade unit of some sort, leading into wanting to make a classic arcade machine like that gone era. And although the minigame market has developed as phone apps that bring a resurgance in a way of the old arcade type of games but I just don't have the kind of mind to come up with a game of the sort, building a physical machine with an original game is still something I want to do.

So let me move to a more recent time. A couple of years ago I got a credit from SparkFun, and picked up a Netduino. When I got that the urge to build an arcade machine really surged again, but the Gameduino - which is basically it as far as video output of the kind needed for game output goes as far as Arduino shields go - reportedly works badly with the Netduino because of a strange slowdown in SPI transfer between them. So I had forgotten it for a while, but something brought it to mind again recently. Then a conversation on Twitter brought up my programming history and I started thinking about the Commodore 64 again, and I got a new idea - using the VIC-II for the video for the project, whenever I get around to bulding it.

So that's how this came about. To facilitate the development of the project I decided to make a simulator for the VIC-II. I have a physical copy still of the Commodore 64 Programmers Reference Guide, so taking that to get the exact specifications for the chip that's how I began writing it. I put it together as an XNA texture, but I have something else I want to use it for now as well so I'm going port it elsewhere. It doesn't exactly do it all according to spec now, but it's still a work in progress and I'll update it as I add more to it. But here it is, available for anyone to use as they wish, as I'm licensing my work on it under the WTFPL. 

What I've Been Doing This Year Wednesday 07 December 2011 at 12:48 pm

So on the outward it looks like I really haven't done much of anything this year, just the infrequent updates to Its Safer Here as that's been building out and whatever can be gleaned out of my probably confusing Twitter posts. And while I already admitted that I haven't done much in the way of writing this year, programming has been somewhat of a different case for me. I have done a bunch of it throughout the year, just not much to show for any of it for various reasons. Usually because of hitting up against blocks. 

At the beginning of this year, after failing (again) to get the roguelike I was working on released, I started working on WP7 development, trying to, instead of trying to do a large project for now, make something smaller, simpler, and more condoning to the phone platform. So I started a game, tentatively called "Get Me Outta Here!", about trying to navigate out of a booby-trapped building. However, the control scheme I came up for it proved to be horribly inadequate once I actually got my hands on a WP7 phone once I bought my LG Quantum, and so I decided to switch it to being an XBLIG instead. However I couldn't get the navigation input to work right on there adequately either, and so I just scrapped it for the time being. 

Not wanting to give up on the phone, I started exploring different input methods to try to design something that fully was designed around a touchscreen input, and after some experimenting had a basic app on my phone with my input experiment to see how it works, simply called "Spaaaaaaaaaaaace" for lack of any particular ideas and it just being navigation around a starfield at the time. In the mean time, the old pinball lover in me got rekindled and I started working on a pinball game, but the lack of any physical pinball machines in general in Utah made it hard for me to see how the real thing works for physics, and not being able to adequately design a table until I could test that made me put it on the shelf for the time.

So while I was doing that I was working on something for DBP as well. I was originally going to make a danmaku shmup, but a little experiment with shadowing lead me to a different idea using colored light as a mechanic. However, trying to do it with shaders led me to realize how little I understand shaders, and trying to find a way to do it without shaders never performed well enough for me to be happy with it, so I ended up having to drop it. And by then I had wasted too much time on that to be able to do the danmaku in time for the DBP deadline, so I had to give up on that too. 

I had also started a rewrite of Spiral Island's code from scratch, which I had already done a couple of blog entries about as I was looking over it and deciding why. I was going to do more as I worked on it more, but I set that aside after building my new desktop and didn't do much else with it.  After that I started with experimenting with a few different things while trying again to come up with something lending itself to a touchscreen interface, and started to formulate together some ideas around when the WP7 Mango developer beta came out. So I had started doing a little more with that, while at the same time experimenting with some new ideas that Mango opened up for ARG and stuff. So I started brewing together some new ideas for that, and finally came up with a good idea to do with that, but after NoDo's fiasco, not knowing when the Mango release was actually going to finish led me to start putting it on the queue for later. However, the sudden simultaneous release of Mango to everybody at once made me take a step back, and it took me a little while to decide whether I wanted to work on that first or whether I wanted to work on what grew out of the "Spaaaaaaaace" experiment first. 

Eventually I decided on working on the "Spaaaaaaace" game first, and so have been working on that some. Getting Minecraft in the last couple months hasn't really been condoning of getting work done on that much, but it hasn't been entirely unproductive because I've found that I can use it to do some spatial design work to get a surrounding feel of how room layouts look sizewise that for some reason I've never really been able to grasp using 3D modeling software for designing areas, so I've been able to hammer out other various designs for my games. As of right now though, I plan on spending the rest of this month of December finishing up the "Spaaaaaaaace" game design (graphics notwithstanding) so I have that done and ready for testing to move on with other work.

And that's what I've been up to design wise. Haven't had any contract work this year so it's just been me left to my own devices.

Why I'm Not Worried About XNA Wednesday 14 September 2011 at 8:54 pm

So with BUILD going on currently showing Windows 8 stuff, there's a lot of exciting things. But an interesting upset has been going around the Twitters over one particular thing: XNA. Starting from a list of the available APIs and culminating with Q&A during the DirectX session, there seems to be a big worry that XNA is now dead. Here's the thing: I don't believe a word of it.

All that we know from the information presented is just that its not in the API's. The thing is, this BUILD is all about showing off new things, and XNA's not that new, being now on its 4th release and available on 3 different devices, as well as bits of it going to be appearing in the upcoming Silverlight 5. All that the information gives us is that there's no XNA built into the new OS. And frankly, that wouldn't be a good thing to do anyway, because it would lock XNA's version to Windows 8.

Now, the second reason people are worried is that there's not an alternative. The Windows 8 guide only shows DirectX programming with C++, it's not listed as available in the new WinRT API for C#/VB/HTML5. That's not particularly a problem, though, because historically DirectX has always been C++ only. It is itself an unmanaged API, and because it has to live in kernel space to do its thing, not meant to itself be managed and be forced to live in userland. That's why we have wrappers: the ill-fated MDX, and its successor the rather successful API XNA. Neither of these were built-in to the OS, and even their other attempt at bringing DirectX straight into .NET, the Windows API Code Pack is not built into .NET, but is instead a set of addon libraries. And we have SlimDX, which is far better a choice than that if you want to use the DirectX API directly, and there's all sorts of ways to wrap around other unmanaged SDK's if you want to.

Third of all is the new architecture support: ARM. Now since ARM is a drastically different CPU arcitecture, there's simply no way that ARM devices will be able to run x86 code. But that's the whole reason we have the the CLR in the first place: because unmanaged code simply can't run cross-architecture on the same build like that, but managed code can. I imagine with ARM there as a possibility now, the extra effort that would be needed to support two different code paths for unmanaged DirectX libraries will bring more weight to using a managed library. With XNA already ported to ARM for Windows Phone 7, that would make it a rather clear choice for the thing, it would simply need to be updated for Win8 ARM. But the XNA team isn't part of the Windows OS team, so they're going to have their on schedule for development and delivery.

And that's what i have to say on the matter. I doubt XNA's going to go anywhere, it's going to continue to be where it is: Xbox, Windows Phone, and PC. And, considering they mentioned right at the beginning that Windows 8 can run everything Windows 7 can now (on x86/x64), Windows 8 isn't going to magically make it so XNA can't run anymore.

And to prove it, and put my money where my mouth is, I will leave you with this screenshot:

Deconstructing The Spiral - Part 2 Tuesday 12 April 2011 at 5:00 pm

So what is needed for a tile engine, anyway? That depends, of course, on what its function is. So the first thing to do is identify what your needs are. The RPG Starter Kit tile engine fit several of my basic needs: multiple drawing layers, collision data, portal information to jump between maps. But my total set of needs were still different than what it offered.

The first thing that it did, that I had to work to overcome, was the way that it handled movement. With the starter kit, it has a freeform movement ARPG style, which I didn't want because I was trying to go for the classic CRPG style, moving the characters along the grid of tiles. This ended up leading to quite a bit of work for me to add, as I ended up with all kinds of behaviors along the way before it was stable: map coordinates becoming out of sync, sprites not lining up along the grids anymore when scrolling, multiple direction inputs causing it to move in more then one direction and getting off grid, and even the entire collision detection being fooled by their movement and walking right through walls! Adding to the fact that the input system was bound to the tile engine, so having to work with it like that to fix things whever keyboard would break gamepad input or vice/versa, when I should have completely separated the input entirely. 

Another difficulty was the way it drew things, which led to several different unusal problems. As it is, since it is just meant to be an example, the kit draws the entire map, including a lot of wasted draws off-screen. The world map for Spiral Island is 200x200 tiles, leading to - with a 96x96 tile size at 1080p (I adaptively selected tilesets depending on resolution) - a whopping 368 Million pixels being drawn every frame to a space thats only about .5% that size. Obviously we couldn't be having that, so I rewired it to only draw what was on the screen and the small overflow for scrolling. However, the other problem that led to was when I came to corners where the screen stopped scrolling, as I found that it didin't draw tiles based on an absolute position, but instead relative to where the player was. So if the character is in the bottom left corner of the screen, and its only drawing 20 tiles across the screen, half of the screen would be blank because there was only half the tiles on the screen at the time. So not only does that have to be adaptive to the aspect ratio, it leads to the additional problem of not being able to script a separate camera for cutscenes without hiding the PC and moving it along as the camera, and having to store their position so you can then return them.

There were a couple minor things as well, such as the particular way the portals worked, which ended up leading me to alter the map format to support a more streamlined set of information, as well as adding the ability to extend with additional data (such as zone information for random encounters). It also was designed to combine all of the NPC data together on the map, which I wasn't particularly pleased with, because I didn't want to lose both map and NPC data all at once if one particular edit became corrupted, and also it didn't make multiple script sets (for translation and alternate New Game+ script sort of scenarios) very feasible. And so that was where I fist began to implement my changes, by creating a new NPC data structure. Which led to a whole lot more mistakes.

Deconstructing The Spiral - Part 1 Friday 08 April 2011 at 1:27 pm

So it's been a couple years now, since I decided to move my core project to XNA. A lot has happened since then: the project grew from XNA Game Studio 2.0 to 4.0, a new XNA platform came out, I've started several more projects with varying levels of completeness and failure, and over all that time I've missed my deadlines for Spiral Island. Not that it's all for naught, mind you, as of right now the bulk of the work left is just art and music, which aren't my key fields. Now I've already done some entries on my personal blog about how the game came to be, as well as posting the story's introduction, and that's not what I'm going to talk about here. These entries will be about the technical side of the game.

So let's rewind to 2008 for a moment. XNA Game Studio 2.0 was the current tech level at the time. I had just placed a different XNA project on the shelf, Phobia: Genome Prototype, because I wasn't going to be adequately able to tell that story the way I wanted. I had only been using XNA for a few months at that point, and only been programming in C# and .NET for a year altogther. Now I'm not going to claim that I'm an expert today, but I have learned a lot in those years since. And, as I look back, I realized that I made some major mistakes back then that have left me in a mess today, by taking shortcuts. And the first shortcut I took was the tile engine.

The App Hub, as it's called nowadays, has an amazing set of learning resources for beginners. One of those, the RPG Starter Kit, is one I looked to for building Spiral Island, not for the purpose of a tutorial, but because I wanted a quick way out of writing the tile engine. I had remembered how much of a pain it was for me years back writing a tile engine in C++/DirectDraw, and wanted to just get up and running and avoid that. So I took the steps from the second tutorial for that kit, and started my project with that tile engine. Which, all these years later, has brought me to the problem I am at now.

The main thing about that is its meant to be a tutorial. It's not meant to fit every need, and my needs were very different from what it offered, and so over the years I began to just hack things into the tile engine where I thought they fit to get the behavior I wanted, leaving my tile engine code compared to the original a horrid mess. I first noticed the problem when I forked off the Spiral Island code to make a Roguelike, attempting to make the entire thing in 7 Days as a challenge but finding myself having to quit halfway in because the code was such a mess now that getting it to work for the new purpose was nigh impossible. Then came converting the code to XNA 4.0, which took a day's work to get working on PC and XBox because of all the changes, only to find when I tried to build for WP7 that it was going to be completely impossible because of some fundamental storage diffences on that platform making some methods I had hacked together completely impossible.

So that's where I'm left now. Code that can't build, code that's a hackish mess, and code that, nowadays, even with my comments, I can't tell up from down anymore in the older sections of it. And so, I think it's best to start over, trash it all and rewrite the entire codebase from scratch, the way I should have done it from the beginning, both to clean up the mess I left it in, as well as to make it much simpler to port to other platforms when I get to the point I actually can release the game. And it will have to begin all the way at the base: the tile engine.

Bullet List Hell Monday 06 December 2010 at 8:36 pm

So, mainly just to see what sort of performance I would get with it, I decided to throw together the sample code from a thread on the XNA forums about bullet management for a danmaku (bullet hell) game. Taking the first of the two example codes on there, I whipped together a good test example that, if I kept all the bullets on the screen, would get ~12,000 on screen on the XBox, and ~20,000 on screen on my XPS before there were any dipping below 60 FPS.

The problem, however, came when I tried to remove them from the screen instead of bouncing them around. The boundary check was not the problem, of course, because it was doing that for every node every frame (way more than it should need to anyway) in the first place. But when I started deleting them, it began to lag after 100+ bullets on the screen, progressively worse for each additional bullet drawn, while still apparently reporting that it was running at "60 FPS". 

Now the entire point of the thread itself was managing draw order so newer bullets would always be on top of older ones, so there are two extra sets of information in addition to the actual set of bullets themselves: a sorted list of bullets, plus a list of all the empty slots in the static array to hold all the possible bullet slots. What didn't make sense to me, though, was that the sorted list, instead of being singly-linked like I was expecting it to be (because there's really no need to step backwards through it), they decided to go with a doubly-linked list for whatever reason. Now, doubly-linked lists I had hated from back when I took AP Computer Science in High School, but had forgotten, so I just ran with it, despite regular lists making more sense for this situation and their test numbers sporting good framerates.

That in itself was the problem. Not ever having used them before in C#, I had to look up their functions, and from what I could find in MSDN I could find no way to drop a node other than the Remove() function on the list itself. And this is where the performance was taking a hit, because as it had to drop a node, it always had to start at the beginning again because of the way a dual-linked list works (instead of simply jumping to an index number with a singly-linked list), delete it, then jump back to the beginning and iterate again. So the more and more bullets there would be, any time one single one dropped there was more the crawler had to go through.

A simple switch to a regular List and simply iterating through it in an index loop, and - with the velocity settings I have set right now since its all entirely random for this experiment - I'm sitting pretty at ~350 bullets on screen at any one time right now at ~1200 FPS. Buch better, much faster, and much more sane.

It's Safer Here! Thursday 28 October 2010 at 8:08 pm

Yes, the Twitter app I was called out on to make works. Welcome! It's safer here!

I'll post source eventually. Test builds will be uploaded every so often to

EDIT: Day 1 Progress

EDIT: Day 2 Progress (not counting a day that was mostly templating)

EDIT: Day 3 Progress

EDIT: Day 4 Progress
At this point its at a stage where its fully usable with what I want without having to run it directly from Visual Studio to handle crashes and debug, now from here its the feature requests 

Project Open Sourced Tuesday 21 October 2008 at 11:04 pm

The map editor project, Castle Tilemap Editor, is now open-source, and available on SourceForge:

No binary releases yet, but the source can be checked out from Subversion.

First Look at Map Editor Sunday 03 August 2008 at 7:30 pm
Genome Prototype on Hold, Spiral Island for XNA Sunday 13 July 2008 at 5:32 pm

I'm putting development of Genome Protoype for XNA on hold for a little while. Now that the actual beta for XNA Community Games is underway, I've noticed a lot of the downloads on there are very small in size.  Based on this, I've decided I'm going to drop back to the basics, and go back to the original 2D version of Spiral Island g, as a challenge to see how much I can push into the currently 150 MB filesize limit and see if I can fit the whole thing.

Genome Prototype Thursday 27 March 2008 at 12:46 pm

Today I'm going to announce the game Genome Prototype. Genome Prototype will be the introduction to the Phobia series. It will be available for the XBOX 360, as a Community Games title. It will be for the most part a 3D, first person puzzle game, with its own goals for just this game and at the same time introducing the storyline to follow in the later Phobia games.

I'll give regular updates to this as I'm working on it, both here in the blog and on the forum, as well as possibly making available for download builds for XBOX 360 owners with XNA subscriptions, or PC builds for anyone (the XNA platform is Windows-XBOX 360 cross-platform). More details to follow!

Castle Revival - Day 4 Thursday 22 November 2007 at 6:16 pm

Since I think I've solved my hardlocking problem, I resumed installing the rest of my applications. After installing Visual C# Express 2008 I loaded up the CastleEngine project to test out to make sure Visual C# Express works, and after that I decided to do some more work on it for a while.

I duplicated all the menu entries for each of the static menus from Castle of the Winds (File, Actions, Window, and Help) and set the shortcut underlines for everything, but those don't seem to show up when running the thing. I also implemented building the map from a chain of images instead of images separately, so only one file is needed for a tilemap. And that was with built-in functions, which made it very convenient :)

I also got it to redraw the map continuously while resizing, and upon program initialization, neither of which it could do before. I was aiming for the drawing it upon program start, the continuous redraw while resizing was an unexpected surprise.

Finally, with the multiple images, I began a simple test map. It loads, it moves upon scrolling, however, I'm in a bit of a pinch with redrawing it. It'll redraw just fine, but not in the space that is the original size of the window before any resizing. I found one way of fixing this, but that caused all sorts of graphic glitches, from constant problems with the scrollbars being drawn, to everything being blank upon the programs start, menues, buttons, everything blank. So, I need to find another method to do that.

Free Image Hosting at

Odd... Thursday 24 May 2007 at 8:09 pm

According to AWStats...

AnacondaSoftware has had 139 unique visitors so far visitors this month, and a total of 18586 hits.

This blog has had 779 unique visitors so far this month, and a total of 2564 hits.

1101 of those hits are recorded as being from traffic that stayed here from 0 to 30 seconds.

No comments are ever posted on here, aside from spam.

There are 22 recorded hits from a Russian search engine for here.

There are 7 recorded hits from links from other sites, six from the Irrlicht forum and one from a malformed version of this blog's address.

There are 3 recorded search phrases that led to this site, one of which is the name of a drug that's been among the spam links.

Google AdWords has recorded only 52 page impressions for this month.

So I guess the real question is, where does all the spammer traffic actually come from?

The Consequences of Forgery Wednesday 16 May 2007 at 2:48 pm

Okay, so someone faked an email so it looked like it was credible from Apple internal, so it got reported as news. Then information came from Apple that it was fake.

But here's the interesting part:

This is why authentication to e-mails is important, and technologies such as PGP were created. The world nowadays online identity is critical. I sign most of my e-mails, through the Enigmail plugin for Thunderbird. More people should do the same.

EDIT: I'm not sure what was wrong, but for some reason this wasn't publishing. Now I finally got it to work (somehow), so just FYI this is an older entry.

Once again it returns Sunday 21 January 2007 at 10:13 pm

So, after trying to figure out how to use BlenderPocket, I picked up the ability to model in Blender. So, to test this out, I decided to make this scene over again:

Free Image Hosting at

I plan on actually completing the scene this time :p

Huegwied screen is HUEGWIED Saturday 13 January 2007 at 8:03 pm

Not much to mention right now, just wanted to show off my new monitor:

Free Image Hosting at

Its only the 20" model (they have a 24" and a 30", and just launched a 27" as well), but its already freaking massive compared to my old 15" CRT.

Time to get things back in gear Sunday 17 December 2006 at 5:28 pm

Been a while since I posted last, so I figured now would be a good time to bring things up-to-date.

I started a new tech support in the beginning of October. Didn't exactly want to go back into the call center tech support field again, but it works. It's a good environment to work in, much better than the place I was at the time before. My first paycheck that I was able to use (first one before that was a half check, and needed to go to other things), was on Halloween, the same day of my very first paycheck at the first place I worked at.

Now that I'm making money again, I got a new video card, an ATI X1650Pro. Since Vista is coming out soon (next month), I decided to get a low-cost but powerful card, because I would be upgrading once again when Vista comes out to get a DirectX 10 card to do DirectX 10 development. Since I've been using this same computer for two years now, there are a couple more upgrades I have to get to get it up to speed for use still. Next I plan on ordering an LCD, the Dell 2007FPW. Next paycheck is the day after Christmas so will order it then. Then, sometime in late January or February I'll get an X2 to bring my desktop up to speed, and then Vista. Other than that, nothing else to upgrade for a while.

No updates on CastleEngine, I had set it aside for some other projects. I was thinking of redoing it for something else tho, maybe a GBA or DS homebrew. Also, I had started a networking library project on SourceForge (link can be found on the main site), but I haven't had time to do any work on it because of other things.

Too early for 64 Wednesday 06 September 2006 at 11:51 am

I've been playing FFXI a lot the last month, and so I've had my notebook open as well so I could get to MSN and the internet for communicating with people (since FFXI doesnt have a windowed mode). In that I'd noticed my notebook had a problem. Under XP Pro x64 (not under the Linux installation though, so I know it wasnt a hardware issue), the clock would fall behind.

A lot.

I'd look at it after it's been on for a while and it would be 2 hours behind what the time actually was. I'd sync it with the timeservers, and 15 minutes later its already 5 minutes behind again.

I couldn't find any solution to this problem, so I ended up giving up on it. Killed x64 and put XP Home back on it.

Now I need to reinstall all my development tools on there.

Castle Revival - Day 3 Friday 04 August 2006 at 12:27 am

I picked up to do some more work on this today, after not working on it for a while. I finished solving my problem with drawing the map (at the point I had left it, it would only redraw when I minimized and restored, not when I resized the window). I then simplified the drawing methods, so it's all done automatically.

I then moved onto trying to solve the problem of easily drawing multiple images. Basically, I needed an array of images, to draw whichever one was needed for the cell by the drawing method. I first tried writing my own method, but it didn't work quite right. Then I found the C# ImageList class, which works really nice for that purpose. :)

Have that all squared away, everything working now. Next time I work on it (maybe tomorrow, maybe not), make up a basic map, and start implementing other functionality.

And for a little laugh, here's the result of my first successful use of the ImageList (didnt know it defaulted to images of 16x16):
Free Image Hosting at

Castle Revival - Day 2 Thursday 20 July 2006 at 11:59 pm

Not that much improvement today... I figured out a couple methods to use later on, but I was primarily dealing with the problem of the image disappearing every time I'd minimize the window, and not updating if I resized the window.

So after several hours of reseraching, I found the solution to the problem, and got it all implemented so it would function properly (it was for a while recreating the backbuffer image each time that call was made, which still made it not doing what I wanted it to). a "Load" event for the form, and a Paint event for the drawing area, and then all was good.

Tomorrow I'll move the methods into separate functions (one for redrawing the window and resizing the scrollbars each time it's resized, another for drawing whtever the current map is into the bitmap, so on and so forth), then move on from there.