Home | Documentation | Atomic Chat | Github

Scene dimensions


Hi All,

I was designing my scene but I do not now the dimensions, where it starts where it ends. Is there anyway to know this info? Please.




There are no arbitrary or explicit limits in scene dimensions in Atomic. There’s a practical limit that’s when the single precision floating points start to get too inaccurate for your usage, but that shouldn’t be an issue for >99% of cases… as a rough estimation, if you’re using the physics engines (which are somewhat sensitive to that) you’re fine up to about 10k units from the origin, which if you’re using meters for units is a 400 square kilometers area or an 8000 cubic kilometer volume (8*10^15 liters :blush:).

If you’re asking however if there’s a way to know what is the visible area for a 2D game for example, that’s dependent on the camera setup. If you’re using an orthographic camera, you can switch to the ‘front view’ (alphanum 5) in orthographic projection (O key) with the camera selected to see what the camera will display, however, that doesn’t reflect the actual end result in terms of aspect ratio. I’m not sure if there’s a better way to do that but maybe this isn’t what you’re asking.

Slider constraint

Hi Alan,

Thank you for your answer.

Yeah I had the impression that there is a lot of space, so I got lost when I saw the black screen in the scene. The camera tips is a good one. :slight_smile:

What I am looking for it’s a way to design the game and to understand in which way the Engine works. Eg.

I would like to make a 2D game (portrait-orientation), so I need to see where to put my assets and what is visible on the mobile screen and what is not, this I guess could be accomplished by using the camera (right?).

Now supposing that I want to deploy on two different devices, what happens? The Engine is going to resize the scene in order to display it correctly? Or I have to design the assets in a way in which fits the majority of the screen sizes?

Thank you,


Hi Marco,

That depends largely on the camera setup of your game. For a fixed-camera game that you can’t discard any part of the gameplay area (like breakout for example), there’s not much option really, the best you could do is try to fit as most of it into the screen (because changing pixel ratio looks really bad), and add some eye candy to fill the non-gameplay areas. Some fixed-camera games can afford to discard some parts of the gameplay area that aren’t that important, and some even allow the user to choose a camera mode that pans around to always show the area of interest - somewhat common in pinballs. For games where the camera naturally pans around, you just get different view area aspects (so if the vertical fov is fixed, in screens with larger w:h ratios you can see more horizontally). The best way to deal with different screen aspect ratio depends on each specific case.

Since you’re asking how to position objects in the view area though, I’m assuming you have a fixed-camera game, so possibly you’ll have to sacrifice some usable screen area in some devices. However, when it comes to actually having an indication showing where the exactly screen limits would be for a given aspect ratio, I don’t think there’s built-in functionality for that but it shouldn’t be hard to draw some debug lines or maybe even use some actual objects to delimit that for development purposes. Gonna ping @JoshEngebretson :slight_smile: for further input (how do debug-draw view limits for a given camera and aspect ratio, I’m assuming ortho, for perspective you’ll need a distance for the intersection plane on the projection volume).

The UI is a different beast though, generally you want the UI to fully adapt to the screen by anchoring the elements to screen positions (generally edges/corners) and resizing accordingly, so a minimap for example always shows on the bottom-left and the score always on top-left, optionally if they overlap the UI elements on the right side of the screen you could resize/reposition them until everything fits without overlaps.



Hi Adam,

Thank you for the detailed answer, much appreciated.

I already faced this issues with Unity3D, I can say that Atomic works very similar to it. For Unity I found a solution after different tests about the right amount of objects to show in the camera in order to fit different displays.

Exactly I am looking to make a game where the camera doesn’t move, but I move just the player, so I was wondering if there was a way to see the scene in the Atomic editor before running the preview, I will try the camera.

I have to say that there are some game engines, like Phaser, Corona and Cocos where the Engine deals with different screen sizes for both scenes and UI, honestly it’s something that I would expect to have, I was hoping that Atomic had that kind of features but it doesn’t seem to have. In my opinion a game engine should use normalisation dimensions/coordinates in the same way of OpenGL does, a range between 0 and 1 where it doesn’t matter the screen size if an object has a dimension of 0.2 would be always 0.2, for sure there will other problems but probably less difficult to solve instead of designing something in a way that looks totally different.

Anyway thanks for your time and your suggestions.


You’re welcome :slight_smile:.

Yes, Atomic is definitely more similar to Unity than the other engines you’ve mentioned, although Unity does have a competent UI system that deals with screen sizes appropriately, what is achievable in Atomic but not as easily.

I’m not sure if the camera ‘trick’ will help as you expect because it has to be selected and doesn’t show the actual aspect ratio of the player screen. In Unity I use debug/gizmos drawing for that kind of indication, but I honestly don’t know what would be the best way to do that in Atomic, I’m going to link this thread on Gitter so hopefully somebody will shine a light on this.

Regarding normalized screen coordinates, for objects on the scene there’s a method called WorldToScreenPoint in the Camera object that returns that for a given point in the world (say a Node position), and the inverse operation ScreenToWorldPoint is also available, so you could use that to convert screen space lengths and get the boundaries of the camera in scene space, so while far from idea at least the API would allow you to manually manage that with not much effort.



Hi Alan,

Thank you very much for your time.

Yeah I had this impression, unfortunately games are not made just using UI, although in Unity would be possible to make a game using the UI system.

How I said I had the same problem in Unity at the end I made an algorithm that was able to re-size the object according to the screen sizes, for most of the mobile platform worked, but it didn’t for web and desktop so I had two algorithm one for the mobile and one for the others, it took my a while to figure it out a working solution, something that I was expecting to have from the engine.
In my opinion, is the camera concept that doesn’t work for 2D games especially for that kind of games in which you do not really need a camera, like arkanoid style, would be great to have a game engine supporting this kind of different design concept.

About the normalisation, I am aware of those functions, it’s quite common in most of the game engines, but what I was saying is about the way of making the object where I shouldn’t use any API or so.
Eg. if I know that my asset has a dimension and in my game I would like to have it as 0.2 (0 - 1) I should call a function that is obj.setDim(0.2), and the game engines resize the content based on screen dimension, where my object would be always 0.2 of it.

Anyway, this could be easily going for ever and ever, after this info I guess that Atomic at this stage is not what I am looking for, I will always keep an eye on it but I would like to use game engines that have this kind of screen features.