JosJuice, is this how it looks on-prizm? or on comp? because most likely this is occuring because it changed it from 8-8-8 24 bit format to 5-6-5 16 bit format -- though this might not be the case. If it is, then it'll look fine on prizm. If not, I have no idea what happened Shock
Ashbad wrote:
JosJuice, is this how it looks on-prizm? or on comp? because most likely this is occuring because it changed it from 8-8-8 24 bit format to 5-6-5 16 bit format -- though this might not be the case. If it is, then it'll look fine on prizm. If not, I have no idea what happened Shock
I'm trying to extract the 16-bit icon from a g3a file and save it as a bmp image for computers, using Tari's program. It isn't going to look like anything on a Prizm, because it can't open bmp files...
I think he's asking whether it looks like that on the prizm with the addon, which I assume it doesn't. I'm probably just flipping the color channels wrong, so I'll have a look at it in a bit.

benryves wrote:
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).
Ah, good to know, although I don't see why that would be necessary since I'm really only using the C standard library. Is there any way to configure the build to use a static version of the library instead, or am I stuck with that dependency when building with MSVC?
Tari wrote:
I think he's asking whether it looks like that on the prizm with the addon, which I assume it doesn't. I'm probably just flipping the color channels wrong, so I'll have a look at it in a bit.
Yeah, the add-in itself doesn't look anything like that on-calc - it's just the normal Conversion add-in, nothing else.
Fixed; I had neglected to invert the endianness of pixel data before extracting the color channels. Earlier download link has been updated with the fixed binary.

To answer the earlier question on quality loss when packing into a g3a, here's my test image.
Original:

After packing and dumping:

There's a slight difference, especially noticeable in the grey background, but not much.
It's working great now. Thanks, Tari!
Oooh, I really like that icon, too! We definitely need a Fractal generator application. Smile
Tari wrote:
benryves wrote:
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).
Ah, good to know, although I don't see why that would be necessary since I'm really only using the C standard library.

The C standard library is still a library and as such needs to be provided somehow. Smile

Quote:
Is there any way to configure the build to use a static version of the library instead, or am I stuck with that dependency when building with MSVC?

