Optimizing Memory Usage

I've been working a bit on optimizing speed and memory usage of my not-yet-released free responsive website editor. I'm quite OK with the result so far:

Yes, that's right: the editor is using nearly 3 times less memory for editing a website then Firefox needs for merely showing the website! And it only contains a bit of text and images, no JavaScript or any other fancy stuff. Wondering what the Firefox devs did there.

Announcing a new project

A few months ago, Google decided to also rank websites based on if they work well on mobile devices. I looked shortly into that, trying to see how much work it would be to convert my software website to a responsive one. After a bit of playing around, I decided that this would be too much work for now.
But still, it itched me, and figured out that a lot of people probably have this problem too.

So I took my web editor WebsitePainter and - for testing - extended it a bit to allow responsive website design. Unfortunately, the result of this was a bit too complicated. WebsitePainter is an editor for creating websites with just a few clicks here and there, without any HTML or CSS knowledge. In order to create responsive websites, you still need to know at least a little bit more in depth about how the web works. But clearly too much for people used to work with WebsitePainter.
So, I forked this work over into another, new project, RocketCake responsive website editor:

RocketCake will be free for most people, because I think it might be a bit too complicated to use in constrast to my other software. But in order to keep the development of this software funded, there will be a professional edition with special features needed only by maybe 5% of all users.

If you are interested in this software, let me know by subscribing to the newsletter so you get a mail once it is released, or following me on Twitter, I will send out a notification once it is ready.

Day/Night cycle in 3D running in your browser

So I finally was able to code a small update for Endtime at Home, the game I use for prototyping new features for CopperCube. It now has a realtime day/night cycle, you can make light using a flash light, torch or match sticks, there is now a UI, a world map, and more:

You can try the game out directly in your browser, if you have Chrome or Firefox. I hear it also runs nicely on the iPad, in Safari. Maybe Apple finally fixed their WebGL bugs.
The same scene at sunset:

It should run fast even on slow computers, but it is pure JavaScript, after all. :)

I'm a celebrity!

You don't get back much for creating open source software, but at least, sometimes it gives you a very good feeling:

And makes you laugh sometimes :)

Implementing your own CSS Layouter

I've written a lot of websites during the last nearly two decades, and know pretty much of HTML, CSS, JavaScript and other web technologies because of that. But there is usually always a situation where I have to scratch my head and wonder how or why a browser is lay-outing a specific part of a website the way it does. And confusingly, why in the world other browsers are doing it in the exact same, weired way as well.

I recently had to implement a big part of CSS 2's visual formatting model for a new component I wrote, in C++. And while implementing this, I received answers to a lot of those questions. After I had a basically working HTML layout engine, it did exactly the same strange things in many situations as the browsers do. But with the difference that I now understood why: In most cases, because the implementation forced it this way. And the implementation seems to be the way it was, because it was the simplest way to make it work.

While testing my implementation, I also found bugs in some browsers layout engines: For example the original Opera apparently doesn't correctly layout blocks with left or right float in justified text flows. A bug my implementation funnily also had in a very similar way.

Anyway, I now understand much more how browsers do what they do. Not sure if this will be helpful when creating websites in the future, but it was definitely interesting. I can at least recommend to read through the specification one day, if you have nothing better to do.

Now on Steam

So, CopperCube is now available on Steam:

It was quite an interesting journey until there, and also interesting seeing Steam from 'the other side', as developer, opposed to previously, as gamer. I may not talk about any details, but I definitely expected something a bit different. :)

CopperCube has a launch discount of -20% applied to it on Steam, which still works until tomorrow, Friday 8th of May. To be fair, I also made this discount available to the non-Steam from our website, which you can get here.

I'll see in the next few weeks if and how much more money this will bring in, and adjust our development plans accordingly: If possible, I'd like to invest much more resources into developing CopperCube further. Let's see if this is possible now.

Android Development Update Hell

It appears to me that recently, some developers have gone nuts. Like the ones sitting at Google. They don't seem to be interested in backwards or forwards compatibility, and are pushing out this incredible crazy development dependencies. As example, see below what I spent half of this day doing: I just wanted to debug CopperCube's Android client code on a newly bought phone. Should be easy, with a ready to run and working development environment, right? No:
Dear developers: Did you ever hear about the term backwards compatibility? Or forward compatibility? The software I write has over 500 highly complex features (from calculating math on 3D GPUs, over running a web server to generating Android apps on the fly, or rendering realtime 3d reflection surfaces), will run on Windows 8 and 10, and while using some of that operating system newest features, it will still also run on Windows 95. And you don't have to update each time you start that thing. It is not magic. You just don't have to be a lazy-ass developer, in order to make this possible.


Last week, Valve sent me a friendly mail, notifying me that CopperCube has been greenlit. That's pretty neat news!

It will take some time making CopperCube available on steam, because this involves quite a bit more than just uploading the app there, but once this is done, maybe a few more people start using the game engine. This would be pretty nice, because then, I would be able to allocate more resources to continue developing even cooler new features for CopperCube.

I'll keep you updated on this.

The Real World doesn't have Undo

Software projects are quite often compared to other scenarios, like building a house or a car. I've often heard the claim that time estimates, planning or defect management are so much better in those other areas of engineering. But they are not true, in my opinion.

How many programmers do you know, who ever did some "real world engineering"? If you are a software developer, have you ever built something with your own hands? During the last 5 years, I've build a lot of stuff which was not software, and I can recommend to try it out: It is different to the process of building software, but you learn a lot which you can also re-use for your programming skills, interestingly.

For example, during the last 2 or 3 weekends, I build this thing here:

It is just a simple wall, a walk-in closet. But it is complex enough, and you need a bit of planning for it. When I built something like this the first time, and did something wrongly, I thought "Damn! There is no Undo button". There is also no copy and paste or version control system, so you need to do that project a little bit more differently than a software project.
But there are also a lot of similarities: Time and resource estimates are nearly always completely wrong. In the beginning usually by a factor 2, by my experience. But it gets better. It also doesn't matter if you are doing the project or parts of it yourself or are outsourcing it. It will usually take longer. And more money then anticipated. Also, there will be bugs. And the way they are fixed will not always be the correct one.

Basically, things I learned from building "real world stuff" is that planning and re-using is much more important than for software. Also, I think the way I am doing software projects has been improved quite a bit since I started building stuff like this. It is also a nice way to 'relax' from a thinking intensive programming session. So I can really recommend trying to do some DIY projects from time to time.

My Adventure of Getting a Code Signing Certificate

It was a surprisingly strange procedure to get a Code Signing Certificate. Which I decided to obtain in order to make the nasty ones of the browsers like Internet Explorer stop complaining when downloading installers for the software I develop.

Finally, I now have one. If you should decided to get one too, one day, read here what I had to go through: After having read quite a few times now that hackers and malware programmers apparently are able to easily sign their software with false certificates, I wonder if all this was it worth at all. And since the certificate is only valid for one year, I hope I won't have to do this again in 2016.

The process of getting this was costly (from the perspective of an indie developer) and quite complicated - and this although mostly everything went well. Imagine something would have gone wrong. I think this might also be the reason why code isn't signed that often.