Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

A repeatable crash with latest CVS! Start the client, cast a remote heal spell, client crashes. I was casting on myself; only problem is you need to loose some health points so the spell works. I was at beam on IP but it works anywhere. This may be related to my other crash as that was just after remote heal spell. There was no output from the client debug. Here's the gdb information:

Program terminated with signal 11, Segmentation fault.
#0  0x080ed52e in ec_get_z (_actor=0x6) at eye_candy_wrapper.cpp:68
68		return -2.2f+height_map[_actor->tmp.y_tile_pos*tile_map_size_x*6+_actor->tmp.x_tile_pos]*0.2f;
(gdb) bt
#0  0x080ed52e in ec_get_z (_actor=0x6) at eye_candy_wrapper.cpp:68
#1  0x080f7cfc in ec_create_targetmagic_remote_heal2 (caster=0xe70b540, target=0x6, LOD=10)
at eye_candy_wrapper.cpp:1832
#2  0x080eb987 in parse_special_effect (sfx=SPECIAL_EFFECT_REMOTE_HEAL, data=0xe94d3b4) at special_effects.c:650
#3  0x080a78b7 in process_message_from_server (in_data=0xe94d3b0 "O\006", data_length=8) at multiplayer.c:1785
#4  0x0809e56a in start_rendering () at main.c:110
#5  0x0809e847 in main (argc=3, argv=0xbfbc6414) at main.c:235
Current language:  auto; currently c++
(gdb) list
63		  eye_candy.set_thresholds(15000, 10);
64	  }
65
66	  float ec_get_z(actor* _actor)
67	  {
68		return -2.2f+height_map[_actor->tmp.y_tile_pos*tile_map_size_x*6+_actor->tmp.x_tile_pos]*0.2f;
69	  }
70
71	  void set_vec3_actor_bone(ec::Vec3& position, actor* _actor, int bone, const ec::Vec3 shift)
72	  {
(gdb) up
#1  0x080f7cfc in ec_create_targetmagic_remote_heal2 (caster=0xe70b540, target=0x6, LOD=10)
at eye_candy_wrapper.cpp:1832
1832	  ret->position2 = ec::Vec3(target->x_pos, ec_get_z(target), -target->y_pos);
(gdb) up
#2  0x080eb987 in parse_special_effect (sfx=SPECIAL_EFFECT_REMOTE_HEAL, data=0xe94d3b4) at special_effects.c:650
650									 ec_create_targetmagic_remote_heal2(caster, target, (poor_man ? 6 : 10));
Current language:  auto; currently c
(gdb) print caster
$1 = (actor *) 0xe70b540
(gdb) print target
$2 = (actor *) 0x6

I was casting the spell on myself so shouldn't target and caster be the same?

Share this post


Link to post
Share on other sites

Bloodsucker: I'd seen that once before. Let me add that getting the sword effects on the right thing has been a royal pain because the actor bones are unreliable. On that actor, it's apparently decided bones 26 and 27 are on the opposite side from where they are on my actor. I really don't know if there's a decent way to solve this, but I can look.

 

Bluap: Blah, the server is giving unexpected info. Grr, grr, grr! Remember that, as my test char is a n00b, I have no way to test things like spells before I commit. Sometimes, I just idle at sto waiting for someone to cast a spell, or at a resource people are clustered around, waiting for a harvest effect :D Hence, unfortunately, you're all guinea pigs.

 

"Target" is simply wrong there; that's not a valid actor. Target comes from:

 

  if (var_b)
 {
target = get_actor_ptr_from_id(var_b);
if (target == NULL)
  return;
 }

 

var_b comes straight from the server. Hmm, actually... I think the interpretation of the server packet is incorrect.

 

 case SPECIAL_EFFECT_POISON:
 case SPECIAL_EFFECT_REMOTE_HEAL:
 case SPECIAL_EFFECT_HARM:
 case SPECIAL_EFFECT_MANA_DRAIN:
{
  var_a = SDL_SwapLE16 (*((Uint16 *)(&data[offset])));
  var_b = SDL_SwapLE16 (*((Uint16 *)(&data[offset+1])));

 

Shouldn't that be "+sizeof(Uint16)" instead of "+1"? Want to try that out? This was code that I inherited, but I don't think it was being used before, so it was probably never tested. If it fixes it, let me know and I'll commit it.

 

Thanks!

Edited by KarenRei

Share this post


Link to post
Share on other sites

Shouldn't that be "+sizeof(Uint16)" instead of "+1"? Want to try that out? This was code that I inherited, but I don't think it was being used before, so it was probably never tested. If it fixes it, let me know and I'll commit it.

Thanks!

Well data is of type Uint16 * so +1 should be fine. I tried it anyway and it still crashes. As this spell works fine normally, may be its something to do with the fact that the client has just loaded. The changing map crash could be very similar.

Share this post


Link to post
Share on other sites
Windows fixes, shrinking of the heal spell, and making spells follow you in. Let me know if they work.

Yup, heal spell now follows actor. I think it needs to be more subtile still since it is about as dramatic as the restoration spell. Also, restoration and heal seem to be slightly offset from the center of the actor, such that the effect sits a little out in space (specifically a bit off to my right side). Anyone else see this? Shield too, but I have not tested other spells.

Share this post


Link to post
Share on other sites

Octane: About the offsets: when did you update? Offset spells have been a pain in my side for a good while. Actors aren't centered where their x_pos/y_pos is. I checked some fixes in late last night that looked good from the angle I was at, but I can't say they're perfect yet.

 

Tonight, I'll scale down the heal spell more. I'm doing this incrementally, so we'll just keep going until you think it looks good. Sorry that I can't test these myself.

 

Bluap: Blah, you're right -- I was thinking data was a Uint8. :) Well, either way, the key problem is that the target that the effect is being supplied with is messed up, so some debugging statements should be able to tease out why.

Edited by KarenRei

Share this post


Link to post
Share on other sites

OK, looks like eye candy is off the hook for my crashes :) I believe I have the solution. I ran the code though valgrind which spotted a problem with counters_set_spell_name() in counters.c; the name of the spell retrieved from the server is not null terminated and the code was using a strcpy(). This was randomly corrupting memory which just happened to take out eye candy. Sounds plausible anyway. There's how counters_set_spell_name() looks now with the old strcpy commented out:

void counters_set_spell_name(int spell_id, char *name, int len)
{
if (!spell_names[spell_id+1]) {
	int i, j;

	spell_names[spell_id+1] = malloc(len+1);
	//strcpy(spell_names[spell_id + 1], name);
	safe_strncpy(spell_names[spell_id + 1], name, len+1);

	i = SPELLS - 1;

	for (j = 0; j < entries[i]; j++) {
		if (!counters[i][j].name && counters[i][j].extra == spell_id) {
			counters[i][j].name = strdup(spell_names[spell_id+1]);
			break;
		}
	}
}
}

With this change in place, the client does not crash. May be someone could check this is ok and commit this change please :)

 

However, I have some new valgrind eye candy messages for you to look at. These still occur with the fixed counters.c:

TargetMagicEffect (0x51b83c0, 0) created(1).
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810B68B: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:884)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810B848: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:895)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810862B: ec::BoxObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:488)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810874D: ec::BoxObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:516)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810875C: ec::BoxObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:516)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810876B: ec::BoxObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:516)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810877C: ec::BoxObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:516)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x8107DEF: ec::SimpleCylinderObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:426)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810B9DB: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:922)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810878D: ec::BoxObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:516)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810879E: ec::BoxObstruction::get_force_gradient(ec::Particle&) (eye_candy.cpp:516)
==10828==	by 0x810B025: ec::GradientMover::get_obstruction_gradient(ec::Particle&) const (eye_candy.cpp:839)
==10828==	by 0x810B994: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:914)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810B9DD: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:922)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)
==10828== 
==10828== Conditional jump or move depends on uninitialised value(s)
==10828==	at 0x810B862: ec::GravityMover::move(ec::Particle&, unsigned long long) (eye_candy.cpp:905)
==10828==	by 0x81139C0: ec::EyeCandy::idle() (eye_candy.cpp:1649)
==10828==	by 0x80EE20A: ec_idle (eye_candy_wrapper.cpp:195)
==10828==	by 0x80872B3: display_game_handler (gamewin.c:679)
==10828==	by 0x807CF0E: draw_window (elwindows.c:1059)
==10828==	by 0x807D44D: display_window (elwindows.c:1207)
==10828==	by 0x807A92D: display_windows (elwindows.c:57)
==10828==	by 0x80749D4: draw_scene (draw_scene.c:98)
==10828==	by 0x809E5DB: start_rendering (main.c:123)
==10828==	by 0x809E84E: main (main.c:235)

Share this post


Link to post
Share on other sites

Yeay bluap!

 

*whistles another one bites the dust*

 

One more bug down :)

 

I'll take a look at those uninitialized values this evening.

 

P.S. -- I wonder how I missed changing that strcpy over to a safe_strncpy? Oh well -- at least that reinforces the importance of not trusting C-strings further than you can throw them!

Edited by KarenRei

Share this post


Link to post
Share on other sites

When my FPS is dropping really badly in storages to <10 FPS the special effects get killed in the command window, but they are still on screen and stick there. The only way to fix it is to go in console and go back out. Just to let you know, I can't add more info to it.

Share this post


Link to post
Share on other sites

That'd be because special effects and eye candy are different. I could do the same with eye candy, but first, I'd like to fix the effects so they don't drop you that low. It already lowers level of detail, but in some cases, that doesn't seem to be enough -- and I ought to figure out why.

Share this post


Link to post
Share on other sites

Commit in.

 

* DEBUG_POINT_PARTICLES added in. To anyone for whom point particles looked odd: please build with this option. It'll turn all campfires into a simple single-particle system (including F9 fires) and print output. Post that output for me and it may help me figure out what the heck is going on with some peoples' systems.

* Made smoke effect use less particles to try and help people who've been having low framerates

* Made having a low framerate disable eye candy

Share this post


Link to post
Share on other sites

It appears that any events that occurred while the client is in console mode are stacked up and played all at once when you toggle out of console mode. Would it be possible to simply ignore the effects if they occur while the client is in console mode?

Share this post


Link to post
Share on other sites

It appears that any events that occurred while the client is in console mode are stacked up and played all at once when you toggle out of console mode. Would it be possible to simply ignore the effects if they occur while the client is in console mode?

The proper thing to do is to start the special effect and pretend it is being done, and as effects wear off while in console, they should be removed. Just, no drawing od special effects is done in console, but everything else should be done. Otherwise you get a lot of different problems as people switchin in and out of console or the Tab Map.

Share this post


Link to post
Share on other sites

Jamincolins: Can you give me examples of specific effects for which this happens? This isn't something that I hard-coded, so it must be something relative to the code in which the calling functions are located,

Share this post


Link to post
Share on other sites

Commit in.

 

* Centering fix -- including sword centering. I think I've got it this time; the reason my previous fixes were inconsistent was due to character rotation and the fact that I was centering on a bone instead of the overall position. Only certain effects should be centered on the hand bone. My offsets to fix the inaccurate effect positioning would vary depend on where the hand was.

 

 

After updating, can people give me a list of bugs that they feel are still open? Thanks!

Share this post


Link to post
Share on other sites

Oh, one more thing: Check out -DNEW_LIGHTING. Remember the discussion a while back that determined that normals were simply broken for some objects (they weren't set in the e3d file), and my observations that with more diffuse lighting, things would look a lot less flat, esp. in evening and morning when there's a big difference between the areas in shadow and light? I've checked in a fix for both of these -- enable -DNEW_LIGHTING and try it out. A late evening comparison (nightfall coming shortly, so the world should be falling into shadow):

 

Old lighting:

 

http://www.daughtersoftiresias.org/progs/e...ts/old_boat.jpg

http://www.daughtersoftiresias.org/progs/e.../old_garden.jpg

http://www.daughtersoftiresias.org/progs/e...s/old_wagon.jpg

 

New lighting:

 

http://www.daughtersoftiresias.org/progs/e...ts/new_boat.jpg

http://www.daughtersoftiresias.org/progs/e.../new_garden.jpg

http://www.daughtersoftiresias.org/progs/e...s/new_wagon.jpg

 

A demonstration of what morning/evening shadows look like in the real world, for comparison:

 

http://www.pipmcgarry.com/gallery/EveningGold.jpg

 

As this was already a reported bug, I considered this a bugfix (the code changes are pretty short and straightforward). What do others think?

Edited by KarenRei

Share this post


Link to post
Share on other sites

Oh, one more thing: Check out -DNEW_LIGHTING. Remember the discussion a while back that determined that normals were simply broken for some objects (they weren't set in the e3d file), and my observations that with more diffuse lighting, things would look a lot less flat, esp. in evening and morning when there's a big difference between the areas in shadow and light? I've checked in a fix for both of these -- enable -DNEW_LIGHTING and try it out. An evening comparison:

 

Old lighting:

 

http://www.daughtersoftiresias.org/progs/e...ts/old_boat.jpg

http://www.daughtersoftiresias.org/progs/e.../old_garden.jpg

http://www.daughtersoftiresias.org/progs/e...s/old_wagon.jpg

 

New lighting:

 

http://www.daughtersoftiresias.org/progs/e...ts/new_boat.jpg

http://www.daughtersoftiresias.org/progs/e.../new_garden.jpg

http://www.daughtersoftiresias.org/progs/e...s/new_wagon.jpg

 

A world of difference, isn't it? As this was already a reported bug, I considered this a bugfix (the code changes are pretty short and straightforward)

-DNEW_LIGHTING will NOT be in the next client because as far as I'm concerned it is a new feature and the original checkin broke other things, like being underground. This is enough of a change of how everything looks that it can't be included! You need to be VERY conservative on what is considered a bug or we will NEVER get the next client released!

 

Please dont check in anything else right now that can change the general looks of anything, specially without out requiring a #ifdef!!

Share this post


Link to post
Share on other sites

I did put an ifdef around the normal-correcting code. I realized that I forgot one around the lighting, but then when I went to add it in (shortly before I posted), found that someone (assumedly you?) had already fixed it.

 

What's broken underground? I'm running with it right now, and underground looks good.

 

http://www.daughtersoftiresias.org/progs/e...ts/old_cave.jpg

http://www.daughtersoftiresias.org/progs/e...ts/new_cave.jpg

 

(the one that's a little redder is due to a special effect going off)

 

Did you compare the images? For example, the boat?

How do you consider fixing *broken* object normals to be a new feature? That boat, for example, had *broken* normals.

Edited by KarenRei

Share this post


Link to post
Share on other sites

eh, earlier I thought that the changes made the shadows look jagged and odd... but I guess that's just because you made them so much darker that it stands out... I don't particularly like it, especially when you see the jaggies moving

Share this post


Link to post
Share on other sites

That's really a bug with the shadows, persay -- but yes, fixing the shadow jaggies bug would probably be too big to do during a freeze. These were little changes.

 

Could we split up the ambient changes from the normal changes so that at least broken normals get fixed?

Edited by KarenRei

Share this post


Link to post
Share on other sites

That's really a bug with the shadows, persay -- but yes, fixing the shadow jaggies bug would probably be too big to do during a freeze. These were little changes.

 

Could we split up the ambient changes from the normal changes so that at least broken normals get fixed?

No, because anything that is trying to affect the looks of the game MUST include Enteopy & Roja and needs to be considered a new feature!

Share this post


Link to post
Share on other sites
No, because anything that is trying to affect the looks of the game MUST include Enteopy & Roja and needs to be considered a new feature!

 

Roja *has* been fixing them whenever she comes into them:

 

Some of the old objects didn't have their normals exported correctly when I used an old exporter. I have been reexporting those objs whenever I find them, thus correcting their problem.

 

I simply corrected them all in one fell swoop with a small amount of code. Also, I'm not sure why you grouped together an ambient/diffuse change with a fix of normals. They're separate fixes.

 

Care to point out what underground breakage you were referring to?

Edited by KarenRei

Share this post


Link to post
Share on other sites
No, because anything that is trying to affect the looks of the game MUST include Enteopy & Roja and needs to be considered a new feature!

 

Roja *has* been fixing them whenever she comes into them:

 

Some of the old objects didn't have their normals exported correctly when I used an old exporter. I have been reexporting those objs whenever I find them, thus correcting their problem.

 

I simply corrected them all in one fell swoop with a small amount of code. Also, I'm not sure why you grouped together an ambient/diffuse change with a fix of normals. They're separate fixes.

Graphics and how they look is her realm though, not yours! At this time you can't just decide to make a whole sale change! That is why there is a feature freeze in place as well!

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.

×