

Then you have the newest content and source, but if you don't want to build the engine yourself, you can check out the autobuilds page: http://hg.openclonk.org/openclonk/autobuild/
A build of the engine from the light branch should appear there soon (I hope)

You'd have to install TortoiseHg, clone the repository, update it to the lights branch, set up something to compile an engine (Visual Studio or MinGW) and compile an engine.
Fortunately enough, Zapper triggered an autobuild. But you will need someone to post the link to the dependencies (meaning: a zip full of dll files) in order to run this build.


For my graphics card, I saw the following problems:
* (!) only each second or so, the display of the landscape is updated. So if I dig, I seem to move into the earth.
* The shown black triangles on the four sides
* on zooming in and out, the lighting lagged behind
* light flickering a bit (which is not too bad, could be also deemed a feature ;-)
Did I already mention how absolutely awesome this is?
Edit: For all those who can't compile and as the last autobuild for the lights branch failed - here is my version. (win32) Use it with the latest development snapshot.
Attachment: clonk.exe (5912k)
> * (!) only each second or so, the display of the landscape is updated. So if I dig, I seem to move into the earth.
Yes, that also happens here. I have no idea whatsoever what's causing that. Maybe framebuffers are somehow incompatible with writing to textures directly?
>Still I wonder if it would be ever possible to have several light sources which light your base and other things.
Try launching a scenario with multiple clonks (or one where you are likely to die and be relaunched). Doesn't get laggy for me.

clonk.exe!C4FoWLightSection::Render(C4FoWRegion * pRegion, const C4TargetFacet * pOnScreen) Line 1159 + 0x3 bytes C++
clonk.exe!C4FoWLight::Render(C4FoWRegion * pRegion, const C4TargetFacet * pOnScreen) Line 783 + 0x9 bytes C++
clonk.exe!C4FoW::Render(C4FoWRegion * pRegion, const C4TargetFacet * pOnScreen) Line 775 + 0x9 bytes C++
clonk.exe!C4FoWRegion::Render(const C4TargetFacet * pOnScreen) Line 761 C++
clonk.exe!C4Viewport::Draw(C4TargetFacet & cgo0, bool fDrawOverlay) Line 242 C++
clonk.exe!C4Viewport::Execute() Line 347 C++
clonk.exe!C4ViewportList::Execute(bool DrawBackground) Line 758 C++
clonk.exe!C4GraphicsSystem::Execute() Line 140 C++
clonk.exe!C4ApplicationGameTimer::Execute(int iTimeout, pollfd * __formal) Line 828 C++
clonk.exe!StdScheduler::ScheduleProcs(int iTimeout) Line 219 + 0xd bytes C++
clonk.exe!C4AbstractApp::Run() Line 27 + 0x9 bytes C++
I saved the dump, so if you want to know the values of any variables, do ask.
> clonk.exe!C4FoWLightSection::Render(C4FoWRegion * pRegion, const C4TargetFacet * pOnScreen) Line 1159 + 0x3 bytes C++
Hm, that's the mid-ray loop for the intermediate point calculation. I suppose a check for NULL wouldn't hurt there - even though it shouldn't really be triggered in the first place. That's why I waited so long to show this code - there's still lots of weirdness going on that I don't fully understand :/
I blame floating point numbers, personally.

Like this. That shouldn't happen - that's what this "intermediate point" thing is for in the first place.

>Hm, that's the mid-ray loop for the intermediate point calculation.
Hehe, reminds me of my bachelor thesis (p25-26). What if the ray is just one unit long?
What do you mean? That loop determines for a shoft shadow how "deep" it should be by accessing the un-smoothed ray at the position which corresponds to the middle point of the fade. Apparantly it hit the end of the ray list for some reason, which should really only happen if the mid point somehow was outside the ray list range (after all, I have 4 lists covering 90° each). On paper, this positively shouldn't happen, as all points are products of projections of existing points and suitable points close to the light point. Indeed it generally is pretty conservative with projecting points "inwards" when in doubt - which is one part of the explanation for the black triangles at 45°.
One point falling out of the section is actually semi-reproducable in tutorial 1 - sometimes when you walk into the tunnel, you see a bright triangle right-top in the earth. It doesn't cause a crash, but it's probably the same root cause. I'll just have to bite the bullet sometime and go through step-by-step logs of everything until I can pin down at what point exactly that point goes astray.
One point falling out of the section is actually semi-reproducable in tutorial 1 - sometimes when you walk into the tunnel, you see a bright triangle right-top in the earth. It doesn't cause a crash, but it's probably the same root cause. I'll just have to bite the bullet sometime and go through step-by-step logs of everything until I can pin down at what point exactly that point goes astray.


