Random float number generator using x86 ASM code optimized in size

While I'm working on the next 4k-64k softsynth for FRequency, I need to implement a simple noise generator. In the past, i used to call directly the c rand() function without digging into the internals... Because i have to develop the softsynth using x86 ASM in order to keep it as small as possible, i went through revisiting the problem of generating a random uniform float number in the range [-1,1) or (-1,1], but with size optimization in mind. This is not a common problem as you'll more likely be able to easily find a speed optimized version other the Internet but not a sized one...

I will focus mainly on 3 implementations, so i will not describe an exhaustive list of technique around. I would be glad if you are aware about a smaller implementation! I found quite some interesting results, like a poor performance of the c rand() function, both in terms of speed and uniformity.

Let's recall one of the simplest C random function you can find around :

float Rand() {
    return ((float)rand()/RAND_MAX) * 2.0f - 1.0f;
}

The rand() is generating an integer in the range [0, 32767]. RAND_MAX is equal to the max value 32767. The result is then scaled to the range [-1,1]. Let us first implement this in x86 ASM, just as an exercise.

AsmHighlighter Part II : Automatic x86 asm instruction size evaluation

Following the previous post about AsmHighlighter, I have just released a new version 1.1 of AsmHighlighter that evaluates x86 ASM instruction size for each instructions in your code. The instruction size is inserted in the comment next to the instruction.

When you are coding 4k or 64k (partially) demos in x86 assembler with size optimization in mind, it's sometimes useful to check the instruction size (as it is sometimes not so obvious, x86 has a lot of weird rules for their instruction size, particularly when using eax register on source/destination, or using ebx without an offset...etc).

This feature is available when you perform a formating of your document (Menu Edit/Advanced/Format document or selection, or Ctrl+k, Ctrl+d). Here is a screenshot result:

The magic behind it is that i have discovered a cool managed library called : Fasm Managed from Shynd's. This is a managed .NET dll that can perform dynamic x86 ASM compilation inside a .NET application. The code is simple as below:

byte[] buffer = ManagedFasm.Assemble("mov eax, 0");

Thanks to this great module, it was quite easy to integrate a fast evaluation of a x86 instruction size, although this evaluation is done at the line level, so the evaluation doesn't have any information on labels, defines...etc. But i have integrated a simple (but not perfect) workaround. Also, because this library is using FASM as a compiler, i had to perform some "normalization" on the code (that is mainly targeting MASM syntax), but it's working quite well!


With this instruction size feature, AsmHighlighter is becoming a bit more related to 4k-64k intros coding! ;)

Adding asm x86 Syntax Highlighting to Visual Studio 2008

While i use to develop some part of 4k's intro code in x86 assembler, it is quite annoying to switch from Visual Studio to an external editor in order to have a correct syntax highlighting. I like the principle of an Integrated Development Environment, and VS is a great tool for that. Based on my previous experience on NShader, i have decided to implement a syntax highlighter for x86 ASM... and thanks to NShader's work, it was really easy to code it! For anyone looking for a place to start when developing a LanguageService Package for Visual Studio, this project is easy to follow and gives a basic implementation for syntax highlighting.

So, i have just released AsmHighlighter under codeplex. This is an AddIn for Visual Studio 2008 (it won't work for Express Editions, as they don't allow communities addIns) that enables syntax highlighting for x86 ASM language. MASM syntax is mainly supported and NASM syntax is partially supported. I have no more reason to switch to an external editor! Cool!

Apart from that, the nice thing with MASM is that it is possible to debug directly under Visual Studio, making a mixed C-ASM project much easier to develop (VS is adding building rules for ASM files automatically to your project). On the other hand, i was not able to debug with NASM as nasm cannot generate debug information under the win32 platform...

I also found a cool project called JWasm developed by Japheth : JWasm is a MASM v6 compatible assembler (with v8 bug fixes and improvements)  that is able to output win32,win64 as well as linux elf object files. Quite interesting when you still want to develop with a MASM syntax and be able to export your work under linux without moving to another assembler! Japtheth even provides JWasm.rules files for an integration under Visual Studio. It's even possible to debug JWasm output objects files under VS, that's great!

Now, you may have noticed that all of this is not strictly related to 4k-64k intros coding, but well, you can consider AsmHighlighter as a productivity tool for 4k-64k development! ;)

Coding a 4k or 64K intro needs tools!

What makes a 4k or a 64k so special compares to others demo categories? Specialized tools of course!

There are some obvious general remarks we may list:

• The smaller the intro, the more specialized tools you will need (eg. crinkler, 4klang...). The bigger the demo (>5Mo), the more you will be able to use standardized tools (Zip, Blender, Renoise, Fmod...).
  
• The smaller the intro (<1k), the less specialized tools are released or even developed.
• The smaller the intro, the more graphists are being excluded from demo development compare to musicians that can still work on a music even in a 1k intro (see Untraceable).

Potatro, RayMarching and DistanceFields : a story of SphereTracing

The "Raymarching + Distancefields" is the technique which was most notably used in the majority of 4k intros released in 2009 (and still will have probably a strong influence in 2010). Within Frequency, xt95 introduced this technique thanks to the fantastic work of iq and Systemkit. When wullon asked Frequency to build a little intro to announce the construction of the demoscene.fr web site, xt95 produced a promising first draft of the Potratro from which i could work to improve the overall design, the "isos" forms and the scenes. Yet I had not taken the time to understand the principle of RayMarching + DistanceFields, even if it did not seem to be totally abscond.

Back from the #main 2009, while i looked at the BBS pouet, I came across the following thread: "So, what do remote field equations look like? And how do we solve them?" . Trivial question, but first answers didn't enlighten me about the basic understanding that i had already, but the main principle was still a bit obscure for me. But Ferris then posted a link to an article by John C. Hart, "Sphere tracing: a geometric method for the antialiased ray tracing of implicit surfaces" in 1996 and iq referred to two articles, a first even older John C. Hart, "Ray Tracing Deterministic 3-D Fractals" dating from 1989 and a resumption of the principle in the "Chapter 8. Per-Pixel Displacement Mapping with Distance Functions "of the book GPU from NVidia-Gems2 dating from 2004. Browsing the original article by John C. Hart, everything became clear! This article is an attempt to restore you some of the basic principle of RayMarching + DistanceFields, or more explicitly called Sphere Tracing.

Welcome to Code4k

A blog tentative about coding intros for the demoscene. When ulrick came to me in 2007 and proposed me to come back to the demoscene and join FRequency, I told him "no way, I'm too old for that now!"... :)

After more than 15 years away from the scene, I found this come back to be somewhat difficult... and well, challenging...so I accepted his proposal, apart the fact that it is much more difficult to spent several hours in programming when your family is expecting to go outside for a walk compared to the "easy student life" when I was coding demos on Amiga!

Thanks to xt95, a talented young coder from FRequency, we were able to release quite a few nice prods. I spent mainly my time developing some "backoffice" tools and worked on the coding/design of some of the demos, and spent (and still spending!) a lot of time to understand the new technical jargon, playing a bit with opengl or directx. Well, I have to admit that it's a huge investment to catch up the real-time graphics/sound coding domain, as i used to work for almost 10 years in a domain not really related to it. I just hope to release an intro on my own in 2010!

One thing is that i'm discovering and learning things everyday, and this is very cool. One other thing is that I want to share this with others, and this is the reason why I opened this blog. Hope that I'll be able to keep it updated! ;)

@lx