hi.
i've made some digging into colowin's resources (coldataX.dll & coltext0.dll, which are 16bit resource-filled dlls) and have written an unpacker-converter2bmp (see attachement, place into colowin path) of sprites, stored there. the dlls contain following resource groups:
- SPRT (sprites);
- CVPC (pics of bkgnds, map-cells, etc., with embedded palette);
- TEXT (labels);
- FLIC (??? animation{s} (modified autodesk FLC, magic AF12), like outro maybe???);
- CTAB (pics of indians, advisors, etc., without palette);
- CRDS (??? credits stuff???);
- CRED (??? credits stuff???);
- MONS (???);
- SHIP (???).
as i understand, sprites are in 8bpp format (indexed color), and there's no palette bundled, as it was in dos-ver resources.
so the problem is: i can't found out, where does the palette come from. can anyone give me a hint on this? even the disassembly didn't help - it is very messy, and everything i get from there doesnt help a lot - it seems to use palette in logpalette format to feed to the api (when blitting).
update dmy|12.12.11:
1) just figured out, CTAB holds pictures also - added unpack of em in 0.0.2;
2) there's a very strange thing in these dlls - duplicated resource entries. each res from SPRT or CTAB has a preceding id-duplicate of 512 bytes. maybe it's a compressed palette? actually rgb888 palette should be 256 colors x 3 bytes=768 bytes. it also aint rgb565 (16bit, 256x2=512) palette - i checked. dunno what is it...
update dmy|16.12.11:
turned out, CVPC type also holds lot's of compressed(tm) pictures with embedded palette... 3 sleepless nights, lot's of studying disasm, gessing and c-coding, and tadam!!! all decompression routines are rewritten in c, compiled and working as it should in 0.0.3) though, palette is still a thing to do, but it won't be THAT exciting)
p.s. this work is the beginning of another multiplatform (x86, arm) colo-clone with multiplayer. win-ver is chosen because it's sprites are of 2x-hi res, then dos-ver.
b.r.,
m4D.
i've made some digging into colowin's resources (coldataX.dll & coltext0.dll, which are 16bit resource-filled dlls) and have written an unpacker-converter2bmp (see attachement, place into colowin path) of sprites, stored there. the dlls contain following resource groups:
- SPRT (sprites);
- CVPC (pics of bkgnds, map-cells, etc., with embedded palette);
- TEXT (labels);
- FLIC (??? animation{s} (modified autodesk FLC, magic AF12), like outro maybe???);
- CTAB (pics of indians, advisors, etc., without palette);
- CRDS (??? credits stuff???);
- CRED (??? credits stuff???);
- MONS (???);
- SHIP (???).
as i understand, sprites are in 8bpp format (indexed color), and there's no palette bundled, as it was in dos-ver resources.
so the problem is: i can't found out, where does the palette come from. can anyone give me a hint on this? even the disassembly didn't help - it is very messy, and everything i get from there doesnt help a lot - it seems to use palette in logpalette format to feed to the api (when blitting).
update dmy|12.12.11:
1) just figured out, CTAB holds pictures also - added unpack of em in 0.0.2;
2) there's a very strange thing in these dlls - duplicated resource entries. each res from SPRT or CTAB has a preceding id-duplicate of 512 bytes. maybe it's a compressed palette? actually rgb888 palette should be 256 colors x 3 bytes=768 bytes. it also aint rgb565 (16bit, 256x2=512) palette - i checked. dunno what is it...
update dmy|16.12.11:
turned out, CVPC type also holds lot's of compressed(tm) pictures with embedded palette... 3 sleepless nights, lot's of studying disasm, gessing and c-coding, and tadam!!! all decompression routines are rewritten in c, compiled and working as it should in 0.0.3) though, palette is still a thing to do, but it won't be THAT exciting)
p.s. this work is the beginning of another multiplatform (x86, arm) colo-clone with multiplayer. win-ver is chosen because it's sprites are of 2x-hi res, then dos-ver.
b.r.,
m4D.