Tasharen Entertainment Forum
Support => NGUI 3 Support => Topic started by: sluresylta on September 21, 2012, 10:15:24 AM
-
I'm making a board game, and have just started on the zooming implementation. Ie. when the player double clicks, the board zooms out. Another double click zooms back in.
So far, I'm doing this simply by toggling the camera size between 1 and 2. My sprites are 44*44 px, and this is how they're displayed - and look good - at the zoomed-in state. Once I zoom out, though, they become visibly degraded (diagonals get jagged edges, straight edges get anti-aliased effects etc). Far more artifacts than I get when doing a resize in Photoshop, for example.
I realize the sprites would be hard put to look perfect at any zoom level/camera size, but I've deliberately chosen to have one zoom level be exactly double the other and have sprites with an even number of pixels to get as few artifacts as possible.
So, I'm guessing I'm missing something. Is it enough to change the camera size for a zooming effect? Or is there something NGUI-specific I should be doing in addition to this?
-
If you want it to look crisp, you will need to create and use an atlas that has sprites with double the original's size, similar to how replacement atlas feature works for SD/HD atlases.
-
Ok. I guess expecting runtime, Photoshop quality resizing was a bit much :-D
Anyway, as I understand it, I could theoretically have any number of atlases, each tailored for its own zoom level. Ie. I'm not limited to only two, as in the SD/HD situation on iOS. Correct?
And I can easily switch between these as the user zooms in and out, without any visible delay, assuming the game as a total is easy on computing resources?
-
Yup.
-
They call it mipmapping in them there fancy places. 8)
-
I have this working, with a slight snag. When I start the game, I'm zoomed in and everything works fine. I can drag the board (UIDraggablePanel) around, and there never appears any blank area around it. However, once I zoom out and switch atlas to make things crisp, I'm suddenly able to drag the board too far down and/or up. Ie. when I drag down, the top edge of the board/panel doesn't stick to the top edge of the viewport.
Any idea about what could cause this?
-
Try calling UpdateScrollbars(true) or if that doesn't work -- ResetPosition(). If not, double check the bounds -- clicking on the panel should show the pink outline. Is it where you expect it to be?
-
Those two didn't work, so I checked the bounds, like you said. The rectangle that looks the most like pink to me seems to indicate the clip range/view port. Ie. any part of the panel outside this rectangle is not visible. This rectangle looks more magenta than pink to me, though. But maybe we're talking about the same rectangle?
The only other rectangle I see when selecting the panel is a big orange one that encompasses the whole panel.
-
Maybe I should also add that the panel I'm testing with has a width that is narrower than the viewport and a height that is taller than the viewport. I don't know if that matters, though.
-
Can you post pics of what you mean? "too far down" can mean a lot of things.
-
Yes, sorry for being a bit vague. Here's a link to a quick screen capture clip I did of me zooming in and out, dragging the panel around (sorry about the lame text on top, but you can see what's going on):
http://www.surfacetension.no/20121012-Record.mov
The blue, rectangular background is there because I added an extra camera to show how big my viewport/output game size is supposed to be (the resolution I've set in Player Settings for the web player). The actual board panel is rendered by an NGUI-created camera.
As you can see, I first drag the panel around in a zoomed-in state, and it sticks nicely to the viewport edges. Then I zoom out, and I can drag the panel's top and bottom edges far into the viewport. I also can't drag the panel much horizontally within the viewport.
The clip range rectangle moves around like expected on the panel in the scene view while I'm doing this. So maybe this is something camera related?
-
Should I be adjusting the clip range when changing the camera size?
-
Ok so you drag the camera around, not the panel. I don't recommend changing the ortho size of the camera at all. I'm not sure how the drag logic will behave with a size other than 1. The entire camera-based approach is an example that shows how it can be done, but it's not the suggested way of doing clipping. Shader-based approach via UIDraggablePanel is a lot more powerful and is what's used everywhere except that one example. If you insist on using the camera-based approach, look in the UIDragCamera script and adjust it as you see fit.
-
Actually, no - there's no camera dragging involved here. I'm dragging the panel. I did look into camera dragging first, but noticed panel dragging was recommended, so I went for that instead. I may have set the panel dragging up wrong, of course, but there are no camera dragging scripts anywhere in my hierarchy. When I drag the panel, the panel moves and the camera stays still.
The panel I'm dragging has both the scripts UIDraggablePanel and UIDragPanelContents attached directly to it. Maybe that's related to this behavior? Should those two scripts be on different objects?
-
Why would you have both there? UIDraggablePanel should be on the panel, yes... but UIDragPanelContents should be on colliders. Panels shouldn't have colliders.
-
Ok, great - so that's probably what's causing my problem, then.
I was bumbling about a bit when setting this up, since I couldn't find any examples, tutorials or whatnot that covered what I wanted to do: Drag the entire panel by click-dragging anywhere on the panel. Ie. drag the whole board around, regardless of what was on it.
So, what's the correct way of achieving this, then? Where does the collider need to go if I can't have it on the panel? Does every sprite in the panel need one, with UIDragPanelContents attached? If so, will that affect performance in any noticeable way if there are 500-2000 sprites in the panel (about 10 unique sprite types, small, all using the same atlas)?
-
Collider usually goes on the sprite that serves as the background for the panel. That's the collider that should also get a UIDragPanelContents. All that script does is forwards drag events to the draggable panel script.
-
Ah, ok - that makes sense :-)
So - considering that the sprites/board squares I already have in that panel completely cover the panel - would it be feasible to use a 1-pixel, stretched graphic as background to save atlas space?
-
I have now changed things up, so that my hierarchy is as follows:
Root
->Camera
-->Anchor
--->Panel
---->Empty game object/sprite holder
----->Background sprite
I've attached a box collider and UIDragPanelContents to the background sprite.
The board is draggable, but regrettably I'm seeing the exact same behavior as I had before. So I guess that was a blind alley. Anything else that could cause this?
-
It doesn't need to be a sprite. It can just be an empty object. The advantage of it being a sprite is that NGUI menu -> Add Collider will automatically resize the collider to the sprite's dimensions. With an empty game object you need to resize it yourself.
-
Ok, I removed the sprite - I don't want unnecessary objects floating about - and moved the collider and the UIDragPanelContents script to the empty object instead. After juggling the event handlers etc. around, I got the panel draggable and everything else working. Except for my original problem: the panel's edges would still be dragged way into the game window/viewport.
After much headscratching, observation and a couple of semi-qualified guesses, though, I managed to figure it out and work out a solution. I have no idea if it's an ideal solution, but it seems to work well. Here goes:
While I was looking at the Scene view while dragging the panel around in the Game view, I noticed that what was restricting how far I could drag the edges was the pink rectangle indicating the clip range. Not the edge of the viewport, as I had previously assumed.
When I zoomed out by doubling the camera's orthographic size, the camera of course rendered not only what was going on inside the clip range, but also all that was going on outside it. Which was basically just a black nothing.
So, in order to make my zooming work properly, I had to do a couple of extra steps. Namely resize the clip range so it would cover the same size of area as the camera frustum (is that the correct term for orthographic camera's?), and slide the panel's anchor over to have the clip range precisely overlay the frustum.
I hope this helps someone down the line.