Elysian Shadows

Hi guys! This is more a question for the developers but if anyone knows, how do you guys go about handling off-screen rendering? I was skimming over the photos on the site when I came across the Mario World 1-1 recreation and noticed the polygon count was 3000+. Not that it would be a problem for todays hardware or more specifically, the hardware you're developing for but i think it would make a nice feature if some kind of culling method was used for the tiles off-screen. Considering that you are planning to release libGyro to the public you can't really predict the projects that will be developed with it. I could be wrong and you have already implemented something like this but i thought i would ask as i've not seen it mentioned before.

Also, i remember Falco commenting on developing for the iPhone/iPod Touch/iPad saying he was against it? Why are you so against it? You could make some serious cash that way. I know objective-C isn't the most desirable language to use but from my experience you can use C/++ and leave objective-C for the specific hardware "communication". I think it wouldnt take long to add an objective-C rendering system specific for the Apple products. Although, i think i would stick to the iPad as the screen size for the other two devices seem too small for a game like ES. Anyway, thats my two-cents

If you do not have camera rotation, and you're rendering tiles from an array, then you can simply loop through the array for the tiles that WILL be on screen and ignore all the others, like

for (column = camera.x / tileWidth; column <= (camera.x + camera.width) / tileWidth; column++){
for (row = camera.y / tileHeight; row <= (camera.y + camera.height) / tileHeight; row++){
renderTile(tiles[column][row] );
}
}

If this doesn't suit the job, you could always look into something more advanced such as quad-trees. But for a simple 2d game, you really shouldn't have to worry that much

Well for a rotated/zoomed camera, you can do something like this.

• calculate coords of rot/zoomed camera rect
  create an AABB around it (so you don't have to deal with all the crazy collision stuff)
  use RyanPridgeon's method, treating the AABB as the camera

i wasnt actually asking for tips on how to actually perform tile culling but thankyou anyway lol i was just wondering how the ES dev team do it if at all. Doesn't look like they do.

tinni5 wrote:Doesn't look like they do.

If that is the case, it would definitely make my day According to some forum posts they consider even ASM optimization. I don't think they've missed the easy way.

K-Bal wrote:

tinni5 wrote:Doesn't look like they do.

If that is the case, it would definitely make my day According to some forum posts they consider even ASM optimization. I don't think they've missed the easy way.

According to the Mario World 1-1 images they are rendering 3500+ polygons which seems excessive in my opinion. There seems to be IMHO < 600 triangles which amounts to about a 2400 polygon overdraw per frame. Im just trying to find out if they are using a method which im overlooking. I think the Mario remake was before the engine was rewritten so they might have made some changes but it was just something i noticed.

Oh, right. I remember that.

It had nothing to do with offscreen tiles. If you have a look at the minimap, you'll notice that every "solid" is represented as 2x2 quad. A great way to assfuck any hardware.

That minimap was more of a "conceptual" thing at that point in time. We weren't sure how we wanted to handle it, so I just kind of threw it together. As you said, it ran fine on a PC, but I had literally put the thing in #ifdef #ifndef blocks to make sure the thing wasn't running on Dreamcast... that wouldn't have been pretty.

K-Bal wrote:According to some forum posts they consider even ASM optimization. I don't think they've missed the easy way.

There are plenty of areas for improvement with assembly once I get around to it. Not even "optimization" necessarily either. The PSP's vector unit is only accessible via straight assembly. The Dreamcast also has 4x4 Matrix and 4x1 Vector registers that allow for ultra-fast calculations. Both of these really SHOULD be happening in assembly to take a load off of the CPUs.

In the past, we had simply made sure 1) to only iterate through onscreen tiles to render and 2) to check if an entity is onscreen before rendering. Once we introduced uniform zoom/scale, it got QUITE a goddamn bit more messy to determine what was and was not onscreen. We haven't really decided on any one algorithm.

