I want to develop a simple 2D side scrolling game using libGDX.
My world contains many different 64x64 pixel blocks that are drawn by a SpriteBatch using a camera to fit the screen. My 640x640px resource file contains all these images. The block textures are positioned at (0, 0), (0, 64), (64, 0), ... and so on in my resource file.
When my app launches, I load the texture and create many different TextureRegions:
texture = new Texture(Gdx.files.internal("texture.png"));
block = new TextureRegion(texture, 0, 0, 64, 64);
block.flip(false, true);
// continue with the other blocks
Now, when I render my world, everything seems fine. But some blocks (about 10% of my blocks) are drawn as if the TextureRegion's rectangle was positioned wrong - it draws the bottommost pixel row of the above (in the resource texture) block's texture as its topmost pixel row. Most of the blocks are rendered correctly and I checked that I entered the correct position multiple times.
The odd thing is, that when I launch the game on my computer - instead of my android device - the textures are drawn correctly!
When searching for solutions, many people refer to the filter, but neither of both Linear and Nearest works for me. :(
Hopefully, I was able to explain the problem in an accessible way and you have any ideas how to fix that (= how to draw only the texture region that I want to draw)!
Best regards
EDIT: The bug does only appear at certain positions. When I draw two blocks with the same texture at different positions, one of them is drawn correctly and the other is not.. I don't get it....
You should always leave empty space between your images when packing into one texture, because if you use FILTER_LINEAR (which I think is default) for every pixel it will sample from the four nearest pixels. And if your images are without empty pixels padding,for all edge pixels it will get pixels from the neighbor image.
So three options to solve your issue:
Manually add space between images in you texture file
Stop using FILTER_LINEAR (but you will get ugly results if you are not drawing in the native image dimentions e.g. scaling the image)
Use the Libgdx Texture Packer, it has a build it functionality to do just that, when you pack your images
Related
I am using libGDX to make a small game, I made a little sprite (32x32) that is shown in the center of the screen. For some reason when I render the texture to the screen it loses its quality. Since the textures are so small I made the screen width and height 200 and 100 respectively. Any tips or answers would be much appreciated.
Your sprite (32x32) needs to be displayed on an area which is larger than 32x32, meaning that the image needs to be upscaled and interpolated (i.e. pixels between the 32 known ones need to be calculated). A common approach is smooth (often times linear) interpolation to fill in the additional pixels, which works well for photorealistic textures; it appears to have occurred here.
For pixel-art, you likely want "nearest-neighbor" interpolation instead. While the exact way to set it depends on the structure of your code, you may be able to do something like:
textureObject.setFilter(TextureFilter.Nearest, TextureFilter.Nearest);
This is the first time I'm trying to deploy a libgdx game to html but having some difficulties.
On desktop everything works fine, but in browser two of my sprites are not showing up, the rest is fine.
These two sprites should be backgrounds and scrolling why the character moves.
I'm loading my textures in a GameScree class' show method like this:
backgroundTexture = new Texture(Gdx.files.internal("background.png"));
//setting wraping to repeat to achive scrolling background by one texture
backgroundTexture.setWrap(Texture.TextureWrap.Repeat, Texture.TextureWrap.Repeat);
//and I render it like this (I create a Sprite of it)
batch.draw(backgroundSprite.getTexture(),0,0, (int) position ,0, 1280, 720);
By increasing position the background is scrolling which works fine on desktop.
I got errors in chromes console:
[.Offscreen-For-WebGL-00000000071AC350]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
Which I don't exactly understand why, how is it incompatible? And also, none of my texture are POT but they are still working.
You should avoid using mipmaps when texture is not power of 2.
backgroundTexture.setFilter(Texture.TextureFilter.Linear, Texture.TextureFilter.Linear);
It's better to use texture is in power of 2 (pixel width and height are some 2n value)
Having a weird issue.
I have a Texture with four frames of a sprite Animation. Each frame is loaded as a TextureRegion.
Most of the time the Animation play without any issues, but occasionally it will draw too much of the Texture in one frame.
Here's an example of what I mean:
As you can see the UFO has a red bar on the left side of it. That red bar is part of a frame on the outside of the TextureRegion bounds stated in my code. (The red frame is just there to make it easier for me to measure, since there is transparency on all the corners)
Here's the Texture:
In the above sprite sheet the red frame for the slide at the top has the bounds 0, 0, 202, 71. The TextureRegion for the frame of the anim is 1, 1, 200, 69 -- at no point should any of the red frame be displayed, as far as I can tell.
I realise as a workaround I could just set the frame as transparent now that I have the measurements I need, but I'd like to keep the red frame in case I need to take the measurements again later, or replace the sprite images, etc, and really a workaround is just a band-aid whereas I'm hoping to find a proper solution to address the root of the issue -- the fact that it's drawing wrong seems to indicate a larger problem than what exists just in this particular case (eg, in a densely-packed Texture it might draw pixels from a different sprite frame or even a different sprite or a menu image or something like that).
Oh and one last note, in case it's helpful: when the SpriteBatch displays the image it applies a rotation based on the movement of the UFO (tilts to the left when moving left, etc). The glitchy red bars sometimes show up on the top, right, bottom, or left randomly (though most of the time they don't show up at all) however they only seem to show up when the UFO has a rotation of zero. (Again, I realise I could just include a check to see if rotation is 0 and then call the SpriteBatch.draw() method without the rotation figure, but that too would be treating the symptom rather than addressing the root of the problem).
Any thoughts from the learned masters?
Your frames of animation need padding around them to account for rounding error. Put two pixels of clear pixels all around each image. If you use TexturePacker to combine the images into your file, it will automatically add the two pixels of padding by default.
If you name your four images with an underscore-frame number suffix, like myAnimation_0.png, myAnimation_1.png, myAnimation_2.png, and myAnimation_3.png, then when you load your TextureAtlas, it allows you get the animation very easily.
Array<TextureRegion> myAnimationFrames = textureAtlas.findRegions("myAnimation");
I am generating very large hex grids (up to 120k total hexes at 32px wide hexes results in over 12k wide images) and I'm trying to find an efficient way to bind these to OpenGL textures in libgdx. I was thinking of using multiple FBOs and breaking the grid up as necessary into tiles, but I'm not sure how to ensure continuity between the FBOs. I can't start with one massive FBO, because that is backed up by a texture so it would fail from trying to load it to video memory. I can't use a standard bitmap on the heap because I need the drawing functionality of an OpenGL surface.
So what I was thinking was I would need to overdraw on the FBOs and somehow pick up on the next FBO exactly where the previous left off. However I'm not sure how to go about this. I'm drawing the hex grid with a series of hexagonal meshes, FYI.
Of course, there's probably some other much simpler and more efficient way to do this that I'm not even thinking of, which is why I pose this question to you fine people!
You have to draw it in pieces. You need to be able to draw your hex grid from an arbitrary position. This means being able to compute which hexes to draw based on a rectangle overlaid over the map. This isn't a hard problem, and I wouldn't worry too much about drawing extra stuff off-screen. You should master this ability to view the hexmap from any position before moving on.
Once you've mastered that, it's really simple.
Draw the top-left corner and store the pixel data. Then move the area you're drawing over exactly one image width. Draw and store that. Move the area over one image width. Draw and store it. Keep doing that until you've covered the entire width.
Move down one image height and repeat the process. Once you've run out of width and height, you're done. Save your mega-huge image.
You don't need FBOs for this. You could draw it to the screen if you wanted. Though if you want maximum performance, I would suggest using FBOs, double buffering them, and using glReadPixels though a pixel buffer object. That should cut down a lot on latency.
I'm trying to write a graphical effect where a circle moves around an image smudging the image as it goes (like the way the smudge tool in Gimp or Photoshop would work). The basic algorithm I'm using is:
the circle moves from position A to position B on the bitmap
copy a circle of pixels from position A into a temporary bitmap
draw this circle of pixels from the temporary bitmap to position B using alpha of about 50%.
This works fine and looks like what I would expect, where the image will look like it's getting smudged if the circle moves 1 pixel at a time over the image.
I now want to add some texture to the smudge effect. I have a bitmap that contains a picture of a paint blob. The algorithm from the above is modified to the following so the smudge takes the shape of this paint blob:
as before
replace the temporary bitmap pixels with the paint blob texture then copy the circle of pixels from position A into the temporary bitmap but only keep the pixels that match up against paint blob pixels (i.e. use Porter-Duff "source in destination" mode when drawing the circle into the temporary bitmap).
as before
This almost works and it looks like it's fine initially but gradually the smudging makes the colors in my image darker! If the circle passes over the same area several times, the colors eventually change to black. Any ideas what I could be doing wrong?
I've implemented the above in Android. I happened upon this post about bitmaps in Android (like my paint blob texture) being loaded with "premultiplied alpha", where the author says it caused his images to become darker because of it:
http://www.kittehface.com/2010/06/androidbitmap-and-premultiplied-alpha.html
I suspect I'm suffering from a similar problem but I don't understand what's going on well enough and don't know how to fix it. Does anyone have hints at what might be going on?
Well from first glance the reason the image is getting darker is because #3 in the first three steps. You overlaying a pixel over an existing pixel at 50%. You might want to consider using the mean of the original pixel value and the new pixel value. You might want to research some blurring algorithms.