pouët.net

I assume most other coders after a certain point start to get really frustrated by the turnaround time from having an idea, and finally expressing the idea in compilable code. Some langauges, particularly lower level languages like C++ make this worse.

You see the concept in your head, you want to see it in action, so you start the lengthy process of typing in boring shit and boilerplate crap (which, even with the use of helper libraries, still takes a bit longer than you would like). Fast forward 8 hours and you finally have it.

Its probably why some of us make demo tools in the first place, ignoring artists for a moment - its still a lot simpler to drag things around in a tool or code an effect as a plugin than to start up a new project etc etc.

Now I know about the hardcore coders that still use a plain old text editor and compile from the command line. Theres something masochistic about that and I really don't understand it.

But my question is this:

What tools and practices do you use, at home or at work that speed up development time for you. These could be, productivity add-ons for Visual Studio (e.g. Visual Assist), a way that you organise your libraries and your projects, not using certain language features, hell even a Dvorak keyboard. Basically anything cool that you think is worth sharing that saves you *that* much more time, in general, to get on with the important stuff.

Streamline!

This whole turnaround problem is the reason I do these mIRC demos and am playing with things like FreeBASIC. I lose my motivation much more quickly the more steps there are inbetween.

If you just want to quickly try some ideas, and you know you will hack and change things a lot within a short timespan Python/Pyglet is nice. Processing seems to be in that spirit. Removing the net wire from his socket helps a lot too.

1. Keep it simple at the first place...
2. Bind your code to a scripting language... Lua ?
3. Have fun :)

I've got a general put-a-mesh-onscreen-with-shaders-and-postprocessing framework that I use as a starting point for pretty much everything. Once I've finished playing around with the look and feel and want to finalise things I remove unused code and optimize what's left by hand.

If I find it would be handy to have an addition to the framework, I code it so I've got it for next time. All a bit dull and traditional, but it works for me. :)

Writing fancy frameworks tends to just take more time than it ends up saving you for demos. Just write the damn code, it's not that hard.

Admittedly, I've not democoded for a long time, but the problem you describe is very much not unique to democoding I guess.

My idea-to-result curve went up significantly when I moved to higher level languages with good tools. My current favourite is C# - it's has a smooth combination of many high-level constructs that make coding a joy, excellent IDE refactoring support, and a great open source community and package manager (NuGet) which is only getting better. The intellisense (which is much better for C# than it is for C++) really helps me understand libraries (.net framework and open source) faster, which gives me more time looking at my code and my work, and less time reading docs.

In the democoding space, I think picking your tools wisely also makes a big difference. I liked seeing in that video about Quite how unc makes his entire (single-shader-on-a-quad) intro with vvvv because it has a really smooth immediately-update-on-screen feature. Save the shader, *poof* the screen updates. No compile-run cycle. If I got it right, the Quite guys only transform it all to code when the intro is just about getting done.

It's cool to make demotools that help you remove the compile-run cycle, but it's even better to use tools that already exist.

What kusma said.

Also an editor that has column edit mode.

Well my advice isn't the best since I also consider myself lost in this C++ thing. I guess I need more experience.

But here is what I do:

Keep writing systems and reusable code. Once you have a pixel plotter set up use it for all kinds of crazy oldschool stuff, and you can even use them to write textures.
write a 3d model loader with your own internal format. Write some functions with which you can modify the data. (ex subdivision, distorsion and you can already have nice realtime morphing geometry) You can keep building on it until it breaks.

My last demo, ReText for Revision was put together from recycled code. It's nothing more than putpixel on a framebuffer, and ugly triangle routine and *.obj loader, an optimized software raymarcher, an asciifier and some code that can sequence and stack scenes and effects. Ofcourse the effects were (mostly) written from scratch but they rely on these previosely written components. The components are were all written during the last 356 days or so.

Just organize your code. When you start reusing your old code you realize what could have been done better. Sometimes you even end up rewriting it and you get a better version. Always thing about what would make your job easier. Write the function that does the job for you. Having 20 "if" statements in a subroutine means you're doing something wrong and there most probably is a better way.

For example, if you consider that setting up a basic window is ugly, write something that simplifies it to one or two function calls. Use classes structs macros functions whatever, they are your friends.