Ginto wrote:Well for a rotated/zoomed camera, you can do something like this.

calculate coords of rot/zoomed camera rect
create an AABB around it (so you don't have to deal with all the crazy collision stuff)
use RyanPridgeon's method, treating the AABB as the camera

That's a great temporary fix, but as the camera zooms farther and farther out, and you look at rotating your viewport something like 45 degrees, you're still going to be potentially overdrawing a FUCKLOAD.

They are using off screen tile culling in there engine.

When I asked Falco how he implemented it, he said something like this:

Take the top left of your screen and divide it by your sprite size.
Then write a for loop within a for loop that iterates from the top left to the bottom right.

GyroVorbis wrote:

Ginto wrote:Well for a rotated/zoomed camera, you can do something like this.

calculate coords of rot/zoomed camera rect
create an AABB around it (so you don't have to deal with all the crazy collision stuff)
use RyanPridgeon's method, treating the AABB as the camera

That's a great temporary fix, but as the camera zooms farther and farther out, and you look at rotating your viewport something like 45 degrees, you're still going to be potentially overdrawing a FUCKLOAD.

looks like bresenham's line algorithm is gonna be use for more than just sprites, eh? I still haven't really been able to figure that thing out SAT collision would just be a clusterfuck, and even circular collision would probably be overkill, and overdraw too much.

Ginto8 wrote:

GyroVorbis wrote:

Ginto wrote:Well for a rotated/zoomed camera, you can do something like this.

calculate coords of rot/zoomed camera rect
create an AABB around it (so you don't have to deal with all the crazy collision stuff)
use RyanPridgeon's method, treating the AABB as the camera

That's a great temporary fix, but as the camera zooms farther and farther out, and you look at rotating your viewport something like 45 degrees, you're still going to be potentially overdrawing a FUCKLOAD.

looks like bresenham's line algorithm is gonna be use for more than just sprites, eh? I still haven't really been able to figure that thing out SAT collision would just be a clusterfuck, and even circular collision would probably be overkill, and overdraw too much.

Oh god no, you'll wanna be looking into a tree structure for this. Like mentioned before, the quad tree is a good way to tackle it. Checking collision for all the tiles is definitely not a way you're going to want to tackle performance.

I imagine when GyroVorbis said he was checking if a tile was on screen before rendering, he meant checking using the final transformed vectors, as I recall something about Elysian Shadows or LibGyro using its own transform system.

Anyway, @OP: you just use the for loop, these methods are only for more advanced cameras which allow zooming and rotation etc

RyanPridgeon wrote: Anyway, @OP: you just use the for loop, these methods are only for more advanced cameras which allow zooming and rotation etc

He already said he knows how to do it, he was just wondering about the team >.>

eatcomics wrote:

RyanPridgeon wrote: Anyway, @OP: you just use the for loop, these methods are only for more advanced cameras which allow zooming and rotation etc

He already said he knows how to do it, he was just wondering about the team >.>

Ye...so....TAKE THAT!! Thanks for clearing it up Falco and everybody else.

May i ask how the PSP build is coming along? Or has it been placed on the back burner for now whilst libGyro is developed? I'm guessing i have to wait until ESRev 3 to see more lol

tinni5 wrote:

eatcomics wrote:

RyanPridgeon wrote: Anyway, @OP: you just use the for loop, these methods are only for more advanced cameras which allow zooming and rotation etc

He already said he knows how to do it, he was just wondering about the team >.>

Ye...so....TAKE THAT!! Thanks for clearing it up Falco and everybody else.

May i ask how the PSP build is coming along? Or has it been placed on the back burner for now whilst libGyro is developed? I'm guessing i have to wait until ESRev 3 to see more lol

It's coming along just as well as the others.

With libGyro, there is no "putting <insert platform here> on the backburner." The engine itself is a completely separate entity from the platform. As long as the libGyro implementation for each platform implements all functions that the engine needs (which it does on all three), it's completely platform independent.