pouët.net

I've had background in Java programming in the past when I was in school, though most of which I've already forgotten as I primarily work on Web development involving mostly html, css, javascript these days. Nonetheless, the concept and logic of programming isn't completely foreign to me.

I know there's webgl + javascript for the web, and I do plan on playing around with that as well in the future. However, I'm at a time in my life where I am considering of trying something entirely different; and as a creative person who has always been fascinated by music video, cinematography, 3d animation, and storytelling. I figured it's about time I give demoscene a shot :)

As I've stated, I'm a blank canvas when it comes to the C family of programming languages. And from what I've seen and researched, the C family programming languages seems to be the ones most used in modern graphics programing and game development right?

I know some people make their demo in C, some in C++, while others uses both, but if you were to recommend one to someone new to the C family of programming languages and new to demo scene, which would you recommend and why? What are the benefits, disadvantages of each, which is easier, messier between C, C++, C#...... or perhaps other languages that I have missed to mentioned.

Another point that seems to come up is that as a beginner I should first figure out what platform and 3d libraries I want to work on.


opengl for crossplatform
or
directX for windows/xbox

I've read up on both opengl and directx a bit, and from an outsider's perspective, the obvious choice would certainly be opengl for most people since it's crossplatform, and some have even mentioned that because it's easier to learn at the start. But without having too much knowledge in graphics programming, or hands on experience with these two libraries, the distinctions between these two that I can make out are rather superficial. :(
Perhaps someone share his/her experience? :D


Lastly, when it comes to learning path:
Do I just start out by learning C or C++, and immediately start learning OpenGL or DirectX?
But aren't those just graphics libraries? I'd imagine they are simply the place in which you pull functions from?

So, after I've learned C or C++, what should I read or study to acquire the knowledge in graphics programming in general? or does opengl/directx teach you all that?

The easiest path to learn graphics programming is to start high-level and slowly go to the bottom.

You could start getting familiar with shader coding at shadertoy.

You could start creating content with demo tools like tooll.io or werkkzeug.

Being familiar with Java, you could take a peek at the C# programming language, that shouldn't be too different to what you're used to.

Before doing serious graphics programming, read up and become familiar with the GPU Pipeline.

Either with Java (not sure how exactly) or C# (using OpenTK), you have the possibility to use OpenGL.

For using DirectX, there's SharpDX for C#.

Once you feel comfortable, you could start learning C or C++. This is just a question of preference. C is more suited for sizecoding, since in small intros you don't want the overhead of all the features in C++ (stl, exceptions, vtables, ...). For full scaled demos, I wouldn't do them natively, I'd use C#. But if I had a choice, then I'd use C++.

Oh and finally, if you plan on doing serious sizecoding, you should learn x86 asm ;)

i wouldn't say i'm familiar with java lol that was ages ago ^^
I actually only mentioned it to demonstrate that I have at least some experience with programming. hehe

Gotta second all of what xTr1m said.
As C# is close to Java in its syntax you shouldn´t have a hard time learning it.
Once you are comfortable with it the switch to C++ is just learning how to do the same things in a different syntax again. Especially as both are object-oriented coding-languages.
C# is maybe better readable, but also slower in most cases (coding visuals that is!), that´s why most coders still prefer using C++ for demos aswell as games.
For most Demo-Effects you won´t need any object-oriented code at all, so you could go the C-route, but the complete C-subset is included in C++ anyway, so no need to restrict yourself if you aren´t planning to do demos with limited size <64kilobytes.

I used DirectX for the last 9 years but will switch to OpenGL now that i finally realized it´ll suit me better in the end! So generally it´s just a matter of taste...if you had a look into both already, you know both are able to do the same stuff anyway.
OpenGL being cross-platform is such a big plus on its side...i always have recommended it to others.

So your plan could be to learn c# and openGL, do a demo or two with it (don´t forget to release them! ;) you´ll get feedback this way and this will help you doing better and better demos eventually.), then switch to C++ and go on from there. Believe me, in no time you´ll have the fun of your life!

Speaking of Fun: you really should consider to release your stuff at Demoparties, which in addition you should also visit, so you can watch your own work on a BigScreen with a good Sound-System! :) Additionally you´ll get direct feedback from other sceners, the possibility to talk to other demomakers about demomaking...all in all you´ll learn a lot if you want to!
There are demoparties around the globe every year, i´ll add a link under this post where you can have a look which demoparties are close to where you reside so you can pick one once you decided you want to release your demo at a demoparty. :)

