I’ve been looking at various posts/etc. and haven’t zeroed in on anything. What would be the best way to scroll a large image (can’t be tiled) within a larger scene. So imagine 50% of the screen has various buttons or other elements and the top half is a scrollable 2D map that relates to a larger 4096 x 4096 sized (or smaller) image that is perhaps a historical map or something like that which can’t be easily tiled. Just need some pointers toward figuring it out. Thanks!
@britzl has a camera and split screen example here that might help: http://britzl.github.io/publicexamples/
1 Like
I looked at it but couldn’t figure out how the split screening would work. Will look at @sicher 's link…
If I have understood correctly, you are not actually split screening according to the traditional definition (i.e two cameras, each sending their view to a portion of the screen). The buttons and other elements are just GUI elements that should be part of the camera object, so that they always stay in the same position on screen.
The easiest thing to do would be to use my example which Davej linked too, and put your GUI elements in the same object as the camera. That way, when the camera object moves, the GUI elements move with it (thereby staying in the position, on-screen.
Josh
In your case I wouldn’t bother with multiple cameras and true split screen. If you create the buttons and stuff using GUI you don’t even have to bother with parenting them to the camera as @88.josh suggests. In the default render script the GUI is drawn in a separate pass and wouldn’t be affected by the camera. My scrolling and dragging example that @Davej linked to should be a working solution to your problem.
well to be clear it wouldn’t necessarily be a GUI only system down below. It could be sprites, etc. I’ll look at both and report back what I did once I do something. My senses is I will start with the multiple camera approach first, so the other half is wide open for whatever else I would do there. I’m mostly creating frameworks now so my sense is to be wide open.
So I have this working a bit. A few weird things…
I’m using 2 GO (camera1.go and camera2.go) and I’m inserting a command (temporary) to “force” camera2 to send a render view of x+5000 to just move it elsewhere in the scene from the core “map” sprite used for Camera1.
This sorta works as proof of concept but here’s where I’m currently stymied:
- both scenes seem to render “small” i.e. zoomed out a bit vs. if I just had a single camera object pointed at scene. So not sure where it’s deciding/how to do that - though I’m still trying to figure that out. I know it has something to do with the aspect ratio or the projection style but can’t quite figure it out.
WHERE IT gets weird is depending on when I start the build, the camera positions (top/bottom) are flipping. i.e. Camera 1 should be on top of Camera 2 but it’s reversed. Seems like it’s s timing issue in terms of when it chooses to render each object?
Are you using my split screen example as a basis? The render script I use there will zoom out and center when you use multiple cameras: https://github.com/britzl/publicexamples/blob/master/examples/camera/split_screen.render_script#L35
If you ignore that bit or set the zoom factor to 1 it should render in normal size.
As for screen positions this is probably my fault. The cameras are stored in a table (acting as a map): https://github.com/britzl/publicexamples/blob/master/examples/camera/split_screen.render_script#L88 and they are iterated over using pairs(): https://github.com/britzl/publicexamples/blob/master/examples/camera/split_screen.render_script#L64
Using pairs() doesn’t guarantee order which is probably why it’s not consistent. It would probably be better if it had accepted 1-indexed sequence of integer camera ids and iterated the list using ipairs() instead.
1 Like
Definitely using your code - it’s been helpful, I’m just too green to perfectly disassemble it.
So I figured out the Zoom factor just before checking on your reply - just trying to experiment with a way to make this able to be set as a variable vs. calculating it - right now I’ve hardcoded local zoom_factor = 1.
As for screen positions that totally makes sense now - I’m still learning the issues with Lua tables and ordering but I think I can adapt the code to enforce the order. Once I have that working a bit better I can share it.
So reporting back. I’ve managed to make some progress. I am now able to spawn cameras using a factory, and position them a bit as I want. Not everything is fully parametrized but getting closer. Cameras can be deemed scrollable as well, but I’ve got to redo the code for that from my single camera test to work with split screens. After that then working on adding some other useful functions.
1 Like
So a small update, I’ve got a system that lets you define sections of the world to map to specific camera instances, and you can drag sprites between those instances (or restrict them) – now working to make it work with the ability to scroll any camera area (have that working but not at same time with moving sprites). What I don’t have working at moment is re-sizing the window as I’m holding Map Zoom to 1. Resizing would mess up coordinate mapping as it works so far but I think once I have this working I can re-do the coordinate system with something more percentage based and get some level of resizing working… just figure get it working at one level first.
1 Like