“Texture atlas” (.atlas) is the libgdx term for the image_name_meta.txt that I sketched… ThanksĪh … Aha … I just watched this … Creating and Using Spritesheets in LibGDX - YouTube This seems straight forward, does JMonkey has built-in functions such as loadBufferedImage() and bufferedImageToTexture()?Ĭan TextureAtlas be used to avoid all these mess? If so, can you give me a hint how to do it. I am thinking the second possibilities is to load the sprite image as one BufferedImage and draw the individual tiles on smaller BufferedImage and convert them to Texture. Do I have to cut the tiles and save them as individual images on my hard drive before loading them back to JMonkey as different textures? It is much easier for me to edit the sprites if they are all on one single sheet thus I don’t want to cut them up. I will add 3D feature after I port the game. I am less familiar with JMonkey it seems JMonkey’s TextureAtlas is a different concept, am I right? I decided to convert my games to JMonkey. Unfortunately the scene graph support of Libgdx is weak. For nice tile maps, it is straight forward to manually create the ‘atlas’ by using a notepad (that is actually how I create). In Libgdx, I can have a ‘sprite sheet’ and use TextureRegion to designate the different tiles as separate textures. I actually tried to use TextureAtlas before I post my question. Not sure what you are trying to do - so I just said everything that came to my mind regarding that thanks for the reply. Another possi might be to use a “3D texture” (sampler3d) which is quite an old feature (I think) and then you would simply put your tiles as slices in the w-coordinate (u and v are sampler2d, w is the third axis).But it’s definitely going to solve the problems of a texture atlas.I don’t know what kinds of graphics cards support that feature (driver version, GL version).I don’t know if jME 3.0 or 3.1 support that feature (but I would like to know).In more recent versions of OpenGL you have “texture arrays” or “array textures”.Texture atlases are often used for game characters and objects and to avoid the problems above, special care must be taken - example: configure a margin of 8 or 16 pixels when you bake your textures in Blender - which then minimizes “color bleeding” (parts in such an atlas are not power two tiles but random sized n-gons) and it also fixes “wrap around artifacts” (when using a special tile-based shader).Note: this is not a problem if you use the tiles on e.g. I observed this behavior when writing a special shader with tiled textures. This comes from having different pixels next to your quad. when trying to use a large polygon with one of your tiles repeating multiple times, then strange lines will appear between the repetitions. You will get problems with “wrap around” - i.e.Which will then work for the first 6 mipmap levels and break at the 7th mipmap level, because the tiles “bleed” into each other (“color bleeding” is actually the term for that phenomenon). If you use texture min/mag filters with mipmaps, your tiles must be a power of two size - e.g.I will be linking a sample in the post itself but here's a MEGA link to a ZIP with more of them. If anyone could give me some help in figuring this out I would be more than grateful. They are somewhat readable with a text editor but they also look odd. The ATLAS and the JSON contain data mostly about screen positioning and scaling along with some other mundane definitions. I also tried a bunch of command line toolsets, both official and unofficial ones, that do the same thing but also to no avail. Most posts related to this format point to the Mali Texture Compression Tool, but I could only find its 2.2 version as its latest one, 4.3, hasn't been archived past the tool's discontinuation of service earlier this year, at least not that I'm aware of, so there could be a chance all that would be needed to open these is that version of the tool. I don't believe the data is compressed or encrypted differently than what is documented, but the header is unusual and doesn't match the 16-byte standard seen in other files of the same format, rendering these textures unreadable by every software I tried. The PKM format is related to the Ericson Texture Compression technique and has been explored by other posts in the past, but the one in this game seems to be slightly different. Its files are all laid bare inside typical folders, with a good chunk of the game's assets being in common formats easy to crack open, however, its textures and sprites are stored in a set of 4 files: Two PKMs (one for the base image, another for the alpha channel), an ATLAS, and a JSON. This is a 2D hack n' slash Chinese mobile game that can only be downloaded through TapTap ( ) and I've been trying to convert the imagery in the game into something viewable.
0 Comments
Leave a Reply. |