comp.png 138.06KB 49 downloads
Jump to content
comp.png 138.06KB 49 downloads
Im adding in a fov script I developed for Lime a while back.
It calculates shadows at the moment and is way too complex, but here is a screen shot of its most basic routine scanning which tiles to render. Implemented in 2D only for the moment.
1.png 23.24KB 32 downloads
In a quick test in 3D this simple fov script takes it from 16.66 milliseconds to 3.2 milliseconds to calculate each frame.
I should add, try to avoid the subdividing if you can - you are introducing t-junctions which can (and likely will) result in sparklies on various devices.
Also, get height in You aren't limited like in my mode 7 demo to a single plane per tiled later, so get some ramps and stuff in. Hell, there's no reason you can't have loops and things in. Go crazy!
Yeah I thought subdividing would cause some issues but I cannot see any so far. My original plan was to leave the original polygon underneath or draw a polygon the colour of the tile, but it doesn't seem to be a problem.
I may kill the subdivision idea as it makes using tile maps ( with margins / spacing ) a lot harder but at the moment its a good fix while I keep on optimising the engine.
The issue with sparkles is that positioning one corner of a polygon off screen, not at infinity, but at an acceptable value, so as to not warp the texture, would also cause the same effect, as its essentially doing the same thing.
But at the moment its just a test so the engine changes every time I have an idea.
Heh I know the feeling
I went over Lerg's skybox thing as he encountered a similar problem, and in fact his solution was completely the opposite from yours and amusingly I think you two should swap solutions
He moved the skybox further away to avoid clipping the Z == 0 plane, and I think the correct solution in this case *is* subdividing, and in your case I'd suggest just backing the camera further away and not subdividing.
Sparklies can show up at odd times. I removed the rotation from retro racer because it was creating sparklies at angles, and that was a minimal test case, despite being 100% sure that each corner of the adjoining polygons used identical values. Happened in the simulator and also on my phone, although maybe they've sorted that now? Might be worth me chucking it back in to check, but the point is I know my phone can show these things so maybe if you are bored one night you could pass me an android build and I'd just take a look.
Ok have tested the unoptimised code...
And also on device noticed sparkles, so damn it all to hell. That will need looking at.
I just took delivery of an iPod Touch 4G, 256 MB, A4 chip. This currently gets 15 fps so there is hope for older devices.
On an iPhone 5S it gets a constant 60fps.
If I lose the subdivision then that would help the cause a lot. How do you suggest doing it the other way?
I think I might have thought around the subdivision problem.
At the moment I'm generating all 4 points for each tile. That needs to be cut down into points in a grid.
Then for each tile, if a point goes to infinity I'm going to use the subdivision routine to trace back up the sides of the polygon until I get to a respectable value for the 2 bottom corners. Im hoping this should fix both issues as the wall as the gird will be generated before drawing any polygons ensuring I'm doing the maximum possible to make them all line up.
If you *really* wanted to go all out, you could generate sub tile frames from the tile sheet, eg for each sheet you might have 8 additional frames, 1 for each quarter, and 1 for each half, or split it into more (resulting in a huuuge number of frames per tile!), and then when you come to subdivide anything up close, you'd be able to have 'sub-tiles' to texture from.
I did something similar in Dungeoneer to make textures line up according to different wall heights. While the frame construction was similar in theory, and it was used for 'chopped up faces' it wasn't for perspective correction up close (and was vastly simpler as it only needed to worry about new vertical versions, not both vertical and horizontal which is what you'd need).
Also I wouldn't worry about the mode 7 demo comparision (which I would probably be able to up to 60 fps, but it was haaaacky!), because it uses a much simpler method of getting the end result, and your way of doing things is more flexible, not least of which is the ability to have ramps and what-not, which the mode 7 thing will never be able to manage.
Plus of course, as you are putting the 3D transform directly into each tile, and not into an overall snapshot like my demo, you also end up with much sharper graphics, which is never to be sniffed at.
The sub tile division is what Im doing now. Each tile is split into 8 segments and those are drawn when close to the camera, using a sprite sheet, but that causes the sparkles.
I tried zooming the world out by 2 and scaling the screen and the result loosed workable. I looks like it will need additional work though as it seems to throw off a few calculations.
Ok well I give up trying to sort the perspective behind the camera using math. I get close but its not good enough and uses a lot of cycles.
I was doing the sprite > subdivision trick. The tile would get divided into 8 sections, but as this only happens close to the screen only a couple of strips are drawn. The problem there being the sparkles.
My solution, untested as its getting late, is to draw a 1/4 strip the full width of the tile next to where it meets the next tile. The draw the 1/4 tiles on top. This should get rid of the sparkles at the edges of where 1 large polygon meets 4 smaller ones.
It will probably only result in 10 extra polygons tops for the whole screen so that itself won't be an issue.
I must admit I don't.
Dungeoneer uses a really basic one but let's face it, it isn't exactly a programming challenge when the point of view is ever parallel to an axis so it isn't really useful.
If I had time I'd have a go as it sounds exactly like the type of challenge I like, but unfortunately I don't have time.
The only thing I could suggest is how I might approach the problem:
1) Work out which is the 'general' axis you are looking along (IE which of the 4 main axes you are most aligned to).
2) Calculate the edge lines (IE where to clip the left and right of the view) by working out how much of an offset each of these lines has per unit movement along the main axis found in 1
3) Iterate along the main axis, finding the left and right boundaries by offsetting in their other axis by the values calculated in 2.
4) Between these two values, include all the tiles found, then move one more along the main axis and repeat to find all the tiles.
Does that make any sense? I think an image would probably clarify it easily enough but alas, I really won't have time for that until tomorrow.
Community Forum Software by IP.Board