Ofcourse you may release your demos whenever you want, only thing you need to do is uploading it here on this very website. (if your chosen party is months away or sth...waiting for feedback for that long won´t help at all i guess! Some demoparties allow remote-entries, you can upload your demo to them without attending the party, you wont get any prizes though. If you are lucky there´ll be a livestream of the demo-competition, so you could even watch it when shown!)

Hope you will have as much fun doing demos as we have ...maybe we have fun together at a demoparty soon! ;)

xtr1m suggested shadertoy, but isn't that just a place for people to to show what they're currently playing around with in terms of shaders/3d effects, etc.

As for tooll.io or werkkzeug, and also shadertoy, wouldn't I have to already know how to do graphics programming in order to actually use them? :D

I haven't actually used java in more than a decade lol. i've only taken a class on it so my knowledge and familiarity is very rudimentry and vauge to say the least. lol

I'll try to find a good book on C++ and learn the basics then. Anyone know a exceptionally good book for C++ they would recommend? if not, i'm sure i can find something decent as well. By the way, if i learn C++, is there no need to learn C afterwards then? it'll just be basically knowing when and when not to use the extra features from C++ and thinking about bloat and efficiency while coding? :)

But aside from the language used for coding, and the library of your choice.
C++ -> openGL

Are there any intermediate skills I need to pick up or learned along the way from C++ to OpenGL? What confuses me are books with titles such as graphics programming, shaders programming, 3d programming, game programming... do i need to familiar myself with these after C++ and before OpenGL? or just go straight to openGL ? will everything become sort of intuitive once i read up on opengl?
========================================

I've recently switched from Windows to Arch Linux (i still have windows 7 as a dual boot)

If i wanna go the crossplatform opengl route, making demos with linux is no problem at all right? i'll be able to make demos that will be crossplatform compatible for all o.s? can i make windows specific demo on windows too ?

and is there a difference between the opengl found on linux compared to windows?

in archlinux i have the proprietary nvidia driver:
https://www.archlinux.org/packages/extra/x86_64/nvidia/

and the nvidia-libgl
https://www.archlinux.org/packages/extra/i686/nvidia-libgl/

and generally write my codes with Vim

Is this totally fine? or should i just go back to windows entirely and use the visual studio too.

contrary to what others said, i would start the other way around: learn some C/C++ and then get started with some very basic openGL 1.x - get familiar with the vector/matrix maths and fundamental 3d concepts: vertices/meshes, transformation, lighting. once you have understood those you have all required knowledge to do the more advanced stuff like shaders and modern rendering pipelines.
understanding the basic concepts is of prime importance. and you can still do very cool stuff with opengl 1.x or dx9. just be awesome like Kewlers :)

I'm with the first 2 guys!

Don't reinvent the wheel, writing a math lib, file io, toolsets just take up time you could've used making demos

get a demotool, usually you can animate some basic primitives in them and then you just learn enough code or about the demotool to make an effect out of that.

get something on the screen and start playing around with visuals! you don't need to know what you're doing, that comes with time

only if you are a backend guy that loves to write all the lowlevel stuff by himself should you do it, making demos must be fun, doing the things you like as much as possible!

here be dragons: if you want to go beyond a certain basic level of coding you need to be knowing what you do. trial & error and copy & paste will only get you so far.
and if you are in the game to do new effects stuff and not "yet-another-raymarching-landscape" you have no choice other than learn your stuff (over time, and it takes a lot of time)

First: please ignore everything that spike said and especially DO NOT LOOK AT OPENGL 1.x. or even 2.x or 3.x. Absolutely go 4.x straight from the start. Reason: The old stuff is more complicated in the sense that it's a collection of a shitload of special cases (many of which are now irrelevant), while the new stuff is a set of versatile building blocks. You'll have to go there anyway if you want to have any fun, you might as well skip the crud and be glad you didn't enter the game 10 years ago when everything was shit.

