Monday, December 31, 2007

Happy New Year everyone! While I have decided that I am going to make the home page change I mentioned months ago on January 4th, that is about the only thing that I have decided. I still have a huge number of decisions to make about the direction that I hope to take the site in 2008, though the paramount thing I have to start doing is to try and be much more focused on my development. Even though I try not to, I tend to have way too many projects on the go at the same time. This is a personal flaw that I really have to solve because I know if I could focus a decent amount of my time on a single project instead of spreading that time between a dozen projects then that single project would be great. That being said, this is not going to be my new year's resolution because that would just curse my efforts.

Thursday, December 27, 2007

Games, of course, require a lot of motion. Characters and bullets need to be able to fluidly move even if the background is static. To accomplish this, video game hardware makers came up with the concept of sprites. While I have yet to find a definitive reason why the term sprite was chosen, it is the word used to describe images with partially transparent regions that can be moved on the screen without destroying the image behind it. While this can be done in software, doing so in hardware is much faster and is often the way that game consoles handled sprites.

In theory sprites can be any size, though console hardware tends to use uniform sprite sizes and requires programmers to combine multiple sprites if they want one larger than the default size. 8x8, the same size as tiles on the tile map, is the common default size. The next question is how many sprites? This is actually a more complex question than it sounds. Hardware sprites commonly had issues with there being restrictions on how many could be displayed on a single line at the same time. I am going to assume my chip designers are really good and managed to allow for 16 sprites all of which could be displayed on the same scan line. More importantly, the sprite data can be changed on the fly so by using raster-line tricks, more than 16 sprites can be displayed. In case you are wondering, the specs for the various 8-bit systems that I looked at supported 64 sprites (4 times as many as I am going to support) but only were able to display 8 sprites per scan line.

Monday, December 24, 2007

While for the B8VGC we are treating the television as having a 640x480 resolution, this is not going to be the resolution that the console displays. While I know that the virtual nature of this project allows me to do things that were not possible back when 8-bit was the order, I want my virtual game system to at least be theoretically possible for the time period. This leads to the question of how much memory is available. If you look at the specifications for any of the 8 bit consoles that were on the market, the answer is not very much. A black and white 640x480 image requires 38,400 which is more than half of the address space available to 8 bit processors. In fact if you have the 16 bit address space that most 8-bit processors used, the total accessible memory would be 65536 bytes. Memory was expensive back in those days, so 64K would have been a luxury. To simplify my design, I am going to assume that all the hardware shares the 64K of address space that is available. How much of that memory is available to the graphics system will then be game dependent. A more important point would be that only some of the memory would be ram, with the rest of the addressable memory being ROM. My design goal has to be to allow the graphics to comfortably fit withina small amount of memory, say 8 or 16K.

The first obvious thing that we can do is to reduce the number of pixels that make up the display. By simply doubling up the pixels we can reduce the display requirements to 320x240, which uses 9,600 bytes of memory. While that is on the high side, it will fit within our 16k limit, with room to spare. While this sounds like the perfect solution, remember that this is only a single bit-plane so we are talking about a monochrome display. While most games are not going to be using a bitmap mode, having this capability on our graphics processor can't hurt, though 9600 is not a nice number. If we letterbox the display and get rid of the top and bottom 20 pixels, we can get a nice 8,000 bytes. Combining two bit-planes, for an excessive 16K, would give us a four color mode which would be good for title screens and games that don't need rapid re-drawing.

Remember that 8-bit graphics aren't exactly speed demons, so a faster way of having graphics on the display would be nice. Of course, the logical choice is tile maps. I've covered this concept before. The display is broken into 8x8 blocks, with each of these blocks represented by a single byte. While a display may only have 256 distinct 8x8 blocks, the blocks can be used multiple times. As a nice bonus, using a tile map that is larger than the display, say 64x64, allows for smooth scrolling. The best part is that 64x64 is only 4K! The data that makes up the tiles aren't likely to change so can easily be stored in ROM. A tile map, some palette information, and some sprites could easily fit within 8K making this the mode most likely used in any games.

Sunday, December 23, 2007

I must assume that anybody reading this is a regular visitor to BlazingGames.com and as such knows that I am taking Christmas week off, at least I am not posting anything on the 28th. I was going to continue working on a few releases for the site that would appear next year but have instead been sick the last few days. That is the reason there have been no entries in my B8VGC blog project. I am not sure why I always seem to get sick just when I am going to take things easy, though it may just be coincidence. Observant Blazing Games visitors may have noticed that the date ends on the 31st not the 29th or January 5th, which would be the logical end dates. Am I planning something for the 1st? Well, I was, but it now depends on how quickly I get over this cold so don't be disappointed if there is no update on New Years day.

