Jump to content

Sacaldur

Member Since 25 Mar 2013
Offline Last Active Nov 18 2016 03:15 PM

Posts I've Made

In Topic: Unity Software Architecture - how to make reusable UI classes that inherit fr...

14 November 2016 - 04:15 AM

The problem about this is: you might be able to use this for Image-Components of the new UI System (UnityEngine.UI.Image), but you'd need to create a sprite on the fly, which is more expensive.

In Topic: Trying to spawn boxes just outside the cameras viewing rect

03 November 2016 - 03:33 AM

Camera.main.transform.position.y might be the top edge, so you might just be able to spawn the object there (or ObjectHeight above).

 
Yeah, that worked, thanks :)


No, that value is not the top edge of the camera, but it is its center. If it results in the desired behavior, the problem lies at another place. The camera in use might not be the main camera, resulting in Camera.main returning the wrong camera. The spawned object might not be "centered" properly, meaning its position is not in its center. Without further knowledge about the GameObjects in the scene and the other code, I can't say with certainty what the reason for this actually is.

Btw: you're better of not using Camera.main, since it probably makes a search for the proper camera by the Tag "MainCamera" every time you want to retrieve the camera. Depending on how often you use it, this could affect the performance of the game. Also, by not searching for the object you want to use, but by getting it assigned from outside, your code is getting rid of dependencies. (See "inversion of control".)

In Topic: Trying to spawn boxes just outside the cameras viewing rect

30 October 2016 - 04:20 PM

The value stored in orthographic size is just the "vertical size". Since the camera is most certainly not showing a perfectly rectengular view of the game, the "horizontal size" is a different value. You can calculate that by horizontal size = vertical size / height * width. Since the aspect ratio is already calculated with a aspect ratio = width / height, you can shorten the calculation to just horizontal size = vertical size * aspect ratio

In Topic: Trying to spawn boxes just outside the cameras viewing rect

29 October 2016 - 06:33 PM

He mentioned he is using an orthographic camera, so the depth shouldn't be a problem.

Take a look at the (orthographic) size of the camera. This value is half of what the camera whill capture on the vertical axis. If you add/subtract it to/from the y-position of the camera, you'll get the upper/lower edge. To get the left/right edge, you'll have to multiply it with the cameras espect ratio, and add/subtract the result to/from the x value. The property "aspect" should be the one you can use for that, otherwise you can calculate it by deviding the viewport width by the viewport height.
After you got the the corner, you'll need to add/subtract half the objects size you want to spawn in order for it to be just outside the cameras view.
(All this assumes your camera is not rotated. If it's rotated in 90° steps, you'll just need to swap some angles or invert some values. If it is another angle, you'll need to do some more math, but the basic calculation should be the same.)

Btw: The C# tag is visible in the topic overview, the Unity tag is not. You might want to change the order of the tags, since Unity is the most important information in this case.

In Topic: Unity Software Architecture - how to make reusable UI classes that inherit fr...

26 October 2016 - 12:52 PM

While you're creating the UI, you know what you're using. In general, this should be Image (those are using Sprites). In some special cases, e. g. when the content is generated on runtime (e. g. once a second or more frequently), then the RawImage should be used, and only then. (If the Image is generated very seldomly, you could generate a Spriteout of it, but since its a somewhat costly operations, you can't do it to frequently, since this would have a huge impact on the performance.)
Right now, you might still have some GUITextures, but since you're starting to use the new UI system, you should get rid of anything done in the old UI system as fast as possible. Once that is done, you don't need those tightly-GUITexture-coupled anymore.

In the end, if there is no reason to do otherwise, you should _only_ have 1 Image component in use.
And even if you'll need to use RawImage additionally for some special cases, you will know if it is a generated Texture (-> RawImage) or a predefined Sprite (-> Image). So you know the proper type and you won't need abstraction.


Btw.: you have 8 tightly coupled scripts. What are those scripts doing?