Python, Javascript and UNIX hacker, open source advocate, IRC addict, general badass and traveler
347 stories

After-Action Review: An Overview of the Making of LuftrauserZ

1 Share

After releasing LuftrauserZ last month, a few people asked for a post-mortem on how Paul Koller created his opus, the demake that many thought was improbable -if not impossible- to achieve on the modest 8-bit breadbin. A brief making of both Luftrausers and LuftrauserZ is included within the game manual, but with a limited page count a great deal of info was missed. So, to rectify this and fill in the blanks, Paul has helpfully written the following blog post on the creation of LuftrauserZ.

Of course, it would be foolish of me not to remind you that the game is (currently) available to buy again on cartridge and as a download. The cartridges don't tend to stay in stock for long though!

Shortly after having finished Micro Hexagon in 2013, I wanted to try my hands on implementing a high-speed full-screen all-directional scrolling engine on the C64. I quickly had an engine running which supported up to 8 pixels/frame. Only after finishing the engine did I begin to look for a suitable game to use the engine in. At that time (early 2014) I knew of the imminent release of the high-speed arcade-shooter Luftrausers by Vlambeer. Having previously ported Super Crate Box to the C64, I knew their games have designs that would also work quite well on more limited hardware.

So even before the original release of Luftrausers, I decided to try and port the game to the humble C64. I knew that I wanted to have the game running as smooth as possible, so that means running at 50 fps (in PAL land :)). To have sufficient time for the general game logic, while also supporting high-speed scrolling, I knew I had to compromise somewhere. The nice thing with Luftrausers is that it was designed around a limited colour palette, while also the in-game background graphics are based on silhouettes. The C64 supports a so-called Enhanced Background Mode (EBM) that supports 4 different background colours at the cost of only supporting 64 different background characters. I knew that this graphics mode would be ideal for this game, since it removes the need to scroll the colour-RAM! However, with this EBM mode, it took some imagination to fit all different background graphics into only 64 different 8x8 pixel definitions! I think I succeeded quite well in the end...

Since the screen resolution of the c64 is much lower than the original game, I first tried to scale down all the graphics, such that the game gives you a similar field of view. However, I quickly realised that I would not be able to get all the different player sprite configurations nicely into the game in this way. And maybe even more important, with a more zoomed-out image it would be more difficult to get a high enough density of enemy planes on screen to give the player enough to worry about. In the end I chose to keep the same detail as the original and thus give a more zoomed-in view. Since there are no real obstacles in the game, this more zoomed-in view does not impact gameplay that much...

The c64 only supports 8 sprites on screen at the same time. I knew this would not be enough for the player, enemies, bullets, as well as the score indicator. In principle this 8 sprite limit can be overcome by using a sprite multiplexor, however I knew it would not be ideal for this game, since one can only have 8 sprites on a horizontal line. Also, I wanted to support lots of bullets as well. In the end I decided to go for character based bullets, and only multiplex the player and score sprites. Since bullets travel quite fast, it would not be that noticeable that they only move in steps of 8 pixels. It does mean that even less characters would be available for the ingame graphics! The c64 also supports expanding a sprite image through hardware. This meant that the big aces could be implemented as expanded fighter images, removing the need for additional sprite graphics!

The different weapon systems were relatively easy to implement. Only the laserbeam caused me some headaches. I knew it would be impossible to have a large solid beam on screen together with all the other graphics. In the end, the best compromise I came up with was a shorter, but fast moving laser beam.

Another crucial graphics element that would be difficult to port over was the damage indicator. In the original game a large circle is drawn around your plane, whose radius indicates the amount of health you have left. I tried different approaches here, but all of them were not large enough for you to notice in the thick of the action. Showing the remaining health as border color worked quite well, since it does not need special attention to notice while in the thick of the action!

The original game is also known for its dynamic soundtrack, which changes depending on the plane configuration that you selected. I wanted to include something similar in my c64 port. However, having 125 different soundtracks would be a bit too much. In the end we decided to go for the 5 variations that are featured on the Kozilek OST (BandCamp link). Stein Pedersen succeeded incredibly well in porting these to three-voice SID-tracks. By linking these to the 5 different weapon systems, some nice variation in the soundtrack has been realised!