Wednesday, December 19, 2007

There was an interesting trailer, or should I say teaser trailer, that was released today. It appears that Duke Nukem Forever, a game that started development in 1997, is still in development and they have released a sneak preview of the trailer that they will be releasing soon. Their site is http://www.3drealms.com/, and if you are a fan of Duke Nukem you will be pleased by this news. How can a game take so long to create? I am sure Coffee Quest fans want to know this as well, though in my defense I can point out that I am a single person working on multiple projects without a budget in my spare time. In Duke's case, I believe it is the marketing equivalent of an infinite loop. The quality level required for a AAA commercial game is very high. When a project takes longer to develop when the game is near ready, the quality level may no longer be AAA levels so the decision is made to take a bit longer and up the quality of the graphics, sound, game play, or whatever it is that is lacking compared to other titles. Since you have more time, the coders might as well add new features to the game as well. This feature creep causes the revised game to be late and when it is finished it is no longer AAA worthy so the cycle starts again.

Tuesday, December 18, 2007

While there are alternative ways to display images, the predominant displays (televisions and computer monitors) are what as known as raster devices. This means that the display is broken into a number of horizontal lines. Each horizontal line can then be broken into discrete chunks which are known as picture elements or pixels for short. While we know that the best resolution in HD televisions is 1080P which means there are 1080 horizontal lines with each horizontal line having 1920 pixels. For the B8VGC project, we are going to have to assume that non-HD televisions will be the display device.

Being in Canada, television broadcasts are in the NTSC (National Television Standards Committee) format. This format has 525 scan lines which are refreshed at 30 frames per second. Television broadcasts are interleaved, meaning that each of the 30 frames are broken into two fields. The odd lines are drawn first, then the even lines. This is what is known as interlacing. Not all the scan lines are visible, as some are used for the vertical blanking interval so the real visible resolution is roughly 480 lines. NTSC isn't the only format, there is also PAL (Phase Alternating Line) and SECAM which has 625 lines 576 visible at 25 fps.

The horizontal resolution of the display is a bit different beast. Because television signals are analog in nature, there is no absolute resolution. Instead, the number of pixels on a scan line is determined by the timing of the signal. DVD uses 720 pixel scan lines. These, however are not square pixels. If you want square pixels, then you will want 640 pixel scan lines. Programmers prefer square pixels so we will go with a television resolution of 640x480. That, unfortunately, will not be the resolution that the console will be using due to memory issues.

Sunday, December 16, 2007

I was at java.net reviewing the task list for the Ultimate Retro Project and I discovered that I have not posted the instructions for Classic Cribbage. This was completed a while ago, but was not done on my Mac (the predominant machine that I use for work on UR). In fact, thinking back, I had forgotten to write the instructions for the classic game and only remembered when I started posting the game. I use Dreamweaver for the Blazing Games site, but my CS3 license is for Windows as that is the OS I originally purchased Flash for and Adobe requires that upgrades are for the same OS as the software being upgraded and their software is too expensive to re-purchase. I quickly wrote the instructions on my Windows machine with the intention of posting it to the repository later. As you can tell by this post, later is much longer duration than I originally intended. For that I apologize. For those of you who are actually interested in the Ultimate Retro Project, I am going to try and start spending a couple hours every weekend working on it until the project is complete. I am also going to try posting to the repository more frequently instead of just when I have finished a game.

Thursday, December 13, 2007

I've decided that it doesn't make sense to repeat content. For that reason, I am not going to post articles that are going to appear on the Blazing Games site in this blog. While there certainly may be some overlap of material, articles that are going to appear on Blazing Games will no longer be written here. That being said, I have no problem with the idea of releasing some material early and providing an early access link to that material, but I obviously didn't do that for chapter 20 of Making One of those Weeks which was released on Blazing Games today.

Wednesday, December 12, 2007

With five different components to design and develop for B8VGC, I am going to tackle each of them separate. The first most logical starting task from my perspective is the graphics processor. This may come as a surprise, but if developed properly it should be flexible enough that with slight modification it could be used for the development of a number of other games. Perhaps even that arcade series that certain people keep asking me to develop. Next will come the memory management unit since the virtual CPU we are developing will be dependent of it. The CPU is going to be the big task so I will develop that once the MMU is finished. At this point we have a usable system with no way of controlling it, so the virtual gamepad will be the next task. Finally, the sound system.

