dabroz.scythe.pl

I've found an intersting post on Twitter: You are NOT a Software Engineer. While I don't agree in general, it can bring us to a question: is programming an art?

Let's start with defining what is art. For me, art is a process of creating something where, at any time, you have full control of the output. For example, designing bridges is not an art, because you can't just remove a pillar here and add an arch there.

In more IT terms, subjectively:

• Doing 2D in Photoshop is an art. Even with multiple layers involved, you can always add another one on top and paint over to achieve pleasing effect.
• Sculpting in Z-brush is an art. At any moment you can add additional tentacle to your model, even since most of the time you shouldn't.
• Modelling in 3DS-max is an engineering. You need to maintain good topology, corrects edge loops and proper smooth groups. You can't easily modify finished model.

Of course I'm not telling that 3D artists are not artists. :) Art can (and usually does) involve engineering, and vice versa. It's just subtle yet important matter of balance. And we can observe that due to reduced technical complexity of doing ,,art'', it's more accessible to traditional artists. I mean, give talented painter a tablet and Photoshop and he will succeed. And Z-brush sculpting is just adding another dimension to it. On the other hand, there is no ,,off-line'' version of polygonal modelling.

So how can we treat programming with such definitions?

Unfortunately, programming is not an art. Most of the time you can't change features without effort. It's very apparent in gamedev where cost of code changes (esp. last-minute code changes) is much bigger than design/art.

I would love programming to be an art. But we need much better languages and tools to achieve it.

One of the biggest programming problems, related mostly (but not exclusively) to OOP is generalization. There are numerous running jokes on Twitter, like foo function that is 100% future-proof:

template <typename T, typename T1> virtual T foo(T1 t, ...) = 0;

There are many failful designs out there that suffer greatly from generalization. Fine example is a 3D renderer I've seen once. It was written by a pro-OOP guy, and it was heavily templated, STLed and smart pointed. There were many [C]Material classes and various [C]Meshes and everything was tightly design patterned. So I've asked the author to add simple vertex extrusion along its normal. He instantly refused, pointing that he would have to add many additional classes for extended materials, shaders and parameters. Objects properties and internal tools would also require changes. He said it would take about 10 to 20 man-hours. I said Wait, it's one line in shader and one additional parameter -- why would it take so long? And he replied: My engine is designed to be easily extended, so such modifications require a lot of work.

This can be described as vicious circle of generalization:

1. We want the code to be as generalized as possible.
2. We design everything future-proof and extendible.
3. When a feature request arrives, we're doomed we need to change a lot of code.
4. Why?
5. Because everything was designed as generalized as possible.
6. goto 1;

And visual version:

