Kindar_Naar

I believe this happens becuase MSVC does not support C99 extensions, so no uint_fast32_t and stdint.h is present. For my version to build I had to: 1. #define uint_fast32_t unsigned int in load_gl_extensions.h 2. remove the include to stdint.h in load_gl_extensions.c 3. added include to <windows.h> in load_gl_extensions.h Generally these actions should be done within #ifdef _MSC_VER not to cause problems for other users System: WindowsXP IDE: MS VC++ 2005 Express

Here are my defines: ELC WINDOWS NEW_FRUSTUM BUG_FIX_3D_OBJECTS_MIN_MAX NEW_TEX ATI_9200_FIX NEW_ACTOR_ANIMATION AUTO_UPDATE OPTIONS_I18N PNG_SCREENSHOT NOTEPAD ANTI_ALIAS COUNTERS AFK_FIX CUSTOM_LOOK CUSTOM_UPDATE USE_INLINE FONTS_FIX SIMPLE_LOD ZLIB FUZZY_PATHS SFX MASKING ACTOR_ALPHA NEW_ALPHA EYE_CANDY __SSE__ NEW_LIGHTING and libs: shell32.lib libxml2.lib vorbisfile.lib user32.lib SDL_net.lib kernel32.lib glu32.lib opengl32.lib SDL.lib ALut.lib OpenAL32.lib iconv.lib Cal3d.lib libpng13.lib zdll.lib SDL_image.lib Both from release. I can click on 'enable music' and the client doesn't crash.. but don't have the music either...

Hi ttlanhil, Here is the offending isalpha: filters.c, line 334. After conversion to (unsigned char) as you suggested the client loaded without assert.

The frame drop is normal (3 FPS on IP beam for me). It's beacause you have Cal3d in debug. I think NEW_SOUND is very experimental. I don't use it.

You should have the call stack window at the bottom right of Visual Studion when the assert hit. From there you should see the last ELC function that has been called before assert. Ok, I'm almost sure I know what is going on. I had the same problem. You need to build your Cal3d library with the same settings as your client. Moreover, you need to have two libraries: one debug and one release. You need to link a debug version of library to debug client and release version of library to release client At least that's what I remember from my fights with building EL client As I remember it had something to do with heaps from different runtimes, the client using a debug and library using a release, but I never fully understood it. ED: Oh, and you should get the same problems with vorbis I think

I didn't get the vector error and just logged in into test server with debug build. Try doing a 'clean' on the whole solution and deleting any intermediate files, the rebulding. Maybe it will help

Great find. That's exaclty what has been happening. I build the current DEBUG version and also got an assertion. The assertion was in function isalpha in filter.c I think the problem is that there have been recent changes to the types. The types were UInt8 before and are char now. UInt8 was unsigned and seems that char is signed by default in VC. The /J switch got the job done, but I don't know if this change didn't affect anything more. I think you should post this problem into this thread

I think that with Visual C++ 2005 the way that C/C++ runtimes (msvcr80d.dll, msvcp80d.dll <- debug runtime) are handled changed to more .NET like and you just can't put them into the folder. They need to be versioned and loaded via system wrapper (at leat that is what I understand). The dll you mentioned were always needed, but they are system ones so you should have them properly installed when doing the installation of Visual C++ 2005. There are projects setting that allow you to see call stack / variables regardless of _DEBUG define. That's how I've been able to 'debug' a release build. If you are interested I could send you my .sln/.vcproj files so that you can see how they differ from yours.

I'm on Windows and textures load for me without a problem... BUT: When I look at the library dependencies, the SDL_image I have requires libpng12, while for PNG_SCREENSHOT I have libpng13 linked in. Luckly I have libpng12 available on one of 'PATH's so the client still loads. I also have zlib available for ZLIB support. Maybe it's the same case with you? Try copying libpng12 and zlib dlls to client directory as see what happens

Thanks. Please remember that this is only for MSVC. I don't build with gcc (DevC++).

Hi Karen, Could you please patch the current codes for MSVC: Index: eye_candy/eye_candy.h =================================================================== RCS file: /cvsroot/elc/elc/eye_candy/eye_candy.h,v retrieving revision 1.22 diff -u -r1.22 eye_candy.h --- eye_candy/eye_candy.h 5 Apr 2007 15:26:46 -0000 1.22 +++ eye_candy/eye_candy.h 5 Apr 2007 15:55:48 -0000 @@ -7,6 +7,7 @@ #if defined(_WIN32) || defined(_WIN64) #include <windows.h> + #include <float.h> #else #include <sys/time.h> #include <time.h> @@ -76,6 +77,8 @@ #ifdef _MSC_VER #define copysign _copysign + #define isnan _isnan + #define isinf !_finite inline float fmax(const float a, const float b) { return ((a < b) ? b : a); }; inline float round(const float a) { return (a - floor(a) < 0.5f ? floor(a) : ceil(a)); }; inline float remainderf(const float a, const float b) { return (a - (float)round(a / b) * b); };

You don't have to explain this to me. I perfectly understand what your are saying... Just please explain this to my compiler for it, there is no such thing as a number.. there is only a type

Ok, Here are the last warnings: e:\cpp\elc\eye_candy\math_cache.h(104) : warning C4201: nonstandard extension used : nameless struct/union e:\cpp\elc\eye_candy\math_cache.h(221) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(234) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(247) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(260) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(273) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(286) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(299) : warning C4127: conditional expression is constante:\cpp\elc\eye_candy_wrapper.cpp(922) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) PS. As I remember 1.0 is not converted to double - it is double. If you want a float, you put a literal of 1.0f.

