Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

932 Good

About Sacaldur

  • Rank

Personal Information

  • Interests
  1. 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.
  2.   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".)
  3. 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
  4. 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.
  5. 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?
  6. As others pointed out already, it would be better for you to just direclty use the methods and properties already available. Hiding an Image should be done by deactivating the game object. (This way, it also doesn't matter if it is an image, a text, or a composition of multiple UI elements.) Same goes for setting the image: just assign it directly, unless you want to apply some special logic that really needs to be encapsulated in another component. Besides that: You should store references to components you're using multiple times. Searching for them every time using "GetComponent" takes more time. If it is done once a frame, it's really worth the refactoring. Also, you should calculate your _imageIndex with something like this._imageIndex = (this._imageIndex + 1) % this.sweepingFrames.Length;
  7. Sacaldur

    GDC Social Tips

  8. Sacaldur

    Mechanics, Dynamics, Aesthetics

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!