Only one constant buffer to update / transfer with 16 bytes per sprite, everything else is immutable on the GPU side. Only a single draw call per frame for all the sprites together. Pros: 8-bit palette effects whee! Color swaps and colorize effects are easy. Data is in an array containing destination position, color shift (to draw sprites with alternate colors, frozen, blinking or any other palette effect) implemented as a row in a lookup table, and sprite flip flags for rotation or horizontal and vertical mirroring.ġ2) the game code calls startUpdateSprites() to map the constant buffer to memory and get a pointer to a sprite data array This buffer is immutable and stays the same from the moment we're done creating our atlas.ġ0) my vertex buffer just contains a list of positions going from 0,0 to 0,1 to 1,0 to 1,1, repeating, created as immutable.ġ1) I have another constant buffer containing a list of sprites drawn to the screen this current frame. 16384 is irrelevant here since we chop down to what we need later (and don't need to allocate any memory until then)Ħ) I read the first element of my list of rects to fill, place the biggest non-placed sprite that fits in the top left corner of the rect, and subdivide the rest into two rects, one to the right for the remaining width and one to the bottom for the remaining height.ħ) Once every sprite has been placed, I create a texture with a width of 1024 and a height of the next power of 2 from how high my texture needs to be to contain everything.Ĩ) I copy from the effective parts of my many PNG buffers to my single large atlas, ignoring the marginsĩ) I create a DirectX11 constant buffer containing an atlas info array: position, size, offset (to re-add removed margins, and to place centered sprites at their center) and 64 bits of padding because of constant buffer restrictions. I chose 1024 wide because I'm simulating 320x200 VGA games, so I can fit 3 full-screen pics of title / intro / stuff wide in my atlas. I start with a single rect of 1024 by 16384. I'm using 8-bit sprites so index zero is transparent.Ĥ) I sort sprites by effective height (transparent margins don't count) from tallest to shortestĥ) I maintain a list of rects to fill. (So game specific code needs to have some form of for loop calling the load fonction on all the rects)Ģ) I open the files with code from as 8-bit indexedģ) I check the size of the top, bottom, left and right edge margins. Sprites from a sheet specify a rectangle to grab from the sheet. Feedback Friday Screenshot Saturday Soundtrack Sunday Marketing Monday WIP Wednesday Daily Discussion Quarterly Showcase Related communities 1ġ) I add sprite filenames to a list of sprites to load, along with centering parameters. For questions, get in touch with mods, we're happy to help you. Free assets OK, be sure to specify license. If you need to use screenshots, that's ok so long as is illustrates your issues.ĭo not solicit employment. Use discord, /r/indiegames, /r/playmygame or /r/gamedevscreens.īe specific about your question. Feedback, praise, WIP, screenshots, kickstarters, blogs, memes, "play my game", twitch streams. 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. |