wraitii

Your first point is probably an ARB problem, because if GLSL is not preferred, it should use those shaders. Some things may have changed in terrain_common or terrain_base that make the ARB one crash. I'm going to try fixing that today. Your second point looks to me like the same issue: it's not yet implemented for ARB. Again, as the guy who decided he wanted to port stuff to ARB, I'll try that today. Is no-one else but me getting a wrong result with the AO? It doesn't seem to recognize the second layer of UV. BTW, hav you reached a decision about my water shader? It think it's an improvement, but it requires re-working most maps to take into account the new settings...

Myconid, testing your merged branch (using GLSL): -I get a "LOS framebuffer object incomplete: 0x8CDD" error, and indeed LOS doesn't work in-game (all black). -I still have an issue with the AO uv, it seems not recognized or something Otherwise it all looks fine, here's a small screenshot using my waterShader too:

Should have kept the same... I must have messed that up. These files should not have changed anyway... I committed them by mistake.

Okay, so I've committed (here still) my changes (merging them too) to yours. It should work properly, though I have not yet tried adding to ARB your stuff from smoothLOS or terrainmapping.

Did it the "no-braincell" way and restarted clean. Thanks to a very neat tool from Apple to merge files, I'll get everything back up in no time.

Well I'll refork from your merged branch and try to reconvert everything from ARB (not re-starting from scratch, though). I'll let you know.

Yup, it fixed it. I'll refork from your merged branch and work from that.

Well, unless you have a reason not too, I'd say it would be a good idea to put that in your code (I don't think it's much slower, and if it offers compatibility). I've seen this thread which seems to be the same issue. I haven't checked but I do not think there is any "newer" driver than the one in the latest system update, on Apple computers... I'm not running the latest on my iMac, but I'll update when 10.8 (mountain Lion) comes out in ~3 weeks Perhaps they'll at last support openGL 3.

I'll check your code with my updated water shader... I'll see if anything works. Yeah, the mat3 thing is probably a bug in my compiler... But then it's probably widespread between all Apple computers (and as my MacBookAir seems to bug the same, I'm inclined to believe so. And the OGL driver's (and thus GLSL compilers) are Apple-made on every Apple machine, and I believe are the same.). I'll check if I can port your merged shader to ARB, but as I haven't found a way to pass "varying" variables, I have to rely on texCoord and I'm getting short of them.

@Myconid: I mean stretching the texture sampling (of the grass) in a perpendicular direction to the eyeDir... I'm not sure how to calculate that, but it could perhaps be done. BTW... I still get the normal problem with this code: vec3 normal = mat3(instancingTransform) * a_normal; #if (USE_NORMAL_MAP || USE_PARALLAX_MAP) vec4 tangent = vec4(mat3(instancingTransform) * a_tangent.xyz, a_tangent.w); And not using this code: vec3 normal = (instancingTransform * vec4(a_normal,0.0) ).rgb; #if (USE_NORMAL_MAP || USE_PARALLAX_MAP) vec4 tangent = vec4( (instancingTransform * vec4(a_tangent.xyz,0.0)).rgb, a_tangent.w); Both should work the same, but it appears "mat3" doesn't work properly on my computer. I can confirm the "bi" water sampling, but I've found it to look slightly weird as the two move at different speeds.

I got the grass effect to work, myconid... Looks really nice (though of course lighting is still not really supported). I think you could try to use less layers if you simulated rotating each grass layer to face the camera (in the fragment shader).

Probably an easier way would be to use 256x256 textures instead of the 128x128 the game is using now. The scaling issue is actually mainly visible in huge zones of open sea with little waviness in the latest version, because in this case I repeat the texture more so the waves appear smaller.

This image is mostly right (the actual images were changed, but still look a lot like this): The transition probably could be smoother. But I'm unsure they'll ever be perfect. Edit: ah, actually, there's a few more now. But still, the problem remains: the gradient could be smoother for some textures.

I'm talking about that too... By using bigger blending squares/textures, we could blend more smoothly as we'd have more space for the gradient.

Can't seem to be able to reproduce it... What map? Do you get any errors? (I assume you're using the ARB shader... I also modified the GLSL shader so both could crash).

In the current system, here's what you get (the blending texture are the size of a tile): To improve the blending between very different textures, we'd need blending texture that occupy at least 2x2 tiles. They could be placed over a tile and go beyond the size of a tile. I'm not completely sure how to do that, however.

I forgot a ";" on the line before.

Dithering is sort of what the game uses right now, though not completely. The thing is that using 64x64 texture for that, like it does now, is a bit too small for proper blending of some textures (such as sand->grass, wet->dry). The game actually uses a full square to blend a texture, using on of 16 (I think) textures.

Nah, I actually called "sundir", and I had forgot to initialize this variable, so the sun direction never changed and was completely buggy. It's fixed. I've committed an update to the waterShader branch: the size of waves is now scaling with the waviness parameter, so with low waviness you'll get an even better feeling of "little wind".

Got it, I was normalizing the EyeDir vector too soon (in the vertex program) and it resulted in the slanting. I commited the changes. I've also changed the shader slightly to use only 7 texCoord and not 8 (changes nothing for most people, I guess).

That's fairly weird... Looks like some problem with the eyedir or the move parameters. I'll see if I can reproduce. BTW, I'd recommend using this texture for the normal: it has no black pixels (the alpha channel is [1-255], as having alpha = 0 means a black pixel), so the lighting is less weird and the parallax too on the rooftiles (see Myconid screenshot for weird lighting). Edit: yeah, I'm getting the slanting too... Even when I use the loops and stuffs, so it must be somewhere in the calculations.

Could you try first loading test.pmp and then adding the temple? I get the same crash, and I'm not sure what's causing it (I also get it in GLSL, so it should come from something else).

Isn't it 7? Looking here, it appears to be, so it shouldn't crash.

Mh. Then that shader shouldn't crash. What do you have for "MAX_TEXTURE_IMAGE_UNITS_ARB"? To debug, you might try changing that line to a lower number, such as "5". It will perhaps crash, but it should crash somewhere else.

Yeah, hadn't thought of that. Let's roll differently. Go to HWDetect.cpp, and change this #define INTEGER(id) do { \ GLint i = -1; \ glGetIntegerv(GL_##id, &i); \ if (ogl_SquelchError(GL_INVALID_ENUM)) \ scriptInterface.SetProperty(settings.get(), "GL_" #id, errstr); \ else \ scriptInterface.SetProperty(settings.get(), "GL_" #id, i); \ } while (false) to this #define INTEGER(id) do { \ GLint i = -1; \ glGetIntegerv(GL_##id, &i); \ if (ogl_SquelchError(GL_INVALID_ENUM)) \ scriptInterface.SetProperty(settings.get(), "GL_" #id, errstr); \ else \ scriptInterface.SetProperty(settings.get(), "GL_" #id, i); \ std::cout << #id << ":" << i << std::endl; \ } while (false) Then when you start the game you'll have (in the console) MAX_TEXTURE_COORDS_ARB: ... (along with a lot of other info). I might be able to cram info to reduce the number of texture coords I use, but I'm afraid I won't be able to change that much.