The landscape shader code is now in the repository. Compile, set HighResLandscape in the configuration... And see that most textures fail to load because they still have the wrong dimensions. Artists to the rescue! :(
A good opportunity to replace the earth.jpg and the old brick texture.
Textures that are not 2^x (512x512):
water.jpg
tunnel.jpg + earth.jpg
lava_red.png
brickback.jpg + brick1.jpg
Edit:
Textures that are not 2^x (512x512):
water.jpg
tunnel.jpg + earth.jpg
lava_red.png
brickback.jpg + brick1.jpg
Edit:
gl: texture Snow size mismatch (64x64 vs 512x512)!
Wait, you only accept 512x512? Why not any potencies of 2?
They must be exactly the same size. Unless you want me to crudely resize them in the texture loading code.
For powers of two, crudely resizing would be simple tiling, which wouldn't look bad at all.
It would just be a bit overkill to have a texture for each snowflake of 128x128px.
Well, the snowflake is never used as a texture, therefore it doesn't really hurt that it doesn't load.
> Edit: gl: texture Snow size mismatch (64x64 vs 512x512)!
Unused textures clearly shouldn't be loaded. Or we need some mechanism to sort out the sprites.
Well, "unused" is difficult to detect. You still have the option to just start using a texture mid-game using, say, DrawMaterialQuad.
Edit: Hm, which wouldn't work right now as I don't update the associations after initialization. Might have to look into that. Will have to do that anyway to implement texture animation.
Edit: Hm, which wouldn't work right now as I don't update the associations after initialization. Might have to look into that. Will have to do that anyway to implement texture animation.
Since the multi-texturing and color modulation is gone (is it?), we could just tie textures to materials.
I think there are still a few things that depend on Material names. Moving the sprites into a subdirectory sounds simpler than changing all that.
Well, maybe we might want to reintroduce it? No reason earth must have the same texture everywhere.
> tunnel.jpg
I resized and slightly modified this one.
> lava_red.png water.jpg
These I just resized.
Also, some notes from tonight's IRC discussion:
We should reduce Earth, Sand and SandDry to just Earth and Sand. The distinction between Sand and Earth is a workaround from Clonk 4 times where one material could only have one color. Now we can just use one material per gameplay element, with different textures for looks. Sand is Instable=1, Earth isn't. Earth should have different textures that are more or less sandy, just like real earth. Sand should be the stuff found on beaches and have "Tropical Paradise" textures.
Baww :-(
Log:
Unhandled exception at 0x6db4463e in ClonkRD.exe: 0xC0000005: Access violation reading location 0x00000000.
msvcr90.dll!6db4463e()
[Frames below may be incorrect and/or missing, no symbols loaded for msvcr90.dll]
msvcr90.dll!6db446fc()
ClonkRD.exe!C4StartupScenSelDlg::`scalar deleting destructor'() + 0x15 bytes C++
ClonkRD.exe!__lseek() + 0x26f74 bytes C++
ff8bcccc()
Log:
[03:05:33] 23 Texturen geladen.
[03:05:33] 19 Materialien geladen.
[03:05:34] Erstellung der Landschaft...
That doesn't look very helpful. Does the stack trace have additional entries further up?
No. I am using Release with Debug information. Could this be the reason why I don't get all the symbols?
After updating to Mesa 7.11-devel (git-cca8887), I now get this:
0:0(0): error: no matching function for call to `texture2DLod(sampler2D, vec2, float)'
Mesa bug #29537 suggests that's by design.
This patch makes it load, but the textures are mixed up, so I can't say whether the patch is correct, though I doubt that it breaks anything.
diff --git a/planet/Graphics.ocg/LandscapeShader.c b/planet/Graphics.ocg/LandscapeShader.c
index 1be420e..203c0df 100644
--- a/planet/Graphics.ocg/LandscapeShader.c
+++ b/planet/Graphics.ocg/LandscapeShader.c
@@ -59,7 +59,7 @@ void main()
if(texture2D(landscapeTex[0], centerCoo + fullStepX + fullStepY).r == lpx.r)
scalerCoo += 16.0 * scalerStepY;
- vec4 spx = texture2DLod(scalerTex, scalerCoo, 0.0);
+ vec4 spx = texture2D(scalerTex, scalerCoo);
// Material pixel
float mix = matTexMap[int(lpx.r * 255.0)];
0:0(0): error: no matching function for call to `texture2DLod(sampler2D, vec2, float)'
Mesa bug #29537 suggests that's by design.
This patch makes it load, but the textures are mixed up, so I can't say whether the patch is correct, though I doubt that it breaks anything.
diff --git a/planet/Graphics.ocg/LandscapeShader.c b/planet/Graphics.ocg/LandscapeShader.c
index 1be420e..203c0df 100644
--- a/planet/Graphics.ocg/LandscapeShader.c
+++ b/planet/Graphics.ocg/LandscapeShader.c
@@ -59,7 +59,7 @@ void main()
if(texture2D(landscapeTex[0], centerCoo + fullStepX + fullStepY).r == lpx.r)
scalerCoo += 16.0 * scalerStepY;
- vec4 spx = texture2DLod(scalerTex, scalerCoo, 0.0);
+ vec4 spx = texture2D(scalerTex, scalerCoo);
// Material pixel
float mix = matTexMap[int(lpx.r * 255.0)];
Well, you can try whether just using texture2D works as well. The Lod part is just a workaround for this problem.
Heh, my editing crossed your post. I'm not seeing any of the artifacts visible in your picture, just the switched material textures. I'll post a screenshot later.
You have to get somewhat close to see them. It causes the hard lines in this early version, especially on the Tunnel/Sky edge:
But normally it's easy to notice because the lines flicker a lot when you move around. It's pretty likely that you don't see the bug, as the documentation clearly states that
But normally it's easy to notice because the lines flicker a lot when you move around. It's pretty likely that you don't see the bug, as the documentation clearly states that
texture2D
should not do any Lod calculation when there's no mipmapping. I think my driver does it anyway, divides by zero and just gives me a transparent pixel.
Too bad, I am still getting an error on the latest version of the landscape shader. However, this time it doesn't just crash (thanks!) but cancels the scenario start and shows this message: "[!] Could not initialize landscape shader! Fehler beim Landschaftsgenerator."
The Clonk.log:
The Clonk.log:
[22:17:12] Erstellung der Landschaft...
[22:17:13] Fragment info
[22:17:13] -------------
[22:17:13] 0(65) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable
[22:17:13] 0(67) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable
[22:17:13] FATALER FEHLER: [!] Could not initialize landscape shader!
[22:17:13] FATALER FEHLER: Fehler beim Landschaftsgenerator.
Huh, that's not good. That pretty much means "arrays don't work". According to various forums in Google distance, I should instead emulate them using a 1D texture. Or generate a gigantic if-then-else construct into the shader. Sigh.
Edit: In theory, I could also put the texture index into the landscape pixel, but that would kill the possibility to animate them.
Edit: In theory, I could also put the texture index into the landscape pixel, but that would kill the possibility to animate them.
That's not particularly surprising given how GPUs work. Though the driver really should be able to work around that with the 1D-texture trick itself, but maybe the driver developers felt that having the amount of available texture units change depending on the shader's usage of arrays was worse, or perhaps less OpenGL compliant than failing a shader compile.
> Edit: In theory, I could also put the texture index into the landscape pixel, but that would kill the possibility to animate them.
So older cards don't get liquid animations. And I think using an extra blit for every liquid is probably better anyway.
Okay, caused a lot of confusion along the way, but there's now a workaround in the repository that falls back to 1D textures. Does it work for you now?
Same error as before.
[19:56:29] 0(76) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable
[19:56:29] 0(78) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable
[19:56:29] 0(76) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable
[19:56:29] 0(78) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable
That's expected, as it will always first try the version without workaround. The question is: What happens after that?
I have noticed that in landscapes where brick edges are placed, i.e. DrawMaterialQuad is used, lightning is not correct. See attached screenshot.
Also on the other side a part of such an edge is missing.
Also on the other side a part of such an edge is missing.
Attachment: Screenshot001.png (418k)
That's not the light that's wrong: It's probably switching to another material right at the edge. Yet another rounding issue probably. Are you sure you have the current version of the shader?
Awesome Work PeterW! Congrats! Will this version be uploaded soon?
I assume it's http://hg.openclonk.org/openclonk/rev/69f2b7917a80
By the way, are normal mapped textures supported already? If yes, what do I have to do to test them?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill