IFF Palette Editor
 

I've just released a palette editor I wrote for assisting in assembling palettes for game graphics. It requires AGA (no RTG support yet - sorry), and let you move around blocks of pens, import and combine palettes, preview the changes and save the palette either on its own or with a bitmap included. It also gives handy information about the pen the mouse is over (e.g. "Sprite 2/3, pen 1").

Pens can be modified using RGB, HSL or hex values, and can be rounded to 12-bit values prior to saving if required.

It's in the upload queue on Aminet, and also available from my website

Screenshot:
http://www.robthenerd.com/pics/PaletteEd-1.png

Nice!
What do you think about include standard colour names, like 'light blue' or 'magenta' or something like that for the ones with bad eye sight?

Not a bad idea :) I can throw in the standard HTML colour table with all the standard names. Consider it on the to-do list for the next update.

Only short test on A1200 040 3.1 and VisualPrefs running. Palette -> Insert from file (ILBM file) gives a guru here. I think it was Exception 00000020. With similar action (sorry, can`t remember but maybe Palette -> ...) I also got hits.

Maybe it is usefull to have the possibility to open on a larger screen for the preview IFF ILBM image?

Guide:
I`m not 100% sure but at the end of the guide there is no word wrap allowed after @ENDNODE. Multiview will only show an empty page here. If I remove the word wrap Multiview shows the guide correct. PowerGuide seems hasn`t a problem with this (works both ways).

@daxb

Hmmm, that's strange. What sort of file are you trying to import, as in, is it an image or a plain palette? What bit depth? Perhaps if you could send me that file I could have a look and see what the problem is.

Yeah, a larger screen would be useful indeed, I'll add screenmode prefs to the next version.

As for the guide, it was working fine under Multiview for me, but that was under OS3.9 so there may be differences in the amigaguide.datatype that means I didn't spot the issue.

Thanks very much for the feedback!

It was a simple ILBM image (705x570x4, attached) made with PPaint 7. Maybe the size? The preview looks wrong (colors and position of elements). Today I need to repeat the action to get the hits/exception:
At the moment I use amigaguide.datatype 45.1 on my 3.1 system. Maybe it is in amigaguide.library, multiview or somewhere else? However, you are not the first one regarding the strange behaviour with word wrap at eof. Many years ago I only luckily noticed it. Btw. on Aminet there is a nice tool by Guido Mersmann: text/edit/guidecheck.lha

Thanks very much, that's most helpful! It appears to be a buffer overrun or something in one of Blitz's image loading commands. I did try it with a large image but maybe I got lucky and it worked, but now it seems to trash the program's memory when large bitmaps are loaded, causing a hard crash at the next memory manipulation/allocation operation. I'll swap it to an alternative routine and test it with your image (and other large images). In the meantime I'm afraid I can't think of a work-around other than cropping the bitmap for preview purposes. Sorry about that.

Interestingly, the only issue GuideCheck found was the un-escaped @ symbol in my email address. It didn't find any issue at the end of the file, and it also works fine under 3.1 with the 3.1 datatypes, Multiview and amigaguide.library. But I'll take away the blank line at the end to make sure it works ok in the future on every combination.

Thanks again! :)

It's coded in Blitz? Blitz is notorious for crashing with VisualPrefs, or rather, VisualPrefs is notorious for crashing Blitz programs.

Well, it also happens on a plain 3.1 setup so it's not the case here (though VisualPrefs does indeed have a habit of causing problems).

Nice that you found the causer! :) Cropping the image is fine for now. Good would be if the window gets x/y sliders or something similar to move the clipping image IMO.

The "problem" with @ in email addresses is mentioned in the guide. I think that can be ignored. GuideCheck reported here "Line: 223" "Unknown command: 1". Options used: NodeNameCheck and HTDS but get it also without them.

That's already on the list ;) I actually had that feature in it but couldn't get it working properly so I disabled it until I had more time to figure it out.

Hm, some sort of human myth?

No, just search the BlitzList archives for the term VisualPrefs.

Maybe Blitz is the reason? In assumption the following is true:

VisualPrefs.guide says this:
"VisualPrefs works well with all programs respecting the rules, like adapting to the window border sizes, using system functions for creating/drawing gadgets, etc. Of course, badly written programs or programs using proprietary code for their interface (like MUI applications) will benefit very little from VisualPrefs."

Okay, so I've uploaded a small update to this editor, mainly to fix the issue with the previewing of large images. So now large images don't cause an overflow and crash, and the preview window can now be resized and scrolled around using the arrow keys.

As for VisualPrefs, I don't actually think that's an issue as the screen is opened as private, not public, and so VisualPrefs leaves it alone with the default imagery.

I added some colour naming and identification, but to be honest it was actually quite slow on an 030 and made using the program feel a bit clunky, so I left it out. Perhaps in the future I'll come up with a more efficient way of identifying colours and use it instead.

Thanks for the feedback everyone :)

I tested a bit PaletteEd 1.1. Works fine so far. What I noticed with MagicMenu active is that a mouse event from using the menu will select the pen under the mouse pointer after menu entry choice. Normaly that doesn`t happen with MagicMenu.

You could make the palette naming make optional via tooltype for example for the people who need it. :)

Feature request:
Open a larger screen to have some more space for review pictures.

Ooh, that's interesting, and you're right - it shouldn't happen. I'll check it out.

Yeah, I'll probably include the colour naming later on as an option. I didn't have enough time to get it working as well as I'd like and wanted to fix the crashing bug, so released it as it was. The plan is to adapt it with RTG support, at which point it should be possible to choose any screenmode (or open it on a 24-bit Workbench screen), so that will allow the larger screens for better previews. It's on the list :)

Thanks for the feedback!

Nice tool! Great effort!
Don't know is it just my setup but both in stock wb3.1 and classicWB, menu background and font color are black. Luckily I had MagicMenu so I could read commands if I click somewhere on screen.
Actually I was looking for some remap tool that could not just swap colors in palette but both in iff picture... Would you consider adding that in some v1.2? :)

Hmm, that's a strange one... Thanks for the report! What system are you using? WinUAE I take it, but emulating any particular system? Picasso96 installed?

Yep, I did consider the idea of saving the previewed image along with the palette, but was worried that it might drop other information (e.g. 24-bit images, colour cycling etc.). I can add that feature with a warning though.

WinUAE 3.5.0, emulating A4000 and A1200 no rtg, picasso.
If its of any help snoopdos.log attached but as I see only the things that should fail fail, cybergfx and wizard libs.

And about that "remap" what I actually thought is not just save new palette to previewed iff but... how to put it... like in dpaint if you would select two colors, remap them and then BG<->FG