Although I wanted to have as much of the original game in there as possible, some things had to go because of technical reasons. The obvious one is that the amount of enemy planes and bullets on screen at the same time had to be reduced. I tried to have the enemy submarines in the game, but I couldn't have them rising out of the water together with the fast scrolling. In the end I decided to remove them completely. Also the laser aces were not possible due to needing additional sprites for the laser beams. Still, the most important enemies, including the blimp, did make it into the game!

During coding of the game I quickly realised that having all the different player sprites in RAM would not be possible. Even with building the player sprites from 3x5 different parts, and only having the 90deg rotation images stored, I needed additional memory to store them all! Having worked with RGCD in the past, I decided that my Luftrausers port would also be exclusive the cartridge format. This enabled me to quickly copy the required player sprite images over from ROM, without interfering with the game flow!

Around the same time Individual Computers were developing a low-cost cartridge that would enable saving to an eeprom chip. Since Luftrausers is based on continuously unlocking new parts, we needed some way to save your progress. In the end we decided to use this new cartridge format, enabling people to enjoy the game without the need for additional tape or disk storage systems. However, at that time no generic flash-software existed to burn the ROM images themselves, so this also needed to be written.

During the development there were quite some ups and downs motivation wise. After having written the bulk of the engine, you realise all the less fun parts that still need to be coded before having a finished game. Because of this, the development of the port took more than 3 years to finish! However, by showcasing the game at several events (including GamesCom in 2016), enough motivation came back to put the finishing touches to the game.

At the beginning of 2017 my c64 port of Luftrausers (titled LuftrauserZ to distinguish itself from the original game) was essentially finished. However, commisioning of the package design, as well as personal issues, lead to multiple significant delays. In the end it took until the beginning of December till we could release the game, just in time to ship for Christmas. James decided to release the game in batches of about 30-40 copies to keep it all manageable and avoid delays in shipping. However, this did lead to the fact that many people only heard about the release after the carts were already sold out! In the end it only took a few weeks to reach 100 sales, making it quite a successful launch (122-and-counting at the time of writing). The response from the community was overwhelming. In the end we scored 4th in the Reset magazine C64 2017 GOTY award. Which is very good if you see what other amazing C64 games came out that year!

In the meantime I'm already working hard on a new C64 game. Follow me on twitter if you want to keep up with the latest news!

(Paul Koller, 15/01/17)
Read the whole story
30 days ago
Helsinki, Finland
Share this story

bring in any receipts you got


old diary entries, anything that could help us pinpoint the time and date of a sin and possible prayer about it. we don’t want the archdiocese involved if we can help it

Read the whole story
35 days ago
Helsinki, Finland
Share this story

Q4 Roundup

1 Share

Ethereum has grown very rapidly in the last few months. Transaction volume on the blockchain has more than doubled, surpassing 10 transactions per second for days at a time. The number of new accounts created per day passed 100,000, and the number of nodes has increased despite rising system requirements. As attention and interest in the blockchain space as a whole continues to hit new highs, we are entering a new phase in the industry’s growth: the phase where we are finally going from experiments and tests to real, live applications.




EIPs (Ethereum Improvement Proposals)

We merged 12 EIPs since the last roundup.

Formal Verification

  • We received a contribution from Sidney Amani and his colleagues at Data61 that reduces the number of reasoning steps in EVM code verification.
  • Fixed a bug in Bamboo related to JSON ABI formatting.


  • Testeth now checks that test .json files are updated with the test filler files. Each test has a hash of its filler.
  • Testeth will show a warning if there is a test without a filler.
  • Transaction test fillers are now in general format. One test describes a case for all different fork rules.
  • Some large test suites (with many tests) were split into separate smaller ones for better execution on threads via ctest.
  • Testeth random code options were revived. With `–createRandomTest`, testeth will generate a smart random state test. This command also accepts options for generating a random code.
  • Testeth options throw a warning/error if used incorrectly.
  • New tests were added from the spreadsheet.
  • A PR with YAML support for test filler files is in progress. Unlike JSON format, YAML format allows user comments and multiline fields for nice smart contract representation.


