KMGENC and ARGB1555

[Snatcher]

I was looking into using KMG files instead of PNGs, and after a few changes I got the working. Basically kmgenc has -a1 (ARGB1555) disabled on the svn. I found some info on this forum post (http://www.dcemu.co.uk/vbulletin/thr...-with-KMG-data) and applied the changes, as well as this change on the kmgenc.h file:

#define PACK1555(a, r, g, b) ( \
  ( (a) ? 0x8000 : 0x0000) | \
  ( (((int)((r)*31))) << 10) | \
  ( (((int)((g)*31))) << 5) | \
  ( (((int)((b)*31))) << 0) )

The (a) on the second line has an extra parenthesis.

With that I got it working and now the images load way faster of course, however the filesize of my elf/bin of course went way up. I was wondering if it would be worth it to implement a version of kmg_to_img that reads gziped data. Also, although I am not using DMA if I try to the PVR always reports the data is not 32 byte aligned.. I tried using memalign for all my stuff even tested with the malloc inside kmg_to_img with no luck, though I know that it won't do any good I wonder why that happened.

So basically my question is, why is that code disabled since 2004? nobody using KMG files? should it be corrected? Would the kmg - gzip routine be worth it?

[JLF65]

BlueCrab is about the only one doing anything with the KOS code repo, and he's SLOW about things he's not concerned with. For example, I've been pestering him a few times a year for the last three years to add a patch I made for BIOS Font that adds support for all video modes, as well as transparent/opaque background with the ability to set both the foreground and background colors. I use it in my DC port of Doom (new version over at dcemulation last week).

[BlueCrab]

Gee, thanks for that wonderful glowing review of how I prioritize my time. I'm sorry if things get lost in my complete and total lack of time to work on things. I'm sorry if I have a job and I'm a full-time graduate student.

Unfortunately, hobbies get very little time from me, and I really can't do much about it.

Bitching about me not committing a patch to KOS in public is not the way to get me to do it. Just saying. In fact, its a pretty good way to make me angry and make me ignore it even more... At least if I'm feeling spiteful (which I'm not, at least not particularly).

Anyway, back on topic, I haven't looked at the kmgenc stuff pretty much ever. I don't know why ARGB1555 would be disabled, but I'll certainly look into it when I get a chance. If there's no particularly good reason then I'll fix it.

[Snatcher]

Thanks BlueCrab.. I can tell you it works alright with the changes I documented above.

Regarding the gzip stuff, I went ahead and implemented it and timed it. For a 512x256 lossless texture ARGB_1555 texture these are the resulls:

PNG size: 109 KB
KMG size: 256 KB
gzipped KMG size: 43.3 KB

Load times: (I am using timer_ms_gettime())

PNG: 236 ms
KMG: 8 ms
gzipped KMG: 45 ms

I think the results are worth it if you are using a serial cable, and even with a BBA if you are using several big textures. For small ones it might not be worth it.
Here's the gkmg_to_img code, completely based on kmg_to_img:

