As for rotating platforms, take the width of the sprite while it's facing 90°, and divide it by 2 to get the radius (you'd probably want calculate that once, and store that in a variable), then add and subtract that from the position.
This can also be used to allow off screen moving platforms to be able to go on screen, based on it's path distance (divided by 2, since it doesn't need to be too big of an area).
But the game is a scrolling platformer, with a camera and all that. Wouldn't that not work? I think the major source of the lag is the constant repositioning. I want something that can take values (like coordinates, thickness, etc.), and check if it would be onscreen, without repositioning.
I can provide some context about the different values of the objects.
(also, if you look in the code, all of the stuff has an extra variable for the level they are in, ignore that, I'm too lazy to rewrite the code to get rid of it. It just basically isn't used, and all objects have the level set to 1)
Platforms:
They cannot move.
They are created like lines.
They have two sets of coordinates, that represent the two points of the platforms.
They have a thickness (most platforms have a thickness of 10, so they are 10 pixels wide)
The troubling part will most likely be that thickness part, as they aren't infinitely thin lines; they do have mass to them.
Saws:
Some move, some don't.
They all rotate on the same cycle, regardless of whether they actually move.
They are a square, that is 24 by 24 pixels.
All of them, regardless of whether they move or not, have two sets of coordinates.
The first is the first point, the second is the second point.
Moving saws move between the two points based on a sine function.
The non-moving saws just stay at the first set of coordinates.
They have another value that is their cycle time.
Non-moving saws have a cycle time of 0.
For moving ones, the cycle time is the number of seconds for a complete loop (starting at the first coordinate, going to the second coordinate, and going back.)
I really don't care about checking down to their direction, it would only be a difference of a few pixels anyway.
Since animating the moving ones to check them defeats the purpose, it should count its entire path.
Checkpoints:
They are much simpler.
Only one set of coordinates, which is where they are located at.
They are a circle with radius of 53, or 106 by 106 pixels.
They pulse on a sine function, going between 65% size and 25% size.
Since there's less of them, just assume they are always at size 65%, or their max.
I hope the context can help. I'm completely unsure how I'd get this function working...
Also, I forgot to mention, the thickness is only present perpendicular to the line. So, if the line goes from (-50, 0) to (50, 0), above and below will have 5 pixels, but the thickness does not push the line past those points.
So, it looks something like this: (the red dots are the two coordinates of the line.)
It would work, you just wouldn't use (my [left V]) , instead use something like ((calculated x on stage) - ((hitbox width) / (2))) . You can also replace (x position) with the calculation you already do to position them on screen (you just wouldn't set the sprite x position).
Now that I'm on my computer (and not my phone), I can explain how to do all this much better.
If the two sets of coordinates represent a line, you just need to calculate the box around the line. This is pretty simple, if you don't care about thickness.
Here's a little visual
This can be calculated by just doing this if we assume both (point A) and (point B) are both a (list [x] [y] @delInput @addInput)
This is just getting the smallest x and y, and then the largest x and y, since the smallest x is always the left side, and the top is always the largest.
However calculating the bounding box with taking into account the thickness is much more difficult, but I have a feeling it won't really be necessary, since you can just add a buffer of the thickness to the on-screen check to pad out the distance (plus, it'll take even more computation time to make a perfect rectangle around the whole platform with taking into account the thickness).
Calculating the bounding box for saws to be checked on-screen, can be done pretty similar to the regular platforms, seeing as how the path is pretty much just a line. However, you would probably still want to add the width of the saw divided by 2 to each side to allow the saw's bounding box to also be in the calculation.
The bounding box of these are also pretty simple to calculate, just take the position, and add the radius to the center to get the sides.
This assumes that (center) is (list [x] [y] @delInput @addInput)
Here's where all the points would end up
After you get the bounding box, you can still use the block I shared earlier to see if it's on the screen.
And since I wrote all this up, and I don't want to completely scrap it
If the two sets of coordinates represent a line, you can calculate the center of the line with (((point 1) + (point 2)) / (2)) (assuming each point variable is (list [x] [y] @delInput @addInput) ), then just use the distance formula to determine a radius in a circle (which would probably be the best option here) from the center to one of the points (it doesn't matter, since they're both the same length), or just calculate the diameter by getting the distance between both points, then dividing it by 2. After that, it's pretty easy to calculate the sides.
Here's a little visual I made to demonstrate how this all works.
As you can see, I was able to get the entire bounding box of a platform with just 2 points.
The reason I would scrap this, is because I realized it's not actually the best solution, since you don't need to calculate the circle of the line to get the bounding box (and it's much simpler without calculating the circle).
If you want my complete visualization script, here it is
