Comments for Christian's Projects Sat, 06 Jul 2013 19:02:18 +0000 hourly 1 Comment on Getting more out of the range-based for statement in C++11 by Christian Christian Sat, 06 Jul 2013 19:02:18 +0000 The main reason for the split in enumerate() was that the code

for (auto e : enumerate(container)) e.value = 12;

looked surprising. Does that change the container or not?

First I made value const so this would just not compile. But in practice, you often do want to change the value. Once I decided to change the name to enumerate_byref I felt I also had to provide enumerate_byval.

Currently I’m leaning towards just not having enumerate – the code may be more verbose, but it’s also more readable.

Comment on Getting more out of the range-based for statement in C++11 by Leo Goodstadt Leo Goodstadt Fri, 14 Jun 2013 18:07:57 +0000 Nice code. Could you explain a little more the rationale for splitting up enumerate_byref and enumerate_byval.

More to the point, enumerate_byval seems to provide little benefit over enumerate_byref. Benchmarking seems to suggest that this is almost no overhead in passing by reference instead of by value, e.g. for integers.

The only other point is if the user is going to modify the value / counter inside the loop, and he/she wants to discard such changes. This seems to be an odd and confusing paradigm…

Admittedly, the usual distinctions between using const T&, T& and T “don’t work” when using an enumerating range. But that is true for enumerate_byref as well.

Thus with:

for (auto e : enumerate_byref(container))

even with the “byref” in the name, are we going to know for sure that “e.value” here is a reference, rather than a copy?

Have I missed anything?

Comment on Getting more out of the range-based for statement in C++11 by Leonid Volnitsky Leonid Volnitsky Sun, 24 Mar 2013 11:34:13 +0000 There is somewhat similar project at

Comment on dynamic soft shadows in 2D by Max Max Sun, 19 Aug 2012 00:17:52 +0000 Thanks for the answer! I will probably try something like what you suggested for the overbrightening before I look into floating point textures.
I will also release it in the future, but it is not finished yet. There are no comments and I still want to do some of the things I mentioned. Right now I want to look into how Box2D does its spatial partitioning. I found this, but understanding the code might take a while:

Comment on dynamic soft shadows in 2D by Christian Christian Sat, 18 Aug 2012 13:51:06 +0000 I’m glad to hear that you got it working. Looks great! :)

What I was thinking about when writing the statement about modern gpus was that the algorithm described here was mainly constrained by the limited number of blend modes available in the old fixed function pipeline. I haven’t thought about improving it in detail. Using vertex buffers and some sort of spacial tree data structure for the lights would definitely make sense though.

As for overbrightening: floating point textures would work. You can also continue to use ARGB32 and change the pixel shader used for blending the lights onto the scene to do a scaled multiplication (something like result_color = 2 * unlit_color * light_amount) . You’d lose some accuracy and would have a maximum amount of overbrightening, but that’s probably ok.

If you release your code somewhere, let me know! People have been asking for a C++ implementation quite a bit.

Comment on dynamic soft shadows in 2D by Max Max Thu, 16 Aug 2012 13:19:54 +0000 Hi,
I implemented this in c++ and it works, but I am interested in learning what you mean by “a lot has changed in the last years. You could probably achieve the same effect much more efficiently on modern graphics cards.” Optimizations I can think of are:
- using a Quadtree to determine which lights/shadowblockers are visible
- use vertex buffers instead of immediate mode
- maybe put the shadow casting stuff in a geometry shader

Also I think there are two limitations right now with this method. First, you can’t get overbrighting effects as described in the original article. I solved this by rendering the whole scene in a seperate fbo and blend it over each light, but I think this is not the most optimal way of doing it. It would be ideal if you could somehow save color values greater than 1 in a fbo, but I don’t know how.(maybe floating point textures or something)
Second, this currently only works if the lights size is smaller than the shadowblockers. I think this can be solved by rendering both the penumbras and umbra in full darkness and then subtracting the areas of the penumbras appropriately.

Anyways, this helped me a lot, I am only interested in knowing what can be improved to make it even better. This is how my implementation looks right know, you can also see the mentioned overbrightening effects:

Comment on dynamic soft shadows in 2D by Christian Christian Mon, 28 Nov 2011 06:26:59 +0000 David: It’s equivalent to this C++ code:

for (size_t i = rightpenumbra.sections.size() - 1; i < blockerLine.size() - leftpenumbra.sections.size() + 1; ++i) {
    Vert &vert = blockerLine[i];
    umbra.sections.push_back(Umbra::Section(vert, extendDir(0.5 * (leftpenumbra.sections.last().direction + rightpenumbra.sections.last().direction)));

Comment on dynamic soft shadows in 2D by David Amador David Amador Fri, 25 Nov 2011 23:17:21 +0000 Hi, great tutorial.
But I’m having some troubles converting it to C++.

Would you mind converting this line to me, I can’t understand the loop, begins where and finishes where?

foreach(ref vert; blockerLine[rightpenumbra.sections.length-1..$-leftpenumbra.sections.length+1])
umbra.sections ~= Umbra.Section(vert, extendDir(0.5 * (leftpenumbra.sections[$-1].direction + rightpenumbra.sections[$-1].direction)));

I’m also having some troubles on other parts but for now this would help a bunch. I’ve placed my email on the form.

Comment on LDC 0.9.2 released by Christian Christian Fri, 08 Oct 2010 13:51:31 +0000 While I’m no longer actively contributing to LDC, it’s not totally abandoned. The repository has moved though:

Comment on LDC 0.9.2 released by Zyx Zyx Thu, 07 Oct 2010 21:27:51 +0000 Will the development of LDC be continued? This is the project I need to switch to D – a good, reliable compiler that not only “is”, but also notices the existence of such things, as 64-bit platforms + a good standard library on board. It’s quite sad that nothing has happened in the repository for the last months…