Project Mode7

[DustyPorViva]

Originally Posted by Hezzy002

Wait, no math or rendering as in a 64x64 loop without transformation or rendering? What else are you doing? It sounds like something odd is going on if you're getting significant performance drops from things other than what should most intensive parts.

Unless I'm misunderstanding what you meant by math and rendering, of course.

Putting each polygon on its own layer, or at least ensuring neighboring polygons don't have the same layer should prevent Graal from trying to sort them. Normally Graal sorts images by their bottom left corner, which, at least on some of the older clients, caused huge performance drops because it was done every frame without regard to the previous frame (It should store the new, sorted data so the majority of the stuff is still sorted).

Dynamically scaling up would drastically increase performance and visual quality..

My mistake, it was disabling everything other than the polygons. I ran a 64*64 loop and only displayed polygons, with nothing else going on in the loop, and that's what caused the massive slowdown. Even without textures applied. I will have to try the layer thing, but I doubt it would make much of a difference in extreme cases. The fact that I can render an entire level with this perspective with no slowdown(while only have some minor visual distortion), is quite an accomplishment in Graal, imo.

[Hezzy002]

Originally Posted by DustyPorViva

My mistake, it was disabling everything other than the polygons. I ran a 64*64 loop and only displayed polygons, with nothing else going on in the loop, and that's what caused the massive slowdown. Even without textures applied. I will have to try the layer thing, but I doubt it would make much of a difference in extreme cases. The fact that I can render an entire level with this perspective with no slowdown(while only have some minor visual distortion), is quite an accomplishment in Graal, imo.

If that's the case, then it's very likely that Graal renders scripted images and polygons into their own draw call. The bottleneck here is the communication between the CPU and GPU taking too long because the CPU has to upload data to the GPU, and wait for it to return before it can push the next polygon, etc. Normally, the CPU uploads it all at once which is significantly quicker.

Because of this, the only way to increase performance here is to use less polygons to reduce the amount of draw calls between the CPU and GPU.

I wonder.. is there a way to render the entire scene with just one, massive polygon? It would be possible if you can manipulate the UV coords independently of the vertex positions. If you could pull that off, your performance would literally skyrocket.

[DustyPorViva]

Originally Posted by Hezzy002

I wonder.. is there a way to render the entire scene with just one, massive polygon? It would be possible if you can manipulate the UV coords independently of the vertex positions. If you could pull that off, your performance would literally skyrocket.

You can, yes, however Graal doesn't map textures correctly. It will break on the diagonal seam(which is also what is causing the distortion with current rendering). That's why I had to resort to using multiple polygons, to break that seam issue.

Oh, and also even if you use one polygon, you can't emulate distance with it.

[Crow]

Originally Posted by DustyPorViva

Oh, and also even if you use one polygon, you can't emulate distance with it.

Why not?

[DustyPorViva]

Originally Posted by Crow

Why not?

Because you can only apply one texture to a polygon, and you'd need the have the Y scale of the image vertically get smaller towards the horizon. At least, that's how I figure. Either way Graal doesn't like skewing textures on polygons.

[Hezzy002]

Originally Posted by DustyPorViva

Because you can only apply one texture to a polygon, and you'd need the have the Y scale of the image vertically get smaller towards the horizon. At least, that's how I figure. Either way Graal doesn't like skewing textures on polygons.

If you can set the UV coords independently from the vertex positions like I said earlier then you can do the exact same thing you're doing now with a single polygon. How do you set the UV coords?

[DustyPorViva]

Originally Posted by Hezzy002

If you can set the UV coords independently from the vertex positions like I said earlier then you can do the exact same thing you're doing now with a single polygon. How do you set the UV coords?

I don't think you can. Regardless, this is what it looks like when you apply an image to a skewed polygon:



The issue was brought up with Stefan a long time ago, but I don't think it will ever be fixed.

[linkrulz4]

Originally Posted by DustyPorViva

Dat GraaLSD

[Hezzy002]

Originally Posted by DustyPorViva

I don't think you can. Regardless, this is what it looks like when you apply an image to a skewed polygon:

The issue was brought up with Stefan a long time ago, but I don't think it will ever be fixed.

You said it an earlier post you could :/

Anyway, if you can't set UV coords independent of their vertex positions, then the only increase in framerate that'll really help you is reducing the amount of draw calls. In your case that pretty much means the only thing you can do is reduce the amount of polygons. You should really scale the quality up from high to low as it approaches the horizon, though, with this technique it's the only room for speed improvements as far as I can tell.

[DustyPorViva]

Originally Posted by Hezzy002

You said it an earlier post you could :/

Anyway, if you can't set UV coords independent of their vertex positions, then the only increase in framerate that'll really help you is reducing the amount of draw calls. In your case that pretty much means the only thing you can do is reduce the amount of polygons. You should really scale the quality up from high to low as it approaches the horizon, though, with this technique it's the only room for speed improvements as far as I can tell.

I misunderstood, but no I don't think you can mess with UV coordinates.

As for the quality, aye I have considered having near polygons larger, but that would involve a lot of core rework. Also, the problem with that is in order to better imply the distance of the ground towards the horizon, it also needs a decent polygon count.

I'm not really stressing over it. I don't run an awesome rig so anyone with decent gamer towers can probably run it at a 2:1 tile to polygon ratio.

[DustyPorViva]

Managed to get this much done just before bed. Finally implemented rendering gmaps. It's still a bit buggy(some levels seem to not be rendering, some divide by 0 issues with some polygons), but I'm very glad I got past that hump.

[Fulg0reSama]

Originally Posted by DustyPorViva

Managed to get this much done just before bed. Finally implemented rendering gmaps. It's still a bit buggy(some levels seem to not be rendering, some divide by 0 issues with some polygons), but I'm very glad I got past that hump.

I must say Dusty, this is really good, extremely impressive, but I do have one small question.

Do you plan to allow certain tiles to stand up with this (of course once you've worked out any bugs like you've mentioned)?
Example: Trees or fence tiles, or house tiles.

[Hezzy002]

Nice work, but the transformation is still quite off. The scene should see more distortion toward the top in the way of shrinking horizontally. Also, the horizon line isn't appearing properly.

[MattKan]

This is quite interesting. Will we finally see a Graal 3D?

[Crow]

Originally Posted by MattKan

This is quite interesting. Will we finally see a Graal 3D?

Does that look 3D to you?