What helped me get into realtime graphics is the book Real Time Rendering, 3rd edition: It's easy to read, has almost no prerequisites, covers the "why" instead of only the "how" and provides the big picture in an intuitive and fun way. It stops going into the details just before differences between opengl and directx would appear, so after reading it you can just go "alright, I want to render a fullscreen quad with a shader into a texture, now just google how to do that in opengl (or directx)". You'll get a framework to hold all the other pieces of information that you find on the net and things stop being a messy jungle filled with incredibly complex and intimidating things. And even if you don't end up doing computer graphics after all, it is still a fun read. Can't recommend it enough. After reading that book, you can do things like read the "Trip through the GPU pipeline" that xtr1m mentioned, but I'd really really recommend to cover the "why" first. If you end up using opengl, I highly recommend the code samples from the book "Opengl Superbible", never seen any better. And don't go the webgl path (unless you already know you don't want to go far), that one is a dead end.

Concerning programming languages: Virtually all examples and documentation is in C (so they work in C++ as well, which is basically a superset of C). That is an incredibly big bonus for C/C++ and will save you a lot of frustration. I consider C++ a shit language (and C useless because it doesn't have any features), but still code demos ~20 hours a week with that language. Reasons: 1. Visual Studio on Windows is the only IDE I've seen that works well. I have used vim and emacs and gdb and all that in my 10-year linux phase, but by now I'm so happy I can just set a breakpoint by clicking, hover over a variable name and see the current value, and countless other things. Also there are extensions for everything you could wish for. You can't get serious work done with vim/gcc/gdb in my opinion. 2. Modern C++ (starting with the one you get with Visual Studio 2013, preferably 2015) is way less shit. I wouldn't be able to stand it without the new stuff. Unfortunately I don't know any books, but when I was first learning C++, I found the C++ Frequently Questioned Answers very helpful (link goes to the "big picture" section of it), because it felt like someone would understand my rage and confusion instead of talking down to me in a "you'll understand it once you're old enough" way that many other sources do. But really, take the most modern C++ you can get. I've been looking at C# as well, but it's not suited to sizecoding, which is what I do, so unfortunately it's out. Otherwise I'd take C# over both C++ and Java any time.

Also, what hardy said about demoparties. That is what it's all about.

(only ignore everything that spike said in their first post, I completely agree with the second post)

please ignore everything that cupe said. the new stuff is a shitload of complex stuff you have to set up just to get a single triangle on screen.
versatility my ass - if you want to do proper dx11/gl4 you need to prepare all the init code for rendertargets, shader pipelines, vertexlayouts, buffer resources, etc. - this is a lot of stuff to swallow in the beginning and easy to get wrong.

:) whatever, were just my 5c. yes it's a different point of view - but no need to get disrespectful if you don't agree.

Get a Commodore 64. Once you can render 3d with c-64 assembly language, you are allowed to do demos for other platforms. Unfortunately many choose skip this crucial first step.

spike, I'm sorry for the wording and I'd edit the post if I could. I'm just so tired of all the "start with the old stuff" advice because I've seen it repeated so often in every single thread of this kind. The old stuff is not the same as the fundamentals, and I completely agree with starting with those.

Always very good to see developers want to jump into demo, congratulations young Jedi! The old masters that wrote here forgot to tell you there is also a dark side of the force that will bring you easy power and amazing post processes from day 1: Unity & Unreal.
There are 3 approaches depending on what you want:
- If you only care about the final result and just want to do something beautiful, go for wild compos and do creative coding by writing your own plugin for After Effects, Maya, etc.
- If you only care about the final result but real-time is important to you, go for Unity & Unreal, these are the fastest paths, and your prods will look like elite.
- If you want to do size-coding, or want that wonderful feeling that you crafted everything with your own bare hands, yeah go for C/C++ and pick your favorite OpenGL. If you know java, go for c++, but you will have to learn what memory management is about as there is no garbage collector.
The last path is the one that gives me the most satisfaction, and is the one I recommend. But we are all different, and I understand some prefer to focus only on the FX instead of spending time on an engine and a tool. Welcome, and have a wonderful journey in the world of democoders!

There's really nothing wrong with JS+WebGL for demos, if you want to just get to it.

wow, thanks everyone for the inputs! really appreciate all the advice!

At first, I wasn't even sure why some people don't use unreal or unity when engines like these already exist to speed up the process. But i think i get it now. From what i've gathered, a lot of game makers use them, because it's a quick way to create a game, because there's many things built in already, cameras, lights, models... in a way it's sort of like the program Poser compared to 3dstudiomax, etc right? For example, in poser, you are basically just taking a simple premade model and posing them, and setting up a scene, etc.

With graphics programming with opengl, vs. using an engine like unity/unreal, basically with opengl, you're responsible for everything, and have to design everything from scratch, so from the ground up, everything is tailored and customized specifically for you and your project.. and tailoring it to fit your need... whereas, with an engine, you're limited to what the engine can provide.

Just out of curiosty, if you're creating a demoscene, what are some of the things that you perhaps want to do in your demo, that you aren't able to produce with an engine? I plan on learning opengl and learning everything from scratch, but still, just a bit curious.

And by definition, demo tools like tooll.io and werkzeug are also engines akin to unreal/unity in a way? just on a smaller scale.
==============================================

Another confusion I have is this. I know a lot of the higher quality demos are done by teams consisting of specialized people doing specialized things and often consists of: coder, art, music.

See, when it comes to graphics programming, I'm having a hard time with knowing what is actually made by the coders, and what is made by the artist? Since I've seen examples of programmers writing codes to generate a simple line, a geometric shape, and furthermore, programming them to animate right on the screen.

In this video cupe seems to be creating a complex building with codes alone
https://youtu.be/T-9R0zAwL7s

Can someone perhaps help me understand just how much a coder is able to do by himself? How much of the graphics on screen are actually created purely from codes alone, and when does the role or need of an artist comes in? (3d modeler/sculptor i'm assuming?)

Are there any videos out there showing the entire creating process of a modern demo by any chance?

What are some demos I can perhaps look at that are done by 1 person alone? ^_^


Cupe: "And don't go the webgl path (unless you already know you don't want to go far), that one is a dead end." could you elaborate on this a little more ? :D

if you want it easy take windows and dx11. or take a generic crossplatform api what you need is a window, keyboard and file access, memory, threads, an audio api and ogl. take care about driver issues. they are there. and i'd recommend atleast 3.0 or 4.0. graphics default are buffer and shaders.

the programming language is actually your choice. take whatever version and style you can read and understand what it does. you can spit graphics fast in old c. if you need more defined objects using specific methods and recycling you got classes. c++ and a ton of soft memory management hackshit in the newer versions. if you need gui involved you probably gotta take c#.

Spend 20 years and copy personas from UFC or WWE guys
Done deal

the only sane thing said in the entire thread

therue: these are good questions.

basically, there's nothing you _can't_ do with unreal - because besides all the high-level stuff (editor, model handling, physics, etc.) they also provide a high-performance, low-level rendering API (look for "RHI") that's quite close to what a typical high-end demo-engine would look like. using that you could do all the code-generated effects you want.

regarding coders vs. artists: if you are mainly aiming for geometry and animation that could be generated/expressed via formulas (aka procedural generation) you can get a long way without a real artist - if you have some basic artisitic talent yourself (choosing colours, shapes, etc.). 99% of all 64k and 4k demos/intros are done using procedural techniques (often using a custom tool to chain procedural generators together, see tooll.io)
however, if you aim to do larger demos with character animation and elaborate environment art (see TBL's Amiga demos e.g.) you will definitely need an artist.

In general the whole demoscene thing is much much more fun in a team of several people/friends anyway - and results tend to be better.

therue: webgl (aka OpenGL ES 2) is only a dead end in the sense that you can't go very far technologically. It's basically the OpenGL 2 feature-set plus/minus some parts, all features from later version of the "real" GL are absent. For example, the latest mercury 64k would not have been possible in webgl (even ignoring the size limit), there would have been no way to even remotely make something like it with the set of tools that webgl provides. With webgl you won't have compute shaders, tessellation, performance queries, 3d textures, a nice debug API, and so many other things that I now take for granted so they don't even come to mind right now. It is by no means a dead end in a sense that it will or should die (like flash), it definitely has made the web more interesting and has enabled awesome things like shadertoy. But you just can't go all the way with it and you'll miss out on all the fun that opengl has become in the last 2-3 years. If you already know you won't use the new toys, go for it. The house that I grew up in was in a dead-end street, that was no reason to not go there ;)

In theory, a coder could do all the visual things by themselves, but at the very least you need a second pair of eyes because after coding a thing for 10 hours you stop seeing the obvious issues. In practice, somebody who actually has some clue concerning composition, color, and cinematography in general can turn shit into gold. I've read a few books on editing, camera work, cinematography, etc. which helped me a great deal and now makes me cringe when I look at my stuff from two years ago, but... a real artist is still something else :)
I could never do anything with audio though. To me, our musician and synth coder is a black box that emits music ;)