Topic: Rides Rendering Tips Needed

Forum: Development

2 posts 773 views

Posts: 19
Joined: Feb 7, 2022, 7:27:49 PM

Hi all,

I am working on some new rides currently. Yesterday I created a Spiral Slide and today a cash machine / ATM. And I am working on a Top Spin. However there is a problem that really gets in the way when designing any ride larger than 2×2 voxels, and I want to ask for suggestions how to make this less inconvenient for designers.

Allow me to explain how in-game rendering currently works. A ride that occupies multiple fields has to be split into image stacks by the graphician; e.g. for a 3×3 ride that's 9 stacks. The game then draws each field occupied by the ride separately with the respective image stack. So technically what you see is not 1 ride with 9 fields, but 9 rides with 1 field each arranged next to each other.

Splitting an image into such stacks is extremely laborious, and more time-consuming than actually creating the ride. The result looks like this:

Nice, isn't it? No it's not. So why do we do this?

For rides of size 2×2 and smaller, it is perfectly acceptable to just put the ride in one piece on its lowermost field and leave the other sub-images empty. That's how I did it for the spiral slide.

But when we do the same thing for bigger rides, the problem arises that the entrance and exit may not be drawn behind or in front of the ride correctly. When the entrance is located on one of the ride's two front-facing sides, but at least one whole field row further up than the ride's lowermost field, the entrance is drawn first, and the ride is afterwards drawn on top of it, even though the entrance should overlay the ride and not the other way around.

So my question is, how to fix Z layering of large objects without being forced to split them into stacks?

A naïve idea would be to declare "precedence rules" for the order in which fields are drawn. Then we would declare that for an object A adjacent to one of the rear sides of an object B, A has to be drawn before B, and for an object A adjacent to one of the front sides of an object B, A has to be drawn after B. However this sounds like a really inefficient approach.

If someone has any idea how to solve the problem, it will make graphics design for FreeRCT so much faster, easier, and more fun, and will accordingly increase the rate at which new rides can be added. Thanks in advance for your suggestions 🙂️

Posts: 8
Joined: Mar 14, 2022, 10:33:31 AM

I suppose this happens, because images are drawn from back to front by placing each fields image onto the screen, right?

So that the row with the entrance is rendered, then the next row, and finally the actual image overlays the entrance.

I suppose the code already has a mapping of fields to rides (to prevent other objects to be placed there etc).

So my naive approach (never looked deeper at the code) would be to continue drawing from back to front, but if an occupied tile is reached, the corresponding object is drawn at its correct position and marked as "drawn", so when another tile of that object is reached, it won't be re-drawn.

This would require that the images / objects are not only related to their base position, but assigned to every tile and store their coordinates independently.

My approach would create the issue that drawing order might be incorrect, if some object is below the top tile (e.g. when the tile some rows above is hit, the object is drawn, while an entrance / object next to it should actually be covered).
This might be solved with some extension to the approach: Each object is assigned tiles that should trigger drawing, which is for square objects always the middle (including that row).

What could also work: Instead of splitting into stacks, objects could be split into sides (which sounds easier to design for me). So the rear of the object is not drawn (and thus avoids my issue I describe above), but as soon as a tile that belongs to a side is hit, it draws that side onto the screen.

I hope my ideas can at least serve as some inspiration, and I didn't misunderstand the current system too much.