Florian

I found two reasoning removal stones harvesting fruit.

Inspired by Schmurck's work for the missiles and the rotating torso I though we might add something similar to casting spells. When the player is not in a fighting/walking/anything animation the char could raise an arm for some spells like remote heal or poison. /EDIT: no server command is needed. The client gets the eye candy message to draw the effect and all arm movement is done in the message handler. This will also help with keeping the arm movement and the spell in sync.

Well, then we're talking about different things. I don't like the static 45/60/whatever angle. All players look exactly the same then, and that's boring. See my bag variety patch, a small change to the bag position adds a lot of variation, and that's more vivid, more real.

Of course only one angle, set before the rotation starts. But a random angle.

Maybe random_min_max(35,75) would be a solution?

NIGHT_TEXTURES and NEW_LIGHTING are unsupported for a while now. And I'm afraid they're obsolete due to the new engine. The high load on texture loading is normal, as some computations are done.

Can the intel chipset be detected by some openGL vendor string thingy? if (have_buggy_intel_driver) { new_code(); } else { old_code(); }

:icon13:

install virtualbox install windows make maps

There's no difference between the official 1.8 release and the CVS regarding Eye Candy. It does not always happen, only if particles fly right throught the effect's center, and the distance between the center and the particle is lower than the accuracy of calculation and is very very near to zero. In 32bit mode, that's 0. In 64bit mode, that's NaN. I don't have an AMD64 to test and debug it, sorry. /EDIT: does ubuntu 64bit define X86_64?

I'm afraid that's a 64bit problem. FP-math works differently when in 64bit mode. (in 32bit mode it returns 0, in 64bit mode it returns NaN) Can you provide backtraces from gdb?

my brand new gcc 4.4 complains about dds.c dds.c: In function 'unpack_dxt_interpolated_alpha': dds.c:147: warning: array subscript is above array bounds dds.c:147: warning: array subscript is above array bounds dds.c: In function 'unpack_ati1': dds.c:147: warning: array subscript is above array bounds dds.c:147: warning: array subscript is above array bounds dds.c: In function 'unpack_ati2': dds.c:147: warning: array subscript is above array bounds dds.c:147: warning: array subscript is above array bounds dds.c:147: warning: array subscript is above array bounds dds.c:147: warning: array subscript is above array bounds dds.c: In function 'unpack_dxt5': dds.c:147: warning: array subscript is above array bounds dds.c:147: warning: array subscript is above array bounds

OK

typedef struct DXTInterpolatedAlphaBlock { Uint8 m_alphas[2]; Uint8 m_indices[6]; } DXTInterpolatedAlphaBlock; block->m_indices[idx0 + 1] idx0 reaches 5, +1 makes 6 --> ArrayOutOfBoundsException

How do you like this: add a slight randomness to the bag position so it's not exactly centered on the tile.

Applied to CVS, please test if it works.

The patch is created with eclipse, maybe the format for the patch command line utility differs ... Actually I don't want to commit untested code into CVS I don't know if it compiles.

Patch to remove x,y offset ### Eclipse Workspace Patch 1.0 #P elc Index: bags.c =================================================================== RCS file: /cvsroot/elc/elc/bags.c,v retrieving revision 1.63 diff -u -r1.63 bags.c --- bags.c 4 Mar 2009 07:05:41 -0000 1.63 +++ bags.c 12 Mar 2009 17:53:46 -0000 @@ -44,8 +44,8 @@ // forward declarations void draw_pick_up_menu(); -float get_bag_offset_x(float pos_x, float pos_y, int bag_id, int map_x, int map_y); -float get_bag_offset_y(float pos_x, float pos_y, int bag_id, int map_x, int map_y); +// float get_bag_offset_x(float pos_x, float pos_y, int bag_id, int map_x, int map_y); +// float get_bag_offset_y(float pos_x, float pos_y, int bag_id, int map_x, int map_y); float get_bag_rotation(float pos_x, float pos_y, int bag_id, int map_x, int map_y); float get_bag_tilt(float pos_x, float pos_y, int bag_id, int map_x, int map_y); @@ -60,7 +60,7 @@ *out=0; } -float get_bag_offset_x(float pos_x, float pos_y, int bag_id, int map_x, int map_y) +/*float get_bag_offset_x(float pos_x, float pos_y, int bag_id, int map_x, int map_y) { char str[64]; MD5 md5; @@ -78,9 +78,9 @@ return (sinf(powf(digest[0], 2.0f)) + sinf(powf(digest[1], 2.0f)) + sinf( sqrtf(abs((float) digest[2]))) + cosf((float) digest[3]) + sinf( (float) digest[4])) / 80.0f * ((((int) abs(digest[5])) % 3 == 0) ? 1.0f : -1.0f); -} +}*/ -float get_bag_offset_y(float pos_x, float pos_y, int bag_id, int map_x, int map_y) +/*float get_bag_offset_y(float pos_x, float pos_y, int bag_id, int map_x, int map_y) { char str[64]; MD5 md5; @@ -98,7 +98,7 @@ return (cosf(powf(digest[1], 2.0f)) + cosf(powf(digest[2], 2.0f)) + cosf( sqrtf(abs((float) digest[3]))) + sinf((float) digest[4]) + cosf( (float) digest[5])) / 80.0f * ((((int) abs(digest[6])) % 3 == 0) ? 1.0f : -1.0f); -} +}*/ float get_bag_rotation(float pos_x, float pos_y, int bag_id, int map_x, int map_y) { @@ -156,8 +156,8 @@ x=(float)bag_x/2; y=(float)bag_y/2; //center the object (slightly randomized) - x = x + 0.25f + get_bag_offset_x(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); - y = y + 0.25f + get_bag_offset_y(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); + x = x + 0.25f; // + get_bag_offset_x(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); + y = y + 0.25f; // + get_bag_offset_y(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); // DEBUG // printf("bag <%i> (%f,%f) rot %f tilt %f\n", bag_id, x, y, @@ -228,8 +228,8 @@ x=(float)bag_x/2; y=(float)bag_y/2; //center the object (slightly randomized) - x = x + 0.25f + get_bag_offset_x(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); - y = y + 0.25f + get_bag_offset_y(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); + x = x + 0.25f; // + get_bag_offset_x(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); + y = y + 0.25f; // + get_bag_offset_y(bag_x, bag_y, bag_id, tile_map_size_x, tile_map_size_y); // DEBUG // printf("bag <%i> (%f,%f) rot %f tilt %f\n", bag_id, x, y, Please test it, I can't

Yes I can. That's already in the code. It's modular: all four influences on the bag are in separate functions.

Hmm, there is no direct connection from actor to bag, especially if the actor gets removed before the bag drops. (Maybe a "removed actor cache" would help ...). I could easily change the color of the bag texture slightly, I'll try that idea when I get home. What about the bag rotation? Should that stay in the code when x,y offset and tilt are removed?

Could you post some screenshots of bag positions where it looks weird? On my test system the variations are very subtle, only really noticeable when I drop lots of bags in one area. But since this is only tested on my mac, maybe on other systems something bad happens.

I'm currently on holiday, so I don't have access to some development machine ... I think it's useful. I'm a voluntary developer. I contribute stuff I think the game needs and stuff my limited programming knowledge allows me to implement. When I have an idea I look at the source code and try to find an implementation I can actually complete. Or other people, granted, mostly from the German EL community, tell me their ideas. I don't have the time and/or the motivation to tackle huge projects like finishing the emotions, porting the new gfx engine to mac, and what else "needs to be done". More variety for the bags doesn't solve that problem, but softens it. People sitting "in" a bag, in other words: no collision detection for objects, is a far more basic problem in EL. So, if there's consens in the community to remove bag variety, then remove it.

I'm trying to compile the new_engine on mac os x. So far I have not found a way to build a boost framework, so distributing the mac el client will be difficult. Is boost really needed? Does anyone of the mac hackers have an idea how to build a mac os x framework from the boost sources? /EDIT please move this thread into the programming section

Libraries aren't the point. Those are easy. Currently the Mac client comes with all needed libs as portable OSX frameworks, not as libraries which the user has to install ... Maybe statically linking boost will help.