Stephane-D / SGDK

SGDK - A free and open development kit for the Sega Mega Drive
https://www.patreon.com/SGDK
MIT License
1.75k stars 187 forks source link

Wrong tile generation #213

Closed pladaria closed 3 years ago

pladaria commented 3 years ago

Hi,

I'm having issues with some PNGs, it looks like the tile extraction has some problem

:point_right: Download project files: issue2.zip

main.c

#include <genesis.h>

#include "../res/bg.h"

int main(bool hardReset) {
    VDP_setScreenWidth320();
    VDP_setScreenHeight224();
    VDP_setPlaneSize(64, 32, TRUE);

    VDP_drawImageEx(BG_B, &resBgSea, TILE_ATTR_FULL(PAL1, 0, 0, 0, TILE_USERINDEX), 0, 0, FALSE, FALSE);
    VDP_setPalette(PAL1, resBgSea.palette->data);

    while (TRUE) {
        SYS_doVBlankProcess();
    }

    return 0;
}

Source image

image Nothing special with this file, just an indexed PNG exported by GIMP

Result

image

VDP

image

heitorgcosta commented 3 years ago

I'd assume the issue is the bit depth, which GIMP seems to have exported as 2 bits. Opening the picture through Aseprite and exporting it as an indexed png (8-bit depth) made it so that the image loads correctly with SGDK. I could be wrong though, the issue may be something else.

pladaria commented 3 years ago

Yep, forcing the image to 8bpp solves the issue, so there must be something wrong in the PNG bitstream reading when the samples are stored at 2bpp

matteusbeus commented 3 years ago

yes I've had this problem previously!

alicesim1 commented 3 years ago

It turns out that the PNG file; if it is 4 colors, but it is exported by GIMP and it is not fully compatible, only partially with Rescom.

If the PNG is opened for example with Aseprite and the PNG is saved is 4 colors, again if it works perfectly with Rescom.

heitorgcosta commented 3 years ago

Did a bit of digging and it turns out the ImageUtil.java file has a typo specifically on the function that converts 2bpp to 8bpp that rescomp calls.

static byte[] convert2bppTo8bpp(byte[] data)
{
    final byte[] result = new byte[data.length * 4];

    for (int i = 0; i < data.length; i++)
    {
        result[(i * 4) + 0] = (byte) ((data[i] >> 6) & 0x03);
        result[(i * 4) + 1] = (byte) ((data[i] >> 4) & 0x03);
        result[(i * 4) + 2] = (byte) ((data[i] >> 3) & 0x03); <- Should shift by 2 instead of 3
        result[(i * 4) + 3] = (byte) ((data[i] >> 0) & 0x03);
    }

    return result;
}

Adjusting it and re-exporting the rescomp jar fixed the issue.

pladaria commented 3 years ago

Did a bit of digging and it turns out the ImageUtil.java file has a typo specifically on the function that converts 2bpp to 8bpp that rescomp calls. ... Adjusting it and re-exporting the rescomp jar fixed the issue.

good catch!

Stephane-D commented 3 years ago

Indeed good catch ! Just fixed :) Thanks for pointing it 👍