Log In  

I've just started experimenting with clipping and camera movement and it seems that when I move the camera, clipping rectangles I use on-screen don't appear to follow cleanly with the camera. I'm attaching a cart that shows what I mean. Arrow keys move the camera and Z / X reset it.

Moving the camera keeps the items I'm drawing in the correct position while failing to move the clipping rectangle.

Here is the cart:

Cart #pillspinstatic-0 | 2020-06-09 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

A rough fix: I got the camera coordinates:
cx, cy = %0x5f28, %0x5f2a

and used them to offset the clipping rectangle by those values:
clip (o.x - cx, o.y - cy, 11, 6)

I probably could just reuse the variables I moved the camera with for the fix, but I wanted a solution that wouldn't depend on those variables existing.

It works, but I wish there was a better way to make the clipping rectangle follow the camera.

Here is the cart with the fixed code:

Cart #pillspinfixed-0 | 2020-06-09 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Is this a known thing? Is this a bug or a feature? It's not crippling since I can just do the peek thing, but it bothers me >_>

Here's how the pills are supposed to spin, if you're curious. The weird clipping is even more wild when they're spinning as intended, especially when moving the camera vertically:

Cart #pillspinroll-0 | 2020-06-09 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#77856 2020-06-09 17:09 ( Edited 2020-06-09 17:13)

I think the idea with clip() is that it's a viewport. If you had a splitscreen game, you'd want clip to be completely separated from camera code, so it would draw properly on both sides.

Note also that cx,cy in your fixed cart have the same values as camx,camy. There's no need to peek the camera's coordinates from memory, since you can just use those values.

P#77915 2020-06-10 21:58

Yup, wasteful programming on my part--I was caught up in trying to find a solution that could generalize to situations without those variables, but in retrospect, I don't think there would ever be a situation where a memory peek would be more efficient than just saving the camera data as a global variable as I change it.

That makes sense -- it seems that clip () affects where the program is allowed to draw its elements, whereas camera () affects where the elements are drawn. Thanks for your help, shy.

P#77917 2020-06-10 22:29

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-29 13:44:00 | 0.011s | Q:21