🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

LibGDX?

A topic by lonewookie created 1 year ago Views: 476 Replies: 15
Viewing posts 1 to 8

I'd really like to use LibGDX for this jam, but I'm not quite sure how to emulate the 64x64 resolution in this engine. Does anyone have any idea how to do this?

(+2)

Glad to see people using LibGDX :D
It's quite simple actually, you need to take advantage of the Viewports, more specifically FitViewport.
Documentation: https://github.com/libgdx/libgdx/wiki/Viewports

Let me show you some snippet for a Screen class which will always maintain the 64x64 aspect:

public class LowResTest implements Screen {
private Color color = Color.BLACK;
private Viewport gameView;
private SpriteBatch batch;
private Texture texture;

@Override
public void show() {
gameView = new FitViewport(64, 64); // This is the internal resolution your game will display regardless of window size
batch = new SpriteBatch();
texture = new Texture(Gdx.files.internal("badlogic.jpg"));
}

@Override
public void render(float delta) {
Gdx.gl.glClearColor(color.r, color.g, color.b, 1);
Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
gameView.apply(); // we set this as the current viewport (we could have more viewports, for example a hudView)
OrthographicCamera cam = (OrthographicCamera) gameView.getCamera();
batch.setProjectionMatrix(cam.combined); // Don't forget this else your viewport won't be used when rendering
batch.begin();
batch.draw(texture, 0, 0);
batch.end();
}

@Override
public void resize(int width, int height) {
gameView.update(width, height); // also don't forget this
} ...

Hope this helps!

And good jamming to all! I still have to spend some day to brainstorm ideas :P

Thanks for that robonutria I'll be using libgdx as well myself.

Hey thanks! I am going to be trying this in libGDX too

(Edited 1 time)
I am getting some nasty pixel bleed

@Ben
Are you using Tiled maps? This is common if you're using a spritesheet that has no padding between each tile. If you modify your image to add a 1px padding between each tile and import it on tiled as such (telling it has a 1px pad) it should display fine.

In case you already made some tiles and don't want to manually rearrange it, I've used this gimp plugin in the past to automatically add padding (or do other modifications) to spritesheets:
http://registry.gimp.org/node/26044

(Edited 1 time)

It had padding, but the padding was white. Apparently each tile needs to have padding of the same color as the pixel next to it. That seems a completely backwards way to deal with this -- isn't this simply a bug in libGDX that shouldn't occur?

Anyway, I wasn't using a TiledMap but I am planning to implement that soon

That sounds very troublesome way to fix it... Have you tried using alpha transparency instead of a color? It has been working fine for me that way.

Have you tried without padding between tiles? I've never used padding and never had problems. But always used tiled map parsing

(+1)

make sure your texture is a power of 2 in size e.g 512x512 not 512x300. The non-power-of-2 will cause some drivers to scale the texture and make pixels appear to "bleed" as well.

Thanks for the snippet, but I'm not sure if this is doing a true 64x64 resolution for me. Everything rests on a 64x64 grid, but in movement it seems to move between the "pixels" I have.

Any ideas on this?

(+1)

you sure you're rounding your positions to the nearest int and rendering to the spritebatch associated with the fitviewport?

(+1)

I'm not sure, how do I do that? Haha

(+1)

floor(Position.x) or ceil(Position.x) and for y for getting the correct pixel position.

(Edited 2 times)

LibGDX seems to be very bad at this. Look what happens when you try to use ShapeRenderer with a low resolution FitViewport:


I was thinking of looking at trying to force it to use Bresenham's line algorithm to draw lines in this but then I discovered this happening:

What the hell is this!? commit that shows this problem is here

(Edited 1 time)

Xoppa on the freenode #libgdx IRC said that the solution to this is to first render everything inside a FrameBufferObject and only then write that to the screen. I will be experimenting with that soon