Yep, it's MIDI. The synth itself accepts a raw MIDI data stream, and so I wrapped it into a VSTi plugin for using it with whatever sequencing software I wanted to, which is Logic (this great but discontinued program, f**kingz to Apple;). To play back the file inside the demo, I use a heavily encoded midi file format which is optimized for maximum compression ratio and is including the required sound banks.
If you want to know more, have a look at the articles section of my home page, where I've written a bit about the inner workings.
.. and you'll find some demos. MacOS isn't too well liked in the demoscene yet, tho this seems to change - we had a Mac Demo competition at this year's Breakpoint party with a stunning three entries (which is three more than at all other parties I've ever been to):)
Our demos and tools (and I think I can speak for the majority of the scene here) are mostly written in C++ (with simple, lean OOP mixed with imperative style whenever objects don't make sense) plus a few time-critical routines in assembler (most notably our software synthesizer and parts of the texture generator).
Doing everything in Assembly is overkill most of the time, demos nowadays are pretty much GPU limited, the only exceptions are the things mentioned above.
nope, apart from the softsynth and a few inner loops of the texture generator it's all C++.. without exception/RTTI bloat tho and only a few templates when it was really the best solution;)
The trick is not to include tons of megabytes of external libs when you can eg. load a JPG file with two WinAPI calls instead of using libjpg. The only libraries used are for deconding the sound files, and that's libvorbis, mimifmod and my softsynth/midiplayer, the latter two optimized for size like hell.
Of course we could, but there are SO many more important things for us to do;)
Honestly, OSS also exists under Windows, and since MS are giving out their compiler suite for free (as in beer) everyone can get the project and even work at it. So you want an OpenGL version? It's up to you then. Apart from the pixel shader stuff that should be quite easy to do actually.
That's actually the best thing that can happen to a GeForceFX 5200. If you buy your next card, try to go for something that's NOT slower than a 4 years old GeForce2:)
The scene itself isn't really interested in making stuff with the.werkkzeug, most comments we got so far were more like "Thanks for releasing, I'll have a look at it, let's see what I can learn from it for doing my own stuff".
There have always been the '1337 selfmade and the l4me demomaker demos, so I don't think we endanger the scene at all. But perhaps some "outsiders" fiddle around with the tool and get interested, that'd be a cool goal;)
I used to think that too... technology keeps rushing by, and you slowly lose your contact. Some people then give up and start whining how much the past was better, and other people don't. And catch up.
Just for the record, the sound system used in the Farbrausch 64k demos is done in 95% hand-optimized assembler, is only 4.5K in size in its newest incarnation and needs less than 10% CPU on a recent PC for synthesizing a complete song in realtime.
No, it's not. Demopaja is "only" (not to say anything against it, it's one of the coolest tools even for producing videos;) a timeline editor for external plugin DLLs, so to say a tool that demosceners can use to concentrate on coding their own effects while leaving the dirty direction work to the artists..werkkzeug on the other hand is a complete, closed content development system which does not support linking your own code (because we never needed that, Chaos always implemented what the others wanted) but includes everything from texture generation, mesh generation/editing, timeline editing, post-processing effects and a few other things.
So you can't even compare both tools, as they've got radically different uses within the same context.
Oh, and in fact the only thing that we claim that hasn't done before is the completely nondestructive modular texture and model editing. We know we haven't invented texture generation itself or demomakers, don't worry. Damn, I used those tools back on the C64 when I was 14, so...;)
Even DOOM 1 had surround sound. Had to find that out when we were playing deathmatch, I had my Dolby surround system with me and suddenly a chainsaw went on directly behind me. Talk about being scared;)
The intro is supposed to be grey, for some unknown reason somebody here considered a postproc effect which uses the alpha blend unit to square (and thus solarize+half) the dest color good-looking;)
As I'm one of the guys responsible for this game, let me explain a few things.
First, to all the people saying this is senseless etc.: Please watch every second story posted on/. - most of them are about people doing something nobody in their right mind would ever try. So come on;)
Then, a few clarifications:
Yes, we are the same guys who are responsible for FR-08:.the.product and all the follow-ups (which you can find at our home page, http://www.farb-rausch.de).
We don't use any hidden texture/sound or game generators in Windows..kkrieger requires DirectX 9, but only to gain access to the graphics and sound hardware. OpenGL and whatever audio API would also work, we just chose to use DirectX. Maybe we will even release a Linux version in the future (which should be about the same size using X and ALSA), but as all this is done in our spare time and none of us has a linux desktop PC, it's rather improbable. So, the only thing where we "cheated" and used ressources from Windows are the Arial and Times New Roman fonts which we use as base material for our fonts (heavily processed tho). This and all Windows DLLs that are essential for running. We don't even use any external libc.
All content, that is: the textures, the models, the map and part of the animations is generated procedurally. The basic concept is a modular graphics synthesizer which only stores the steps needed to opbain a certain image or mesh with their parameters. On www.theproduct.de you'll find a short explanation..kkrieger uses the very same concepts, only in a really evolved and refined way.
Also the sound is created procedurally by a virtual-analog software synthesizer processing heavily compressed MIDI data. It runs in real-time (for the music) as well as as pre-processing step (for the sound effects). Actual sound output is done via simplest DirectSound programming.
The graphics engine is made for Doom3-style graphics, that means full Phong lighting model with various light sources and normal mapping everywhere, and of course stencil based shadows. It requires a PS1.3 level graphics card such as a GeForce4Ti or a Radeon8500 or better, though it's only fun on at least a Radeon 9600 or a GeforceFX 5700, we know.
We also know about the insane hardware and memory requirements and all the bugs as well as the mostly missing gameplay, but we worked on it (partly) for about two years and we definitely wanted to get it out at the Breakpoint party on Easter. This meant lots of things we had to cut, this meant lots of thigs we didn't test, and we know this beta is far from perfect. But expect a final version in a few months (we'll definitely take some rest now) which will be about 128k and not only feature less bugs, hangs and fsckups but only vastly more content and hopefully an improved engine capable of real vs/ps2.0 support for more speed and quality. Oh, and gameplay. And monsters that actually DIE instead of just being turned off:)
Hope that clears up a few things...
Tammo "kb" Hinrichs
Farbrausch Consumer Consulting
freelance audio programming guy for.kkrieger
shocked that our server is still alive.
I won't allow myself the time to dismiss your "arguments" on a detailed level, but:
* Why is the game SO dependent on the graphics card then? * Why do you talk about missing lighting effects when there's a full phong lighting model with several light sources and stencil shadows everywhere? * Why do you think you know ANYTHING of the used algorithms? Did you already reverse engineer the whole game? * Timer interrupts? ON WINDOWS? Come on.
Please. "I have no idea how this all works, but I hate them" would really have been less hassle to type
kb / farbrausch.kkrieger audio programmer
game programmer at Inverse Entertainment,.de
Maybe somebody should point out that is not the first time somebody has done such a thing... back in 1998 there was a quite similar event at the University of Paderborn where 512 normal home PCs brought by people were connected for one night (the event was even broadcasted live on German TV). I have to admit that the "flash mob" element here is more predominant (back then people knew about this two weeks in advance), but it's definitely not the first attempt to create a spontaneous supercomputer with home machines. The cluster even made it into the Top250 IIRC.:)
Sorry, but I don't see any evil motives or anything here. Preventing cheating in multiplayer games (and this is what the patents are about) is a damn good thing, and the patents actually talk about encrypted network communication and SystemID/key pairs which are stored on their central servers for authentication. Together with their EXE signatures this is a quite good protection as it prevents messing around with the game code. Of course you can build your own custom hardware to patch the game in memory after is has started, but what the heck. At least average Joe Schmo can't simply download a cheat off the net, and that should do for the most part.
So to make this clear again: These patents are solely about "illegal" (as in patched exectuable, spoofing another player's identity etc) cheating in Xbox Live games. Their method in their given context IS new and needs hardware support, so the patents are not that ridiculous (only a little:). Oh, and for the people whining that big bad evil M$ is locking your poor new wannabe Linux boxes for their evil purposes: This is what console manufactures are doing for 20 years now. All 32bit consoles need to be modded to run Linux or your own exes (except PS2 linux of course, but let's talk about a non-crippled use here), so what's the friggin' difference.
The SID isn't in the FPGAs. It's quite impossible to do so because the SID consists of a mixture of analog and digital circuitry and can't be built from logic circuits alone. If you look closely at the C-One's mainboard, you can see two empty sockets which are for two original SIDs.
Though I really hope that one day someone is nuts enough to produce a SID compatible synth chip, the chip was awesome for its time and still has a distinguished sound that can't be really emulated with curent anlog or virtual synths. And maybe with a new, cheap SID chip the SIDstation wouldn't be so terribly expensive...;)
I didn't read the article, but looked at the paper..
This technique claims to reinvent neither voxels nor point sprites, but it's rather a way to convert voxel datasets (like CT scans) into a threedimensional stipple representation. Imagine a particle system with the particle density at a given place about proportional to the density value in the voxel data at that place.
Ok, it's not that easy, there are a few algorithms described which allow for more "intelligent" placement of particles to enhance features and the general transparency, which makes up the main part of the paper.
The trick is then that these particles can be sent to a modern graphics card (GF3 and up) for immediate and fast display. You can zoom and rotate the model and your camera without having to recalculate anything, which makes rendering really fast.
A few future thoughts in the paper are about using vertex shader programs to shift some of the per-particle calculations to the GPU which would anhance rendering speed and clarity further, as now angle-dependent particle calculations would be possible without any significant overhead.
I didn't find any real thoughts on decreasing the complexity of the precalculation process tho. Still, having to calculate the major part only once per dataset instead of once per frame is a significant improvement over similar methods (such as most triangulation methods which require a complete re-calc as soon as you try to look at other features of the dataset).
And the comparison with Id? Come on, this doesn't have ANY relationship with 3d games, and furthermore Carmack is a good engineer who knows to deploy new rendering techniques at exactly the time PCs are good anough for them, but all of his techniques since Wolf3d were invented years ago by the very bunch of PhDs etc who also wrote this paper:)
For demos of course... hmmm... this could actually make metablobs look good;)
... trust the programmers when it comes to testing. You may find some obvious buigs in your own code, but when it comes to runtime testing most programmers tend to emphasize on "correct" user behaviour or maybe the few wrong input sets they've taken care of and completely neglect the pervert fantasy of lusers *g*
Dedicated testers OTOH are perfect in letting a program die in the most obscure ways. Did you know that you can crash a Commodore 64's BASIC interpreter by just typing PRINT 5+"A"+-5 ?;)
They say something about "Product Activation" on their web site. I won't buy a single can if this means they can track all my eating behaviours and drag me into jail for w4z3z3d f00d5.
The current MySQL AB/Nusphere legal issue isnt the first court case on the GPL because nobody has tried to violate the GPL before. It's because everyone else has realized they dont have a chance in court, and have given up rather than trying to persue a case which their lawyers have eventually realized they will lose.
Yeah, sure. The few thousand non-GPLed programs using parts of GPLed source codes in a way that nobody notices it surely don't count:)
- The Fourier theorem says (and imho proves) that every periodic signal consists of an arbitrary or even infinite number of sine waves. So a square wave actually IS a composition of the base tone and all odd harmonics.
- Typically, when humans grow older, the upper end of their listening range goes from about 20KHz to 12KHz at worst. I know enough 20-year-olds which aren't able to hear a PAL TV's beeping (at 15625Hz) anymore.
- Harmonics aren't sine waves BELOW the base tone, but actually ABOVE them, at 2x, 3x, 4x etc the frequency.
- The nyquist theorem is correct in a certain way, but it's neglecting the fact that from frequencies at samplerate/10 up, there is enough aliasing to severely disturb the signal. Go try sample a 22051Hz sine wave with 44100Hz.
- What's that complete nonsense with 32bit/sec? A CD player reads at 176400bytes/sec (2x44100x16bit). With 16bit resolution, the quantisation error and thus the SNR is at about -96dB. Go look up what "dB" means next time, please.
- it's interesting that you first claim everybody knows what "digital" means and then compare digital signal transmission with your oh-so-cool car stereo. Digital audio signals are transmitted with about 2-3 MBit and can even pass some 10 metres of simple cinch audio cable without any loss. Flipped bits are very improbable and timing jitters are completely neglectable, as they get flattened out by the receiver's internal clock (if the equipment is good, that is). The only situation in which jitters are important is mixing of arbitrary digital audio signals which all have their own clock source - and normally, this does not happen outside studios.
So, better do some research next time or ask the people you refer to all the time before throwing around words and expressions you obviously do not understand.
Slashdot Mirror
DirectX ... ROYALTIES?
What exactly did I miss here?
kb
game developer
who never had to pay anything to MS so far for using Direct3D
Yep, it's MIDI. The synth itself accepts a raw MIDI data stream, and so I wrapped it into a VSTi plugin for using it with whatever sequencing software I wanted to, which is Logic (this great but discontinued program, f**kingz to Apple ;). To play back the file inside the demo, I use a heavily encoded midi file format which is optimized for maximum compression ratio and is including the required sound banks.
If you want to know more, have a look at the articles section of my home page, where I've written a bit about the inner workings.
kb^fr
Our (Farbrausch) demos are all Windows+DirectX, but there are a few other ones for the Mac. Just have a look at
.. and you'll find some demos. MacOS isn't too well liked in the demoscene yet, tho this seems to change - we had a Mac Demo competition at this year's Breakpoint party with a stunning three entries (which is three more than at all other parties I've ever been to) :)
http://mac.scene.org/
kb^fr
Our demos and tools (and I think I can speak for the majority of the scene here) are mostly written in C++ (with simple, lean OOP mixed with imperative style whenever objects don't make sense) plus a few time-critical routines in assembler (most notably our software synthesizer and parts of the texture generator).
Doing everything in Assembly is overkill most of the time, demos nowadays are pretty much GPU limited, the only exceptions are the things mentioned above.
kb^fr
nope, apart from the softsynth and a few inner loops of the texture generator it's all C++.. without exception/RTTI bloat tho and only a few templates when it was really the best solution ;)
The trick is not to include tons of megabytes of external libs when you can eg. load a JPG file with two WinAPI calls instead of using libjpg. The only libraries used are for deconding the sound files, and that's libvorbis, mimifmod and my softsynth/midiplayer, the latter two optimized for size like hell.
kb^fr
Of course we could, but there are SO many more important things for us to do ;)
Honestly, OSS also exists under Windows, and since MS are giving out their compiler suite for free (as in beer) everyone can get the project and even work at it. So you want an OpenGL version? It's up to you then. Apart from the pixel shader stuff that should be quite easy to do actually.
kb^farbrausch
> Destroyed the GeForce 5200's in the lab...
:)
That's actually the best thing that can happen to a GeForceFX 5200. If you buy your next card, try to go for something that's NOT slower than a 4 years old GeForce2
The scene itself isn't really interested in making stuff with the .werkkzeug, most comments we got so far were more like "Thanks for releasing, I'll have a look at it, let's see what I can learn from it for doing my own stuff".
;)
There have always been the '1337 selfmade and the l4me demomaker demos, so I don't think we endanger the scene at all. But perhaps some "outsiders" fiddle around with the tool and get interested, that'd be a cool goal
kb^fr
ROTFL.
I used to think that too... technology keeps rushing by, and you slowly lose your contact. Some people then give up and start whining how much the past was better, and other people don't. And catch up.
Just for the record, the sound system used in the Farbrausch 64k demos is done in 95% hand-optimized assembler, is only 4.5K in size in its newest incarnation and needs less than 10% CPU on a recent PC for synthesizing a complete song in realtime.
And honestly, that FELT right when I did it.
kb^fr
No, it's not. Demopaja is "only" (not to say anything against it, it's one of the coolest tools even for producing videos ;) a timeline editor for external plugin DLLs, so to say a tool that demosceners can use to concentrate on coding their own effects while leaving the dirty direction work to the artists. .werkkzeug on the other hand is a complete, closed content development system which does not support linking your own code (because we never needed that, Chaos always implemented what the others wanted) but includes everything from texture generation, mesh generation/editing, timeline editing, post-processing effects and a few other things.
;)
So you can't even compare both tools, as they've got radically different uses within the same context.
Oh, and in fact the only thing that we claim that hasn't done before is the completely nondestructive modular texture and model editing. We know we haven't invented texture generation itself or demomakers, don't worry. Damn, I used those tools back on the C64 when I was 14, so...
kb / farbrausch
Even DOOM 1 had surround sound. Had to find that out when we were playing deathmatch, I had my Dolby surround system with me and suddenly a chainsaw went on directly behind me. Talk about being scared ;)
The intro is supposed to be grey, for some unknown reason somebody here considered a postproc effect which uses the alpha blend unit to square (and thus solarize+half) the dest color good-looking ;)
;)
For the rest, well, a final will come
As I'm one of the guys responsible for this game, let me explain a few things.
First, to all the people saying this is senseless etc.: Please watch every second story posted on
Then, a few clarifications:
Hope that clears up a few things...
Tammo "kb" Hinrichs
Farbrausch Consumer Consulting
freelance audio programming guy for
shocked that our server is still alive.
Raytracing? What exactly have you smoked?
.kkrieger audio programmer .de
I won't allow myself the time to dismiss your "arguments" on a detailed level, but:
* Why is the game SO dependent on the graphics card then?
* Why do you talk about missing lighting effects when there's a full phong lighting model with several light sources and stencil shadows everywhere?
* Why do you think you know ANYTHING of the used algorithms? Did you already reverse engineer the whole game?
* Timer interrupts? ON WINDOWS? Come on.
Please. "I have no idea how this all works, but I hate them" would really have been less hassle to type
kb / farbrausch
game programmer at Inverse Entertainment,
Well then, someone send over a dev kit, I've got the source code lying around somewhere, bring it on!
(To Valve: That was a lie. I don't. Spend your money finishing that darn game instead of wasting your money suing me. Thanks.)
If "non-destructive" excludes the buggy 2.0.36 Adaptec SCSI drivers which fried a handful of AHA2940 controllers... yep :)
Maybe somebody should point out that is not the first time somebody has done such a thing... back in 1998 there was a quite similar event at the University of Paderborn where 512 normal home PCs brought by people were connected for one night (the event was even broadcasted live on German TV). I have to admit that the "flash mob" element here is more predominant (back then people knew about this two weeks in advance), but it's definitely not the first attempt to create a spontaneous supercomputer with home machines. The cluster even made it into the Top250 IIRC. :)
More info...
Sorry, but I don't see any evil motives or anything here. Preventing cheating in multiplayer games (and this is what the patents are about) is a damn good thing, and the patents actually talk about encrypted network communication and SystemID/key pairs which are stored on their central servers for authentication. Together with their EXE signatures this is a quite good protection as it prevents messing around with the game code. Of course you can build your own custom hardware to patch the game in memory after is has started, but what the heck. At least average Joe Schmo can't simply download a cheat off the net, and that should do for the most part.
So to make this clear again: These patents are solely about "illegal" (as in patched exectuable, spoofing another player's identity etc) cheating in Xbox Live games. Their method in their given context IS new and needs hardware support, so the patents are not that ridiculous (only a little
The SID isn't in the FPGAs. It's quite impossible to do so because the SID consists of a mixture of analog and digital circuitry and can't be built from logic circuits alone. If you look closely at the C-One's mainboard, you can see two empty sockets which are for two original SIDs.
;)
Though I really hope that one day someone is nuts enough to produce a SID compatible synth chip, the chip was awesome for its time and still has a distinguished sound that can't be really emulated with curent anlog or virtual synths. And maybe with a new, cheap SID chip the SIDstation wouldn't be so terribly expensive...
I didn't read the article, but looked at the paper..
:)
;)
This technique claims to reinvent neither voxels nor point sprites, but it's rather a way to convert voxel datasets (like CT scans) into a threedimensional stipple representation. Imagine a particle system with the particle density at a given place about proportional to the density value in the voxel data at that place.
Ok, it's not that easy, there are a few algorithms described which allow for more "intelligent" placement of particles to enhance features and the general transparency, which makes up the main part of the paper.
The trick is then that these particles can be sent to a modern graphics card (GF3 and up) for immediate and fast display. You can zoom and rotate the model and your camera without having to recalculate anything, which makes rendering really fast.
A few future thoughts in the paper are about using vertex shader programs to shift some of the per-particle calculations to the GPU which would anhance rendering speed and clarity further, as now angle-dependent particle calculations would be possible without any significant overhead.
I didn't find any real thoughts on decreasing the complexity of the precalculation process tho. Still, having to calculate the major part only once per dataset instead of once per frame is a significant improvement over similar methods (such as most triangulation methods which require a complete re-calc as soon as you try to look at other features of the dataset).
And the comparison with Id? Come on, this doesn't have ANY relationship with 3d games, and furthermore Carmack is a good engineer who knows to deploy new rendering techniques at exactly the time PCs are good anough for them, but all of his techniques since Wolf3d were invented years ago by the very bunch of PhDs etc who also wrote this paper
For demos of course... hmmm... this could actually make metablobs look good
... trust the programmers when it comes to testing. You may find some obvious buigs in your own code, but when it comes to runtime testing most programmers tend to emphasize on "correct" user behaviour or maybe the few wrong input sets they've taken care of and completely neglect the pervert fantasy of lusers *g*
;)
Dedicated testers OTOH are perfect in letting a program die in the most obscure ways. Did you know that you can crash a Commodore 64's BASIC interpreter by just typing PRINT 5+"A"+-5 ?
They say something about "Product Activation" on their web site. I won't buy a single can if this means they can track all my eating behaviours and drag me into jail for w4z3z3d f00d5.
kb
Sorry, but this whole post is like complete BS.
- The Fourier theorem says (and imho proves) that every periodic signal consists of an arbitrary or even infinite number of sine waves. So a square wave actually IS a composition of the base tone and all odd harmonics.
- Typically, when humans grow older, the upper end of their listening range goes from about 20KHz to 12KHz at worst. I know enough 20-year-olds which aren't able to hear a PAL TV's beeping (at 15625Hz) anymore.
- Harmonics aren't sine waves BELOW the base tone, but actually ABOVE them, at 2x, 3x, 4x etc the frequency.
- The nyquist theorem is correct in a certain way, but it's neglecting the fact that from frequencies at samplerate/10 up, there is enough aliasing to severely disturb the signal. Go try sample a 22051Hz sine wave with 44100Hz.
- What's that complete nonsense with 32bit/sec? A CD player reads at 176400bytes/sec (2x44100x16bit). With 16bit resolution, the quantisation error and thus the SNR is at about -96dB. Go look up what "dB" means next time, please.
- it's interesting that you first claim everybody knows what "digital" means and then compare digital signal transmission with your oh-so-cool car stereo. Digital audio signals are transmitted with about 2-3 MBit and can even pass some 10 metres of simple cinch audio cable without any loss. Flipped bits are very improbable and timing jitters are completely neglectable, as they get flattened out by the receiver's internal clock (if the equipment is good, that is). The only situation in which jitters are important is mixing of arbitrary digital audio signals which all have their own clock source - and normally, this does not happen outside studios.
So, better do some research next time or ask the people you refer to all the time before throwing around words and expressions you obviously do not understand.
Thanks,
kb