3D World - Graphics 2.0 Competition Submission

Solar2D Advanced Graphics
#21

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.

#22

Thanks, will give that a try.

At the moment the fov script is scanning simple octants which are decided upon by the angle the camera is facing. Its fast but gets too many tiles. I think a slower script might speed things up as it will require less rendering and clipping at the 3d stage.

Im also considering pre-calculating the tiles visible for each degree of rotation at all 4 points of the tile and then using offsets to update for the current camera position. Each degrees will only have 60 tiles top so the table won’t get too big. Would only do this for the camera pitch the game will run at for optimum speed but for all other angles I am going to need to calculate realtime.

From my calculations I would lose around 1/2 of the tiles I’m currently plotting so it should give another speed increase.

Got the sparkles sorted as well last night. I subdivide the tile into 8 squares and also 4 horizontal and 4 vertical strips. Only a few of those get drawn as close to the screen, but the way they overlay cancels out any defects.

#23

Put up a new video. Towards the end I’m showing the different subdivisions.

http://www.youtube.com/watch?v=PT70aQPI5ag&feature=youtu.be

#24

I don’t suppose you care to share with me the Tiled levels so I can look into this myself? I should have time this week (starting today in fact, hurrah!), and I’m sick of looking at my own crappy tiled level I knocked up with ripped-off assets for that Mode 7 demo!

#25

Here you go.

The tile map is using offsets and margins to stop any oddities happening.

The actual tile map is made in fireworks so they are layered and editable.

Matt

– Image Sheet Options
layer.imageSheet = {
border = 2,
width = layer.imageTileWidth,
height = layer.imageTileHeight,
numFrames = layer.imageWidth / layer.imageTileWidth * layer.imageHeight / layer.imageTileHeight
}

#26

Cheers :slight_smile:

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.

#27

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.

#28

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.

#29

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.

#30

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.

#31

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.

#32

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.

#33

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.

#34

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.

#35

What does that translate to on devices, any rough idea? Does indeed sound promising, there’s nothing like precalculating for speed!

#36

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.

#37

WOW, FANTASTIC :slight_smile:

I can see so many games using this.

Thanks for the share!

Mo

#38

Lovely :smiley:

Got any framerates benchmarks for devices - am rather curious indeed about that.

#39

Not Yet.

The actual drawing of the 3D bit, that doesn’t seem to affect the fps too much.

The maths however is taking around 16.66 milliseconds per frame which is way too much. I am however calculating every point of the entire world 4 times so once I implement fov on the grid to get just a sample of the entire world I’m hopeful it will run on devices at a decent frame rate.

#40

Oh, if you watch to the end of the vid, you will see where I fixed the texture problem by subdividing the polygons. The bit where tons more points pop in on each tile. That too needs a lot of optimisation.