I am developing a game for iPhone retina enabled.
This game has alot of sprite sheets to be used.
MyQuestion which is better to use
pvr
pvr.gz
pvr.ccz
or normal png format
which is the best practice for using sprite sheets.
Counter-Question: Is it better to use a sports car or a pickup truck?
It depends on your particular use case. You'll use PNG if you can't afford any loss in quality. You'll use PVR if memory and rendering speed are of higher concern.
GZ and CCZ are simply compression algorithms that determine how well the data is packed and how fast it can be loaded. I hear that PVR.CZZ is the fastest to load.
Now, what made me curious is that you say you have "a lot of sprite sheets". Ideally you'll want to be using as few as possible (best: 1) sprite sheets in a scene. If you create a sprite sheet per game object you're approaching it the wrong way, sprite sheets (texture atlases) are not a tool to structure and categorize your image assets! Your goal should be to cram as many images as possible into a single sprite sheet (texture atlas) to improve rendering performance.
In some cases you'll even want to duplicate some of your images so that you can create a single texture atlas for the current scene (level) even if that means to duplicate some images in the other scenes.
Related
What is the purpose of "bake" option in SceneKit editor. Does it have an impact on performance?
Type offers 2 options: Ambient Occlusion and Light Map
Destination offers: Texture and Vertex
For me, it crashes Xcode. It's supposed to render lighting (specifically shadows) into the textures on objects so you don't need static lights.
This should, theoretically, mean that all you need in your scene are the lights used to create dynamic lighting on objects that move, and you can save all the calculations required to fill the scene with static lights on static geometry.
In terms of performance, yes, baking in the lighting can create a HUGE jump in performance because it's saving you all the complex calculations that create ambient light, occlusion and direct shadows and soft shadows.
If you're using ambient occlusion and soft shadows in real-time you'll be seeing VERY low frame rates.
And the quality possible with baking is far beyond what you can achieve with a super computer in real time, particularly in terms of global illumination.
What's odd is that Scene Kit has a bake button. It has never worked for me, always crashing Xcode. But the thing is... to get the most from baking, you need to be a 3D artist, in which case you'll be much more inclined to do the baking in a 3D design app.
And 3D design apps have lighting solutions that are orders of magnitude better than the best Scene Kit lighting possible. I can't imagine that there's really a need for baking in Scene Kit. It's a strange thing for the development team to have spent time on as it simply could never come close to the quality afforded by even the cheapest 3D design app.
What I remember from college days:
Baking is actually process in 3D rendering and textures. You have two kind of bakings: texture baking and physics baking.
Texture baking:
You calculate some data and save that data to a texture. You use that on your material. With that, you reduce rendering time. Every single frame, everything is calculated again and again. If you have animations, that is a lot of time wasted there.
Physics baking:
You can pre calculate physics simulations exactly like above baking and you use that data. For example you use it in Rigid Body.
I'm new to ios game development field.
I have been going through the following apple tutorial multiple times but not getting the points
https://developer.apple.com/library/ios/documentation/GraphicsAnimation/Conceptual/SpriteKit_PG/Sprites/Sprites.html
thanks
Directly from the SKTextureAtlas class reference :
Texture atlases can improve memory usage and rendering performance. For example, if you have a scene with sprites drawn with different textures, Sprite Kit performs one drawing pass for each texture. However, if all of the textures were loaded from the same texture atlas, then Sprite Kit can render the sprites in a single drawing pass—and use less memory to do so. Whenever you have textures that are always used together, you should store them in an atlas.
SKTextureAtlas Class Reference
animation can be hundred of files. atlas puts them in one large file.
reading one file (large with lots of images) is much more efficient then reading hundreds of files (with one image each)
rendering of one large image and then showing only part of it is much more efficient then rendering each file separately.
I am making a test xna game as a learning exercise and I have a small question about using 2d textures. Basically the game is a grid of different 'tiles' which are taken from a text map file. I basically just parse through the file when initializing a level and create a matrix of the different tile types. The level is essentially a tub of wall tiles and spikes. So essentially, there are lots of wall tiles and multiple spike tiles and then lots of empty tiles. However, there are four types of wall tile and spike textures to cover different directions.
My question is what is the best way to load the textures for each of the tile? Do I load individual textures for each tile? i.e when I create a tile, pass it a texture2d which I can draw and load the texture at the same time. This seems like a good way, but then I have to load each tiles texture individually and this seems wasteful.
The other option I can think of is to use a static texture in the tile struct an then simple load this texture as a tile atlas with the different walls and spikes. This way I am only loading a single texture, and then when drawing I just move a rectangle to the area of the appropriate tile within the sprite.
I am not sure which of these ways would be optimal from a performance perspective, or if there is an alternative approach?
Thanks in advanmce
The wonderful thing about the content pipeline is that when you do
Content.Load<Texture2D>("sometexture");
It doesn't load the Texture2D everytime. The content pipeline is smart enough to load it once and send back the same Texture2D for that texture everytime. It would actually be worse if you made the static struct.
I have a pool of CCSprites numbering 1200 in each of two arrays, displayGrid1 and displayGrid2. I turn them visible or invisible when showing walls or floors. Floors have a number of different textures and are not z-order dependent. Walls also have several textures and are z-order dependent.
I am getting about 6-7 frames when moving which is okay because its a turn based isometric rogue-like. However, I am also getting a small amount of flicker, which I think is performance related, because there is no flicker on the simulator.
I would like to improve performance. I am considering using an array CCSpriteBatchNodes for the floor which is not z-order dependent but am concerned with the cost of adding and removing sprites frequently between the elements of this array, which would be necessary I think.
Can anyone please advise as to how I can improve performance?
As mentioned in the comments, you're using multiple small sprite files loaded individually which can cause performance issues as there is wasted memory being used to store excess pixel data around each of the individual sprites. Each row of pixel data in an OpenGL texture must have a number of bytes totaling a power of 2 for performance reasons. Although I believe OpenGL ES under iOS does this automatically, it can come with a big performance hit. Grouping sprites together into a single texture that is correctly sized can be a tremendous boon to rendering performance.
You can use an App like Zwoptex to group all these smaller sprite files into a larger, more manageable sprite sheets/texture atlas and utilize one CCSpriteBatchNode for each sprite sheet/texture atlas.
Cocos2D has pretty good support for utilizing sprite sheets with texture atlases and converting your code to using these instead of individual files can be done with little effort. Creating individual sprites from a texture atlas is easy, you just call the sprite by name instead of from the file.
CCSpriteBatchNodes group OpenGL calls for their sprites together, a process known as batching, which causes the operating system and OpenGL to have to make less round trips to the GPU which greatly improves performance. Unfortunately, CCSpriteBatchNodes are limited to only being able to draw sprites for the texture that backs them (enter sprite sheets/texture atlases).
Basically, I'm trying to cover a slot machine reel (white cylinder model) with multiple evenly spaced textures around the exterior. The program will be Windows only and the textures will be dynamically loaded at run-time instead of using the content pipeline. (Windows based multi-screen setup with XNA from the Microsoft example)
Most of the examples I can find online are for XNA3 and are still seemingly gibberish to me at this point.
So I'm looking for any help someone can provide on the subject of in-game texturing of objects like cylinders with multiple textures.
Maybe there is a good book out there that can properly describe how texturing works in XNA (4.0 specifically)?
Thanks
You have a few options. It depends two things: whether the model is loaded or generated at runtime, and whether your multiple textures get combined into one or kept individual.
If you have art skills or know an artist, probably the easiest approach is to get them to texture map the cylinder with as many textures as you want (multiple materials). You'd want your Model to have one mesh (ModelMesh) and one material (ModelMeshPart) per texture required. This is assuming the cylinders always have a fixed number of textures!. Then, to swap the textures at runtime you'd iterate through the ModelMesh.Effects collection, cast each to a BasicEffect and set it's Texture property.
If you can't modify the model, you'll have to generate it. There's an example of this on the AppHub site: http://create.msdn.com/en-US/education/catalog/sample/primitives_3d. It probably does not generate texture coordinates so you'd need to add them. If you wanted 5 images per cylinder, you should make sure the number of segments is a multiple of 5 and the V coordinate should go from 0 to 1, 5 times as it wraps around the cylinder. To keep your textures individual with this technique, you'd need to draw the cylinder in 5 chunks, each time setting the GraphicsDevice.Textures[0] to your current texture.
With both techniques it would be possible to draw the cylinder in a single draw call, but you'd need to merge your textures into a single one using Texture2D.GetData and Texture2D.SetData. This is going to be more efficient, but really isn't worth the trouble. Well not unless you making some kind of crazy slot machine particle system anyway.