Cheers 
Expanding upon what I said earlier, do you need the data returned in any particular format?
Iām thinking of just coming up with a generic ātiles within a triangleā routine, so the order wouldnāt be specific according to the view direction.
Its cool you are having a look. At the moment the FOV first finds a list of unordered tiles.
I then sort them by grid order, Iām basically storing tile references. Tile 8 being col 4 row 2 in a 4 x 4 grid etcā¦
I then sort them with ipairs into an indexed array.
Thats so when plotting the grid I scan horizontally then vertically. So each tile might ( if it exists ) get the corner points of adjacent tiles, making for reduced calculations.
Just worked out. With the subdivision. Its best to start into the screen and not at the edges of the screen like I was. It draws a few more tiles, but more are left on screen to help with the effect.
Decided to try a different way of removing the polygon gaps / slivers.
Im still subdividing the tile, but before hand Iām scaling by an additional 0.25, where a scale of 0 means the tile would be the original size. Its not enough to alter how it appears on screen but I have yet to see any more artefacts.
Yeah expanding ye corners will remove sparklies for sure, but it kinda makes me rebel, as it is part of the OGL spec that polygons that share vertices and an edge should not produce sparklies (although worded a bit more technically than that). T junctions are obviously NOT part of that, but Iāve seen sparklies anyway, which just makes me sad. Subdividing is not something Iād enjoy doing I must admit - Iād be looking for ways to avoid the need. I think the reason you are hitting the need like this is because of a particularly high field of view (I noticed this from watching one of your vids). A lower FOV would provide less distortion as tiles get closer to the screen edges, but the effect visually from a lower FOV isnāt always what is desired, naturally.
Glad you sorted that anyway. Iāll have a look at my triangle thingy shortly, the idea is it would return a table containing a list of X and Y pairs that determines each cell returned. Do note that triangles arenāt actually the shape needed if you have a particularly high vertical angle (that is to say, the more directly down at the ground you look, the less a triangle works as the cull shape would tend towards a box). But for a fairly flat ālooking across the planeā style itāll be fine.
At the moment only 2 - 3 tiles are subdivided so its not a big issue. That now happens very close to the bottom of the screen so its momentary at best. I have also dropped the horizontal and vertical subdivisions as they are now no longer needed.
The sparklies were only ever visible at T junctions where a normal tile and a subdivided one met. I nearly scrapped the scaling as it actually introduced sparklies between the subdivided tiles. I have experimented quite a bit and a scale of 1.02 for the subdivided square has worked 100% in all test cases so I am wrapping that bit up now.
As of yet the normal tiles are not producing any sparklies which is good as it saves scaling each tile individually which wouldnāt allow me to cache their points for less calculations.
Had a quick look at the tile map for mode 7.
Are you using padding for the tiles and drawing a 1 px offset around them? If not thats a cause for lots of edge defects where the texture isnāt rendered to the edge of the polygon correctly.
Heh Iām lazier than that in the mode 7 demo - all the tiles are just touching so yes it flows over, but I couldnāt be bothered to do any more work for what was a throw-away demo.
Iāve semi implemented the cached / pre-rendered fov calculator that uses the camera and dumps a json encoded file of all points visible. This buffering, which will be used at the angle the game is set to run at, to save cycles for other things, takes the rendering time down to 2.5 milliseconds per frame, on my laptop, down from originally about 16ms and with other optimisations it was running at around 5 - 7.
It still needs a lot of work but it looks promising.
What does that translate to on devices, any rough idea? Does indeed sound promising, thereās nothing like precalculating for speed!
Im guessing that it will hold a steady 30fps now on a A4 chipset, it was roughly getting that when the laptop was showing double the time per frame. Will test once I have it working good enough to not crash!
I have ordered an A5 iPod Touch ( iPhone 4S equivalent ) to test on. That will be the base device Iām guessing.
I think limiting the app to iOS7 would only allow devices with enough power to run the engine at full speed.