The International Simutrans Forum

Practically koord should not go much into the minus range, i.e. below -5 mximum lets say.

Also there are some places where the square of koord_distance is used. This works only, when it is uint32. So lots of work ahead for you. But if everything goes well, you might find also errors/questionable code.

On signed/unsigned and type conversion warnings: Please note that those are compiler and OS specific! Even fixing everything for GCC 4.x on Linux will give lots of warning on GCC 3.x on Mingw or 2.95.y on BeOS. Not to mention the MSVC and BeOS cc warnings. Even more since some architekture have char signed while other have them unsigned. P****ing unsinged char str[20] to printf is then an error.

I actually does prevent maps with more than 8000+8000 tiles.

Apart from your code being much more difficult to read, actually what warning does it fix?

Code: [Select]

const uint8 *data = (const uint8 *)d;
return ((uint16)data[0]) | ( ((uint16)data[1]) << 8 );

The only possible one, I could think off, is a singed unsinged conversion warning, which could be fixed using 8u instead 8. (But this would not adhere to K&R!)

The types should be like this: type(x) == type(x<<y) or else the compiler needs to be beaten.

Accordingly, it's also worth noting that two of the casts in your existing code do *nothing* unless "int" is less than 16 bits.
Code:
return ((uint16)data[0]) | ( ((uint16)data[1]) << 8 );

When I learned C (it was before C89 though) it was definitely implementation specific.
char c=1;
int i = (c<<;
did usually return zero on 3 out of 4 compilers (including early GCC. Did not check on the haiku 2.95.X though ... ) And back in my 68000 days I frequently looked at the compiler output in the debugger, and the code did rarely a sign/unsigned extetsion (which is very costly on 68k). But I learn new stuff every day (albeit this is really braindead).

*sigh* (On the other hand 40 bit integer and 20 bit chars are nowadays even rare on DSPs and will have hopefully never to compile simutrans.)

By the way, it seems the implementation of that is even not 100%: http://www.lysator.liu.se/c/rat/c2.html

This is not true; some compiler might do a signed shift otherwise (see above link), which usually is slower (although this more important for right shifts, of course).

BTW: what platform are you compiling on that you are not using intel byteorder. PPC?

Edit2:
-Wconversion seems not to work for Mingw or Haiku ...

simgraph16 uses KOORD_VAL which is sint16 ...

The usual answer is to try this out. I think some calculations should be done as sint32 whenever a screen coordinate is converted into an offset. There might be some errors around.

However, changing KOORD_VAL alone would not be enough, since all dialoges uses koord() for GUI elements.

Neroden - how enormous? I have a monitor with a resolution of 1200 x 1600...

Then use koord for the map-coordinates, and something like koord32 for others. Could be achieved with a template as well

Code: [Select]

template<cl**** some_int> koord_base {
         some_int x,y
};

typedef koord koord_base<sint16>;

Another thing that comes to my mind are the min/max functions. They take int's and return int's. Why not define macros here instead?

Quote from: Dwachs – on May 14, 2010, 05:23:19 am

Then use koord for the map-coordinates, and something like koord32 for others. Could be achieved with a template as well

Code: [Select]

template<cl**** some_int> koord_base {
         some_int x,y
};

typedef koord koord_base<sint16>;

Another thing that comes to my mind are the min/max functions. They take int's and return int's. Why not define macros here instead?

I was actually planning to define them as template functions --

Code: [Select]

T min(T x, T y);

  I've already found quite a lot of suspicious integer conversions due to the min/max functions.