Yes, statically link to the C runtime library - see Configuration Properties, C/C++, Code Generation, Runtime Library (change it to the one that doesn't have "DLL" in the name). Bear in mind the usual caveats of an inflated executable size and the lack of security updates if Microsoft finds a bug in the CRT.
A few questions --

1. What type of input should we give to this? a CPP file? an ASM or HEX file? What's the input?

2. How many parameters does the application take, and what are they?

3. How does the application know what icons you're using? Are they part of the parameters?

4. What would you suggest to use to make the C files? I'm using notepad right now, and without even running it through a compiler -- sorry, I just never really dabbled much with C/C++, so I really don't understand the beaurocratic (complex setups and compiler stuff) side of it much :/

5. Are there any tutorials that can help teach me exactly how to carry out the process of using this in steps, from installing the libaries to how to use the other features? Like I said, I'm lost.

I'm just asking these because I just crashed my prizm 3 times with weird add-ins from feeding just a SNAKE.CPP file :3 (a 2MB file for the g3a when the source was the same size -- though I think I just was supposed to feed in an already-compiled thing first, I think)

Sorry if I sound n00bish.
Ashbad wrote:
1. What type of input should we give to this? a CPP file? an ASM or HEX file? What's the input?
Give it a compiled binary.

Ashbad wrote:
2. How many parameters does the application take, and what are they?
3. How does the application know what icons you're using? Are they part of the parameters?
mkg3a -h:

Code:
Usage: mkg3a [OPTION] input-file [output-file]

  -i (uns|sel):file
                Load unselected/selected icon from file
  -n lc:name
                Set localized name for language code
  -v
                Show version and license information then exit

Valid values for lc are basic, internal, en, es, de, fr, pt and zh.
Empty lc is an alias for basic.  Unset names will be derived from
basic, which defaults to output file name.

Multiple -n or -i options will all be applied, with the last
specified option overriding previous ones with the same key.


Example of compiling addin.c into MyFirstAddin.g3a with the gcc Prizm SDK package (mostly stolen from the included Makefile):

Code:
# Compile
$ sh3eb-elf-gcc -m4a-nofpu -mb -Os -mhitachi -Wall -nostdlib -Iinclude -lfxcg -lgcc -Llib -Tprizm.lkr -Wl,-static -o addin.bin crt0.s addin.c
# Make g3a with a few localized names and icons
$ mkg3a -i uns:unselected.bmp -i sel:selected.bmp -n "en:My First Addin" -n "es:José" addin.bin MyFirstAddin.g3a
(Yes, its Spanish name is José.)

Ashbad wrote:
4. What would you suggest to use to make the C files? I'm using notepad right now, and without even running it through a compiler -- sorry, I just never really dabbled much with C/C++, so I really don't understand the beaurocratic (complex setups and compiler stuff) side of it much :/

Find an editor that suits your taste. I like Notepad++ for small tasks, but I usually find it useful to take the effort to set up Eclipse CDT for cross-compilation when projects reach any sort of larger size. If you can't figure this out, though, setting up Eclipse for cross-compilation is probably far beyond you. See above for compilation.

Ashbad wrote:
5. Are there any tutorials that can help teach me exactly how to carry out the process of using this in steps, from installing the libaries to how to use the other features? Like I said, I'm lost.

Most everything you need is in the PrizmSDK package Jonimus is hosting. Kerm and I have not been able to get it to compile C programs for us yet, but that seems to be a misconfiguration on Jonimus' part. When using that package, building should be as easy as editing the makefile a little and running a script.
The program works, but there's a bit of a stability problem* and the dependence on msvcr100.dll is annoying. I didn't have that .dll library installed in the system folder and it wasn't in the SDK from what I could tell, so I had to steal a version from another program to get it to work.

As for stability, entering the name of a file that doesn't exist will cause the program to enter an infinite loop or crash. You might want to consider validating the inputs...
Can you provide a test case? The parts that read the input file check that it was opened successfully, as do the icon handling bits, so I'm not sure where that fault might be.

I uploaded a statically-linked version of icodump just now (so it doesn't require msvcr100.dll), but mkg3a itself fails to link properly when I do the same to it, so I'll have to muck with it some, and I'll post again when I get that uploaded.
Alternatively, you can install the VC++ 2010 runtime package (32 or 64 bit), although I understand if you'd rather not do that.

EDIT: ah, I see the problem now. The lazy assertions I threw in aren't handled when compiled in non-debug mode with VS. Fix coming up.
EDIT2: all fixed now, and the static linking problems with mkg3a had to do with my getopt implementation trying to still link against the dll. Fresh static binaries of both tools are up.
Has the new version been re-integrated into the SDK available from Jonimus' website yet? When Tanner and I and the rest of us make more progress on our Prizm projects and I post more news, I'd like to post an updated PrizmSDK link too. Smile
KermMartian, well the current issue is that I am having issues getting gcc to actually be static. It looks like the best option would be to recommend the use of the KPIT tools in place of my self built GCC until I can get a better setup. The main issue with that is KPIT requires you register on their site but at least it is still free.
TheStorm wrote:
KermMartian, well the current issue is that I am having issues getting gcc to actually be static. It looks like the best option would be to recommend the use of the KPIT tools in place of my self built GCC until I can get a better setup. The main issue with that is KPIT requires you register on their site but at least it is still free.
I think I missed something somewhere about KPIT; I'll go look in the PrizmSDK news thread to see what you're talking about. If I just track down the relevant DLLs, that would be enough though, would it not? Anyway, I'll stop hijacking Tari's thread for now.
KermMartian wrote:
If I just track down the relevant DLLs, that would be enough though, would it not?

Yes. You need libgmp-10.dll, libmpd-2.dll, and libmpfr-1.dll. They need to be in your working directory for some reason (not the bin directory).
*nudge*

New version, 0.1d. Changes since 0.1c:
  • Icons default to all black rather than uninitialized
  • More useful error messages
  • Added g3a-icodump to distribution (previosly just icodump)

I'm too lazy to make release tarballs right now (or binaries for that matter), so you'll need to check it out of source control for yourself:

Code:
$ hg clone -r 0.1d https://bitbucket.org/tari/mkg3a
/me does a clone. Thanks for your continuing hard work, Tari! I'm really looking forward to finishing classes in a few days and being able to relax with some heavy-duty Prizm development.
Okay, apparently mkg3a fails when the files are >768 MB large Razz

EDIT: Pointer failure appears to have caused the assembler to produce a 768 MB file from a 30 line source.
Sounds like a sort of 'not my problem' bug. I tested on some large files anyway, and successfully built a g3a from a ~900MB file, although it took a while. I'll add an input file size limit (16MB, to match the amount of user-accessible Flash) anyway, just so nobody wastes time waiting for it to write a pointlessly large file.

EDIT: done, and in the repo. Takes a page from gzip for the error message:

Code:
printf("Cowardly refusing to operate on input file larger than 16MB\n");
  
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
Page 2 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