pouët.net

... Makefiles ?

Well, I'm more in the 8-bit area of stuff, but, I now have a project framework (happens to be makefiles, but choose your tools) that I copy over when I start a new project. It's minimal and meant to be modified a bit everytime (with copypasting from previous projects as needed). But at least I get to the interesting parts faster. And overall, scripting is a good thing. Don't do repetitive and boring stuff by hand, the computer was built for these tasks :)

damn.. you are discussing the story of my life here.. I code as much as I can on my spare time and I'm sad to say that it's either frameworks or some tools. I really need to get my act together and just jump straight into the fun parts and skip all the big and fancy plans of how much simpler things will be "when this next framework/tool is done".

??? I know i'm no computer scientist and only use asm+c, but is this true, c++ is lower level???

:)

ekoli: the recipe is simple. You start a blanco project and you envision rendering *something*, then write all but strictly just all code necessary to render it. Add some music and whatnot and go from there.

I slowly and tediously write the code and think about a helper library I'll write afterwards to save the rewrite time in the future - needless to say, most of those libraries never get even started. But the idea does wonders for motivation :)

I'm with Ferris on this one, except that I do Direct3D 10.1. I've got some mild wrappers for Texture/Shader loading, RenderTarget creation and so on... When it comes to code a demo, I have to use my wrappers exactly like I would use raw D3D calls, in the same order. Except I don't need to write 5-20 lines of struct data each time I want to call a d3d function... Texture creation, rendertarget creation, Shader creation, Texture assignment for rendertargets, the binding of them all, some mesh creation operations, all of those are oneliners. That's the kind of "framework" I consider to be portable. This way, DirectX 12 can come alog with Utopia Shaders and QuanticViews (hi kebby!), I just wrap the new features and am ready to use them.

TL;DR: An effective framework should consist of minimalistic wrappers of existing libraries, in order to reduce the amount of code needed, and not to invent a new way, to use them.

[another useful thread . . . filing away]

chaos: This is exactly the point :)

It takes a rare and very enviable breed of developer to work weeks, even months and churn out hundreds of thousands of LOC towards a goal in their spare time. Of all people I know this is only a handful, and most people, myself included, wouldn't want to work this way. I don't want to know how many ruins of well thought out generic audio frameworks populate my c:\code dir (and d:\backup\code and d:\backup\backup\code, etc :).

(Meh. Apologies for the first sentence btw... the kind of stuff that sounds funnier when writing than when reading afterwards :/)

what Kusma and the other are saying. keep things super simple ("don't start building your house from the roof"). don't write the ultimate math library, the complete image loading and manipulation library, the more abstract API agnostic renderer, the future-proof scene graph library and all that bullshit. just write demos. be clever, though. code only what you need, but leave room in your design/architecture/code structure to expand when needed, plan for future needs but just indicate them, do not implement anything around them yet, think what else you would like your code to be able to do, and plan the interfaces or hooks or slots for it, but just plan them. grow your libraries and modules and reusable pieces organically as you make demos, which is your goal in the first place. frameworks get obsolete, demos don't (they always make sense in their historical context). my approach is to have a set of libraries (called "iqLibs", hah!) for different things, from simple things like an "iqSystem" for OS abstraction (threads, timers, windows, i/o, strings, memory) to things more crazy like "iqMesh" (mesh manipulation, from loading to procedural operators), "iqCameras" (kinect, webcams, etc) or "iqRenderer". So making a new demo, or vj set, or experiment, or ebook, or whatever is "just" a matter of bringing the relevant pieces together and coding the specifics of the application and some glue code. prototyping ideas takes 20 minutes, not 8 hours. the creative proecss and iteration process is also super fast today given that you do most of your stuff in shaders which can be reloaded at runtime (so are textures, meshes, etc, btw), so no needs for scripting languages or stuff like that anymore really. basically, as an """demo artist""", i believe more in a set of libraries that function as building blocks for your application, than in a monolithic framework or demotool which can do only one thing, in one way.

again, as Kusma and Kb and the other guys said, the rule is ALWAYS : "keep it simple, code only what you need". i don't want to see more failed demoscener-wannabes that give up after a month of coding frameworks, libraries, systems, apis, tools and shit. don't you already have a job, or what? make demos, goddamnit!

What gives me a kick is to see the result first. e.g. if I've had to write a SPH simulation of 1000000 particles the only way I succeeded in finishing the project would be to actually *see* these particles on a screen first (even static, even GL_POINTS, whatever). Then I could develop all the integration / physics stuff. But visual result has to come first.

I heard a good one recently: Code so that every piece of code is just barely sufficient, but make it come together in a final product that is more than so.

WTF kb_!?! you make backups?

Apparently he's not Purple Motion. :D

I find that drinking helps me with coding in general. Stops me from overthinking everything and just get shit done.

Amen to that.

Cygnus Editor for Amiga :)

/me wants CygnusEd in FullHD on Amiga6000 ;)

pfff, real amiga coders, carve the bits by hand

Gargaj: are we really going to end up here?

what I *really* miss is the macro functionality of the original ASM-One editor

maq: The actual macro definition commands or the "record and playback any arbitrary sequence of keystrokes"-stuff? Both are powerful but also ridiculously unpredictable at times (at least in some implementations) :)

So, yeah, C++, my enemy. Actually, I can say: I either use plain C except for some library code. Lot's of things, like the generalization issue (I should put this into a class because I might need it later on) just do not appear (at least for me, of cause you can put everything in structs). If I want to write reusable code (like at work) I use Java or build my own JVM language even (using Xtext). I worked in the framework/IDE/language engineering context for a while now and tend to say: If you know in advance what you have to do and there is just a huge amount of boilerplate code to be written, it is worth thinking about a domain specific language. I can already hear the "oh noez, this takez more time than solving the problemz", but the toolchain I use is quite fast and very nice for prototyping and agile stuff...

Back to the C(++) topic: I wrap stuff in functions. That's all. But I'm not a skilled demo coder or something near that ;)

Fun thing about C++: It's versatile. You can have it as procedural, functional, object oriented or generic as you want. There is no one true code style, even if 100s of people are trying to convince you otherwise (and contradicting each other). C++ is kinda the Swiss Army Knife of programming languages - lots of tools, you really need when to use which, and though most of them aren't the best of their specific kind, you can go a very long way with them if you're good.