pressing R for pal grab

Confirmed. I noticed that too when I tried to find a slingshot tile in DoR today.

I'm not very familiar with the tile grabber; what's 'R' suppose to do?

Hmm...If you're grabbing from a quest I don't think "R" is supposed to work. It was working fine for grabbing from .bmp or the like for me.

"R" is like pallete color "re-order", "resemble", or ...actually I don't know wtf it stands for but when you press "R" all the colors change to the closest match(in theory), it's like magic!

Playing around with R for random bitmaps on my hard drive seems to work fine; at least the results are the same as when I do it in build 509.

I guess the question is; "are you supposed to be able to use "R" when grabbing from .qst files"?

I've only tried that in 564 so i'm not sure if it was working correctly at some point.

I was grabbing from a gif and had all the colors in my cset 2 only in a different order and it huffed it.
It might be just gif format that's messing up then.
I'll try and convert it to bmp just for kicks and see what happens.

Sorry fellers, I have to disagree, that just isn't working right at all, even with bitmap.
In addition once you grab an image and try to grab it again there is nothing there, it washes your image out and you have to exit to restore it.

DN fixed it last time, maybe he can take a look at it again.

It's a very important feature that saves hours and hours of graphics work time.

😮dd: I'll have to look into this. I mean, I was just ripping enemy sprites from png and bmp yesterday using 564...???

Again, what is "r" suppose to do? Find the nearest match of the current image using only the colors in the current cset? Do you have specific .bmp that you know is not being correctly processed?

Number 1, what the image is

Number 2 What it should look like

Number 3, what it grabs,

If you look at the screenshot, I recolored those by hand because it wouldn't do it.
Look at palette #3 in that screenshot and you will see it has all the colors that the original stalactites have.
and before you say it, yes I was in cset 3 when I grabbed, even though that screenshot isn't. 😉 I went back in and snapped that pick.

What I'm seeing is that the grabbing works fine unless you already have another file loaded, in which case you have to turn r mode off and back on (hit r twice) for it to calculate the correct colors.

Is that what you're experiencing?

Did you toggle the pallete by pressing "P".? Or how many colors is the bitmap? If the .bmp pallete is like 200 colors, it always comes out like crap.
I'll try it again. The importance of "R" is paramount as a new feature. It has already saved me literraly MONTHS of work. If there is a bug here, it should get fixed. 😉

EDIT: DD posted at the same exact time. ;p

in which case you have to turn r mode off and back on (hit r twice) for it to calculate the correct colors.

Yep. I got into a habit of hitting r,r whenever I load an image.

No, I've never had to hit r twice, so I didn't know anything about that.

Gleeok, they're 16 color images

If you hit P to view the palette colors, then hit R to recolor the grabbed tiles, you will get funky colors. You need to be recoloring in the standard color mode (not the graphics native palette mode). Is this what is happening?

Except for the problem when loading a second file (now fixed), I'm not having any trouble.
I first grab cset 3 from the second screenshot. I then go to the tile editor, change to cset 3, hit "grab," load the first screenshot, and press r. The colors are assigned perfectly - the first screenshot looks exactly the same now and if I turn on pal and disable r.
So unless I'm missing something that's exactly what's suppose to happen. I'll ask DN to take a look at it next time I see him.

EDIT: Well nevermind about that last bit 😉
DN, all I've done so far is add
calc_cset_reduce_table(imagepal, cs);
at line 3417.

http://www.mediafire.com/imageview.php?quickkey=agmlzbn5mzm&thumb=4

I know what freedom is talking about now.
The whole reason "R" kicks ass is because you don't need to grab palletes from images before you rip them. You can use just about any cset that you already have that might have some similar colors.

For some reason I tried this with freedom's image (bmp) and EVERY time I tried to rip it using a pallete (lv/main) cset, it looks like ass. But then I tried it with a random cset (main 10) on other images and had no problems...weird. As you can see in the pic.(I just grabbed and ripped stuff at random in like 30 seconds, and everything else came out looking good.)

Maybe it has trouble seperating the browns.:shrug:

Well, for many of the default csets, there's only so much you can do with 6 colors...

Do you an example of an image that gets mapped differently to the same CSet in this build and previous builds?

They all look the same to me. Same cset too. I tried 492 and 364. Here it is;

For some reason it is almost impossible to use "r" on freedoms pic though. I have no idea.

Pressing R recolors the image to the closest possible match. Depending on the palette and CSet, sometimes it works perfectly, others it looks like ZQuest puked on it. 😉

I tried it again this morning, ZC just keeps puking on that image, but if you guys are sure it's working properly then move this bug report out of here.

Freedom, send me the pic and the quest file you are trying to rip it to and I'll take a look.

The pic is in post 11, it the first one.
The second pic has the right colors in cset 3 but in the wrong positions.
You should be able to grab cset 3 from the second pic, and then try to rip the first pic in using that cset 3 and "R" to set it.
That's exactly what I did, but failed repeatedly.

I still don't think this is working right.
Sharon Daniel gave me some fire keese that were only 3 colors all of which I had in my cset 10 and it screwed them up.

Post the image and the exported colors.

I suspect that if it's not assigning colors correctly, it has never done so, and is not just a problem with the latests builds. However, if you're sure the colors were correctly assigned for the same image and the same colors in an old builds, please let me know which build.

The first (small) image was what it grabbed, even though closer colors are in the palette.
The red background in the large should be the transparent color, maybe it could be made to ignore the first color in a palette?
Otherwise it uses it where it shouldn't.
The black in the small image is transparent, even though a solid black is in the cset that it could have used.
There was a closer yellow then it picked and 2 reds but yet it only grabbed 1 red and used it for the bat and the background, note how different the red is, there is one in my palette that is almost an exact match for that red in the large shot but yet it ignored it.

This ripped closer than the one the other day, which would never rip, but it still could do a lot better.

I need the colors in the cset you're trying to use too; could you please export the quest colors?

Have you still got the SwanSong Genesis quest I sent you?
It's cset 10
If not I'll get an address to you.

Ok, I did some investigation, and here's what I found:
The relevant colors in your palette are:
Dark yellow (54,41,1)
Bright red (63,0,0)
Bright yellow (63,63,16)
Dark red (39,0,0)

The colors in the keese image are
Yellow (60,48,2)
Red (51,0,0)

Now, the red is equidistant from both the dark and bright red - with square distance 144 - so either one is an equally valid choice for nearest match. The dark red is chosen because it's closer to the beginning of the cset.

Next, the yellow: the square distance from the yellow to the bright yellow is 3^2+15^2+14^2, which is much bigger than the square distance from the yellow to the dark yellow, which is 6^2+7^2+1^2.

So despite what it may look like, mathematically speaking the matching done by ZQuest here is correct.

Thank you sir, I'll mark it not a bug and get it out of your hair. 😉