Does it matter, how high the resultion of my graphics are (the picture of my player is 1500 x 2000 px) or are there any problems, that the game couldn't work very well or smooth or something like that? (Unity, 2D Game)
This really depends on the target device, as well as the scale of your game. I wouldn't think that it would cause issues, but it really depends on how many large images you have rendered at the same time. You can also always change the max size in the sprite settings if it becomes a problem.
Also keep in mind that if your player is small it really doesn't need to be that large, so I would just go ahead and decrease the max size in the sprite settings if that is the case.
I'm assuming that you are asking about texture size.
modern hardware can handle resolution such as 1500 x 2000 very easily and I would not worry about rendering speed.
However, texture loading (affects both CPU & GPU) may become issue if you have large textures (or large number of textures). if you have 1000 textures of 1500 x 2000, it will become hard to load the texture without affecting user experience.
Related
I am making a 2d game in Unity.
when i put a background sprite that will cover the whole screen it drops my frame rate from 60 to about 40 on my android device (galaxy tab).this is really strange i would not expect this degrade in performance from a single sprite. Did any body else encounter this?
A large sprite can absolutely affect frame rate, especially if the image you use matches the display resolution. It can also vary per device, as not all GPUs are equal - higher resolution displays with lower-end GPUs are bad in these cases.
To minimize the performance impact you try the following:
Ensure that alpha blending is disabled before rendering the background image. Rendering a large image (even one without any alpha) while alpha blending is enabled will affect your framerate severely.
Remove all background "clearing" operations (those that clear the frame buffer). These are redundant since your image will cover the entire background (effectively clearing it).
Use a smaller image and stretch it to fit the entire background (use filtering to smooth out the enlargement).
Use lower bits per pixel (such as 16 bit) for the image.
All of these impact performance to some degree.
Numbers 1 and 2 are essentially "free" optimizations, which you should definitely implement. Numbers 3 and 4 will degrade the quality of your image, but may improve your framerate - it will be up to you to decide whether the tradeoff in quality is worth the speed improvement.
I've seen a few discussions regarding 'Point Sprites vs Textured Quad Sprites' and the like.
However, one thing confuses me, if I understand correctly, aren't the size of point sprites limited (By a point sprite range)?
I'm fairly new to OpenGL ES 2.0 so am very likely missing something, but under what circumstances could point sprites be used effectively in a game (apart from the obvious being a particle system)? If they can't go over a certain size, then aren't they pretty much useless for characters etc? (I understand also that the min and max sizes may vary from device to device making things even more unpredictable)?
EDIT: Further to the comments below and further research it appears that the only size that is guaranteed for a 'Point' is '1' (being 1 pixel).
So on a system like Android with so many screen DPI's and resolutions, are points even realistically usable for particle systems?
Let me elaborate, on a low Res / DPI screen a single pixel point will appear quite large , but on say, a Nexus 10 tablet with it's really high Res / DPI screen a single pixel point is going to virtually unnoticeable. Normally when I work with sprites I scale them according to the screen resolution (ie, if I want a sprite to take up 1/4 of the available screen I will simply scale it by screen/2 in both X and Y directions. This gives me screen independence and works great. But if I need a particle size of say 4 on my N10 Tablet so it takes up the same amount of relative space than of say a lower-end (and lower res) phone device which only uses a point size of 1 and I can't be guarantee anything bigger than 1 pixel - how is this going to work?
I'm just trying to understand when Points/Point Sprites would be useful in a system like Android!?
I understand that Andengine gives us option to scale our scene to any size screen that the user may have.
My question is if it would be better to develop for a larger resolution, say 1280/800 and scale it down for smaller screens OR to go for smaller resolution, say 800/480 and scale it up on bigger screens?
I did try to test this in a sample game by developing it for 1280/800 and scaling down (by ratioResolutionPolicy) to 800/480, and the results weren't satisfactory, there was stutter every here and there the framerate on the debugger though showed 60+. Is it bad programming on my part or does it have to do with the scaling down of the pixels, should I develop for smaller screen and scale it up?
I guess it depends on what kind of graphics you are using.
Say, for example, you want to create something in a retro-gameboy-pixel style, then it makes more sense to use small images and develop for a small resolution (like 480x320). Pixel graphics can be scaled up without loosing quality, but not down (then the pixels loose form).
But if you want high resolution graphics you are most likely better of developing the whole thing for a big resolution and let the AndEngine scale it down.
In both cases the quality of the pictures also depends on the TextureOption of your TextureAtlases as well.
Anyway, I can imagine that neither scaling down, nor scaling up is more efficient. Scaling is done by openGL and should go quite quickly. The downside of using big resolutions though, is that the device has to hold huge images in it's memory and the of course processing big images always takes more time than processing small images. So maybe the best way is to develop for middle-size devices (e.g. 960x640) ?
I know this isn't much help, unfortunately it is a lot of try and error to get the best results for your specific requirements.
christoph
To achieve good result on all type of android device you have two ways to follow from my perspective.
First, you have to develop and use two graphics to handle all the type of devices. For example one with resolution 1024x600 and other with 480x320. Based on device current resolution you have to load specific one type of graphics.
Second, you choose any single resolution that best suits to you and have great share in the market. Develop and use graphics only for that resolution. For other resolution scale that graphics based on aspect ratio. For this you have to create super class of sprite and change value of x,y,height and with based on aspect ratio calculate.
This was my experience that I share with you. If you have any doubt then feel free to ask it.
I am trying to write a libgdx livewallpaper (OpenGL ES 2.0) which will display a unique background image (non splittable into sprites).
I want to target tablets, so I need to somehow be able to display at least 1280x800 background image on top of which a lot more action will also happen, so I need it to render as fast as possible.
Now I have only basic knowledge both about libgdx and about opengl es, so I do not know what is the best way to approach this.
By googling I found some options:
split texture into smaller textures. It seems like GL_MAX_TEXTURE_SIZE on most devices is at least 1024x1024, but I do not want to hit max, so maybe I can use 512x512, but wouldn't that mean drawing a lot of tiles, rebinding many textures on every frame => low performance?
libgdx has GraphicsTileMaps which seems to be the tool to automate drawing tiles. But it also has support for many features (mapping info to tiles) that I do not need, maybe it would be better to use splitting by hand?
Again, the main point here is performance for me - because drawing background is expected to be the most basic thing, more animation will be on top of it!
And with tablet screen growing in size I expect soon I'll need to be able to comfortably render even bigger image sizes :)
Any advice is greatly appreciated! :)
Many tablets (and some celphones) support 2048 textures. Drawing it in one piece will be the fastest option. If you still need to be 100% sure, you can divide your background into 2 pieces whenever GL_MAX_TEXTURE happens to be smaller (640x400).
'Future' tables will surely support bigger textures, so don't worry so much about it.
For the actual drawing just create a libgdx mesh which uses VBOs whenever possible! ;)
Two things you dindn't mention will be very important to the performance. The texture filter (GL_NEAREST is the ugliest if you don't do a pixel perfect mapping, but the fastest), and the texture format (RGBA_8888 would be the best and slowest, you can downgrade it until it suits your needs - At least you can remove alpha, can't you?).
You can also research on compressed formats which will reduce the fillrate considerably!
I suggest you start coding something, and then tune the performance up. This particular problem you have is not that hard to optimize later.
What is the best way to go about using large textures with opengl on android?
I want to load some background images for my game with my target resolution being 480x800. Going by the recommended 512x512 resolution cap, I've tried scaling the images down to 240x400 and having opengl scale them back up, but that looks like trash and I would rather keep them as high-res as possible. I've seen one or two other people talking about using 512x1024 so I'm wondering:
How many phones would actually have trouble handling these image sizes?
Would it be better to risk an OOM and use 512x1024 textures, or risk a performance hit by splitting the images in two and increasing opengl calls?
For consideration: In general I will only be using two other 512x512 atlases at a time (aside from the background), with a maximum of three on menu screens where framerate isn't important.
Thanks!
I've experimented using large textures for for planets in my game. With two 1024x1024 hemispheres per planet and probably only one or max two planets visible at a time. Once in game, they render fine on my somewhat dated ZTE Blade running 2.1.
However, the load times were terrible (talking an extra 10 to 30 seconds for two large textures to load).