TerraGenesis Perlin

[Rubidium]

Arnau, the bug should have been fixed in the TGP branch by now. It was due to the fact that winbase.h uses Thread as a variable name, whereas OTTD defines Thread as a type, which clashed.

So thanks for this bug report and we'll hope you can now test the branch to its full glory :)

[Arnau]

Hi,

It worked for some time, but with the last build now I receive this new error...

genworld_gui.c
.\genworld_gui.c(165) : error C2220: warning treated as error - no 'object' file generated
.\genworld_gui.c(165) : warning C4293: '<<' : shift count negative or too big, undefined behavior
.\genworld_gui.c(165) : warning C4293: '<<' : shift count negative or too big, undefined behavior
engine_gui.c

Perhaps I should change VS2005 for VS2003....

I'm getting the feeling that I'm starting to become tedious always with new errors...

Anyway Great work with the new terragen!

[TrueBrain]

Hi,

It worked for some time, but with the last build now I receive this new error...

genworld_gui.c
.\genworld_gui.c(165) : error C2220: warning treated as error - no 'object' file generated
.\genworld_gui.c(165) : warning C4293: '<<' : shift count negative or too big, undefined behavior
.\genworld_gui.c(165) : warning C4293: '<<' : shift count negative or too big, undefined behavior
engine_gui.c

Perhaps I should change VS2005 for VS2003....

I'm getting the feeling that I'm starting to become tedious always with new errors...

Anyway Great work with the new terragen!

As stated in the svn log messages, those 2 errors are known and won't be solved for a while. They are because of some limitations of the code, and every compiler reports the error. Switching to an other won't help. Your compiler should just ignore warnings and continue compiling.

[Arnau]

Ok, Thanks!

[DaleStan]

Switching to an other won't help. Your compiler should just ignore warnings and continue compiling.

In case you hadn't noticed, there's a compiler error in there. And it's in there because someone told MSVC to treat warnings as errors. Someone (possibly a different someone here) needs to (1) Remove the /WX from the compiler options (2) add a #pragma warning(disable:4293) to genworld_gui.c, (3) add the equivalent setting to the MSVC project files, or (4) fix the shift.

Undefined behaviour means that a conforming compiler can do absolutely anything. Including compile it to a HCF instruction.

[CobraA1]

I vote (4) - AFAIK, there's been a policy of no errors or warnings, and IMHO it's a good policy that shouldn't be changed.

[Rubidium]

The issue is caused due to the fact that the genworld_gui.c has gone over the widget 'limit' (disabled_state is 32 bits). This currently caused 'wrong' behaviour (a combobox does not get disabled under certain circumstances), though not threatening (nothing is done with the given value).

The fact that you are shifting 32 or 33 positions should yield a warning, as the statement is effectively a NO-OP, but it is not a real error as it cannot cause undefined behaviour in _any_ sane implementation; shifting is simply put multiplying/dividing in steps of two and for an unsigned integer multiplying 2^31 by 2 is 2^32, which overflows to 0, which always stays 0 when shifting.

About option 4, that means that (parts of) the GUI subsystem needs to be rewritten. Currently someone* is busy increasing this limit and this warning is just a reminder for the fact that we need the increased widget limit. Therefore we will leave the warning.

*) I won't disclose the identity of this mystery person, unless the person grants me permission to do so, or identity is disclosed by the person in question.

[DaleStan]

The fact that you are shifting 32 or 33 positions should yield a warning, as the statement is effectively a NO-OP

No, it's undefined. Which may compile to a no-op (<< 32), or it may compile to a one-bit shift (<< 33), or it may be the equivalent of a 0.

The exact behaviour depends on the compiler, the processor, and the post-optimization status of the operands. (After all applicable optimizations, are both literal constants? Is only one a constant? Are both variable?) Have you inspected the assembly output from all supported compilers, in all supported configurations, and determined that they all have the same behaviour? If not, the code has to respect the possibility that for some people, 1 << 33 is 2, and for others it is 0, and for others, it could well be 0x2 0000 0000. This is the essence of undefined behaviour.

About option 4,

... "remove" is a valid value for "fix".

[CobraA1]

If the extra bit isn't used, why include it at all?

Anyways - I tried playing around with the interpolation function (ie, changing from linear to cosine, as shown on the webpage that was the inspiration of the function), and it doesn't seem to make much of a difference.

Anyways, don't be afraid of a little rewriting - it's good practice for the real world, I'm sure. I had to rewrite the queue code, refactor the z coordinate, and rewrite part of the aircraft speed routines in order to accomplish everything I wanted in my patch.

[TrueBrain]

We released a test version of TGP. Read more here.

[Darkvater]

blop.

[Arnau]

Oh, How surprising was seeing my name on the main openttd page! I did nothing!
Anyway for sure I'll be testing my beloved TGP.
If there's some part I should focus, just tell me!

Bye!

[Rubidium]

Oh, How surprising was seeing my name on the main openttd page! I did nothing!

You made us aware of the fact that 'Thread' is used in the windows API and that it is therefore not a good name for a type.

Anyway for sure I'll be testing my beloved TGP.
If there's some part I should focus, just tell me!

Mainly the new features; you do not need to play for any length of time, just create lots of maps with all the different settings in the 'New Game', 'Load Heightmap' of the intro menu and panels behind the 'Random' and 'Heightmap' buttons of the landscape sculpter of the scenario editor.

But, please, notify us of bugs via the new topic in the 'OpenTTD General' subforum.