Hey Walter.
You can see the culling bug in the video. The trackside objects vanish before they are in front of my cull plane (basically when things get too close). You can see another way the culling bug kicks in in the video when I brake to a stop and move left and right - the nearer I am to the left edge of the road the less track sections that get culled (in fact if I stay at the left edge, it draws all the track sections correctly).
The reason I base everything off top left is for simplicity. While a sprite retains its square shape, things like width, height, rotation, offsets etc make sense, but when you can move any of the corners to where you want, this relationship begins to break down. For example, what is the angle of rotation of an image if I also rotate the corners arbitrarily?
That’s not to say these things aren’t useful but they are complimentary.
Anyway, bottom line is, when dealing with 3d calculations like this, you don’t think of each polygon as a seperate entity, but as part of a whole. So the easiest way to set things up is to position all the sprites at 0, 0 (top left of the screen) and just calculate all the coordinates of the various polygons together - that is to say, ey all use a common reference point or origin.
For whatever reason, the culling goes rather haywire, hence why instead of doing this I choose the top left corner (convenient because it is the first in order, and also the top left, ignoring massive distortions). However, that is likely to be unneccesary when the culling bug is fixed, so doesnt really worry me now.
The fact that the path is an offset is what concerns me.
For a system like this, where each sprite is a face you run into problems almost immediately. Anything but the most simple of 3d representations will require faces using different images. As my code shows (and it didnt show all of it) the difference between being able to specify the corners by pure coordinates, or having to do them via offsets based on the size of the source image is rather drastic - something that will certainly add up on the overhead per face and how many you can throw around.
For the origin method I proposed, the anchor point is also the sprite’s position - that is to say I place the sprite at 0, 0 and make the anchor 0, 0 as well. At this point, having spent only a few hours in graphics 2 I must admit I’m not quite following the reason for not allowing direct placement of the corners - my suggestion was that the path, instead of being offsets, would be the actual values of the corners (relative to the anchor and x y pos of the sprite). You could ‘easily’ make the path be the real values rather than offsets (ie fill them with the width and height of an image when created or you change frame), which would allow for easier and more direct control.
I understand the difficulties of using real values rather than offsets - it can cause problems if you change the frame of a sprite and the frame is a different size, but in reality what would be the expected result in this case? I think this sort of issue is far more likely to be relevant where people are arbitrarily changing the path and frame of a sprite and want to maintain the path between changes.
Now, having said that, I’ve not looked into the other uses of paths - errr polygons I think use them too? I will take a gander is week as time permits, but I don’t expect to find any anomolies there making offsets make more sense than actual coordinates, but any help in understanding this would be gratefully accepted.
I’ll sort out the code tomorrow I think - I’ll include the whole project but will chuck everything you don’t need to look at into functions at the end of the main.lua, and hilight where the nice bits happen. One question - where do I send this stuff soit gets to the right people?
