Wednesday, September 20, 2017

Emulator Project Starting

I have decided that I am going to attempt to allocate a few hours every Wednesday to work on a homebrew project. While going back to my NES RPG would probably be a popular choice, the 2600Dragons.com project that I did for university has me interested in creating my own emulator. I know that there are many emulators available for pretty much any old system that you can think of so the work here is not really needed. Moreover, the emulators available tend to be pretty well written. Still, creating an emulator from scratch would be a very entertaining project.

My choices for target platforms would obviously be the Atari 2600, the NES, or a custom 8-bit console that I created just for the sake of creating an original emulator. Depending on what happens with my Masters degree, a variant of the third choice may be what ultimately happens but for now I am thinking of writing a JavaScript 2600 emulator. I have already created a rough simulator for the TIA chip, though it does need more work. It is the easiest of the three options to work on, and much of the work here can be translated to the other two ideas if it ever proves successful.

JavaScript is not the best choice of languages for creating an emulator but does have the advantage that it works on the internet. For this reason I am also considering writing the code in C and using an asm.js  compiler. Writing the emulator core library in C and compiling to JavaScript would allow me to use the core library in other C projects if I decided to go that route. I haven't used asm.js yet so this would be an interesting experiment.

The project would then be broken down into getting a memory subsystem for loading cartridges working, getting a disassembler working for disassembling the 6502 code on the cartridge into readable assembly language. Once I can get code disassembling then I can implement the emulation of the processor. Get the TIA chip emulated and add some interface code and I will have a rudimentary emulator. This sounds easy but I suspect the path will be a lot harder than I anticipate.

And yes, I do plan on creating a CoffeeQuest2600 game for the 2600 which would run in my emulator.

Monday, September 11, 2017

When I said quarterly updates...

