Does unity have any limits when it comes to .tmx files? I am creating a .tmx map on tiled and each tile is 16x16 pixels. I am making a game and I would like to make it fairly universal and make sure most graphics cards can handle it but I'm not sure whether I should divide my map in to chunks that will load when the boarder is crossed or just load the whole map, as I'm not sure if I would be able to program the game to only load say a 50x50 texture and render more of the map as the player moves. So does unity have a maximum number of tiles it can render? Thanks in advance
Open statistics window and see performance stats of your game. Mostly and basicly, Draw Calls is defined your game's parformance. For example FPS decreases under 60 for more than 2500 draw calls on most of PCs.
Assume that your map is 128x128, if you use 16x16 tiles you need 64 nodes otherwise if you use 32x32 tiles you need 16 nodes. More nodes means more loading.
Just check stats and get visuals under control for better performance.
Related
I am currently making a mobile match-3 like game in unity. I have made all the graphics for the gems(the objects with which you make the matches) in Inkscape at 256x256 and exported them(PNG Files) with 90 dpi(also tried with 360 but nothing changed). My problem is that when I run the game in the editor the graphics seem to be "pixelated" and blurry. In my sprite settings I've set Pixels per Unit to 256, checked Generate Mip Maps, I am using Bilinear Filter Mode and the aniso level is 0. I have also set the max size to 256 and compression to high quality(My Main Camera's size is 10 but I tried to change that and nothing changed as far as the quality of the sprites). What can I do to "perfectly" display my sprites? Do I have to export them in some other way from Inkscape or do I have to change some Unity's settings?
Thank you.
NOTE: My sprites are not "pixel art"!
Edit(Added photos of the purple gem as file and how it is shown in editor):
Because scaling
You're display resolution on the images isn't a 256x256 region where those images are displayed, which means that they must be scaled in some manner in order to display in the desired region. Camera rendering is notoriously bad at scaling. As your images aren't Vector (and Unity doesn't support vector graphic formats anyway), scaling will always result in a loss of detail. Detail like hard edges.
Your options are:
smaller images where you have complete control over how the image is scaled down
bilinear filtering (which is fundamentally blurry)
mipmaps (which are automatically scaled down versions of your image in powers of two)
If the later two aren't giving satisfactory results, your only option is the first.
I have a building model with 6K faces and I want to texture with some pretty high detail 512x512 tilable textures (which represent about 32cm x 32cm), and I'd like to be as mobile-friendly as possible, but not necessarily with old phones but for like GearVR capable phones.
The model happens to have mostly long horizontal quads eg
|-----------|---|----------------|
|-----------|---|----------------|
|-----------| |----------------|
|-----------| |----------------|
|-----------|---|----------------|
|-----------|---|----------------|
So the uv's of each of those horizontal sections can be stacked on one tileable texture, to achieve both horizontal and vertical tiling.
Further, if the tiles were 512x512 textures, I could stack 8 of them in a 512x4096 non-square (but power of two) texture.
That way I could texture the main mesh with a single texture or one extra for metalic.
Is this reasonable, or should I keep them as separate 512x512 textures? Wouldn't separate textures mean like 8x the draw calls which would be far worse than a non-square 512x4096 texture?
After some research, I found the technique of stacking textures and tiling horizontally is called using a trim sheet, and is very much valid, and used extensively game development to be able to re-use high-detail textures on many different objects.
https://www.youtube.com/watch?v=IziIY674NAw
The trim sheet info I found though did not cover 'non square' which is the main question. But from several sources I found that some devices do not support non-quare and some do, and some do but don't do compression well on non-square, so it's a 'check your target devices' issue.
Assuming a device does support non-square, it should in fact save memory to have a strip of textures, and should save draw calls, but your engine may just 'repeat them horizontally until square' for you when importing the texture to 'be safe' (so again, check target devices and engines). It would perhaps be wise to limit to 4 rather than 16 stacked textures, to avoid 'worst case scenarios'.
Hopefully, the issue will be addressed by either having video cards able to do several materials in 1 draw call, or by more universal handling the texture strips well, but it seems state of the art has not focused on that yet.
Another solution is more custom, but some people have created custom shaders that use vertex color information on a mesh to choose which part of a texture to use, and then tile from there. Apparently the overhead turned out to be quite low, and it was a success, so it's good to have an idea about 'backup plans'. This however would be an engine/environment/device specific kind of optimization, not a general modeling practice.
http://www.gamasutra.com/blogs/MarkHogan/20140721/221458/Unity_Optimizing_For_Mobile_Using_SubTile_Meshes.php
I'm just getting things going in my game and I'm using CCTMXLayer for my tiled background. Everything is going fine when my map is 30x30 tiles, but my world is about 500x500 tiles. I would just use a map that size, but it lags terribly during animation. Any ideas as to handle a really large, tiled map without having lag?
Being biased here: check out Koboldtouch, specifically what features I added to make tilemaps more useful. Among them no limits on map size, tilesets, layers - as much as can fit in memory.
The only alternative is HKTMXTiledMap. I never actually used it, the forum thread is full of (unresolved?) issues.
The CCTMXTiledMap is not only slow, you can only create 128x128 tiles tilemap with a single layer and all tiles set to non-empty. 500x500 is only possible if you leave enough empty tiles so you never go above 16,384 tiles on the map. Unlikely. Restrictive.
I am trying to use sprite sheet animation in my application.
The first POC with a small sprite sheet worked fine but as i change the sprite sheet to a bigger one, i get "check_safe_call: could not restore current frame" warning and the application quits.
A quick search revealed that this problem meant my app is taking too much memory or the image is too huge in dimension.
My image is 4.9 Mb and dimensions are 6720 * 10080 (oops!!). i read that iphone allows maximum 3 Mb image with dimensions up to 1024 * 1024. Also that the sprite sheet image dimensions should be a power of two.
So please let me know how i can use a sprite sheet this big.
One approach could be to cut the sprite sheet into many smaller sprite sheets and use them one at a time.
Please suggest if you know any other/better approach to accommodate bigger sprite sheets and whether the problem with my sprite sheet is size (4.9 Mb) OR dimensions (6720 * 10080).
(Just FYI, i am not trying to play a movie so using MP4 file instead is not an option for me. i need to animate the sprite sheet based on accelerometer input and i have been able to achieve that in my POC with smaller sprite sheet.)
Thanks,
Swapnil
You should cut up the sprite sheet into multiple textures as you describe. The iPhone's memory and graphics chip simply can't hold an image/texture of that size in memory at once. By splitting up the sprite sheet it will deal with loading/unloading the appropriate textures into memory when you use them.
You might also consider optimizing the image format. Using the PVRTC format can save a huge amount of memory, but it is only well-suited to certain kinds of images. See this Apple page for more information.
definitely keep it within powers of 2. also, keep the sprites within the spritesheet in containers that are powers of 2 (say, you have a 17x31 sprite... put it in a 32x32 container). the problem with your sprite sheet is both the 4.9mb and the dimensions. i would consider using adobe fireworks or pngcrusher to bring the size of your sprite sheet down considerably.
mike weller's right about splitting the sprite sheet up (you simply cannot max 1024). i think the best bet would be to reorganize what you're doing with your sprite sheet into elements (though it's tough to say without knowing particulars). only things that move should have multiple frames. overlay those over a background (from the same spritesheet) by calling there location on the spritesheet and tossing them into play.
I am working on a 2D scrolling game for iPhone. I have a large image background, say 480×6000 pixels, of only a part is visible (exactly one screen’s worth, 480×320 pixels). What is the best way to get such a background on the screen?
Currently I have the background split into several textures (to get around the maximum texture size limit) and draw the whole background in each frame as a textured triangle strip. The scrolling is done by translating the modelview matrix. The scissor box is set to the window size, 480×320 pixels. This is not meant to be fast, I just wanted a working code before I get to optimizing.
I thought that maybe the OpenGL implementation would be smart enough to discard the invisible portion of the background, but according to some measuring code I wrote it looks like background takes 7 ms to draw on average and 84 ms at maximum. (This is measured in the simulator.) This is about a half of the whole render loop, ie. quite slow for me.
Drawing the background should be as easy as copying some 480×320 pixels from one part of the VRAM to another, or, in other words, blazing fast. What is the best way to get closer to such performance?
That's the fast way of doing it. Things you can do to improve performance:
Try different texture-formats. Presumably the SDK docs have details on the preferred format, and presumably smaller is better.
Cull out entirely offscreen tiles yourself
Split the image into smaller textures
I'm assuming you're drawing at a 1:1 zoom-level; is that the case?
Edit: Oops. Having read your question more carefully, I have to offer another piece of advice: Timings made on the simulator are worthless.
The quick solution:
Create a geometry matrix of tiles (quads preferably) so that there is at least one row/column of off-screen tiles on all sides of the viewable area.
Map textures to all those tiles.
As soon as one tile is outside the viewable area you can release this texture and bind a new one.
Move the tiles using a modulo of the tile width and tile height as position (so that the tile will reposition itself at its starting pos when it have moved exactly one tile in length). Also remember to remap the textures during that operation. This allows you to have a very small grid/very little texture memory loaded at any given time. Which I guess is especially important in GL ES.
If you have memory to spare and are still plagued with slow load speed (although you shouldn't for that amount of textures). You could build a texture streaming engine that preloads textures into faster memory (whatever that may be on your target device) when you reach a new area. Mapping as textures will in that case go from that faster memory when needed. Just be sure that you are able to preload it without using up all memory and remember to release it dynamically when not needed.
Here is a link to a GL (not ES) tile engine. I haven't used it myself so I cannot vouch for its functionality but it might be able to help you: http://www.mesa3d.org/brianp/TR.html