Change The Size of the SubWindow and the Area It Covers In Unity - camera

I'm creating a simple 2D racing game in Unity. The game has another subwindow that displays the enemy's view. Kinda like a small screen on top; that lets you know where your enemy is or what he's doing.
Currently, I'm using a secondary camera to follow the enemy and a render texture to limit the display of the subwindow as well as its size.
However, I want the size of the window to be flexible like if i want the ratio of the window to be 4:3 instead of a perfect square. With my current implementation, whenever I rescale the subwindow, it just rescales everything up including the view being displayed. What I want to happen is, when I rescale the subwindow, the area being displayed should just be wider. It should just cover more area because I made the window wider. I want the view to be independent.
Is there a way to do this with my current implementation? If not, how can I achieve what I want?
I'm new to Unity so I really hope someone could teach me. Thank you so much.

The are viewed is independant of the size of your window, if you want to change how much is displayed instead of just re fitting the same content in another size you'll have to work with the field of view http://docs.unity3d.com/ScriptReference/Camera-fieldOfView.html

Related

Positioning items dynamically for different screensizes

Good morning!
I'm currently trying to create a view similar to this mockup.
I have put down 3 different screen sizes so you can see the issue.
I have a header background image (grey box) with an angled bottom. On the right I want to display an image, which obviously needs to be positioned.
Positioning it horizontally is no issue but how can I position the image vertically? I have it positioned fixed for one screen size but obviously need to make it flexible.
Any ideas? Help would be much appreciated!
David
You can definitely use measure as #rajesh pointed out, or you can use Dimensions. As far as getting the layout consistent across devices, using position absolute and measuring the device height should allow you to get consistency across these devices.
Check out this example I set up, it should be a good starting point at least.
https://rnplay.org/apps/pSzCKg

windows 8 metro app designing for multiple Resolution

I am designing a simple music app where the user gets to play instruments i.e. Drums, and the problem that I am facing is with resolutions.
The drums are images, which I have converted them into buttons. Everything looks great at the state that I have designed it.
However, when I switch to other resolution states, the button(image) are distorted, e.g. skewed, scaled, and looks nasty.
I have tried designing or arranging them via selecting 'Enable state Recording', but the specific designs for that state are not being saved.
Have you tried the approaches discussed here? http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx For the actual button sizes, make sure you are not fixing the width/height with pixel values. Use * weighted rows and columns to layout your grids and have the buttons autosize to fill a given cell in the grid. Then match with the appropriate image resource per the article.
Grids are great for dividing up available space but they can't account for changes in aspect ratios. If your items are still set to Stretch (or Fill) then they can end up out of aspect ratio. Another option is to design the entire layout at a fixed size (let's say 1024 x 768 or 1366 x 768) and wrap the entire thing in a ViewBox. ViewBox will scale all elements equally and maintain the aspect ratio, adding letterboxing (or empty space) on the sides / top & bottom if necessary. This might be a better approach for a drum kit.
Hope that helps.
Redid the whole project of designing again.
This time, I put the image inside a specific grid and that made things lot better. :)

Create an omnidirectional scrollview

I want to create an omnidirectional scrollview that works pretty much like the one in the "Wall of Sound" app. As in, the user should be able to pull into any direction and never get to an end. I want to keep the move to be smooth (and not see the pages change as you would in a standard scrollview). Does anyone know how that can be done? Or would I need OpenGL for that?
Create a 3x3 grid of views, each the size of the viewport. As the scrollview moves into another section, rearrange the views to constantly put the viewport in the center. In most cases 3x3 is sufficient, but if redrawing the views is expensive, you may want to use a larger grid (5x5 for instance). This requires that you have some mechanism for splitting up your full view into tiles.
You can implement the same thing using CALayer if you like. If you go that way, you should consider instead using CATiledLayer. See Matt Long's quick introduction on CIMGF.

CCParallax for a moving background

I got a tiled map and I want to make lava lakes. I wish to have some kind of lava texture image on the background looping diagonally slowly. I could make it with four 960x640 images and move all of them diagonally etc. But when I do, a black/white line appears between each...
... and someone suggested me "CCParallax". I have never used it and am not sure if it really can achieve the effect I am seeking.
Also note that as the player moves on the map, the parallax will need to simulate that as well etc.
So my question is, what would you do for this effect? Four looping images or "CCParallax"?
CCParallaxNode is pretty limited because you can't specify endless parallax scrolling without modifying the class. It also doesn't quite fit your use case.
Using four 960x640 images is wasteful. Just to make some lakes underneath the background this is overkill and will negatively affect performance.
The solution depends a bit on how big the lakes are. For example, if these are just 1 or 3x3 tiles in size you could add a textured sprite underneath each lake. If on the other hand your tilemap consists mostly of a few narrow pathways while the rest is lava lakes, then you need a different approach.
You might want to try GL_REPEAT to repeat a single sprite's texture over a defined area. That allows you to use a relatively small texture, for example 64x64, that will be repeated over the rectangle you specified.
You can then modify the sprite's position each frame to scroll the texture. Every time the sprite has moved 64 pixels in horizontal or vertical direction, you subtract 64 pixels (sprite.contentSize.width) from the sprite's position to reset it back to its original state. That means the sprite will never move further than 64 pixels from its initial position in any direction but you still get smooth scrolling.

Translate Colors to Image?

Im not sure how else I should approach it, but if I was to (in my mac application) have a grid of NSViews, which the user can change the colour of each, is it possible to then translate this, so now I have been given a colour for each pixel by the user, make this into an exportable image?
I honestly can't think of how else to do this. I don't want to go ahead an realise I have taken a rather foolish path.
The idea is I will have a grid of squares which the user can paint, a colour in each square, a square representing a pixel in the final image. So they paint with like a paint bucket filling each one, then export it into an actual image file.
Any help much appreciated, thanks.
A grid of NSViews sounds really heavy for what you're doing. Why not write one single custom view that checks the mouse position and modifies the data appropriately? Then you'd write a custom drawing method to fill the custom view, and you could use the same exact draw method to write to an NSImage which you could export.
You'll need to do a bit o' math. For each "pixel", call -set on the appropriate NSColor, then use NSBezierPath's -fillRect method. It may help you to get out a pencil & paper to figure out the math for the rect origins & sizes.
Check http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaDrawingGuide/Introduction/Introduction.html for help if you've never done custom drawing before. It's really not that bad, just takes a little reading. :)