37

Okay, I think you have two problems going on here. The first problem is with mipmapping. In general, you don't want to naively mix atlasing with mipmapping, because unless all your subtextures are exactly 1x1 pixel sized, you will experience texture bleeding. Adding padding will simply move the problem to a lower mip level. As a rule of thumb, for 2D, ...


23

A sprites-sheet (often refers to a large image that) is supposed to contain the animation frames of a specific 2d character or projectile in a game. You can almost think of it as the model of a 2d-character. It stores all the various animations created for a specific character. A texture-atlas (is often taken to mean a large 2d image that) contains many ...


19

One option that'll be a lot easier than fiddling with mipmaps and adding texture coordinate fuzz factors is to use a texture array. Texture arrays are similar to 3d textures, but with no mipmapping in the 3rd dimension, so they're ideal for texture atlases where the "subtextures" are all the same size. http://www.opengl.org/wiki/Array_Texture


16

We have a similar case with our RTS Remake. All units and houses are sprites. We have 18 000 sprites for units and houses and terrain, plus another ~6 000 for team colors (applied as masks). Long-stretched we also have some ~30 000 characters used in fonts. So the main reason behind atlases are: less wasted RAM (in older days when you upload NPOT to GPU it ...


16

The problem with using texture atlases and adjacent texels leaking has to do with the way linear texture filtering works. For any point in the texture that is not sampled exactly at the center of a texel, linear sampling will sample 4 adjacent texels and compute the value at the location you asked as the weighted (based on distance from the sample point) ...


14

You'll be okay to ship your game to majority of your users with a configuration like that. Even the fairly old (nearly 3 years now) old Samsung Galaxy Captivate will run with a texture resolution of that size. You won't have too many issues supporting almost any device like that (I can't think of any off the top of my head. Okay, that's a lie... maybe the ...


12

As noted in the comments above, performance is going to depend on implementation, your particular hardware, and what you're trying to do with the textures, so the only reliable answer there is to profile each alternative. There are a few differences in terms of how you use each option though, which will apply consistently: One big difference is that, for ...


11

Create an AssetManager: AssetManager manager = new AssetManager(); This to begin the loading: manager.load(FILE_SPRITE_ATLAS, TextureAtlas.class); This getting called continously for asynchronous loading: manager.update(); Or this called once for synchronous loading: manager.finishLoading(); and then this saves the spriteAtlas (when update() returns ...


10

SDL2 doesn't need any functionality to be added for either of those items. Texture batching You yourself can sort the sprites by texture used. The SDL backends can already do draw call batching if they wish to (nothing requires that the Copy command be executed immediately; the only requirement is that it be executed by the time any side effects are ...


9

TextureAtlas#findRegion(String) returns a region with a name that matches the name specified. It does not copy the region, therefore any changes you make to the region will be reflected in the TextureAtlas. To overcome this issue, simply instantiate a new TextureRegion object and pass it the region found inside your TextureAtlas: background1 = new ...


7

After struggling a lot with this issue, I finally came up with a solution. To use both, a texture atlas and mipmapping, I need to perform the downsampling myself, because OpenGL would otherwise interpolate over the boundaries of tiles in the atlas. Moreover I needed to set the right texture parameters, because interpolating between mipmaps would also cause ...


7

Technically seen it's the same: It's a big image that contains smaller images (sprites). The 3d vs 2d does not make a difference here since almost all 2d game engines use 3d hardware for rendering....


6

if( (NULL == strstr( (char const*)glGetString( GL_EXTENSIONS ), "GL_ARB_texture_non_power_of_two" ) ) ) //############ it points here ############// You are creating an OpenGL 3.2 context. glGetString(GL_EXTENSIONS) returns NULL because it has been deprecated in 3.0 and removed in 3.1. It was replaced by glGetStringi(GL_EXTENSIONS, i). See ...


5

I have a tangentially related answer in here, but the general idea is that, if you're loading and drawing textures at different times (you're not loading additional textures while you're rendering), then there are two places where what you do will affect your performance: Loading time: This is the moment where you upload your textures into memory. The ...


5

There's a bug in com.badlogic.gdx.backends.gwt.GwtFileHandle that adds a slash before the image path in the atlas, but here is a workaround: Put the atlas files are inside a folder like "assets/images/", don't put it directly in the assets folder, and make sure the image path in atlas file is correct (relative to atlas), then it should work. Or you can ...


4

Looks like the issue could be caused by MSAA. See this answer and the linked article: "when you turn on MSAA, it then becomes possible for the shader to get executed for samples that are inside the pixel area, but outside of the triangle area" The solution is to use centroid sampling. If you are calculating the wrapping of the texture coordinates in ...


4

I put together a greedy meshing implementation for voxel data which includes various attributes (https://www.youtube.com/watch?v=0OZxZZCea8I). I understand you're looking to merge voxel faces even when they aren't the same voxel type - but it would seem that the only way to do that is to send the set of voxel types represented by the quad into the shader ...


4

There's no real benefit to sorting those sprites by not-Pokemon index; the texture packer doesn't care what order the not-Pokemon are in, it cares about minimizing the atlas size. I'd just let it do its thing, the atlas file already specifies the position, dimensions, and other settings for each sprite. All you have to do is reference them by name.


3

The textures are named as in the .pack file, without extensions. Try using "image1" instead of "image1.png". If you watch your ta variable using the debug tool you should be able to see the names of textures actually loaded.


3

Use it individually. Texture atlases are used to gain efficiency by minimising texture swaps for many small textures, and avoiding wastage due to textures having to be bumped up in size to dimensions that are a power-of-two. A single image on an atlas gains you nothing except more book-keeping, and if the atlases are required to be power-of-two in size, your ...


3

First of all 1920x1080 is not power of two, even if your card support NPOT textures I think it's a best practice to use a POT texture. Second let's calculate the size in bytes. 1920 * 1080 * 4 = 8294400 bytes that is around 8mb of memory. Since the answer is tagged as android I assume you are talking about a mobile platform. A lot of the mobile platforms ...


3

A sprite sheet and texture atlas are nearly the same. They are both bitmap image files (jpg, png, etc.) that contain multiple smaller images, usually in a grid, that are indexed and displayed using software / game engine that locates the individual images by their coordinates. They also both serve to simplify resource management and lower draw calls by only ...


3

You should reconsider whether you really need to do this. Most of the time, querying the GL for such information should be avoided because it has an important performance cost. Since you are the one doing the glBindTexture calls, you could track the resources yourself instead (this is called client state tracking). It could be as simple as having a global ...


3

All of the atlas regions are automatically available through the skin as TextureRegions. I just tried it, and works without modifying the json file. You can just call skin.get(name, TextureRegion.class); or skin.getRegion(name); Unfortunately, the skin docs are not very clear about this. libGdx docs


3

The sourceRect is much better for this. Watch this if like a funny video explaining why: https://www.codeandweb.com/what-is-a-sprite-sheet-performance The more technical explanation: I am using pseudo code - the exact number of commands required might vary - but you should see what I am talking about. If you use isolated sprites the game engine has to ...


3

There are a variety of different imposter techniques. Level of detail is probably the easiest to achieve, but has two main drawbacks. The noticeable 'pop' effect when you swap between low and high resolution models, solved by gradual transitions between LODs. The second problem is that it's MUCH more work for the artist to generate LODs for every single ...


3

Since you found the picture online, without any json file attached or any other information, its not possible to cut this into multiple sprites automatically. You'd have to do it by hand.


2

The params describes the upper left location of the region and the width/height. So 20,20,50,50 describes a region starting at 20,20 and then has a width and height of 50. However, extracting regions manually can be a pain. Texture packer allows you to put multiple images together into a single texture. Then using texture atlas you can retrieve those regions ...


2

Setting "extrude: 1" in TexturePacker, then CIwMaterial::ALPHA_NONE/DEFAULT for the alpha mode of the material that the sprites are rendered off, solves the problem.


Only top voted, non community-wiki answers of a minimum length are eligible