Wednesday, September 27, 2017

Why asm.js?

Developing a JavaScript application in C/C++ may seem strange, but there are many languages that do compile, or transpile if you wish, into JavaScript. A large reason for this is simply the fact that JavaScript is a scripting language and was not really designed for large applications so simply does not have some of the language constructs that aid in the creation of larger projects. The later version of ECMAScript (the standard that JavaScript is based on) are attempting to solve that problem, with TypeScript being an example of what the future of JavaScript may be like. The problem, however, is that there are people using old browsers so may not have access to the latest language features. Therefore, tools such as TypeScript are useful as they take new language constructs and compile them into older JavaScript code making the code useful to a broader range of users.

Developing in C or C++ is quite a bit different from using a language like TypeScript that was designed to compile into JavaScript. The reason a person would do this would most likely be to port existing code to the web. In fact, Unreal and Unity are two examples of such uses of this process. In my case, developing in C++ makes some sense as it would give me a very performant version that would run on computers (and possibly Android, IOS however does not allow emulation). The web version would be compiled into asm.js to give it satisfactory performance on browsers that implement asm.js and would still run on browsers that did not support asm.js.

The last sentence may sound contradictory but only if you don’t know what asm.js is. For those of you not sure what I am talking about, asm.js is a subset of JavaScript that can be compiled into very optimized machine language. Browsers that support the standard will then spot the asm.js code and compile it into native machine language for the best speed. Because the subset is designed for optimal code, the result is much faster execution than what JIT compilation would give you. Browsers that are not aware of asm.js would just see perfectly valid JavaScript which it would be able to run, though this would be at JIT speeds so the results would not be as good.

There are a couple of other ways of compiling C++ for use on a web page. The most obvious alternative is Native Client (NaCl) which is Google’s sandboxing technology for allowing native code to run in a browser. This has the advantage that the code being run is already compiled, but needs to be compiled for the processor that the client is using (so multiple versions would need to be created). The bigger issue is that many browser venders are not implementing this so it largely limited to the Chrome browser.

The other alternative is the relatively new WebAssembly bytecode standard. Instead of using a subset of JavaScript, this uses a bytecode compiled version of JavaScript. This results in much more efficient downloading of the application as the bytecode version is smaller than the code version. I find this a fascinating development as what is effectively happening is a replacement of Java bytecode that is vanishing from browsers and replacing it with a new bytecode. It is receiving support from all the major browser vendors but is a relatively new standard. In the future, I may go with WebAssembly for creating web applications, but as it may be a while before older browsers that can’t run it disappear, going with asm.js in the short term makes the most sense. Once I start getting some asm.js material out, I will see how difficult it would be to support both formats.

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 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 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.