Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

Okay. I can't verify this issue (because it doesn't crash for me), and I can't verify my theory that whoever is working on NEW_E3D broke shadows again, in the exact same way that they were broken before (because Berlios is down, so I can't check revisions). However, I see this code, part of my fix from last time, modified:

 

#ifdef NEW_E3D_FORMAT   // Always supplies a texture pointer
	glEnableClientState(GL_COLOR_ARRAY);
	glEnable(GL_TEXTURE_2D);
#else   // Doesn't always.
	glDisableClientState(GL_COLOR_ARRAY);
	glDisable(GL_TEXTURE_2D);
#endif

 

They're turning on GL_COLOR_ARRAY. Yet, I don't see any call to glColorPointer anywhere in the code. In fact, in all of EternalLands, there's only one call to glColorPointer, and that's inside an #if 0 in particles.c.

 

Even if this is not the problem, please people, let me once again remind people to be very, very careful with your client states. It's much better to do too many state changes (there's a real, but mostly trivial, performance cost) than to risk having the wrong state. The crashes resulting from having the wrong state are obscure and hard to track down.

 

Anyways, to people with shadow crashes: Do you have NEW_E3D_FORMAT enabled? If so, disable it. If this fixes your crashes, let us know. Whoever added this code, I'd recommend that they check it out. If you *don't* have NEW_E3D_FORMAT enabled, I'll take another look and see if I can figure it out.

There are probably only 4-6 people that can even run NBEW_E3D_FORMAT, so that can't be the cause in the reported crashes. Very few people have the new format files available.

Share this post


Link to post
Share on other sites

Okay, well, even still, I'm very concerned about that code.

 

I can't cvs diff because of Berlios, so this problem is made much harder than it already is by me not being able to reproduce it, which was already made harder by it not being in my code. However, I do have an older backup (April 3rd) of shadows.c to compare to. I don't know why the following changes have been made, or by whom, but here are some possibilities.

 

* Client state changes after "watch for a change" were moved inside the if statement. They were outside before.

 

* This section didn't exist in the old version:

 

	glEnableClientState(GL_VERTEX_ARRAY);
	glDisableClientState(GL_NORMAL_ARRAY);
	glDisableClientState(GL_TEXTURE_COORD_ARRAY);
#ifdef NEW_E3D_FORMAT   // Always supplies a texture pointer
	glEnableClientState(GL_COLOR_ARRAY);
	glEnable(GL_TEXTURE_2D);
#else   // Doesn't always.
	glDisableClientState(GL_COLOR_ARRAY);
	glDisable(GL_TEXTURE_2D);
#endif

 

It seems to likely have been added to try and counter moving the previous state changes inside the if statement, to reduce the number of state changes.

 

* Above there, you'll see two commented out lines, one for disabling GL_TEXTURE_2D and the other for enabling GL_TEXTURE_COORD_ARRAY. These used to be uncommented.

 

One can try rolling these particular changes back and see if that helps.

Share this post


Link to post
Share on other sites

Caveat: I have skimmed this thread from time to time, but I did not go through and search if this has been brought up already and is in the progress of being fixed. I'm not that pr0 at searching :)

 

The teleport effect appears slightly northeast of the character. I'm sorry I don't have a screenshot, apparently my Windows computer is too stupid to figure out that button on my Microsoft keyboard.

Edited by Tanyia

Share this post


Link to post
Share on other sites

I think the build was like yesterday or something. I didn't actually build it. But if the person who built it makes a new one, I'll be sure to let you know the outcome :)

Share this post


Link to post
Share on other sites

Ok here's what I see with my client(just built this morning from the cvs):

http://img.photobucket.com/albums/v59/ffle...candy_test1.jpg

(this uses the -DNEW LIGHTING thing too)

 

The shadows look way too black all over.

 

The fire has one big ball of orange and so much thick black smoke, it doens't look good like this

 

Edit: a close up example of the shadow problem:

http://img.photobucket.com/albums/v59/ffle...candy_test2.jpg

Share this post


Link to post
Share on other sites

Okay, that's really messed up looking. Everything about that screenshot is wrong. I'm going to look into it this evening.

 

Ed: Just discovered that there was an entire thread about the campfire and slowdown problems that I didn't know about. And here I was, thinking that everything was running fine because nobody was posting bugs...

Edited by KarenRei

Share this post


Link to post
Share on other sites

Newest CVS (27/4 - 07):

1>Linking...

1>elconfig.obj : error LNK2001: unresolved external symbol _min_ec_framerate