int gkmg_to_img(const char * fn, kos_img_t * rv) {
kmg_header_t hdr;
int dep;
int length = 0;
gzFile f;

assert( rv != NULL );

/* Open the file */
length = zlib_getlength((char *)fn);
f = gzopen(fn, "r");
if (!f) {
dbglog(DBG_ERROR, "gkmg_to_img: can't open file '%s'\n", fn);
return -1;
}

/* Read the header */
if (gzread(f, &hdr, sizeof(hdr)) != sizeof(hdr)) {
gzclose(f);
dbglog(DBG_ERROR, "gkmg_to_img: can't read header from file '%s'\n", fn);
return -2;
}

/* Verify a few things */
if (hdr.magic != KMG_MAGIC || hdr.version != KMG_VERSION ||
hdr.platform != KMG_PLAT_DC)
{
gzclose(f);
dbglog(DBG_ERROR, "gkmg_to_img: file '%s' is incompatible:\n"
" magic %08lx version %d platform %d\n",
fn, hdr.magic, (int)hdr.version, (int)hdr.platform);
return -3;
}

/* Setup the kimg struct */
rv->w = hdr.width;
rv->h = hdr.height;

dep = 0;
if (hdr.format & KMG_DCFMT_VQ)
dep |= PVR_TXRLOAD_FMT_VQ;
if (hdr.format & KMG_DCFMT_TWIDDLED)
dep |= PVR_TXRLOAD_FMT_TWIDDLED;

switch (hdr.format & KMG_DCFMT_MASK) {
case KMG_DCFMT_RGB565:
rv->fmt = KOS_IMG_FMT(KOS_IMG_FMT_RGB565, dep);
break;

case KMG_DCFMT_ARGB4444:
rv->fmt = KOS_IMG_FMT(KOS_IMG_FMT_ARGB4444, dep);
break;

case KMG_DCFMT_ARGB1555:
rv->fmt = KOS_IMG_FMT(KOS_IMG_FMT_ARGB1555, dep);
break;

case KMG_DCFMT_YUV422:
rv->fmt = KOS_IMG_FMT(KOS_IMG_FMT_YUV422, dep);
break;

case KMG_DCFMT_BUMP:
/* XXX */
rv->fmt = KOS_IMG_FMT(KOS_IMG_FMT_RGB565, dep);
break;

case KMG_DCFMT_4BPP_PAL:
case KMG_DCFMT_8BPP_PAL:
default:
assert_msg( 0, "currently-unsupported KMG pixel format" );
gzclose(f);
if(rv->data)
free(rv->data);
return -5;
}

rv->byte_count = hdr.byte_count;

/* And load the rest */

rv->data = malloc(hdr.byte_count);
if (!rv->data) {
dbglog(DBG_ERROR, "gkmg_to_img: can't malloc(%d) while loading '%s'\n",
(int)hdr.byte_count, fn);
gzclose(f);
return -4;
}
if (gzread(f, rv->data, rv->byte_count) != rv->byte_count) {
dbglog(DBG_ERROR, "gkmg_to_img: can't read %d bytes while loading '%s'\n",
(int)hdr.byte_count, fn);
gzclose(f);
free(rv->data);
return -6;
}

/* Ok, all done */
gzclose(f);

/* If the byte count is not a multiple of 32, bump it up as well.
This is for DMA/SQ usage. */
rv->byte_count = (rv->byte_count + 31) & ~31;

return 0;
}

[BlueCrab]

I've fixed -a1 in the kmgenc code in r704 of the KOS repo. Still have no idea why it was disabled in the first place...

The only problem with including a gzipped version of the kmg_to_img function is that you then have to link with zlib, even if you're not using it anywhere in your code, just by pulling in the kmg functionality. I'd prefer to avoid that, since it may be an unexpected requirement for people.

[Snatcher]

Quite true, I implemented it on my image code anyway and not on KMG lib.

I tested it with an 8x8 image, and the results are as good as without compression.. so I am leaving it in for my proyect.

[JLF65]

Gee, thanks for that wonderful glowing review of how I prioritize my time. I'm sorry if things get lost in my complete and total lack of time to work on things. I'm sorry if I have a job and I'm a full-time graduate student.

Unfortunately, hobbies get very little time from me, and I really can't do much about it.

Uh, my post was more tongue-in-cheek sarcasm, not meant seriously.

I don't think reminding you every 4 to 6 MONTHS is bitching. I know patching the bios font is more serious than just a couple changes here and there, but you HAVE had over a year to look it over. No rush... take your time.

That's more sarcasm... I do appreciate the work you do on KOS - at least SOMEONE is doing work on it. Perhaps rather than bug you about bios font, maybe I should work on a standalone font system that you would use in place of it when you need more advanced font handling.

[BlueCrab]

Uh, my post was more tongue-in-cheek sarcasm, not meant seriously.

Sorry, I've been rather stressed lately, and my sarcasm detection skills seem to be nil in that kind of situation. I'll try to get a chance to test/commit the code sometime soon (hopefully this weekend I should have time, but I can't promise anything).

[Snatcher]

Another option would be to convert a KMG to IMG from a buffer, that would solve both issues.

[JLF65]

Sorry, I've been rather stressed lately, and my sarcasm detection skills seem to be nil in that kind of situation. I'll try to get a chance to test/commit the code sometime soon (hopefully this weekend I should have time, but I can't promise anything).

It's okay, I've been in the same position before. Sorry about the hassle.

On MyConfinedSpace, the issue got out of hand one time, so a lot of us took to using a pilcrow after sarcastic remarks to help the sarcasm impaired.