|You don't have any items in your cart|
|Subtotal (ex. VAT)|
Moving from Stable 1.4.1474 to 1.4.1567
In the last blog, I explained how I created the walls and doors of my dungeon, as well as how I added in some initial graphics to see how it all works together. The results were better than I could have hoped for, especially after I added in some optimisation, but having a nice looking dungeon isn't really much fun if the player can't see it properly, so in this weeks tech blog I'll be talking about the decisions I took for setting the view size and aspect ratio as well as the GUI layer.
For some time we've had requests to make some of the graphics pipeline more visible, so that developers can get things like the order of texture page usage, the size of vertex batches and even helping to debug shaders. The reason we've never bothered with these, is because theres already a tool that does this for you, and gives you more than we ever could - PIX.
After creating the base of my new game engine (see last weeks tech blog on procedural generation), it was time to start to bring the game world to life. This meant taking the data I had generated for my dungeon and turning it into instances in a room so that the player actually had something to interact with. So, in this weeks diary, I'll be explaining how I went about this, as well as talking about some of the challenges I faced and the techniques I used for optimising things.
In last weeks tech blog I went into some detail about the creative process behind making a game, and came to the conclusion that I wanted to make an action rogue-like (ARPG) in the style of the classic Gauntlet. So, I have my design brief with a list of things that I want to achieve and at the top of the list is the procedural creation of dungeons for our player to explore...
This weeks tech blog continues on in the spirit of the previous ones that Mike Dailly has written, only instead of taking a look at the development of an emulator, we're going to be taking a look at creating an actual game from start to finish. The game in question is one that I have been wanting to make for quite some time and is in fact a return to my roots using GameMaker...
So if you followed my last emulator series, you'll know that I built up a lot of caches of shapes (characters and sprites) on demand, and then drew them when required. This works great for old consoles, and computers with character map screens, because on the whole, games tend not to change character set images very often, just the actual character map screen, which referenced these images. Because these kinds of machines have pretty good hardware support, they don't have to resort to shifting bitmaps around, there are much easier ways of doing things.
So in this, the last part of my Commodore 64 Emulator series, I want to talk about some of the optimisations I did to help speed things up. But before getting into this, why do we need to speed things up? Wasn't it all running at 100fps+ anyway? Does it matter if your already over 60fps, as this is the refresh of the monitor? Well, yes and no.... No once you're over 60fps, its not that going to show any real difference. And yes... it does matter, because when things "hicup" the more spare capacity you have, the easier it is to absorb the hicup.
So in this chapter, I thought I'd tackle the tricky subject of SID chip emulation, both how I generate the sounds, and how I get them to play back in GameMaker. Before getting into any of the nitty gritty, let's have a quick look at the SID chip itself. Back in the day, it was the sound chip, the sound it generated was unparalleled in computers, and the musicians that created music on them - Gods among developers, superstars in their day. So what can this masterpiece of engineering do?
So, now that we have C64 sprites being rendered, how about characters? Well like sprites they are made from blocks of memory on even boundaries, all be it a lot smaller. So we can do the same trick with invalidating and caching on demand 8x8 surfaces. So how many 8x8s can a C64 hold? Well...8,192. That's a fair old step up from the 1024 that Sprites used. So can we fit 8,192 characters on a surface? well, as it turns out they fit nicely on 1024x512 surface, which isn't too large at all these days.
In this part, I'm going to start looking at sprites, and see if there's anything I can do in order to display "something" so I can better see games running. The simplest thing to do, is to just display a blob, but before we do that let's look at sprites in general.
In this part, I'm going to start discussing how I handled the screen at the start of this process, and the reasons behind these choices. I said in the first part that you could simply read the C64's screen memory and print it, so what did I mean by this?
In this part I want to talk first about the CPU bug I had, and how I fixed it, then I want to discuss the C64's memory mapping system, and how I deal with rapid paging on a per instruction basis.
So my next post was going to be about tracking down my CPU bug and how the memory mapping was going to work, but then I suddenly realised I needed to do another first, on how I actually emulate the CPU - a bit more detailed at any rate. So I've moved all the others out by a week, and thrown this one in first....
So I started this very much in the "can you even do this" spirit, and have been surprised how much I've been able to do with it. Sure, it does require YYC (GameMaker: Studio Compiler), but as YYC is now available to everyone, then I no longer see that as a dependency, but just another tool in the GameMaker box. There are several complications in even trying this, but the CPU emulation is "just" a program so should work easily enough, while rendering emulated memory is a tough nut to crack - but we'll come to that in a later part. The reason for writing these posts, is that I've come up with some interesting tricks to over come some GameMaker limitations - as well as good tricks to just help speed up your code (much as you would in any language). So I thought it would be a good idea to share them.