c0deff - canvas Oldskool Demo Effects Framework (Forked)

What the fork?

This library is a partial remake of NoNameNo's CODEF, made by lowpolybrain

• Please, check out the original CODEF license.
• Original thing's homepage
• CODEF demo gallery
• Mellow Man's collection of CODEF screens

Is it worth it?

Again, this library is a set of routines to create demoscene-looking oldschool effects in JS.

Should you rely on c0deff while making a game or something? Nah, it is just a set of demo routines, really. Use something game-dedicated like phaser or pixi

Should you prefer this to original codef? Yea, probably, as it has more features, a bit better code and will be maintained some day.

Why?

Main reason of me doing this is that I do want to use CODEF. It is pretty amazing how much stuff you can do with so few code with original CODEF. This fork exists to write even less code and do even more.

What's different from the original?

The parts of framework are now modules (and they support webpack, too). Everything is now inside a single global cdf variable. There is a couple of new things (see below) and a bit improved API (also, if you prefer the original codef way to do things - there's a legacy wrapper and it all is still pretty much possible)

So, there are some (and will be more) new features, options and possibilities. The incomplete list of them:

• Core now has init and animate methods to bootstrap common tasks: initialization on dom ready and animating stuff.
• Images now have onload property (and ImageLoader module, that will help preload assets first)
• New core methods - ellipse, ngon, text, poly and polyline
• There is some sort of masks support now
• Some old methods support additional arguments.
• Youtube module allows playing youtube music (requires internet, of course)
• Vectortext. Not sure it should be a part of c0deff, maybe will be removed or something in future.
• Pixel module for drawing bresenham lines and pixels.

In original CODEF, couple libraries it depends on are copy-pasted in. I believe that third-party libraries should be separate, so in c0deff they are external depenencies (still supplied in lib/thirdparty folder, don't worry ;-):

• 3D functionality of the original CODEF uses Three.js (and has it copy-pasted right in).
• Music module is now only YM playback written by Antoine Santo, the author of the original CODEF. Everything else now requires flod. I think, you can even build flod with, say, only MOD playback. You can find complete flod in lib/thirdparty folder, too.

Example of the difference between CODEF and c0deff

The old way to do things:

document.addEventListener('DOMContentLoaded', function(){
	  var mycanvas = new canvas(640,480,"main");  				
	  function go(){
	  	mycanvas.fill('#fff');
		  mycanvas.contex.fillText("Hello World!",mycanvas.width/2,mycanvas.height/2);
		  requestAnimFrame( go );
	  }
	  go();
	})

..and now - the way the same is done in c0deff:

cdf.init(function($, animate){
  var mycanvas = new $.Canvas(640,480,'main');
	animate(function(){
	  mycanvas .fill('#fff') .text('Hello, world', mycanvas.cx, mycanvas.cy, '#000')
	});
});

Pretty similar, but handier, huh? The old way is possible too, of course!

Legacy

The library provides a legacy wrapper, that mimics everything the original can do, that allows using old codebase pretty seamlessly. Just load the codeff and include the legacy.js script, that will export everything back into window context.

If having to write CODEF (or $ or whatever) in front of everything - you can use the with construct. It is considered bad for your code, but so is using common names in global scope...

Yet still, for new things I'd retain from using legacy. It exists only to make hundreds of demos already esisting work with c0deff.

Building

There's a lib/all.min.js, that contains all the modules as a single file. In order to build your own lib/all.min.js you have to first run npm install to install webpack, and then run npm run all to compile everything. The all.min.js also exposes the global cdf variable, but that variable has isComplete and buildDate variables, that indicate the information about this build.

The reason the code is shaped just like that is that I want to be able to edit and use the lib without compiling it, but also want to have the ability to somehow "optimize" everything by including only the stuff I need.

Future plans

This is only the very beginning. More to come in future... I am planning to re-write some parts of the original I personally do not like and improve some stuff.

• canvas renderer is now removed from Three.JS, as well as some other things. Rewrite the 3d module to support modern three.js (webgl renderer and some geometry things removed in newer versions), and make it still compatible with modern Three.JS canvas renderer, too.
• own simple 3d engine, because for some things there's no need to add a "heavy" Three.JS
• Probably add webaudio api support to YM playback and flod (I doubt I will be able to handle that, because that would mean I would need to rewrite a lot of stuff, I guess, but the time will show)
• Document the entire thing, also port some WAB demos or maybe create own ones (that's the goal after all) to make sure the library is easy to use, and also modify some demos to use legacy wrapper (to make sure it works fine.)
• Some sort of asset management (there is now, but only for images). Turns out this is vital.

... the plans are to add some new modules et cetera, making the great tool even better.