Project Mode7

[Hezzy002]

Originally Posted by DustyPorViva

I cranked up the quality to 1 polygon per tile simply to make it look nice Here's at 16 tiles per polygon:
There's more distortion because of the extreme angle, but honestly I'm okay with that. People with more powerful computers will be able to adjust the quality.

Does it bottleneck during rasterization or transformation with the higher quality?

You could also probably get away by scaling up the polycount for the closer sections.

[DustyPorViva]

Originally Posted by Hezzy002

Does it bottleneck during rasterization or transformation with the higher quality?

You could also probably get away by scaling up the polycount for the closer sections.

I was curious and checked it out before. Simply running the loop at 64*64 with no math or rendering drops the fps down to about 8. Then the math/rendering drops it down to 3.

I was thinking about the scaling resolution as well, but that may be WAY too much work.

[Hezzy002]

Originally Posted by DustyPorViva

I was curious and checked it out before. Simply running the loop at 64*64 with no math or rendering drops the fps down to about 8. Then the math/rendering drops it down to 3.

I was thinking about the scaling resolution as well, but that may be WAY too much work.

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..

[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?