This is usually solved by making texels around uv-borders extend/bleed over said edges - enough to make sure there are never any outer 'undefined' texel values involved in a filtering operation.
- If you're baking this texture, modelling apps often have an option to 'expand uv-borders'.
- If your texture comes with an alpha map, one quick trick is to place a slightly blurred duplicate of the texture underneath the image. Or write a script that for any texel with a zero-alpha value duplicates the RGB value of the nearest texel with a non-zero alpha value.
The issue is, I'm not terribly sure where to put the disc center. All I got is a light direction for the "sun", not a position. All of this ties in with something else I have yet to implement, rendering the glowy sun disc, so no idea how to do that.
If any ray parallel to the light direction hits the sun in its exact center, regardless of where it originated or its length, then you'll have to define the size of the disc as a minimum of the dot product of the ray and the light-dir. e.g.: if(-dot(ray, light) > 0.98) hitsDisc();
Two of these discs slightly apart (that is, have near perpendicular light directions), one reddish/yellow the other a blue tint, added together should give white light in in their overlapping areas.
1. Store an array of structs/classes instead of an array of integers. Every struct can contain a series of variables, including the index to the sprite, but also other properties like a boolean that tells a cell's collision condition.
2. Create a virtual camera. In this case that can simply be a pair of x, y coordinates. When you draw the playing field from bottom to top, you add these coordinates to an array indexing offset.
Simplest alternative to clipping would be to generate a triangulated volume of the boundary (if you don't already have a volumetric representation) using something like poly2tri. Then subdivide the mesh until all its edge lengths are below a certain threshold (to prevent too much distortion when you map its vertices to a sphere). If the map itself is triangulated you don't have to draw the sphere underneath it, avoiding possible intersection/z-fighting issues.
This is probably easiest when the underlying road structure is defined as a network of interconnected splines. That way the center of the road and its tangent/direction are exactly defined. Also, you can do distance tests between the (tessellated) curve and surrounding points to see whether such points lie on the road. Lastly, a user-defined route becomes a simple series of (spline-)key-points.