Latest update ( includes:

  • A way to record transactions (in order to execute them later on).
  • Use of the standard JSON IO interface for the Solidity Compiler.
  • Improvement on the Solidity Editor.
  • Direct use of the ABI to interact with contracts.
  • General interface improvement.
  • New Static Analysis module.

Thanks to @ninabreznik (Solidity Editor), @serapath (Recorder), @ryestew (Interface) for their active contributions.

We are now focusing on improving the code editor, improving Remixd (which is now hardly usable for huge folders) and polishing the themes.

We continue to work try our best to update each month and for each important bug fix. As Remix is under heavy development, there are always new features coming in, so feel free to contribute feedback and code.


We are working on an optimizer for our new intermediate language IULIA. The first goal is to turn the extremely modular code of the new ABI coder into efficient code. Of course all inline assembly and also the main code generator will benefit from this work in the end. In contrast to the old optimizer, which basically soaked in bytecode into an internal representation and then re-generated the code from scratch, the new optimizer is composed of many small and very simple individual stages that directly operate on the IULIA AST and thus are easily verifiable for correctness.

The second large area of work is the SMT checker component. It is now able to correctly follow branching and joining control flow and also takes conditions into account. Experimental loop unrolling is the next stage.

Apart from that, we are making many tiny changes to the compiler and language and fixing the remaining issues that were identified in the recently completed compiler audit.

I would like to thank the many voluntary external contributors for their hard work (individual attributions are made on the release page, as always)!


We are continuing the efforts to fuzz-test the EVM, and we are also applying fuzz testing to other areas of the Ethereum platform such as the geth networking stack and the solidity pipeline where we are seeing if it can be used for quality assurance of some new IULIA components.

We are creating a new signer to enable more advanced use cases where account management is decoupled from the network node. The idea is to have a what-you-see-is-what-you-sign experience, where the sensitive components can be executed in a separate VM, or on a separate computer or a mobile phone.

There has been quite a lot of activity on the bounty-front, particularly targeting Mist, and we’d like to remind all usersurge you not to use the Mist browser on untrusted networks or untrusted websites.

Also, EthereumJ is finally being added to the group of clients which undergo Hive-testing, and EthereumJS is being added to the group of clients supporting the common shared json output so that it can play along with the others in the Evmlab tools.

Python Ecosystem

We have completed migrating the repositories for most of the python libraries to the Ethereum Foundation github. Many of these libraries were renamed in the process to conform to a single naming convention. If you use any of the following libraries, you should update your dependencies.

  • ethereum-utils renamed to eth-utils
  • ethereum-abi-utils renamed to eth-abi
  • ethereum-keys renamed to eth-keys
  • ethereum-keyfile renamed to eth-keyfile
  • ethereum-tester renamed to eth-tester

In addition, most of the python tooling will now issue deprecation warnings when run using python 2. Support for python 2 will be removed in the first quarter of 2018. Please upgrade to python 3 if you haven’t already.


The eth-tester python library has gotten a few upgrades and improvements. This library is still in a pre-release beta.

  • New pyethereum>=2.1.0,<2.2.0 backend
  • Updated py-evm backend for latest byzantium rules.
  • Various bug fixes. lets your python code interact with an Ethereum node. Version 4 was released, as Beta, including these changes:

  • Automatic Ethereum Name Service lookups: methods that accept hex addresses now accept ENS names.
  • Working with local private keys: sign and verify simple transactions, contract transactions and messages.
  • Better guessing at connection parameters, for less boilerplate when initializing Web3.
  • EIP 55 checksum addresses returned everywhere, and required as input.
  • Better native handling of string and bytes types; more `bytes`, less hex `str`.

EthereumJS ecosystem

  • Our Byzantium update is well-received (pre-Byzantium still usable with v2.2.2 release) and already used by Remix and Ganache (former TestRPC).
  • Devcon3 talks on web3.js 1.0, the EthJS dev toolkit and remix development, were presented, as were also various other talks regardingwith relevant technical background.
  • New rustbn.js library for the elliptic pairing precompiles in the VM based on the Rust library from Zcash/Parity.
  • Support for merkle proof creation and verification in the merkle-patricia-tree library (courtesy of @jbaylina).
  • EIP-8 compatibility and better documentation for our devp2p library.
  • A lot of Devcon3 EthJS feedback, coming updates: possible callback support removal for Node.js clarity, easy BLS signing libs (thanks DFinity!), an Ethereum node wrapper for easier testing, package management helper libraries, better filtering support.

Web3.js 1.0

The 1.0 branch is evolving with the help of a lot of community contributions. Even though it is still in beta, many developers already use 1.0 for their projects and the response so far has been overwhelmingly positive. In the next weeks, the web3-accounts package will be audited as it can be used for generating keys and signing messages and transactions.

eWASM (Ethereum WebAssembly)

Progress continues on ewasm-kernel and evm2wasm, which form a prototype VM and transpiler written in JS. Progress also continues on Hera, a VM written in C++ that is compatible with the EVM-C API. We are working to transpile the EVM state tests into an eWASM test suite which can be used for testing Hera. The near-term goal is to build a “Geth+Hera” client and use it to launch an eWASM testnet.

C++ Ethereum


There has been one geth release since the last roundup, v1.7.3. Highlights in that release


  • Version 2 of the les light client protocol. les/2 adds support for retrieving partial log bloom filters, which enables quick log filtering with the light client.
  • `geth –dev` is much faster and uses Proof of Authority instead of Proof of Work.

For the next release, work is focused on:

  • An overhaul of the VM tracing infrastructure:
    • support for tracing a range of blocks, including reconstructing historical states.
    • predefined tracing functions, e.g. for collecting all internal transactions or the state closure of a particular call.
  • Moving handling of account private keys from geth into helper tools:
    • the signer, a tool for signing transactions.
    • ethkey, a command-line tool for dealing with key files.
  • Shipping a working peer discovery v5 prototype and publishing associated EIPs.
  • Enabling more static analysis tools for continuous integration builds.


Ethereum Wallet and Mist Beta had surpassed the 3 million downloads mark, combined. The latest version, 0.9.3, was downloaded over 450k times.

Our team welcomes two new members: Marc Garreau and Ryan Ghods.  After a while, we’re back to a full squad.

Main changes since the last update:

– Light client integration and Wallet Dapp adaptations, although the LES v2 is still experimental.

– A rewrite of the core of Mist, enabling a better state control and resources handled by the application.

– Studies and a lot of mocks/sketches concerning the next step of node, transaction and accounts management.

– Numerous bug fixes and issue handling.

We recently released a security alert concerning Chromium vulnerabilities affecting Mist Browser Beta.


One of our projects is PSS, a messaging system built on top of Swarm. The features planned for PoC3 are mostly done, and PSS is already used as the backend of the prototype chat application of Mainframe.

PSS uses the routing network of Swarm to deliver messages between nodes. It already implements the following features: encryption (optionally with ephemeral keys generated by the handshake module), luminosity control (full, partial or no disclosure of addresses of communicating nodes), RPC api and flood prevention. We still have a few tasks to do, mostly stress testing and benchmarking and we also have to merge back the code to go-ethereum master.

We are also working on the swap, swear and swindle incentivization system. We have a basic implementation of swindle, swap and chequebook in the Swarm code, and the other parts are described in the in-progress paper. Our goal is to finalize the paper and start to implement the incentive layer.

In our network testing and simulation project, we implemented a framework to create and run a simulation network of devp2p nodes. For the simulation we implemented node adapters which create a test environment for the nodes to run in ( in-process, executable and docker adapters). We also created a 3d visualization app to display the network structure and behavior.

We also started promising collaborative efforts with Wolk (to develop a database layer on top of Swarm), Livepeer (to implement live video streaming using Swarm) and Status (to implement light swarm nodes for mobile).


Version 6 of Whisper has started., Wwe hope to be done by the end of February. v6 offers nodes more control over the network load, explores the use of libp2p in the go codebase, and improves compatibility with the Parity version of whisper.

The post Q4 Roundup appeared first on Ethereum Blog.

Read the whole story
48 days ago
Helsinki, Finland
Share this story

Temperature Preferences

4 Comments and 11 Shares
There's a supposed Mark Twain quote, "The coldest winter I ever spent was a summer in San Francisco." It isn't really by Mark Twain, but I don't know who said it—I just know they've never been to McMurdo Station.
Read the whole story
97 days ago
Helsinki, Finland
Share this story
4 public comments
85 days ago
Lisbon doesn't get a look in? I'm hurt...
FourSquare, qv
97 days ago
First xkcd for a while I don't think works. I have been to Riyadh and Hong Kong in the summer. I find it hard to believe anyone who loves one of their climates would even like the other. Dubai+Delhi seems dubious too though I have no first hand experience there.
97 days ago
Yeah that’s the thing, heat and humidity don’t necessarily go together. I could definitely see liking hot, dry summers but hating hot, humid ones. I would understand the other way less but that’s just me :)
97 days ago
I'm tolerant of hot, dry, but I don't like it. Hot and humid, or even warm and humid just makes me miserable.
97 days ago
Awesome. And I love that both Lahore and Karachi are in there!
Melbourne, Australia
98 days ago
I was wondering if KC would make it and sure enough, it is where it belongs: if you love cold and love heat. I live here and love neither.
Overland Park, KS
98 days ago
Yup. I also hate both, but I hate heat more. Looks like I need to move in the direction of New York (on the chart, obviously).