1>elconfig.obj : error LNK2001: unresolved external symbol _max_ec_framerate

 

I tried to remove/readd all and such including rebuilds but at no different result.'

 

Also bug in shadows:

I get very cube like shadows, no detail at all even with 4096x4096 shadow map... I had one moment some day ago where I was stunned at that I saw how the leaves where shaped on the shadows but that was a one time only obviously, now and all other times I get very low detail shadows. (No matter settings in options)

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

Linking: That isn't even in the code:

 

[meme@daughtersoftiresias elc]$ grep -R -i _min_ec_framerate .

grep: ./.#interface.c: No such file or directory

Binary file ./elconfig.o matches

./elconfig.c:void change_min_ec_framerate(float * var, float * value)

./elconfig.c: add_var(FLOAT,"min_ec_framerate","ecminf",&min_ec_framerate,change_min_ec_framerate,0,"Min eye candy framerate","If your framerate is below this amount, eye candy will use minimum detail.",LODTAB,0.0,FLT_MAX,1.0);

grep: ./.#keys.c: No such file or directory

 

The only instances of it are in change_min_ec_framerate (i.e., they're prefixed with "change")

 

Where are you finding that?

 

Shadows: Are you sure your shadow map really is at 4096x4096? Have you pulled up your preferences in-game and verified?

 

Also, there was a shadow map crash reported a while back -- I wonder if people's recent shadow problems are related to that. I posted some changes that people could try to make, but never got any feedback.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Linking: Well so what am I suppose to do? I update CVS, compile as usual, get linking errors... Try what solved unresolved link problems before: remove->add. But not working.

 

Finding where? What?

\elconfig.c(107):void change_min_ec_framerate(float * var, float * value)

\elconfig.c(1210): add_var(FLOAT,"min_ec_framerate","ecminf",&min_ec_framerate,change_min_ec_framerate,0,"Min eye candy framerate","If your framerate is below this amount, eye candy will use minimum detail.",LODTAB,0.0,FLT_MAX,1.0);

 

Shadows: Yes... of course... as I said I tried every option available and changed to different shadow maps with no changes at all, except for very choppy shadow at lowest sizes... otherwise higher sizes just mean sharper edges on the "cube shadows"... as I said I have only had 1 proper shadow time that I have seen, and that is with same client that also got choppy shadows some hour later or so. And now I get choppy aswell so something isn't applying the correct shadow map size or something.

Share this post


Link to post
Share on other sites

Linking: Your linker is complaining about this: _min_ec_framerate

 

It doesn't exist in the code, as far as I can tell. Can you find it in yours?

 

Shadows: Well, I'll look into it this weekend. EL's shadows are a pain, and it's annoying that I have to be the one to take the mantle for them because nobody else wants to work on that code.

Share this post


Link to post
Share on other sites

Linking: Ooh oki, your right, nope I cannot find that anywhere in the code., but what is there to try then? How come something changed over a CVS update if it's not a code issue? Thats weird=/

 

Shadows: Yes, sorry to bring more work onto your shoulders but well I would help with the code if I were more "into" coding and had more of a clue on how the ELC works. But as I said many times, your doing a good job. I am too abit stunned over that no one else seems to be coding or trying to help you on all these kind of stuff you get reports about.

 

Update:

Commenting this:

//add_var(FLOAT,"min_ec_framerate","ecminf",&min_ec_framerate,change_min_ec_framerate,0,"Min eye candy framerate","If your framerate is below this amount, eye candy will use minimum detail.",LODTAB,0.0,FLT_MAX,1.0);

// add_var(FLOAT,"max_ec_framerate","ecmaxf",&max_ec_framerate,change_max_ec_framerate,0,"Max eye candy framerate","If your framerate is above this amount, eye candy will use maximum detail.",LODTAB,1.0,FLT_MAX,1.0);

 

And this:

#ifdef EYE_CANDY

void change_min_ec_framerate(float * var, float * value)

{

if(*value >= 0) {

if (*value < max_ec_framerate) {

*var = *value;

} else if (!max_ec_framerate) {

*var = *value;

} else {

*var = max_ec_framerate - 1;

}

} else {

*var= 0;

}

ec_set_draw_detail();

}

 

void change_max_ec_framerate(float * var, float * value)

{

if(*value >= 1) {

if (*value > min_ec_framerate) {

*var = *value;

} else if (!min_ec_framerate) {

*var = *value;

} else {

*var = min_ec_framerate + 1;

}

} else {

*var= 1;

}

ec_set_draw_detail();

}

#endif //EYE_CANDY

 

I got no error, so there's something in here that my compilers linker doesn't like.

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

Small question on the teleport effect:

why is there one teleport effect coming down where you get teleported away from?

 

I think there should be two effects:

- one going upwards at the old position

- one coming down at the new position

 

Flo

Share this post


Link to post
Share on other sites

I agree, too.

Bug entropy :omg: I can't mess with the server.

 

What I really want is a small delay between when a spell gets cast and when its effect occurs. For example, picture teleport to range. I have this great effect coded where you get a teleport beam where you are, you disappear into little orbs of light, they fly to their destination, and you get a new beam of light as you reappear. However, without a delay and without the extra server info, that just won't work.

 

These sorts of things don't just effect teleporting. Do a remote heal. They get health before the spell hits them :omg:

 

Beaverhunter:

 

My best bet is that your compiler is tacking a _ onto the variable name for some strange reason. Hmm. Idea: in eye_candy_wrapper.cpp, you'll find find where min_ec_framerate and max_ec_framerate are defined (line ~50). Move them up into the extern "C" section (line ~20). See if that works.

 

 

Oh, and forgot to mention: some fire fixes are in, and I'm working on shadows. It's really tempting to just implement shadow volumes and be done with it. No penumbras, or anything -- just basic stencil buffer shadow volumes to at least catch up to the tech level of ~Quake II or so. However, Learner would call it a new feature, refuse to allow it in, and then we'd still be stuck with our current broken shadows. :D So, I'm stuck trying to fix something that needs to go away anyways. Conventional shadow maps are obsolete tech with tons of weaknesses.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Aah, that did the trick! Very good idea=) Moving

