pouët.net

Forgot the "why" part:
1. Because designing and implementing your own programming language is great fun!
2. Because you can cram more stuff into an intro by using bytecode and a tiny compiler/interpreter.
3. Because using a specialized language makes you much more productive and makes you try out stuff that you otherwise wouldn't bother trying.
4. Because you can give it to others and they go "hey, this is fun" and they'll make a demo with it (well, ideally).

@cupe: I normally go to Revision every year, so I suppose we can meet there!

C, assembly, GLSL.

C because it works everywhere.
Assembly because it's fun and sometimes it's the only way to get what I want, and what's needed.
GLSL instead of HLSL, because GLSL works on a wider range of platforms.

I've been thinking of doing something for 16 bit DOS oldskool PCs using good old Turbo Pascal, for old times' sake and because it's fun.

C# / HLSL for demo stuff. C# in VS with respharper is a real cool combo and DX over OGL because DX diagnosis in most cases tells me exactly what I'm doing wrong all the time ;)
For the functional programming guys here: our actual render core was originally written in F# - was basically working back then. But at least 4 years ago there were some points that made us switching this also to C# in the end.

Started with Turbo Pascal+asm. In retrospective, it was awesome how quick it compiled, and having the built-in help was SO useful.
Nowadays it's mostly only C. I avoid asm because portability and readability is always useful. And I avoid C++ because, like it's been said, you just waste time keeping it clean. I'm realizing I was way more productive in my TP times mostly because I didn't care about doing stuff the clean way (ie. small libs arranged in neat independent subsystems).

And why I'm using the plain old C? mostly because there are TONS of info on the web about it, and because I know it. I hate learning APIs, so by using outdated stuff at least I'm sure it won't keep on changing.

As for 3D, I've got a soft spot for GL, probably for the same reason; you don't have to have a new version every year. But overall I probably spent most time (and did more demos) using my own software renderer.

Started with Amos and BlitzBasic 2 (even did a sloooow texturemapping algorithm), then moved to c/c++ after i got a pc. At that time the DirectX sdk was like 60-80 megabytes (which would download for ages on that dial-up connection) so I decided to start with OpenGL. Now doing the demo stuff in java because at the university all teachers forced it (and making demo-ish things in java seemed challenging too). Probably I will get back to C++ as soon as I finish my studies.

In ye olden times I used to use C++ and assembly with DirectX. Then in my day job I've done a ton of C# and Javascript (and now, after switching jobs, Java and some Scala). Been doing some small democoding recently using C++ again, along with OpenGL (just as an excuse to learn a bit of that) and I'm pleasantly surprised by how nice C++11 is. The syntax and template related shenanigans are still shit of course, but it's pretty decent overall.

The forthcoming .NET ecosystem is looking really nice too, though...

Blueberry: That language looks cool. Reminds me when I was very young playing with LOGO/Turtle draw.

C'ish C++, GLSL... python is my calculator, processing my drawing board.

lately javascript. i guess it's because i feel it's a more user accessible platform somehow despite it's slowness and quirks. And also because i hate dealing with dependency hell issues that the other languages usually entail.

Z80 coding under Atom editor supported by both C#/C++ under Mono/Xamarin Studio. Yep, all on Mac! :)

umm, the language u like? == the scene is dead

C and C++ (and some assembly bits) + some custom-made script language for UIs (tools!) and to glue the native parts together => Inefficient CPU-cycle-wise, efficient human-time-wise.

disclaimer: I did not read the entire thread.

Blala: Looking forward to it :)

Processing for those endless converters, generators and tools, plus for trying ideas out. Cross-compiled C and/or asm for the final version running on some nerve-wracking retro machine. For modernish crossplatform stuff C for portability and speed.

C++ for demos

Because you can create the objects you can work with at a low level with high performance. Like a software rastarizer, raytracer textmode converter, optimized vector math for cpu (inline inline inline)

But I don't use strictly objects. I tend to move towards C with my programming style and I tend to create unmutable objects.

However it's easier to write wrapper code for components/devices in OOP, the syntax makes more sence. Keyboard.ReadKey() or FrameBuffer.BlitTo(backbuffer).

But then I also have demo effects like void Effect0(Canvas *canvas, const float x, const float y, const float time) where using x,y,time parameters an effect gets renderred into the canvas.

Aaand I use

C# for work
Java at school (mostly)
C++ for demos
Javascript when doing any webpage
NASM for 256b demos

and yeah also GLSL/HLSL

change processing with rendermonkey and we're doing exactly the same :D

Blueberry: your language has wait and fork instructions ! I had the same idea for the language I developed to do Shogun Rise of the renegade and they are my favorite features :D

I tend to not try to use Objects in Demos at all, restricting myself to C instead of C++. Ofcourse there are some Effects that are more easily achieved with objects, but they all can be done in pure C aswell!
I am not too sure after reading the thread, but a STRUCT should be a feat of C iirc (no c++ needed) and is enough of an "object" to work with for a demo! If you are new to C(++) you should start with C++ though, as this is only my way of handling it! C++ offers a lot of comfort and this is still just a hobby! Also we dont have to make best use of a CPU since we dont have any fixedPlatforms anymore and GPUs do the most amount of work anyway!
Sorry for optimus-alike-wall-of-text once again, but i didn´t cover the "why"-part in my first post! ;) :p

MsK`: Yes, those are exactly the kind of features which makes you put things into a demo which are very different from what you would have if everything had to be a function of the time.

Long-time D user here, more than content with it. When I was doing demos I found it very fitting, moving around code there and there is faster.

C for tools & prototyping
Assembly for the main stuff (Atari ST)

Code is written in either 6502 or Z80 assembly language depending on target (C64, C128, VIC 20, C16/Plus/4, PET, C64DTV, Atari 8-bit, Amstrad CPC, Atari 8-bit... you get the idea) which is all cross assembled on an old Windows XP box.

Bespoke cross conversion and development tools are built with BlitzMax/MaxGUI and rarely get finished to the point they could be released. =-)

how to compile program with ca65?

No idea to be honest; i throw Xasm at the Atari 8-bit, NESAsm at the NES and ACME at everything else 6502. =-)