Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (516)
Games in Android Showcase (123)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Libgdx Texture Array because of bleeding  (Read 744 times)
0 Members and 1 Guest are viewing this topic.
Offline Cero
« Posted 2014-05-22 20:11:02 »

I'm bleeding... you know, the usual. Even with Nearest there is enough bleeding for it to suck hard.
padding is... not an option, changing all those tilesets changing the logic, and then the inconvenience in the map editor and all that, because tiles are no longer side by side. Just no =/

So it really appears Texture Arrays / GL_TEXTURE_2D_ARRAY is the way to go.
However I'm not too big on OpenGL, in fact I'm using 100% libgdx right now, no direct calls, at least nothing big.
The question is how to integrate an OpenGL Texture Array with Libgdx ?

Offline trollwarrior1
« Reply #1 - Posted 2014-05-22 20:13:07 »

Hmm this is the method I used for my games..

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
   private void set(SpriteSheet sheet, float x0, float y0, float x1, float y1) {
      float ph = 1f / sheet.width; // texture pixel width
      float pv = 1f / sheet.height; // texture pixel height

      int bleed = 8;
      this.x0 = x0 + ph / bleed;
      this.y0 = y0 + pv / bleed;
      this.x1 = x1 - ph / bleed;
      this.y1 = y1 - pv / bleed;
      this.sheet = sheet;
     
   }


Not sure if this works with all texture sizes.. Mine was 256x256 with this method.
Offline Cero
« Reply #2 - Posted 2014-05-22 20:41:02 »

have been using pixel values for my tiles (TextureRegions) until now

not sure why that code works for you, I guess you're just lucky with the rounding issue there

Also Linear filtering should still not work, right ?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trollwarrior1
« Reply #3 - Posted 2014-05-23 04:54:18 »

Linear filter will only make bleeding worse, as it smudges out the edges. Here is how my code works.

Not sure if this is the best representation of what I was trying to achieve with this code, but it seems to have worked by removed texture bleeding and not altering the shape of the texture.

In this picture gray grid is a texture of 8x8 texels. Red line is the outline which is passed into my method I described earlier.
Green line is what my method does.


Offline Nate

JGO Kernel


Medals: 153
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #4 - Posted 2014-05-23 07:09:54 »

I suggest using individual images in Tiled and then pack your images into an atlas for use at runtime (see AtlasTmxMapLoader). This allows you to change how the images are packed (padding, which images are on what atlas page, etc) without breaking your Tiled map.

Otherwise you could maybe fork libgdx, see the Mesh constructor which takes a VertexDataType. You'd need to add a new VertexData implementation.

trollwarrior1's approach is even simpler, just move UVs one texel toward the region center. This will stretch your images but filtering won't pick up neighboring regions (it will pick the texel you excluded).

Offline Cero
« Reply #5 - Posted 2014-05-23 09:28:49 »

I suggest using individual images in Tiled and then pack your images into an atlas for use at runtime (see AtlasTmxMapLoader). This allows you to change how the images are packed (padding, which images are on what atlas page, etc) without breaking your Tiled map.
Not using Tiled as I need way too many features and customization that would be very hard with tmx and the editor / that the editor doesnt have anyway.
So I wrote my own tile system and especially very elaborate editor.
Even if I would be using Tiled: separate images for tiles... thats a nightmare for the artists. Every time there is something bigger than the tilesize they would have to cut it up, and then you would have to somehow pack it perfectly onto the tileset which happens automatically.

Otherwise you could maybe fork libgdx, see the Mesh constructor which takes a VertexDataType. You'd need to add a new VertexData implementation.
Thats for the pointer.

trollwarrior1's approach is even simpler, just move UVs one texel toward the region center. This will stretch your images but filtering won't pick up neighboring regions (it will pick the texel you excluded).
Gotta try it out, but I would imagine it looks like crap :o

Offline Cero
« Reply #6 - Posted 2014-05-23 10:14:34 »

1  
2  
3  
4  
5  
6  
         float adjustX = 0.25f / texWidth;
         u += adjustX;
         u2 -= adjustX;
         float adjustY = 0.25f / texHeight;
         v += adjustY;
         v2 -= adjustY;

Seems to work very well.
Of course I get greedy and try even linear filtering now. Round camera positions and certain rounded zoom values do work... hm

Offline Nate

JGO Kernel


Medals: 153
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #7 - Posted 2014-05-23 15:26:27 »

separate images for tiles... thats a nightmare for the artists. Every time there is something bigger than the tilesize they would have to cut it up, and then you would have to somehow pack it perfectly onto the tileset which happens automatically.
Tiles in libgdx are not limited to a specific size. You don't need to break a large image up into many small images, you can just use the large image.

Offline Cero
« Reply #8 - Posted 2014-05-23 16:14:26 »

Well in my engine and physics there has to be a fixed tilesize.
Good to know though, if I ever wanna use tmx for something smaller

Offline Nate

JGO Kernel


Medals: 153
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #9 - Posted 2014-05-23 23:07:30 »

You can still have a standard tile size for placement and the collision layer. The way it works is the image for a tile can simply be any size. Makes it much easier to build maps. FWIW, Super Spineboy does this (using Tiled but the idea is the same).

Pages: [1]
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (32 views)
2014-10-27 03:28:38

TehJavaDev (26 views)
2014-10-27 03:27:51

DarkCart (41 views)
2014-10-26 19:37:11

Luminem (22 views)
2014-10-26 10:17:50

Luminem (27 views)
2014-10-26 10:14:04

theagentd (33 views)
2014-10-25 15:46:29

Longarmx (61 views)
2014-10-17 03:59:02

Norakomi (58 views)
2014-10-16 15:22:06

Norakomi (47 views)
2014-10-16 15:20:20

lcass (43 views)
2014-10-15 16:18:58
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!