But, using your file changes nothing. Using Pyrit's file gives me the error:"[!] Could not initialize landscape shader! Fehler beim Landschaftsgenerator."
Using the last snapshot (32bit), the posted clonk.exe and tried both LandscapeShader.c linked in this thread as well.
Clonkonaut's shader seems to be from the default branch (doesn't mention lightTex), so no wonder it doesn't change anything. Does the log have anything more to say before that generic error message? What sort of GPU do you have?

[17:47:33] Command line: G:\Program Files\OpenClonk\clonk.exe
[17:47:33] OpenClonk Beyond the Rocks Alpha
[17:47:33] Version: 5.2.90 [cb475e689a7d] Alpha win-x86 (cb475e689a7d)
[17:47:34] Grafik wird geladen...
[17:47:34] WARNING: Unknown bit name: MenuSelect (in line 564, PlayerControls.txt)
[17:47:39] Spiel deinitialisiert.
[17:47:39] Engine heruntergefahren.
I have a Nvidia Geforce GTX 680, 4GB RAM, overclocked
This doesn't look like you started a scenario. 5 seconds you spent in the main menu don't really tell me much, sorry ;)


http://pastebin.com/btYmq1d4
The GLSL compiler is complaining about a lot of "<" and "/" in the shader, which isn't really using them much. Are you sure you copied it correctly? This looks a lot like you have HTML pieces left in there. Try to use the "raw" link in the gray bar up top.

http://pastebin.com/h1NBpg42
The dmp:
http://www36.zippyshare.com/v/84215395/file.html

Also after having a short look at the code (to figure the above out): What happens on an owner change - it looks like a FoW-object would only remove itself from its current owner's list - and on death of a crew member the view range is not reset to 0, so the FoW is also still there?
Yes, and the whole code for attachment of the FoW-objects isn't finished at all. I just built the minimum what allowed me to test it a bit. And don't dead Clonks get this cool animation where their FoW range drops to zero eventually?

I used the latest development snapshot (32 bit) and the engine Newton compiled, but I have a 64 bit Windows. Log is here.

Attachment: LandscapeShader.c (4k)


I have played a few rounds and expierienced 2 crashes. In the 2nd tutorial and Krakatau. Here's the Log.
Btw - you can now activate that mode by turning on debug mode and pressing Ctrl-F7 four times. You're welcome ;)

Absolutely.
Once I get this done properly, at least. For anyone wondering: The current stuck-up is that I really don't want material that's close to the Clonk to cast too huge shadows. Basically, at that point it really shows that I'm only faking the light having a size. I was trying to achieve this by "shrinking" the light for closer rays, but it turns out I can't just do that without violating some assumptions the rest of the code makes. Argh, messy.
Once I get this done properly, at least. For anyone wondering: The current stuck-up is that I really don't want material that's close to the Clonk to cast too huge shadows. Basically, at that point it really shows that I'm only faking the light having a size. I was trying to achieve this by "shrinking" the light for closer rays, but it turns out I can't just do that without violating some assumptions the rest of the code makes. Argh, messy.
Keep it simple? Ignore material on the first 20 pixels?
Ah, btw, are the shadows updated every frame? Would it look good to give the clonk a flashlight and let that bounce up and down a little when he walks?
Ah, btw, are the shadows updated every frame? Would it look good to give the clonk a flashlight and let that bounce up and down a little when he walks?
That's one of the options I'm exploring. Makes everything explode even worse though :/
And yes, they are updated every frame. However, I'm currently "smoothing" it by alpha-blitting the old light map over it every frame. That makes it look better, as it covers up some jitter due to everything being pixels at some point - when you stand directly in front of something, even small bumps in the ground the Clonk is walking over might cause significant changes in shadows.
So this kind of effect might be less visible.
And yes, they are updated every frame. However, I'm currently "smoothing" it by alpha-blitting the old light map over it every frame. That makes it look better, as it covers up some jitter due to everything being pixels at some point - when you stand directly in front of something, even small bumps in the ground the Clonk is walking over might cause significant changes in shadows.
So this kind of effect might be less visible.

To illustrate - if I assign an over-sized light to the Clonk and set the algorithm to ignore any material within double the size of the light, we get something like this - the light is still big enough that it sees material that is far away but below the light as still party shadowed by my faked big-light algorithm.
The shape is also really coarse and unstable.

Here's what I was using before: By scaling the light down I get a much more natural progression. I really like the look of this better, but - as I said - it violates some assumptions. Specifically, now we might have situations where the transitive property "if A shadows B and B shadows C, A also shadows C" doesn't hold anymore. And I'm pretty sure that the best I could do would be to try to push these cases off-screen :/
(oh yeah, and in case anybody is wondering - in the screenshots, the red line is the surface of "full visibility", and the yellow one for "no visibility")
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill