Grum

Very sad news, indeed. Hatwood was a wonderful person, who, despite challenges in her own life, never failed to make my day brighter whenever we talked.

I also am very saddened by this news. I have worked with and talked to Learner on and off over the years. He was not only an excellent programmer and system administrator, but also a very likeable person with a wry sense of humour that I appreciated very much. This news came as a very unwelcome shock. Rest in peace, Learner. We will miss you.

Thanks. As it seems that the water is working fine, one way I can think of fixing this is by writing a shader for the entire scene. Which is something we want to do anyway, at some point, but it will be a lot of work and I was kind of putting it off. One other question, you mention zooming makes a difference. Does the vertical camera angle also make a difference? Like when you rotate the camera down to a horizontal level, or even below (if that possible)?

The new water shader only works on water anyway. But I am curious if the water outside is also black, using the old water shader.

Thanks, I missed that. You're right, that is very odd. I will have to check what the global light is doing. It's worse, it's actively turning off lighting somehow. Even in the absence of any lights, there is a default implicit ambient light value of 0.2, which the client never turns off. If that were applied, the scene would be quite dark, but not pitch black as it seems to be here. Yes, that puzzles... wait. @bkc65, can you try tu turn off shadows and see if that has an effect?

I see more lighting issues cropping up, of late I have a sneaking suspicion more and more drivers are dropping support for classic OpenGL. Not saying that is the case here per se, but it's a possibility. What does #glinfo report?

Try ./el.linux.bin lrnr-main to connect to the game through learner's proxy. (Disclaimer: on phone, no access to game data. Check servers.lst in your game data directory if lrnr-main is correct)

Or your ISP has started blocking port 2000. It would not be the first one to do so. Please try the telnet command bluap posted, it will tell us whether you can make a connection to the server at all. If you cannot, you can try to connect through learner's proxy.

Raz reminded me of this. These two are harmless, I don't have these extensions either, and as far as I can see, the client (nowadays?) never uses them, only s3tc compression.

Thanks, this is useful. Two things jump out: I am going to try and track down what might cause these.

I have already solved three problems with the water reflections, but yours presents an entirely new one Given that you do not see any reflection at all, I suspect the reflection texture is not generated for some reason. If you're interested in helping us debug this, I have uploaded a debug build of the client here. This should generate a more extensive log file. Could you do a short run with this executable (just place it in your EL data directory and run it), and send me the log file afterwards? Just upload it somewhere, or contact me for an email address. Also, can you send me the output of #glinfo? Thanks!

Looks like there are no reflections at all, which is a new issue for me. I'm sorry if you already mentioned this, but do you have reflections when water shader quality is set to 1?

While that is true, OP has indicated they were the only player there. Besides, any dead actor that is on an adjacent tile in the view direction of the player should be counted. So kills can be counted for multiple players, but should not be missed. Unless the player character has moved away or turned before the damage update for the killed character arrives from the server.

This fix is incomplete, as (at least on my system) it renders the wrong side of the reflected objects. Although it looks more or less right, due to the waves on the water, what you are seeing is actually the inside of the reflected objects. This is also the reason you don't see the sky reflected in the water. Also, making this change unconditionally will break the water display for systems that currently display the reflection correctly. I am working on finding a proper solution, I already have away to detect if the reflection texture is upside down. In the mean time, if you really want to try what I did: in your EL data folder, there should be a folder named "shaders", which contains a file named "reflectiv_water_fs.glsl". Open this file in a text editor, and add a line reflection_tex_coord = vec2(reflection_tex_coord.x, 1.0 - reflection_tex_coord.y); right before the line that reads #ifdef USE_CUBIC_FILTER If you do so, please let me know here if that works for you. In particular, if it does show some reflection, I would be interested to know if you also see the inside of the reflected object (best seen with water shader quality set to 1 in the settings window).. It is possible you have to remove this change once a proper fix is in the client, though.

Looks like the vertical coordinate of the reflection is flipped on my Windows installation somehow. Patching the reflective water shader to flip the y coordinate: --- reflectiv_water_fs.glsl.orig 2022-01-02 12:17:14.316457200 +0100 +++ reflectiv_water_fs.glsl 2022-01-02 12:05:26.031011000 +0100 @@ -47,6 +47,7 @@ reflection_tex_coord += noise_diplacment * noise_scale.xy; tile_tex_coord += noise_diplacment * noise_scale.zw; #endif // USE_NOISE + reflection_tex_coord = vec2(reflection_tex_coord.x, 1.0 - reflection_tex_coord.y); #ifdef USE_CUBIC_FILTER vec2 coord_hg = reflection_tex_coord * size - vec2(0.5, 0.5); fixes the water reflection for me. Of course, the same change messes up the display in my Linux, so we either need to detect when to do something like this, or fix the root cause of this problem. Also, my actor textures seem messed up somehow. Perhaps a similar problem?

I have an integrated Intel 530 HD graphics chipset. I see no problems in Linux, but running on Windows in virtualbox on the same machine shows some other interesting issues: This is with the water shader quality set to 1. With the level at 2 I get some extra striping. Well, at least I have something I can reproduce. I'll see if I can do anything fix this.

Good find! I wonder though, if saving a single byte is worth the extra code complexity, and if we shouldn't just send two bytes always. Oh well.

Good to hear! the exp updates are unaffected, this is only for the damage numbers. EDIT: You are correct The damage numbers are drawn at z=0, so on top of everything else. So while checking the depth buffer should be superfluous, it should not change the behaviour of the game.

That actually gave me an idea. For the bouncing damage numbers, the depth test function is set to GL_ALWAYS, so that they are always visible. For names and health bar texts, the test function is GL_LESS, so that they can be obscured by objects in the world. Allowing the damage updates to be obscured as well: diff --git a/actors.c b/actors.c index 26f6e574..32842fb5 100755 --- a/actors.c +++ b/actors.c @@ -533,7 +533,8 @@ void draw_actor_banner(actor * actor_id, float offset_z) glColor3f (1.0f, 0.0f, 0.0f); - glDepthFunc(GL_ALWAYS); +// glDepthFunc(GL_ALWAYS); + glDepthFunc(GL_LESS); if(actor_id->damage_ms){ if(floatingmessages_enabled){ float a=(float)(cur_time-actor_id->last_health_loss)/2000.0f; @@ -594,7 +595,7 @@ void draw_actor_banner(actor * actor_id, float offset_z) } } - glDepthFunc(GL_LESS); +// glDepthFunc(GL_LESS); //figure out which lines should we display display_health_line = (actor_id->kind_of_actor != NPC && (display_hp || display_health_bar) && actor_id->cur_health > 0 && actor_id->max_health > 0); seems to resolve the crashes for me. Why? No idea, but it seems to work. The disadvantage is of course that damage updates can now be obscured by world objects or other text in front of them.

Thanks, you are right. That observation allowed me to zoom in a little further on the problem, unfortunately still without a full solution. New observations: The crash only seems to occur when we draw multiple strings in a banner, e.g. health or exp updates as well as the character name. Strangely, though, it seems that player name and stats next to the bars can coexist? There does not need to be fighting for the crash to occur, it can also happen when e.g. you simply heal a point with a positive food level. When I disable alpha testing in draw_ortho_ingame_string(), the game no longer crashes. But then the text has a solid black background. I have tried saving and restoring the current alpha test function in draw_ortho_ingame_string(), but that does not help. I hate state machines in general, and the OpenGL one in particular

Not making any progress on the crash. Some more data points: you don't need to be the one fighting, the crash can happen with another player fighting in your view. draw_actor_banner() is called from draw_actor_banner_new(), both of which push the modelview matrix. I had hoped that by removing one push the situation would improve, but no such luck. drawing with a constant z value of 0.0 does not help printing the arguments to draw_ortho_ingame_string() shows nothing our of the ordinary Copying the actor name to a temporary before drawing does not help (why would it? I dunno, at this point I would be tearing my hair out if that were feasible). EDIT: interestingly, drawactor_floatingmessages() which does something very similar to the banner name/stats drawing code, seems to cause no issues.

Beats me. The only thing I can think of is that an actor animation command somehow subtly messes up the OpenGL state, which is exposed when drawing the banner. No idea which one, randomly commenting out stuff does not help :/ Either that or a bug in gl4es. Speaking of which, the fact that there's exactly one version of gl4es that works is somewhat troubling in itself. I've been trying to bisect, but as Nogrod noticed, that's near impossible since the bisection points refer to the main branch which is missing all the Android stuff. Perhaps we should at some point merge the Android branch back into main, so this can be prevented for future bugs. Does not help us now though Edit: we should resolve this soon. My wife wants her phone back

This is one aggravating bug. As far as I can tell: The crash only occurs when we draw banner text Replacing quads with triangles in draw_ortho_ingame_string() does not help Turning off texturing and just drawing filled rectangles does not help The crash is triggered most easily when the name is drawn. But the health/mana texts will cause a crash as well, though less frequent. bluap quite reasonably suggested that the pointer to the string might be invalidated if the character dies. But the actor is not removed (immediately) when it dies. Just to be sure I merged my actors_list_lock branch which should prevent unlocked access to the actors, and I still get crashes. I'm starting to run out of ideas. Perhaps the matrix stack overflows? But then I don't understand why drawing the health bars does not seem to result in errors. EDIT: BTW, the GL_INVALID_ENUM error is caused by the GL_TEXTURE_MAX_ANISOTROPY_EXT parameter in textures.c. Removing the corresponding call to glTexParameterf() does not prevent the crash, however. EDIT 2: replacing the string to draw with a constant string "blob" in draw_ortho_ingame_string() still causes the crash, so I think we can rule out that the crash is due to an invalid string pointer.

Just leaving this out here in case someone else wants to look further, because I have to stop now: The crash seems to be related to Font::draw_ortho_ingame_string(), responsible for drawing the actor names and other banner text. It looks as if trying to draw even a single quad in there will cause a crash at some point, though I have no clue why that would be, or why the crash only seems to occur during or after a fight.

Huh. I can trigger the error messages (protocol error, resource deadlock) and crash without even rendering the actors (immediate return in cal_render_actor()), catching invisible rabbits or beavers on IP. So the problem is probably not due to weird triangles on the actor models. Digging further, though I'm not sure how much more I can disable before I am no longer able to fight at all.