I've been working on this most of the weekend thus far, so here's mkg3a, a utility to create Prizm .g3a files from raw binaries, designed for use with the GNU toolchain.

mkg3a-0.1b: http://www.taricorp.net/projects/mkg3a/mkg3a-0.1b.tar.bz2

Usage information is in the included README, you'll need cmake and a functional C compiler to build it. It should compile properly on any system with a working standard library, although my bitmap-handling code won't work on big-endian systems yet (you can remove the #error directive and build it anyway, but icons will be broken).

Icon support is currently limited to .bmp files with 24-bit color depth (I tested with ones generated by Paint.NET), but it should be able to support any image file once I implement the MagickCore-based icon handling (hopefully in the next version).
This sounds awesome! You just convinced me that I need to buy a prizm now Wink

I'm assuming the icons get scaled down somehow into true color format? How do they look after losing the 8 bits of depth?
Ashbad wrote:
This sounds awesome! You just convinced me that I need to buy a prizm now Wink
Smile

Ashbad wrote:
I'm assuming the icons get scaled down somehow into true color format? How do they look after losing the 8 bits of depth?
I'd assume it's not too obviously different, but can't say for sure as I don't have a Prizm either.
FWIW, the color depth conversion routine:

Code:
u8 convertChannelDepth(u8 c, char depth) {
   float v = c / 255.0;
   v *= (1 << depth) - 1;
   return (u8)v;
}

If I wanted to try to be even more accurate I could do the color operations in a non-RGB colorspace to get slightly better perceptual accuracy, but it's probably not worth the effort, especially since the ImageMagick libraries which I intend to optionally support probably do do such a thing.
Ashbad, take a look at some of the existing prizm add-ins that Merth, Tanner, and myself have made; we've completed or made significant progress on quite a few applications between us. Tari, this is stupendous, I will be trying it out as soon as the crashiness issue is resolved with the GNU toolchain.
*bump* Needs moar uploading to the Cemetech Archives! Specifically, the Prizm Tools directory:

http://www.cemetech.net/programs/index.php?mode=file&path=/prizm/tools/
Submitted, now pending approval. I may have a look at packaging it up for various distributions later today so there can be packages out there for those users who find installing software from source to be confusing.
Tari wrote:
Submitted, now pending approval. I may have a look at packaging it up for various distributions later today so there can be packages out there for those users who find installing software from source to be confusing.
Accepted, and available at the link below. I also had to modify the archives script so it would let people download bzip2 files, since no one had previously uploaded any such files. Smile

http://www.cemetech.net/programs/index.php?mode=file&path=/prizm/tools/mkg3a-0.1b.tar.bz2
Unless Tari beats me to it I'll build a mingw based version of it later today.
TheStorm wrote:
Unless Tari beats me to it I'll build a mingw based version of it later today.
Excellent, and I will therefore use that. I haven't gotten a chance to confirm this with you, but the rumor was that you resolved the crashiness issue?
The crashiness was a gcc thing, but you can use this tool with binaries built with any of the SDK setups. Unless I'm missing something and someone figured it out and didn't tell me.
KermMartian wrote:
Ashbad, take a look at some of the existing prizm add-ins that Merth, Tanner, and myself have made; we've completed or made significant progress on quite a few applications between us.


I'm not sure what you mean by that, as I don't see any correlation to how it scales down colors Question but maybe I just have a foot in my ear
Jonimus, I know, but this doesn't do me any good for Obliterate unless I have a GCC toolchain that can mess with 64-bit integer types for me. Smile There was a rumor on #cemetech yesterday that you had resolved the problems.

Ashbad, my point was that you can take a look at the icons that Merth, Tanner, and I made for our programs and see that you don't suffer too much from the loss of color depth for icons.
Meet mkg3a 0.1c. This version includes fixes to the CMakeLists to build properly when using the included getopt implementation, and adds help information on the -i option.

Download: source code or Windows binary.
That's great, Tari! I will certainly grab this immediately. The problem is that we still don't know what's wrong with the completed binaries. Sad
To keep this thread somewhat up-to-date, the toolchain now works. See elsewhere for that.

Someone was looking for a tool to convert the Prizm's 16-bpp images into some more useful image file, so I finally got around to that now. Here's icodump, which dumps the icons from a g3a file. Simple enough to do something similar for any other sort of file; just ask, and I can do it.

http://media.taricorp.net/icodump.exe (temporary download while I figure out where these other utils should go in the long run)
[link broken indefinitely, you'll have to build icodump yourself]

I also changed mkg3a to make unspecified icons all black rather than leave them uninitialized, so here's a new binary for that as well.
http://media.taricorp.net/mkg3a.exe
I believe that Fishbot/Qwerty was the one looking for that. Smile Nice job on putting it together so quickly. How big is it? If it's decently small, you should readme and zip that icodump tool and submit it to the archives.
It's tiny (binary ~8kb), but not release-quality at all. That binary, for example, still has debug output of row offsets while writing image data. Sometime when it's more properly complete, sure, I'll upload it, but not now.
Tari wrote:
It's tiny (binary ~8kb), but not release-quality at all. That binary, for example, still has debug output of row offsets while writing image data. Sometime when it's more properly complete, sure, I'll upload it, but not now.
Sounds good, that works for me. I like that we're building up all these tools, though! When I can next nag you about it, some kind of image or stream compressor/decompressor in C or anything would help me have a titlescreen in Oblit smaller than 166KB. Smile
KermMartian wrote:
I believe that Fishbot/Qwerty was the one looking for that. Smile Nice job on putting it together so quickly.
I think it was me...

Thanks for making it, Tari.

EDIT: It doesn't seem to be working correctly. First, it said that msvcr100.dll was missing, so I downloaded it and put it in the directory of the program. Then, when I tried to extract the icons, the colors in the bmp file were all wrong... This is the selected icon of Conversion:



I tried to invert the file using MS Paint, but it didn't make it look normal.
JosJuice wrote:
First, it said that msvcr100.dll was missing, so I downloaded it and put it in the directory of the program.

For the benefit of others, you need the Visual C++ 2010 runtime, though Microsoft do allow you to bundle the DLL directly with your program these days (in the past you weren't allowed to and had to bundle the redistributable installer instead).
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page 1, 2, 3, 4, 5  Next
» View previous topic :: View next topic  
Page 1 of 5
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement