Current CVS errors

[Grum]

(gdb) print select->lines

$3 = (text_field_line *) 0x0

That helped a lot. Thanks! Unless someone fixes this before, I'll have a look tomorrow.

Edited June 26, 2007 by Grum

[Florian]

copy_to_clipboard is not #ifdef'ed correctly for OSX

[kibora]

Neither for WINDOWS

 

widgets.obj : error LNK2019: unresolved external symbol _copy_to_clipboard

 

And about the glTexImage3D error the problem is that the Windows Opengl 1.1 doens't support that function

Edited June 27, 2007 by kibora

[Grum]

copy_to_clipboard is not #ifdef'ed correctly for OSX

My bad, should be fixed now (in the "copy/paste work on OSX and Windows but at least it compiles" sense of fixed).

[Florian]

One of the last updates caused this:

 

[18:56:30] Frame buffer format: NONE, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: NONE, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: NONE, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA4, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA4, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA4, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA4, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB8, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB8, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB8, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB8, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA8, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA8, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA8, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA8, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5_A1, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5_A1, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5_A1, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB5_A1, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB32F, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB32F, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB32F, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB32F, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA32F, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA32F, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA32F, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA32F, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB16F, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB16F, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB16F, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGB16F, depth bits: 32, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA16F, depth bits: 0, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA16F, depth bits: 16, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA16F, depth bits: 24, stencil bits: 0 is supported

[18:56:30] Frame buffer format: RGBA16F, depth bits: 32, stencil bits: 0 is supported

[18:56:30] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 1/4...

[18:56:30] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 2/4...

[18:56:30] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 3/4...

[18:56:30] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 4/4...

[18:56:30] gl_init.c.init_gl_extensions:904 - OpenGL invalid value

... other messages ...

[18:56:41] reflection.c.draw_lake_tiles:840 - OpenGL invalid value

 

 

Reflections with shaders worked fine 2 or 3 days ago.

[0ctane]

Florian,

Those messages were generated by Xaphier's code. We are trying to fix the framebuffer issues in OSX.

[Florian]

Florian,

Those messages were generated by Xaphier's code. We are trying to fix the framebuffer issues in OSX.

 

Framebuffer and reflections with waves worked 2 or 3 days ago.

[Beaverhunter]

So doesn't anyone feel like fixing map.c errors?

 

1>map.c

1>.\map.c(323) : error C2065: 'int_fast32_t' : undeclared identifier

1>.\map.c(323) : error C2146: syntax error : missing ';' before identifier 'terrain_buffer_size'

1>.\map.c(323) : error C2065: 'terrain_buffer_size' : undeclared identifier

1>.\map.c(324) : error C2146: syntax error : missing ';' before identifier 'water_buffer_size'

1>.\map.c(324) : error C2065: 'water_buffer_size' : undeclared identifier

1>.\map.c(325) : error C2146: syntax error : missing ';' before identifier 'i'

1>.\map.c(325) : error C2065: 'i' : undeclared identifier

1>.\map.c(325) : error C2065: 'j' : undeclared identifier

1>.\map.c(325) : error C2065: 'cur_tile' : undeclared identifier

[Grum]

So doesn't anyone feel like fixing map.c errors?

 

1>map.c

1>.\map.c(323) : error C2065: 'int_fast32_t' : undeclared identifier

1>.\map.c(323) : error C2146: syntax error : missing ';' before identifier 'terrain_buffer_size'

1>.\map.c(323) : error C2065: 'terrain_buffer_size' : undeclared identifier

1>.\map.c(324) : error C2146: syntax error : missing ';' before identifier 'water_buffer_size'

1>.\map.c(324) : error C2065: 'water_buffer_size' : undeclared identifier

1>.\map.c(325) : error C2146: syntax error : missing ';' before identifier 'i'

1>.\map.c(325) : error C2065: 'i' : undeclared identifier

1>.\map.c(325) : error C2065: 'j' : undeclared identifier

1>.\map.c(325) : error C2065: 'cur_tile' : undeclared identifier

Just out of curiosity, what is the reason for using int_fast32_t there?

 

and no, I'm not 'fixing' this before I know that

[0ctane]

So doesn't anyone feel like fixing map.c errors?

...

I don't want to sound rude here, but how about investigating why the error is happening and trying to fix it? It is great and all that you (and others) are finding compile errors, but it would also be beneficial to everyone if you posted a fix (or even post a "I think the problem is ...").

[crusadingknight]

So doesn't anyone feel like fixing map.c errors?

...

I don't want to sound rude here, but how about investigating why the error is happening and trying to fix it? It is great and all that you (and others) are finding compile errors, but it would also be beneficial to everyone if you posted a fix (or even post a "I think the problem is ...").

Already did:

• Post 44
  
• Post 45
  

Mainly at Beaverhunter: Have you confirmed whether what I posted works?

Edited June 29, 2007 by crusadingknight

[ttlanhil]

Just out of curiosity, what is the reason for using int_fast32_t there?

According to the docs I read; that type is used when you want the compiler to guarantee that you will have an int of at least 32bits, but it can be bigger if larger is faster (ie native bitsize or whatever, I guess).

This looks like the sort of thing that's a case of premature optimisation; Xaphier has a compiler that supports a lot of new things (the TR1 #ifdef is to use technical recommendation #1 support for the next C++ standard, as I understand it), so he uses it. Later on, we find out other compilers don't support a lot of this stuff, and have to compensate.

 

One of these days I'm just gonna up and split global.h into two parts; one for the bulk-include and one for platform issues, and then #include the platform one to anything that uses types or functions we have to (re)define... I don't like the bulk-include in files that don't need it, but things like the above problem will be easily fixed if we can just include the platform one.

Edited June 29, 2007 by ttlanhil

[Grum]

Well, I read stdint.h, and assumed that's what it was, but it seems rather weird to me to use such a specialized type where a normal 'int' would do. I can understand it if you want to match some preset interface, like a library, or if you must know exactly how large your integer is, but in this case it just seems utterly pointless.

[ttlanhil]

Well, I read stdint.h, and assumed that's what it was, but it seems rather weird to me to use such a specialized type where a normal 'int' would do. I can understand it if you want to match some preset interface, like a library, or if you must know exactly how large your integer is, but in this case it just seems utterly pointless.

Actually, no, when you don't care what the max size is.

Theoretically, it could be slightly faster than an int, depending on the CPU. As such, it may be useful in highly-critical sections of code where you need to squeeze out every last cycle (ops that are called a thousand times per second; where a large amount of the CPU time is on integer mathematics, for example).

There are certainly places in ELC that need tuning, the client doesn't run as fast as it could, but things like that datatype just look like premature optimisation to me. Of course, you should probably talk to Xaphier before changing it

[Grum]

Actually, no, when you don't care what the max size is.

In this case no max size is specified, there are also type defs in stdint.h for specifying integers with exact sizes, integers able to hold pointers, etc.

 

Anyway, I'll poke Xaphier.

Edited June 29, 2007 by Grum

[trollson]

Bored waiting for things to build...

 

The C99 standard [1] requires support for the following width-specific types:

int_least8_t	 uint_least8_t	 int_fast8_t	 uint_fast8_t
int_least16_t	uint_least16_t	int_fast16_t	uint_fast16_t
int_least32_t	uint_least32_t	int_fast32_t	uint_fast32_t
int_least64_t	uint_least64_t	int_fast64_t	uint_fast64_t

Where the 'least' types are the smallest supported type of at least that width, and the 'fast' types are the fastest type of at least that width. Compare to optimising for size or speed. Also required are intmax_t and uintmax_t, which represent the largest integer widths supported.

...so use the 'least' types for storage, and the 'fast' types for calculations.

The following width specific types are optional:

• intN_t & uintN_t where N is the bit-width. The widths corresponding to integer types supported by the platform are required.
  
• intptr_t & uintptr_t which have width sufficient to hold a pointer type; these are very useful when dealing with different architectures.
  

How to determine whether the platform supports a particular type?

 

Each type comes with a set of macros defining min and max values (capitalise the type name, and replace '_t' with '_MIN' or '_MAX'). The standard requires that <stdint.h> defines these for each supported type, and does not define them for unsupported types, allowing you to test for their existance:

#include <stdint.h>
#ifdef INT32_MIN
typedef int32_t		  my_int32_t
#else
typedef int_least32_t	my_int32_t
#endif

 

[1] ISO C STD ISO/IEC 9899:1999 §7.18 "Integer types <stdint.h>"

Edited June 29, 2007 by trollson

[ttlanhil]

