LÖVE

I'm using the HUMP camera and got what I wanted in less than 15 minutes which is fantastic.

It has movement smoothing (x/y movement) but it doesn't seem to have zoom in/out smoothing. The zoom jars quickly and suddenly and checking if I'm missing something?

I'm happy to "roll my own" zoom smoother for HUMP.Camera but obviously won't if I don't have to. Cheers.

The other thing I'm trying to do is zoom and pan around while the score remains locked at the top of the screen. This seems very difficult with HUMP. If I draw something in the world at 50,50 (for example) and then pan the camera down then that score moves off the top of the screen.

"Easy" I think - I'll just redraw that score at the new X,Y location so that it appears to be locked at the top. It seems that determining that new X,Y is not straight forward.

worldcoord doesn't do this and cameracoord is not explained/documented (and doesn't do what I want). Anyone had this problem before?

why not just tween the parameter passed to camera.zoomTo function?

Why not draw the score after finishing the camera?

I have rolled my own zoom smoothing but wanted to make sure I wasn't missing something obvious.

The way hump seems to work is that zooming or scrolling will move objects off screen when the camera moves. The origin (top left corner) is actually off the screen. The origin doesn't reset - meaning I no longer have a point of reference to draw/refresh fixed objects.

Hard to explain. An object that is drawn at 0,0 before the scroll needs to be redrawn at (x,y) but it's not clear how hump can tell me what this new x,y value is. If I could determine the new x,y after the camera movement then I could redraw fixed objects in the right place in a hopefully seamless way.

Those 2 functions do convert world coords and camera coords.

Camera coords are what you see on the screen.
World coords are where coords actualy are in your logic.

(or maybe it's the other way :^) )

Maybe the "origin" is not the topleft in a camera system but the middle of the viewport perhaps?

Also, score is usually part of the GUI that shouldn't be affected by world camera transforms anyway, as pgimeno said above.

Yes - the origin of the viewport - or the screen origin relative to the world's origin is tricky to track.

I need to play with it more to understand where the score needs to be drawn each time the camera moves because currently it scrolls off-screen when the camera moves.

togFox wrote: ↑Wed Feb 17, 2021 7:59 am I need to play with it more to understand where the score needs to be drawn each time the camera moves because currently it scrolls off-screen when the camera moves.

It needs to be drawn after you draw everything related to the world and you stop using hump.camera's transformation stack; its position should not be affected by the camera at all.

Gosh - as simple as that:
As suggested - I did this drawing outside the camera manipulation and it worked instantly. I don't know how long it would have taken me to stumble across that accidentally. Thanks!!