So -- at least in my opinion -- reject toxic design patterns and KISS instead. Small functional changes should not require big code changes. And everytime you over-engineer something, another startup dies (and there aren't many left after all singleton experiments).

Disclaimer: this post is related to IGK presentation [PL only, unfortunately] about efficient C++ and DOD from Adam Sawicki and me.

(from #altDevBlogADay)

Tomorrow I'm heading for Polish gamedev conference (IGK [pl]). Along with Adam Sawicki we're having a prelection about Developing Efficient C++ Code with Data-Oriented Design.

Few days ago I've started new game project codenamed Neon. It's going to be simple Wipeout-style racing game using my UT Engine. I'm going to publish very short development news in Neon Game Blog (mostly screenshots with few words). Here is the first video with spline-based track:

#altdevblogaday entry

I may be in no position to criticize any programming language, but hey — we were told to be bold and controversial so here I am with Yet Another C++ Rant.

C++ is a terrible language. I’m pretty sure all of you already know C++ Frequently Questioned Answers — it’s a bible of C++ quirks, a must-read. C++ claims to be multi-paradigm; procedural, object-oriented and generic. But it fails on all levels — I mean, have you ever tried to implement delegates in C++ without external libs? Or STL containers, they should be so superior to C# generics due to compile time evaluation, but have you ever seen assembly generated? And I’m pretty sure that the whole metaprogramming idea inspired many folks to build a CPU inside Minecraft.

But to be fair: a lot of good software was build and shipped with C++ (or not entirely crippled by C++ as FQA would state). So perhaps people may find use of various C++ features, depending on personal taste. But the real problem with C++ features is an amount of them. There are tonnes and tonnes of those features, some widely known and some remaining in the dark, waiting for years to shoot your foot off. And C++0X is only going to make things worse. I greatly admire people behind C++ compilers. Those guys are real heroes. But I’d love them to improve optimizations, not some bizzare and/or creepy features that are likely to explode when used together. If I didn’t care about performance, I would not use C++ anyway, right? But the sad fact is that a lot of C++ features prevent optimizations in direct (e.g. side effects you don’t care about) of indirect (because compilers are getting extremely complex) ways.

And you can’t expect people to know all those tiny little features of C++. It can be expressed like this:

(∀ x ∈ C++ programmers) (∃ ε > 0) x is the only one who knows some bizarre C++ feature around radius ε

And so, to keep people sane and deliver some software, most companies that still use C++ put a lot of restrictions, mostly “don’t use …” (exceptions, RTTI, non-container templates, whatever you hate). In extreme cases, only “C with classes” is left. Not that it’s bad, it’s something I use personally (BTW: usage of C++ features can be perhaps measured in ratio of Release/Debug performance — and I know some games in which Cornell box level is just a little too much for debug build). But the compiler doesn’t know that we disrespect that “bad part” of C++ and still have to do its job.

Any alternatives to C++? It’s not easy. The sad fact is that most languages have compiler/library/IDE issues. D haven’t ever gained attention, C# is not crossplatform and Java is <insert your favourite joke here>. At the moment there is no easy replacement or at least I don’t see one.

But I keep my fingers crossed for LLVM. LLVM is a complete compiler infrastructure, but the most interesting part is backend: optimizations and generation of machine code (either static or JIT). Our job is “just” to make a front-end for our language, which is quite simple for simple languages (especially using tools like Flex/Bison). But why limit yourself to one language? I can think of following scenario:

• “main” language, similar to “C with classes and whatever we really need” used for most engine/game code
• “computational” language, similar to shaders (see my previous post here)
• “gameplay” language, similar to Lua

The greatest benefit I see is that using uniform infrastructure we could glue those pieces of code without additional layers of wrappers (like in typical C++&Lua code). Another win is uniform debugging using one tool only (LLVM IR may contain standardized debugging information). And of course another huge advantage is an ability to fine-tune each language to specific needs:

• “computational” language doesn’t need to have classes
• but must have robust vector/matrix support
• “no side effects” functions and compile-time optimizations using this
• SSE/Altivec is mandatory
• GPU/SPU support would be cool, too (although some folks would be very unhappy not having to manually adjust SPU assembly)

On the other hand:

• “gameplay” language could implement a number of Lua-like features
• like functions as first-class citizens
• maybe also coroutines
• garbage collected, duck typed? a lot of options here

But wouldn’t maintaining three different languages be harder than just one? Well… if you need a language suitable for any job with a bunch of features, I can’t help noticing that there is one already, yet I think you already know that I don’t like C++ very much. And wouldn’t maintaining any number of custom languages be harder than just shutting up and continuing to use C++? Honestly, I don’t know. While C++ is horrible as a language, it has excellent IDE/debugger/libraries/etc support. This would be very tricky to fight and you probably won’t get far without some kind of C/C++ compatibility in “main” language. However, I’d still give it a shot.

Good read: Forward vs. Deferred Rendering: why/when forward rendering still matters. I totally agree. Many developers/games push into Deferred not taking into account that they do outdoor game (directional lighting only for 95% of the game) and/or have completely static environment. You should not use some technology just because it's ''cool''. Mirror's Edge looks beautiful with its light-mapped levels. Now imagine that you swap lightmaps with ''dynamic'' deferred lighting (which would be a static sun for most levels). Deferred fail!

Good read: Forward vs. Deferred Rendering: why/when forward rendering still matters. I totally agree. Many developers/games push into Deferred not taking into account that they do outdoor game (directional lighting only for 95% of the game) and/or have completely static environment. You should not use some technology just because it's ''cool''. Mirror's Edge looks beautiful with its light-mapped levels. Now imagine that you swap lightmaps with ''dynamic'' deferred lighting (which would be a static sun for most levels). Deferred fail!

Good read: Forward vs. Deferred Rendering: why/when forward rendering still matters. I totally agree. Many developers/games push into Deferred not taking into account that they do outdoor game (directional lighting only for 95% of the game) and/or have completely static environment. You should not use some technology just because it's ''cool''. Mirror's Edge looks beautiful with its light-mapped levels. Now imagine that you swap lightmaps with ''dynamic'' deferred lighting (which would be a static sun for most levels). Deferred fail!