+1 for mu6k. I've some classes and code snippets which were born 6 years ago, they are polished now (but always improved). Things like vector math, procedural textures, geometry. Those snippets were born out of need, not "let's code this I might need it", or random tinkering that somehow stuck on the wall. Not a fancy framework, but those snippets tends to work well together. Those are born out of time, sweat and pain. And lot of fun.

what mu6k said. after a while you get to a point that's just copy pasting existing code whith little changes and you're left alone with your own creativity...

Always pick the easiest solution to your problems unless there's a (very) good reason not to.

I've recently gone through old code (10+ years, back when I still released) and what struck me the most is the dirty simplicity of it all. The day I lost that attitude I stopped being able to get hobby projects done. I'm still in the process of readjusting my approach.

Oh and something Skrebbel once told me is of value here: get something on screen as fast as possible, even if half your boilerplate stuff or what have you is still missing. It will motivate.

This is how to write reusable code the proper way:
1) Write the minimal amount of code you need to reach your goal.
2) When you have proof that the code isn't sufficient any more, modify it until it is.

Don't think you can foresee every possible future scenario. You can't. YAGNI, you know.

Plek: Amen.

Bleh. That's why I'm stuck with Processing. It kind of sucks, but it's fast and typed and you get something up running in a very short amount of time. If I'd be "serious" about demo coding, I'd probably cook up some minimal (geo/frag/vert-)shader-only tool in C# or some such, where you just write script stuff in windows and use some curves for parameters and compositing. But what I really want is a simple, typed language with a well integrated and up-to-date gfx library. A bit like processing, but much more robust, mature and without all the limits (some of which will be gone at last with pde2.0, which is currently in alpha).

Never design large architecture/systems unless you've proven that you can.

Gargaj: I'd go a bit further and say "unless you've proven that you have to". Large frameworks isn't just difficult to design, they are a pain in the ass to work with. Because no matter how huge your brain is, some of the perfectly reasonable assumptions you made when you started are going become invalid at some point.

This.

Incidentally, I'm writing a fancy framework just for fun now. Don't know if I'll ever use it for anything though :)

I wrote headploads of fancy code from 2007 all the way until last year. Not one single release, and now it's on backup drives, only used sporadically to cut and paste small pieces of code I can use in my Xbox project.

For that project, I'm doing a total 180. Absolute minimum boilerplate code, hell I don't even have a matrix or vector class: I use D3DX (or XG on Xbox) and if common sense or the profiler starts screaming mercy I optimize locally. Also I've told myself not to be picky about codestyle (though with me today that still means "pretty damn consistent").

So far I've got some cool stuff on screen. That's more than I got done the last 5 years or so.

I'm with plek on the minimalistic approach. My "engine" is merely a collection of convenience wrappers (texture loader, fbo creation, shader compilation), fmod+rocket, and glm. Perfectly suits my needs; can get things up really quickly. But that's tailored to my specific workflow.

I'm in a weird place here because I've got Chaos whose sole point of existence seems to be writing frameworks :D, but from my own attempts at coding stuff I do agree to most of the people here:

* Just churn out the code needed to Get Things Done
* Generalize stuff on the fly. Eg. start with this: "class Vec3 { public: float x,y,z; };" and as soon as you need some piece of vector math, add it into that "framework". That way it'll grow with your needs, and in case you find out that you ran into the wrong direction with something, there's not much that you'll need to refactor or rewrite.
* Funny drinking game: Every time you think "I _might_ need this or that", pour yourself one. This way the problem will gradually solve itself.
* And stop thinking about long-term reusability. Actual case in point: As soon as you nailed down the perfect abstraction for multi platform 3D, DirectX11 comes along with its compute shaders, tesselation, SRVs and UAVs, and your stuff is obsolete again. Congrats.

Writing a small 4K intro using ready-made tools and starting an empty .cpp file really was an eye-opener in that regard. :)

I always start from ultra-simple things then finish to get some complex stuff with tons details because I added more and more small things here and there, so I'm never bored or think that the job will be too huge :)

even if you're coding frameworks the rule about getting stuff onscreen as soon as possible applies. the best way to debug graphics is visually. :)

i just love coding...