Sure, except that MSVC does not support all of C99 (a lot is supported than gcc, though gcc doesn't support all of C99 last I heard either).

We can generally rely on C89 support, with support for some C99-isms (such as C++ style comments).

Variable declarations mixed with code are another case where we have to go with the C89 standard, MSVC doesn't like that, either.

[Florian]

* Fixed crash with water shaders

 

Can't select shader quality 1 or 2 anymore.

[ttlanhil]

* Fixed crash with water shaders

 

Can't select shader quality 1 or 2 anymore.

That's intentional It's designed so that it will no longer allow levels that your computer doesn't support.

[Florian]

About 5 days ago my computer supported shaders, and the waving reflections worked well.

 

/EDIT:

[19:15:28] Window size adjusted to 1070x785

[19:15:28] GL_ARB_multitexture extension found, using it.

[19:15:28] GL_ARB_texture_env_combine extension found, using it.

[19:15:28] GL_EXT_compiled_vertex_array extension found, using it.

[19:15:28] GL_ARB_point_sprite extension found, using it.

[19:15:28] GL_ARB_texture_compression extension found, using it.

[19:15:28] GL_EXT_texture_compression_s3tc extension found, using it.

[19:15:28] GL_SGIS_generate_mipmap extension found, using it.

[19:15:28] GL_ARB_shadow extension found, using it.

[19:15:28] GL_ARB_vertex_buffer_object extension found, using it.

[19:15:28] GL_EXT_framebuffer_object extension found, using it.

[19:15:28] GL_EXT_draw_range_elements extension found, using it.

[19:15:28] GL_ARB_texture_non_power_of_two extension found, using it.

[19:15:28] GL_ARB_fragment_program extension found, using it.

[19:15:28] GL_ARB_vertex_program extension found, using it.

[19:15:28] GL_ARB_fragment_shader extension found, using it.

[19:15:28] GL_ARB_vertex_shader extension found, using it.

[19:15:28] GL_ARB_shader_objects extension found, using it.

[19:15:28] GL_ARB_shading_language_100 extension found, using it.

[19:15:28] GL_ARB_texture_mirrored_repeat extension found, NOT using it...

[19:15:28] GL_ARB_texture_rectangle extension found, NOT using it...

[19:15:28] GL_EXT_fog_coord extension found, NOT using it...

[19:15:28] GL_ATI_texture_compression_3dc extension found, using it.

[19:15:29] Your graphic card supports the default requirements for the next EL release.

 

/2nd EDIT:

(from old log, sorry I don't have the exact date, maybe a timestamp with date would be good in error_log when DEBUG is enabled ...)

[22:07:14] Frame buffer format: NONE, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: NONE, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: NONE, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA4, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA4, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA4, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA4, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB8, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB8, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB8, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB8, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA8, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA8, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA8, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA8, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5_A1, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5_A1, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5_A1, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB5_A1, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB32F, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB32F, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB32F, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB32F, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA32F, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA32F, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA32F, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA32F, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB16F, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB16F, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB16F, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGB16F, depth bits: 32, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA16F, depth bits: 0, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA16F, depth bits: 16, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA16F, depth bits: 24, stencil bits: 0 is supported

[22:07:14] Frame buffer format: RGBA16F, depth bits: 32, stencil bits: 0 is supported

[22:07:14] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 1/4...

[22:07:14] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 2/4...

[22:07:14] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 3/4...

[22:07:14] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 4/4...

Edited June 29, 2007 by Florian

[LabRat]

Log started at 2007-06-29 15:48:15 localtime (GMT Daylight Time)

From chat_log.txt at client login

 

hth

[Florian]

hth

 

tyvm

 

Log started at 2007-06-27 22:07:13 localtime (CEST)

[Xaphier]

I increased error logging of shaders. Now with -DDEBUG there should be always infos if the compiling and linking of the shader failed or not.

[Florian]

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 1/4...

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 2/4...

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 3/4...

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 4/4...

[08:54:59] shader/shader.c.log_shader_compile_log:91 - Compiling shader './shader/water_fs.glsl' failed

[08:54:59] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/water_fs.glsl' successful

[08:54:59] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:54:59] shader/shader.c.log_shader_compile_log:91 - Compiling shader './shader/reflectiv_water_fs.glsl' failed

[08:54:59] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/reflectiv_water_fs.glsl' successful

[08:54:59] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/reflectiv_water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/reflectiv_water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] gl_init.c.init_gl_extensions:904 - OpenGL invalid value

[Alia]

I'm not sure if this is right place to post it, but current cvs tries to free pointer to

a function

Those pointers are placed to the queues at lines elconfig.c:1572, elconfig.c:1574.

Freeing them while destoying queues causes segfault.