Work in progress, 4k intro for Breakpoint 2010

Hey, almost one month that I have posted a message about coding a 4k intro for BP 2010. So what's going on?

Well, I'm happy to be close to the end, fighting with the last available bytes, working on the music with ulrick, running, and rerunning several times the intro to work on the synchro. We are almost done now, but It's far from what I was expecting to release! I have developed around 4 to 5 scenes but was forced to only use 2 of them. I will publish a complete detail about compression ratio/vs part of this intro after releasing it.

We have finally worked with 4klang for the music. This synth is very well designed and very versatile. The only drawback would be the total size code + data that goes around 1.4k to 1.5k. That's a lot and It didn't help me to inject more scenes. I would expect a synth code + data to be around 1k to 1.1k max, of course with less flexibility and probably a sound that could not be as rich as 4klang, but still with something nice. I have started to implement a small softsynth player based on my previous work. But I have suspended this laborious task, as I know that It would have taken me much more time to plug everything in a VST (although It's quite easy when you do this through .NET), design a simple GUI, file formats, develop a cool sound bank, test it, debug it....etc. That option was too risky, so I have postponed this work after BP.

Anyway, from what I have seen while starting coding this softsynth, is that It's possible to go around 600 byte for the player... and probably 400 byte for the music + the sound bank... but I will be able to confirm this when I'm done with it, It's only a projection. The fact is that a stackbased synth is powerful, allowing for complex sound design (and synchronization/modulation, nicely done in 4klang) but If you look closer at it, you will see that most of the synth part are almost common to all sounds : While a stackbased synth allows everything, pragmatically, a sound respond to some classic design rules : a collection of cascaded/combined oscillators/noisers, few insert-fx (and the most common ones, filters, stereo delay/reverb), and those rules have a straight translation to a stack based system that you will recognize immediately among different instruments (and this pattern will repeat). This "static" pattern is probably more efficient for a 4k, both for the code size and the data, allowing for example to "bitify" data organization. Crinkler is using exactly this kind of static pattern (I still do have to write an article about it) : instead of having a generic context modeling compressor, It's using some kind of semi-dynamic/static context modeling that is in the end, much more powerful then it's generic equivalent (from what I have seen, a generic context modeling decompressor code is around 2% to 4% larger for a 4k, not a huge deal, but 2 to 4% is around 80 to 160 bytes for a 4k.... and that's a lot for a 4k). Of course, this is not only a question of some static algo vs more generic one... it's also a question of being able to produce a well done code-size optimized x86 assembler code (and crinkler just for this, is a masterpiece).

So, 400 bytes would have allowed me to add a scene, add some nice text... :) But ok, we had to move on! I'm not going to complain about 4klang, when rudebox was so impressive, using exactly the same synth. It's possible to code something cool... and in the mean time to get some benefits from 4klang sound quality, so I found this an acceptable compromise... and a nice challenge!

Anyway, see you soon at BP 2010!

Coding a 4k intro for Breakpoint 2010

I'm going to be quite busy here until the demoparty Breakpoint 2010, as I want to release a small 4k intro for this great event! I didn't plan anything few weeks ago and was slowly working on d3d10/d3d11, working on some effects for a 16k/64k intro to release later this year... but BP2010 is supposed to be the last one and I don't want to miss this experience, first time to go there... and probably last time, so I have decided to go to this party and try to contribute to it, yep!

I have started to work with d3d10, as i wanted to add some direct2D nice layout text over 2-3 raymarching scenes... but I have found that direct2D is bit too costly for a 4k, specially if you want to avoid the basic white logo... so I have to switch back to a plain d3d9 and forget about some cool text. I will use this direct2D technique for a bigger intro. Due to my lack of investment in all the d3d apis until now, I had to manage the API from the ground up... and it took me a while... To facilitate the d3d10/d3d11 coding experience, I have developed a lightweight c++ wrapper around d3d10/11 APIs, almost exactly in the same way (naming conventions,enums) SlimDx has done the job, and I'm really happy with it. The d3d10/d3d11 API is very clean but due to some verbose API contraints (ugly enums mixed sometimes with some #define, HRESULT to check from every function return, a famous windows programming philosophy), It's really worth to wrap this API around something that transparently hide all those things, rename and rearrange enum/methods/interface. Currently, It's working great with this SlimDx's like wrapper, much easier to program, much easier to read, and It does generate almost exactly the same code than a straight d3d10/d3d11 code, with the capability to remove the HRESULT check and so on... I will probably release this wrapper ( a single .h with a bunch of inline methods) around codeplex later this year, as it should probably help people like me that prefer a syntax much more closer to the C# coding experience than c/c++.

During my small d3d11 incursion, I have also discovered that the DirectX Effect framework (fx syntax files, with techniques, pass) is no longer available as part of the D3DX runtime! Yep, you need to go to the Utility directory in the DirectX SDK to find that you can compile this framework yourself... It means that for all intros, you can forget about the DirectX Effect framework and program a much lighter Effect framework. One good thing about this change is that I had to better understand the d3d10 philosophy with the constant buffers access and so on... In fact, It's much easier to work directly with constant buffer, and surprisingly, It gives a smaller code. As soon as I'm done with the 4k intro for BP2010, I will publish a small post about this along the SlimDx like wrapper.

Last thing is that I didn't have time to finish my softsynth, because I was more targeting a 16k/64k, with a more complex synth... so we should go with the great 4klang gopher's synth... but I have two problems with it : 1) ulrick (my old friend, main FRequency musician) is unable to use it under Renoise. It burns its notebook's CPU and we don't know why, as it's a pretty standard core 2 duo intel processor... we did check lost of 4klang/renoise/system parameters without any success. 2) 4klang is great, but, the total code is often close to 900 bytes... I know that some of the top's 4k softsynth are around 500 to 700 bytes, so I'm not completely sure that I will use 4klang. The other idea is to take part of the work I did already for the bigger synth (that is developped in assembler x86), and try to plumb it into a fixed pipeline (and not a stackbased as 4klang)... I'm not sure, but I suspect that I could save a substantial amount of bytes... but still, not sure, and I need to check it... but It's going to be really hard to make it on time for BP... so we'll see...

Currently, I have only coded one scene for the 4k intro, I'm quite happy with it... but that doesn't make a full intro! I need to add at least 3 scenes, work on the transitions, overall design, synch with synth & so on... even for a 4k, that's a lots of work, moreover when you consider that this is my first prod on my own (I mean, first prod for the PC, after the 3 prods i released 20 years ago on Amiga! ;) ) but It's possible in less than 2 month to do it, so I'll try to do my best!