The Global Token Awareness Initiative

1 Share

Screen Shot 2017-10-10 at 2.24.09 PMFollowing the Canadian version of Token Awareness, today I’m introducing Token Awareness, a global initiative to promote responsible token generation events and token-based models for entrepreneurs, startups, and industry practitioners.

Token Awareness is mostly a curated collection of current and proposed best practices models and self-regulatory projects covering token generation events (TGE) and initial cryptocurrency offerings (ICOs).

Throughout my interactions with the market, it was obvious that several groups around the world expressed the need for self-regulation and some jumped-in to propose projects to show how it would work. My belief is that, not one project, approach or self-regulatory project will dominate nor impose a process on the rest of the market, at least not at this point. Rather, the reality is a collection of such initiatives and projects that will intermingle with one another, and together, they will complete the picture, especially that the local vector is always omnipresent.

The reality is that regulators will regulate, and the market needs to implement sound and responsible practices, which is the focus of this initiative.

On the website you will find:

  • Compliance status from the major regulatory bodies, including significant updates from them
  • A list of best practices projects (current or in-progress), coupled with a reading list
  • A directory of organizations in the following categories: Associations, Regulators, Lawyers,  ICO Service and Data Providers
  • A comprehensive news feed, integrated via my other website OnCoins which aggregates news from 274 sites


