PathSprites or uint8

[DSchulz]

While trying to get some overview the path code works, I noticed two things I would like to ask:

• There seem to be two types of representation a path tile, one "imploded" with no bitwise information and the other "expanded" with its single bits containing information about the edges and corners. As far as I can tell the imploded form is just another name for the PathSprites enumeration, even though the data type used is very often uint8. Converting all the occurences to "PathSprites" where the imploded form is used would help for some clarity and while debugging, because now one would be able to actually see what kind of path the variables contain. At least while playing around with the code it seemed to me that the replacement did not break anything.
• Usage of the word slope: Often there is some variable or argument called slope, but it actually seems to hold information about the connected corners / edges. I think it would increase readability if these names were replaced with something more obvious.

I know these files already grew a bit old, but maybe someone who can still remember a bit can comment a bit about this ;)

An example for both of my questions:

http://pastebin.com/FxKMr8gR

[Alberth]

I would say it's the other way around, the uint8 sprite number is also mapped to values in PathSprites. That holds for both imploded and expanded form though.

There are however a few layers above path tiles that would be helpful to understand things.

The world contains rides. Things that people use in the park. Anything from a complete rollercoaster thingie to a singe tile shop.
Scenery and paths are also rides, but their amount of data is small, and usually you have a lot of them.

Rides use space in the park. The world is divided in voxels, cube-like areas of space. A voxel is the smallest amount of space that a ride can get (although somewhen in the future, it may need further sub-division, eg scenery may need only 1/4 of a tile). In the voxel, the ride that owns that voxel is stored (the instance). Rides can also store their own information (the instance data) in a voxel. Typically, they would store what to draw in that voxel. In terms of values, it's a uint16 number iirc.

Since a path is a ride, it claims a voxel (actually, 2 above each other, and if it is non-flat, even 3 voxels above each other). The data of a path ride is the sprite number to draw when you are in the voxel with the actual path together with the type of the path. Somewhen in the future, the existence of light, waste bin contents and litter amount, and a place to sit should also get stored there. The instance data is thus several different properties of a path, where the path sprite is just one of them.

"The sprite to draw" is what is known as imploded path. While the values are also represented in the first part of PathSprites, it's mostly a random and irrelevant number, where only the FLAT_COUNT value is relevant, and the 4 ramps beyond it (with the _path_up/down_from_edge[] arrays). Finally, PATH_INVALID is used for the voxels above the path. This is sufficient to compute how paths are connected, except for the edges. In other words, I see the sprite number as mostly useless, except for the above mentioned properties. Conversion to PathSprites doesn't give more information, since the precise flat sprite doesn't mean much. Instead you may want to print the value in hexadecimal base after expanding.

To get edge information as well as for doing efficient computations with them, the imploded path sprite number is useless. For this reason, there is also an expanded form, where edges and corners each have their own bit.
This is done in the second part of PathSprites, with the PATH_BITs. The actual values (ie all combinations of edges and corners that are possible), are however not in that enum (wouldn't be very useful either, as the values overlap with the imploded numbers).

Converting the uint8 value to PathSprites is probably not needed. Since the voxels use imploded values, almost all code works on the imploded form. Edges or corners are mostly used very locally, and the variable names or documentation already hints what it represents. If not, it could be added.

'slope' points towards a general "orientation of the path". Obviously, this includes information which edge is raised. Depending on the purpose of the code, edges could also be part of orientation. For example guests will only travel to neighbouring tiles when the current tile has an edge in the direction of the neighbour. Even if edges are not that relevant, it is probably too much work to invent a new enum for a slope; the current one works nicely, except you have PATH_FLAT_COUNT values for representing "flat path tile".