float min_ec_framerate = 13.0;

float max_ec_framerate = 37.0;

Into extern "C" worked. No error no more.

 

Yep, shadow needs a new system, it's quite futile to even work on improving the current system. But yes, we want to release a RC within 1 week now so would be a new feature to add new shadows yes=P At least Learner would say so.

 

Update:

I just compiled without NEW_WEATHER and NEW_LIGHTING and I can confirm that my darkness problem seems to be gone. I just logged out with the CVS with those features included, it was very dark in PL cave, Now I just logged in without these features and PL Cave is lit, even if it's very unaturally/flat lighting.

Does the NEW_LIGHTING rely on map light sources? If so we need someone to check in all caves and narrow spaces so map makers can get reports on adding light sources, because having darkness even at daytime is not more natural than having flat lighting.

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

I'll commit the moved variables. Thanks for trying that out.

 

Darkness: Can you give me a screenshot? Thanks :) I don't get it, but that doesn't necessarily mean that I can't debug it ;)

Share this post


Link to post
Share on other sites

No problem=)

 

Darkness:

eternallands0225bx3.th.jpg

 

Let's play spot the Beaverhunter... If it wasn't for the HP bar and Name... you would go crazy.

Note that I just beamed from SRM, walked to WS docks and took boat to PL then through PL to PL cave where it was complete daylight, outside... pitch black inside!=/

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

Ah, that's just what I needed ;) Yes, that's due to there being no lights in that cave. Yes, I still have options, and will work on them once I get shadows done. :)

Share this post


Link to post
Share on other sites

Beaverhunter, quick question: Do you run with the Shadow Mapping flag? set or not? Obviously, you run with the Shadows flag set. This is related to my shadow bug fixes, not NEW_LIGHTING.

Share this post


Link to post
Share on other sites

Huh? Yes of course I run with all possible options on that somewhat is suppose to enhance the visual experience, with exclusion of Render fog cause it's totally bugged due to me:P Cause you barely have any field of vision.

 

I just tried on Test server inside PL cave with NEW_LIGHTING and NEW_WEATHER on, and disabling or enabling all options did barely make any difference at all, if any.

 

Everything the same but without NEW_LIGHTING and NEW_WEATHER inside PL cave, right now with all shadow options and alike enabled I get no darkness, all is clear and visible.

Share this post


Link to post
Share on other sites

Dont know if it was posted or not, but problem still exists:

when we cannot draw teleporters at max LOD and it begins to change we change

number of cylinders. But as fps changes almost every frame number of cylinders also changes

every frame and portal beams begin awfully flicker.

 

We might use instead of instant LOD average LOD of last few seconds, at least

for number of cylinders.

 

PS

Fire now looks great :lurker:

As for fountains, maybe water should be more blue?

Edited by Alia

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×