New update broke rendering

[selimanac]

@Mathias_Westerdahl

Not sure what you mean and how it’s different from e.g. the camera.get_projection()/camera.get_view()?

I’m sorry, but I also didn’t fully understand what you’re asking.
I don’t want to hijack the actual sender’s subject here, but simply put:
local draw_options_world = set_camera_world(state) returns nothing in build-in render.script but sets the one of the cameras as main_camera at state. So, the draw_options_world is simply empty, and the state contains only one (the last) camera view/projection/frustum. You may call this a habit, but I like to know which camera’s values are being used (since I sometimes use two cameras in the same render script), so I prefer to get exactly what I needed.
Basically, I would like(this was my suggestion) to access all my cameras and their properties in render.script without needing any get operations. I’m specifically talking about the built-in render.script here. I know we can customize it as we like, but it could be easier for newcomers to get started.

@jhonny.goransson

Sorry but I don’t see the point of doing what you are doing here, you are calculating a frustum matrix from the camera, and then setting the same matrices on the render context which is the exact same thing as render.set_camera does internally.

I also need those view/projection matrices and their inverted versions elsewhere. So I had to get and invert them one way or another, and I chose to do it in the render script. Is this the wrong thing to do?

I might not fully understand render.set_camera() -I haven’t used it yet or read its docs- but I have to change the projection/view multiple times (in this case, after the light projection, I set them to the camera’s). Since draw_options_world is empty, I don’t see the point of using the state’s main camera frustum. I can simply set it myself, especially when I have constants. Also sometimes at some places I might prefer not to use frustum at all. My knowledge might be limited on this subject, so please feel free to share any suggestions. I’ll be glad to learn more deeply if I’m mistaken.

[robotiger77]

I see that it works like intended. But my argument is that it’s not a correct approach. Think about all these pixelated games where you will get distorted graphics after scaling with a ratio of, let’s say, 1.25. All the pixel art goes to nothing. I’m asking for a way to avoid it, and looks like there isn’t any right now. Pointing on some kind of problem here.

[robotiger77]

Actually it can be undone very easily, by dividing camera components zoom (GUI camera is uninfluenced) and the window size by the display scale factor… And it looks like the new API is on the horizon. I was stressing too much, pardon me!