preprocessor-free coordinate system about openage

[Jon0]

There are no const modifiers on operators

no match for ‘operator+’ (operand types are ‘const openage::coord::tile’ and ‘const openage::coord::tile_delta’)

[andrekupka]

Parameters of those binary operators should be changed to const references.

[franciscod]

could someone explain the pain of the current implementation, and how would the paradisiac version be like?

[TheJJ]

By "someone" you probably mean @mic-e as he wrote the coord system in the first place.

[mic-e]

The pain with the current version is that it's pretty unmaintainable and extremely hard to read because it uses preprocessor #defines and #includes in an unconventional way to produce the required .cpp and .h files for the absolute and delta classes for each coordinate system, including all of their overloaded operators.

Writing all code by hand would be an option, though it would create immense redundancy. It also would make adding a new coordinate system pretty hard.

An ideal solution would have instruction files of some kind == in the coord folder, and have a python code generator module use them to create the full .h and .cpp files from them.

[detrumi]

I'm planning to implement this. There's not much that changes between the different types, so the following information would be enough:

namespace = coord;
scalar_type = phys2;
members = ne, se;
body = {
    phys3 to_phys3(phys_t up = 0) const;
    tile to_tile() const;
    phys2_delta get_fraction() const;
};
delta_body = {
    phys3_delta to_phys3(phys_t up = 0) const;

    //allowing conversions of phys deltas to tile deltas isn't such a great
    //idea. you never know whether a phys change of 0.9 will _actually_
    //change the tile.
};

This example would be something like phys2.scalar, which would then generate phys2.h with the structs and all operations for the phys2 and phys2_delta types.

Some loose ends:

• It would be nice to be able to define these files for example in the cpp/console folder, with the correct namespace generated. At the moment cpp/coords also contains some types for the console, so it would be nice to separate them.
• Some of the types have a hash function defined, but phys3 only uses the first two values in the hash. Can we generalize this, or otherwise just specify which members are to be used in the hash?

[TheJJ]

A few thoughts that I had about the coord system: (for the record, i just extracted the following from a 2000 lines-xmpp-conversation):

• Constraint: conversions should be very fast.
• Eliminate the global state (e.g. scroll position) by inheritance:
  • Every component having some coord state inherits from a coord base class.
  • This class provides the state members (the new struct coord_state) and functions for modifying the state.
  • Calling these will only modify the inherited state members, global state is purged.
• All coordinates instanced have to be bound to some coordinate system, where they can access the state (e.g. current camera position etc).
  • This means one coordinate has an absolute position in this system. When converting to other systems, the state of the relevant reference systems are used in the transformation calculation.
  • The delta coordinates don't need that binding, as they are just relative values for one reference system (can be applied to other deltas, like a vector, or to an absolute position within one ref system).
  • This way the conversion can still be done conveniently as the .to_whatever() just makes use of the initially-remembered coordinate system it was bound to.
• When creating new coordinates, they could be generated by a factory of the the respective coordinate base class (the one defining the coordinate space and state). This way generated coordinates are bound to that space without passing the space to the new coordinate's constructor all the time.
• example:
  • the r could e.g. be the scroll state of the minimap, or the view center of the main game view.
  • code:

struct phys3 {
    phys_t ne, se, up;
    CoordReference *r;
    to_camgame() {
        // of course that's not sufficient but just an example:
        return camgame{r->state + ne + se + up};
    }
}

• One could even perform a reference transformation, by defining a vector etc between two reference spaces, the coordinates can be translated between two bases.
  • This is basically a vector space with base transformations.
• All the transformations between systems are performed by applying operations to coordinates that rely on some state that is kept by members of e.g. engine, minimap, terminal, etc.
• To create a new coordinate, you have to fetch it at the reference system (so that the coord is bound to it). The reference system is a factory that tracks state and can produce coordinates that are linked to it.

[TheJJ]

Another attempt: #662

[TheJJ]

Closed through #975.