Over time, content will be updated via a careful and conservative curation of only the most essential and useful resources via the guidance of the Steering Group, and proposed addition that are submitted using this form. Anyone is encouraged to suggest content additions. We realize we have missed content, especially from Asia. The Lawyers list is also developing and needs beefing-up.

To help steer the direction of this initiative, I’m joined by 4 unique individuals whose work I value tremendously. Each one of them is known for their extraordinary contributions: Selva Ozelli, Oliver Bussmann, Juan Llanos and Simon Taylor. Selva, who may not be as well known in the blockchain circles, has been researching the global regulatory environment for cryptocurrencies, with a focus on tax implications. Her latest paper, Regulations Fall on Bitcoin Around the World is excellent. We will add a few more people to this initial list in order to round-up and deepen the global coverage and expert oversight for this initiative.

Read the whole story
133 days ago
Helsinki, Finland
Share this story

Firefox Nightly enables support for FIDO U2F Security Keys


This week, Mozilla enabled support for FIDO U2F (Universal 2nd Factor) security keys in the pre-beta release of Firefox, Firefox Nightly. Firefox is the second largest internet browser by user base. In the near future, 80% of the world’s desktop users, including Chrome and Opera users, will benefit from the open authentication standard and YubiKey support out of the box.

When GitHub made support for U2F in 2015, the open source community voted U2F as the most wanted feature in Firefox. We are delighted to now see it happening. Yubico has helped with U2F integration for Firefox and for other platforms and browsers that have or are in the process of making support, as it is critical for taking the YubiKey and U2F unphishable authentication to the global masses.

In today’s world, software installation brings with it not only added complexity for the user, but also the potential risk of malware. Chrome has already enabled millions of websites and services to deploy FIDO U2F seamlessly, mainly through Google and Facebook social login, to help mitigate that. Now with native support for FIDO U2F security keys in Firefox, millions more will benefit from strong, hardware-based two-factor authentication without the need to download or install client software.

Thanks Mozilla for working on increasing security and usability for internet users!

The post Firefox Nightly enables support for FIDO U2F Security Keys appeared first on Yubico.

Read the whole story
136 days ago
Helsinki, Finland
150 days ago
Oulu, Finland
Share this story
Next Page of Stories