When I said quarterly updates I meant every quarter of a decade or so. Okay, things got way to hectic, with university only being one huge time sink so I never really had much time to do anything. With that complete, at least for the next year (I am considering going for a Masters degree) I decided to take a look at my older material. With Java already dead on websites and Flash having a 2020 end of life, I have decided to close down Blazing Games. The Flash and Java games that people are interested in will be ported to HTML 5 and moved to my spelchan.com domain (which will be undergoing a major face-lift.

I don't foresee myself doing that much in the way of game jams or home-brew development, though I did post my 2600dragons site which I did as part of my web development course that didn't have a challenge option. It covers how the Atari 2600 works so people interested in how older consoles work may find it interesting.

I am trying to decide if I should post updates about the Blazing Games games that I port here or if I should resurrect my Blazing Games Development Blog even though Blazing Games no longer exists. I am going to try to update either this blog or my Development blog more frequently.

Wednesday, September 30, 2015

Going Quarterly for a While

Going to University combined with the other things going on has taken up a lot more time than I anticipated. While I have some homebrew related material and soon to have some game projects as a result of some courses I am taking, I have no idea when I am going to get the time to post these. When I do I will be writing and posting postmortems here. I am hoping to be posting at least once a quarter until the end of next year when I will be (I hope) finished with university and will actually have some spare time to do my own things.

Thursday, July 23, 2015

Kickstarter from an Indie Perspective

The fact that I am not talking about 2600 development should be a good indication to regular readers that I have not yet received my final marks for my Homebrew 2600 project. This means that I am falling back to my rant on Kickstarter.

The idea behind Kickstarter, and it's now numerous clones, is that poor artists/inventors are unable to publish their works because they do not have enough money to fund the development of their dream product. This not only is bad for them but bad for the people who actually like the product that they want to develop. The solution, crowd-funding. The people who want to see the product come to light can vote with their wallets and give money to the creator in exchange for product related rewards based on how much they donated. In the case of Kickstarter, the donations only get given to the creator if there are enough people interested in the project to fund the project past their minimum goal.

This sounds ideal for Indie developers, and a number of Indie projects have appeared on Kickstarter. The problem here is that as more people discovered Kickstarter, the more projects started to appear. Now we are at the point where there are far too many Indie projects so just being on Kickstarter is not enough to allow for people to discover your project. Instead, indies must now be able to market their kickstarter in order to get enough attention so that people will look at their project and potentially donate to the project. Needless to say, many Indies are (like me) totally abysmal at marketing so many awesome projects simply never get the attention that they deserve.

The marketing problem is actually even worse. Scammers, who will always exist where there is easy money to be made, tend to be really good at marketing. They, however, are just pretending to be creating a really interesting project with no real plans on even attempting to create something. Their goal is to get the money and then vanish. This makes it worse for newcomers to Kickstarter as if people don't know who you are they are much less likely to fund your project as legitimate Indies look the same as Scammers. Personally, I think the solution to this problem is to have simple prototypes available so potential funders know that a real product is possible. This can backfire, as many people can't seem to comprehend that a prototype is NOT what the final product is going to be like. Even when there are disclaimers on the prototype!

The next problem that happens is the fact that many Indie developers have never actually worked on a real commercial game so have no clue about costs. As a result, you see projects that have a far-lower estimate than they should. Even if they do get funded, they will not have enough money to actually complete their project to the quality level desired. This leads to either products being released half-finished, or projects being cancelled. Both situations reduce the number of people willing to risk taking on a Kickstarter project.

If things were not difficult enough for Indies attempting to kickstart a project, real commercial companies have discovered Kickstarter. In some cases this is a good thing as you have "dead" game categories such as adventure games being resurrected on Kickstarter. This is however bad for the Indies as why would someone take a chance funding an Indie game when they can fund a "real" game? In cases where the commercial developer is actually funding a game using Kickstarter this is not an overly bad thing but unfortunately, there is a trend towards another type of commercial funding that is starting to happen far too frequently.

Some commercial kickstarters are not actually using Kickstarter for funding but are using it as a type of pre-order system to determine if the game is worth developing. On the surface this may not sound too bad, but most of them do not disclose this fact so their funding requirement is substantially lower than the cost of the game. When you have a AAA quality game asking only for a million dollars, when in reality the game is going to cost 100 million, the game that is properly asking for a million is going to look pretty bad by comparison. This means that indies actually having a realistic budget are still at a huge disadvantage because people who don't know what is involved in creating a game see games costing a hundred times that amount being listed as being the same cost.

Would I do a Kickstarter? I actually am thinking about doing one. This would probably be combined with my final Computing Science project assuming my professor agreed. The idea here would be I would develop the prototype and Kickstarter campaign as my final project. The Kickstarter would then be used to decide if this project would be turned into a proper commercial project by funding the project. Essentially, I would be using it for what it was designed for and get money to finish the project.

Wednesday, June 24, 2015

End of the Game

The steam sale is over.  My ever-growing stream backlog grew slightly but for the most part I controlled myself. Most of the games in my steam account are bundle games. In the early days of steam they had catalog sales where you could buy a company’s library of games for less than the few games you were going to buy. Many other games in the bundle are also ones I want to try when there’s time so on the surface the bundle seems like a bargain. The reality is that there is not enough time.

Making matters worse is the proliferation of bundle sites. The first one I heard of is Humble Bundle. It was made up of indie games and wasn’t that frequent. Now it is every week and there are a large number of other bundle sites doing the same thing.

So, I have a lot of games, what’s my point? There are a lot of people in the exact same position. This may not be good for the game industry. If all the people with huge backlogs of games start working through their backlog instead of buying new games, game sales could plummet. Free-to-play games are already making it hard to sell games. Making things even worse are the huge number of game making tools on the market. It is now possible to make a game without any programming skills. As a result there are a huge number of games coming out. People claim that the good games will stand out, but I have seen a lot of great games fail. With the glut of games coming out, do people want to find diamonds in the manure pile?


Essentially game development has become a very difficult field to make money at and things are going to get worse before they start to get better. My solution is to keep it a hobby. There are probably other solutions. I had thought that Kickstarter was one alternative, but I am no longer convinced about it. That is a topic for a different rant. Possibly next month, but I am hoping my 2600 project will be marked before then and that I will be able to get into my 2600 material.

Thursday, May 21, 2015

The changing face of optimization

Optimization is simply the act of taking existing code and making it run more efficiently. This does not necessarily mean faster, as it is certainly possible to optimize code for storage size or for end user efficiency (work flow) or any number of other factors that management/clients deem important. For homebrew development, the key things that need to be optimized for are memory use and speed. This makes sense as the storage space on a cartridge is very limited. Likewise, frame rates are always important to maintain. One of the interesting things about doing homebrew development is it brings home how much optimization techniques have changed over the years.

The scariest change in optimizing is the “why don’t you just use the -O3 flag?” response that less experienced programmers give. I find this scary because it is an indication that compilers have become some type of magic tool to some people. Compiler optimization switches simply tell the compiler to take extra time to produce more efficient machine code. When you consider how lousy the code compilers produced use to be, this is very impressive. In the “old” days, your average assembly language programmer could write better code than the best compiler could produce. Now you need to be a really good assembly language programmer to produce better code making writing assembly language a mostly obsolete skill. Knowing how the machine works, however, will always be important so I do believe that all real programmers should know some assembly language even if they never use it.

It use to be possible to write faster code by employing techniques such as code re-ordering and loop unrolling. This is now done by the compiler when optimization is enabled. As code re-ordering and loop unrolling resulted in ugly and hard to understand code this is an improvement that I actually like.

The biggest change that has happened, and will probably continue to happen, is shifting bottlenecks. When I started programming, floating point was something you used as a last resort as is was so much slower than using integers. Integer techniques such as Fixed point math were used as despite the extra instructions and complexity they were still faster than floating point math. Now floating point is just as fast as integer math, and in certain cases may be faster.

Today’s biggest bottleneck is probably memory. We are now at a point in time where RAM access speeds are significantly slower than the speed that the processor is running at. I have heard it claimed that a cache miss will result in over a hundred cycle delay. This means that techniques such as lookup tables may be a lot slower than you would expect. In a few years this will probably change as technological solutions to the RAM bottleneck are discovered. At which point a new bottleneck will appear causing optimizers to have to change their techniques yet again.

Ultimately the best form of optimization is the same as it always has been. Simply to understand the problem enough that you can develop a better algorithm for solving it. This often requires thinking outside of the box which is something a compiler simply can’t do. When compilers get to the point that they are able to do this for the programmer, we should be very worried as the robot overlords will be soon to follow.

Wednesday, April 29, 2015

Still Alive

It has been a few months since I posted here, but I am hoping to get back to monthly postings shortly. My NES RPG project is going to be taking a rather strange detour but I think I am going to try to allocate at least 10 hours a month towards that project. Before I get into the detour, I think an explanation of my tardiness is required.

When I went to post my January game I was told that I reached the limit for One Game A Month. This got me thinking and I decided to focus on University. I am in the process of upgrading my associate degree into a bachelor degree. I am hoping modern credentials will offset my age when looking for work in the future. I do still plan on occasionally participating in game jams when the topic is of interest and I have no pressing deadlines.

As being in a classroom filled with teenagers and twenty-somethings is not something I want to do, I am doing my courses online (through Thompson Rivers University and as a visiting student at Athabasca University) which gives me a lot of flexibility with my courses. I made the newbie mistake of taking 6 courses at a time with the idea of finishing my degree quickly. In hindsight this is not the optimal way of doing things as jumping back and forth between numerous courses results in slower progress than focusing on just a couple of course would. As most online courses can be completed at your own pace, what I am going to be doing in the future is to just have 2-3 courses going at a time but complete them quicker. This will result in less stress and the ability to take advantage of other opportunities that may pop up.

One of the courses that I am close to finishing is a web design course. The site I am creating for my final project is an Atari 2600 homebrew site. This was chosen so that the JavaScript component could be a TIA simulator. The thought of doing a PPU simulator was there but it is much more complicated than the TIA so the Atari 2600 was chosen. Once I have officially finished the course I will move the site to my own domain but knowing how slow bureaucracies are, this probably won't be until July. This is where the detour comes.

For the next while I want to play around with the 2600. Both are based on the 6502, so much of the work I do on the 2600 will be related to the NES. In particular, work on math functions and random number generation are needed for NES RPG and will be readily portable.