My thoughts for developing a graphics subsystem for the console would be to develop a general purpose flexible system and then design the consoles memory representation in a way that it would be fairly easy to write an emulator of the graphics processor that converts the necessarily more restricted console data to the more flexible general purpose system. While this may not be the most efficient way of doing things, we are talking about an eight bit console being emulated on very fast hardware so the overhead shouldn't be that big of a deal. Still, I am going to have to keep the 8-bit restrictions in mind.

Tuesday, December 11, 2007

Shortly after posting my entry yesterday I found out that the Canadian DMCA Bill was withdrawn. As I had already posted my entry, I figured I would wait until today to let the few of you who read my blog know the good news. While I highly doubt my letter was the reason for this, I suspect the public outcry combined with a minority government is what caused the temporary delay. I am sure that another attempt will be made in the future, but I can at least hope that due to the outcry that the next attempt will at least try to keep with the spirit of Canada and will at a minimum address fair use issues properly. I'll probably be writing more letters to my MP.

Monday, December 10, 2007

While I normally only discus my own projects on this blog, after all it is the Blazing Games Development blog, today I am going to make a bit of an exception and point you to another project that while I am not involved in is one which I will be keeping an eye on. This project is none other than the Apricot project (http://apricot.blender.org/). This is an open source project that is attempting to develop a commercial quality game using just open source tools. In particular, they will be using Blender and the Crystal Space game engine.

Blender is a 3D modeling/animation program that is quite powerful if you can get past the atrocious user interface. That may not be a fair comment since it has been a while since I played with it so things may have gotten better. I just installed it on my Ubuntu machine though doubt I will have a chance to play around with it any time soon. There are also windows and OSX versions available. Still, if you want to create 3D movies, Blender is certainly more than powerful enough and considering it's price it may be the perfect choice.

Crystal Space is a 3D engine. If I recall correctly, it is portal based. I had considered it in the past and may yet use it for a future project. That is assuming I decide to develop a download only game which is probably something I should do since applet development is so restrictive. Sure there are some game engines designed to run on browsers, but their installed bases are small and system requirements are high so right now Flash and Java are the only real choices for web games.

What is really interesting about the project is that the goal of the project isn't the commercial quality game, but instead the goal is to develop a proper pipeline for developing games. This means that both Blender and Crystal Space will be improved to allow for better game development work flows.

Sunday, December 9, 2007

There is proposed legislation for a Canadian version of the DMCA. The problem is that fair use rights are not addressed in this law. For this reason I have mailed my members of parliament.

As the creator of vast quantity of copyrighted works I certainly understand the need for copyright laws. Though I personally feel that the length of copyrights are way too long, that is a separate issue. What is at issue is the omission of fair use rights from the proposed Canadian DMCA. These rights are of tantamount importance and must be present in any DMCA bill that is put forward. If you feel it is necessary to delay addressing these concerns, then the introduction of the Canadian DMCA should be delayed with them.

As both a creator and consumer of digital content, it is my opinion that consumers should be allowed to copy, time-shift and format-shift material as long as it is strictly for personal or educational use. If digital locks prevent such things, consumers should be allowed to use any tools available to bypass those locks. Likewise, parody and the ability to criticize works is of up-most importance to citizens and not even the most vile of police states would try to make such practices illegal. Also, when you consider that the entire Technology Industry was built on top of the practice of reverse engineering it is vital for our economy that this practice is allowed in the future.

If you are under pressure from trading partners to pass a DMCA bill into law, it would be best if you incorporated the broadest possible fair use laws and then have a Copyright Review Panel to consider if the fair use rights are too lenient and restrict those rights in the future if the majority of Canadian Citizens felt that it was necessary.

Thursday, December 6, 2007

The Christmas special is potentially the first of two Christmas releases, though I won't guarantee it. It is also being dedicated to my mother who's birthday it is. For those who are wondering, the graphics are scaled down versions of graphics that would have been used in the originally planned three part Christmas special, though the scaling does not do justice to the original images.

Wednesday, December 5, 2007

GameSpot's weekly podcast, the HotSpot, discussed the firing of Jeff Gerstmann. The podcast is free and available on their site. I assume everybody knows that you do not need an iPod to listen to podcasts. It is still not clear why Gerstmann was fired, but it is clear that the GameSpot staff were devastated by cnet's decision to fire him. I am not sure I like the direction that cnet is trying to take GameSpot and will be distrustful of all cnet owned properties for a long time. This whole situation was handled very poorly by cnet, and GameSpot really is going to have a tough time rebuilding their reputation. The podcast was a good start, with the best part of the podcast being a listener phone comment, "Jeff Gertsmann got released before Duke Nukem Forever."

Tuesday, December 4, 2007

As I said a few days ago, I am doing the B8VGC project entirely in this blog and only when I have nothing more pressing to talk about. At least, that is the plan for the design stage. When I get to coding, things may change, but we will cover that part of the project after we have reached it. The first thing is the design, and when I am starting the design on any project the first thing that I do is break the project down into more manageable components. So, what are the components that make up a game console?

Obviously, the heart of a game console is the CPU that powers it. This CPU will be the 8 bit virtual machine that we will be designing. Being able to run code doesn't do much by itself. We will also need a way of handling input and output. The input requirements can be very simple since we can make the assumption that the virtual console is uses a virtual ROM cartridge. Of course, the cartridge, to allow for a reasonable amount of storage, will allow for some type of overlay memory management so some type of simple memory management chip will have to be emulated. Of course, the player(s) of the game console is also going to be a source of input via 1 or more controllers. The output comes in two forms. We are going to need a graphics system and a sound system.

Monday, December 3, 2007

I had to come to a hard decision today. As readers of this blog already know, I have started development on a Christmas special that will be sharing a lot of code with my Android project. With less than a week left to finish developing the game I am at the critical juncture where I have to decide if I focus on finishing the game for this year or put the game on hold until December 5, 2008. After taking a look at everything I want to be in the game, I am quickly realizing that everything that I want to do with this game is not possible within such a short time frame. It is certainly possible at this point in it's development to rush something out the door, and there are numerous companies that would do just that. In fact, I suspect there are more companies that would rush something out than delay a project for a year. Still, I have an alternative christmas special and some One of those Weeks releases so I don't think my regular visitors will be overly disappointed with this December's releases.

The gamespot website has finally posted something on the firing of Jeff Gerstmann, though the news article doesn't give any details or provide any useful information. They do say "However, contrary to widespread and unproven reports, his exit was not a result of pressure from an advertiser." That may be true, but then why edit the review? It will be a long time before I start trusting reviews on cnet owned sites again. Had they left the video review alone and made a statement right away, I would be a lot less leery of them than I currently am.

Saturday, December 1, 2007

While cnet has said that they do not let advertisers have any say on editorial content, it is interesting to note that their gamespot site has re-posted the kane & lynch review with the content edited to remove some of the legitimate criticism that Jeff made about the game. To me this just confirms the fact that cnet is a sellout.

The bigger issue is how did this situation happen? My personal view is that there is a cycle of greed. Sites initially start off small with only a few people working for them. The only thing they have is their integrity. As a result, they have honest reviews. As they start to grow, they start needing to hire people and spend more on their structural costs. This costs money. As today's generation don't want to pay for anything, the only real choice is to have advertising. Some sites have subscription services that don't have ads, but too few people are bothered enough by ads to pay for such a subscripion. This means that the bulk of their money must come from advertisers. While this does not have to be a problem, far too often the advertising department, which is bringing in the money for the company, gain too much power and slowly editorial integrity is forgotten in favor of appeasing advertisers. This is when people who care about integrity have to find new sources for their information.

As there are no reviews on Blazing Games, I don't really have to worry about this issue. What would I do if Blazing Games somehow managed to grow to the point where advertisers wanted to control the content of my games? If advertising is the only real revenue stream it is a very tough decision. I am sure I have a price, and that price is probably a lot lower than what I think it would be. That, however, does not change the basic fact that if advertisers can dictate the reviews that their games get, the reviews are no longer worth the electricity that transmits them across the internet. What is sadder still is the fact that this will continue to get worse until people decide that content should be paid for which would decimate any say advertisers would have as then they would be only a small portion of revenue. After all, it is the content that drives traffic.

About Me

I am a programmer who can program in a large variety of programming
languages (including some Assembly Language) but am currently focused
on interactive web development which means my current focus is on Flash
and JavaScript. When I am not programming for clients, I am working on my
game site.