Just a few more left. Here is the log. You mentioned in the other thread that after the release you would like ot run with -Werror to clean all the warning. Do you plan to correct MSVC warnings as well (becuase as I saw the latest changes, right now you just disabled them with #pragma)?

I posted my log here Have fun

I sent you the compiler log. As for the warning, try "float blah = 10000.0001". The compiler just nicely asks you, are you sure to have him assign a value of double to a variable of float. If you are sure, just reply by adding 'f' postfix and he will be happy

Ah, now I understand why there are so many warnings.. if you can't see them, you can't correct them. That function caused a warning in Release mode but an error in Debug, so I was not able to build the debug until Lachesis' fix. Also if it helps you, my release compilation has warning set to Level 3 (/W3) (out of 4), while my debug compilation is set to Level 4 (/W4). Maybe you could enable higher level warnings (or something similar) in your compiler. Would you like me to send you the output from my compiler so you can correct them? This is an example of how it looks (cut to make shorter): e:\cpp\elc\eye_candy\eye_candy.h(21) : warning C4067: unexpected tokens following preprocessor directive - expected a newline e:\cpp\elc\eye_candy\eye_candy.h(21) : warning C4067: unexpected tokens following preprocessor directive - expected a newline e:\cpp\elc\eye_candy\math_cache.h(104) : warning C4201: nonstandard extension used : nameless struct/union e:\cpp\elc\eye_candy\math_cache.h(221) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(234) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\math_cache.h(247) : warning C4127: conditional expression is constant e:\cpp\elc\eye_candy\eye_candy.h(91) : warning C4305: 'initializing' : truncation from 'double' to 'const float' e:\cpp\elc\eye_candy\eye_candy.h(92) : warning C4305: 'initializing' : truncation from 'double' to 'const energy_t' e:\cpp\elc\eye_candy\eye_candy.h(245) : warning C4244: '=' : conversion from 'double' to 'coord_t', possible loss of data e:\cpp\elc\eye_candy\eye_candy.h(246) : warning C4244: '=' : conversion from 'double' to 'coord_t', possible loss of data e:\cpp\elc\eye_candy\eye_candy.h(247) : warning C4244: '=' : conversion from 'double' to 'coord_t', possible loss of data e:\cpp\elc\eye_candy\eye_candy.h(422) : warning C4244: 'argument' : conversion from 'double' to 'float', possible loss of data e:\cpp\elc\eye_candy\eye_candy.h(600) : warning C4244: 'argument' : conversion from 'double' to 'const coord_t', possible loss of data e:\cpp\elc\eye_candy\eye_candy.h(601) : warning C4100: 'p' : unreferenced formal parameter e:\cpp\elc\eye_candy\eye_candy.h(705) : warning C4244: '=' : conversion from 'double' to 'coord_t', possible loss of data e:\cpp\elc\eye_candy\eye_candy.h(817) : warning C4305: 'argument' : truncation from 'double' to 'coord_t' e:\cpp\elc\eye_candy\eye_candy.h(817) : warning C4305: 'argument' : truncation from 'double' to 'coord_t' ...

Thanks But I still have a lonelly '}'in line 770 EDIT: Thanks

Hi Karen, Since we are now in feature freeze/removing bugs phase, could you please work on correcting the warning message I get from eye_candy code? I get about 900 warning messages from your code when in Release mode (more in Debug). 99% of these messages are connected with the fact that you use 'double' literals with 'float' variables, so correcting them is really simply and would also give you a chance for a code review (because maybe there are places where the values should actually be double?). The remaining 1% is connected with something else.. but since there are 900 message, who would bother go through them and filter... If you don't get these warnings on your compiler, I can send you output from mine compiler. Please let me know. PS. the ec_create_effect_from_map_code should return ec_reference but the code is totally commented out and I can't build Debug version. e:\cpp\elc\eye_candy_wrapper.cpp(770) : error C4716: 'ec_create_effect_from_map_code' : must return a value PS2. In Debug mode I get 3200 warning messages from the whole client and about 2500 comes from eye candy system.

I don't know if it can help you, but I also get repeatable crashes in my client. Running Windows, compiling under VS2005 Express. The client crashes with... Access Violation in draw_3d_object_shadow_detail on call to glDrawArrays (same as 0ctane... weird eh? . In order to be able to play at all I just added return; at the biginning of the function... but someone more skilled might actually check what is going on.

You missed the loop in 'ec_delete_effect_loc_type', the one I originally reported You should get more sleep

I got one Beer for me extern "C" void ec_delete_effect_loc_type(float x, float y, ec_EffectEnum type) { for (int i = 0; i < (int)references.size(); ) { std::vector<ec_internal_reference*>::iterator iter = references.begin() + i; if ((*iter)->dead) { delete *iter; references.erase(iter); continue; } if (((*iter)->position.x == x) && ((*iter)->position.z == -y) && (type == (ec_EffectEnum)(*iter)->effect->get_type())) { (*iter)->effect->recall = true; continue; } i++; } } In my case: references.size() == 3 i = 2 if ((*iter)->dead) == false if (((*iter)->position.x == x) && ((*iter)->position.z == -y) && (type == (ec_EffectEnum)(*iter)->effect->get_type())) == true so... we continue and never increase the i. The i stays at 2 and we have infinite loop Happens at random time after starting campfire effect. Call stack > elc_d.exe!ec_delete_effect_loc_type(float x=52.750000, float y=73.250000, ec_EffectEnum type=EC_CAMPFIRE) Line 212 C++ elc_d.exe!remove_fire_at_tile(unsigned short x_tile=105, unsigned short y_tile=146) Line 587 + 0x15 bytes C elc_d.exe!process_message_from_server(const unsigned char * in_data=0x0d911a00, int data_length=7) Line 986 + 0x15 bytes C elc_d.exe!start_rendering() Line 110 + 0x12 bytes C elc_d.exe!Main(int argc=-1, char * * argv=0x00000000) Line 251 C elc_d.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * lpCmd=0x00151ef7, int nShow=1) Line 306 + 0xd bytes C elc_d.exe!__tmainCRTStartup() Line 589 + 0x35 bytes C elc_d.exe!WinMainCRTStartup() Line 414 C

Well in my opinion the new code for invsqrt is worth using. Let us not forget that the client is build on at least 3 different platforms with about 4-5 different compilers. Taking this into consideration I think we can sacrifice a bit of speed in favor of portability. We don't know if that '-fno-strict-aliasing' option can be enabled in all of them (I didn't see it it VC++; maybe I missed it) What's more, by using and union we get rid of the call to invsqrt_workaround. I tested this new invsqrt WITH SSE2 enabled and it works ok, so even though there is an union, we might actually gain by SSE2 optimization.

Ok I get the new files.. don't have time to build right now.... and I know the problem with effect_breath... I'm talking about the .h file not .cpp. The 10 that need to be changed to 10.0f is in the .h file

Browsing through the CVS shows that the current revision is 1.4. Oh, and I think you forgot to add dont_optimize.h/cpp into CVS