WorldSpawn official WIP thread

[Mugwump]

compression is never used so these numbers are always the same.

What's the point in duplicating the line, then?

[MadGypsy]

@bfg
Cause the specs say it has to be there. Omitting it will throw off the size of the entry in bytes making it impossible to determine where one entry ends and another begins. Setting the field to some arbitrary value like 0 under the assumption nothing will ever try to read it is not smart. What if something out there does try to read it? Also, storing some arbitrary number is the exact same thing as storing the correct number, except you are using an incorrect one. There is no difference in performance and size, you just have the wrong number. This is because no matter what number you use it is going to be written to 4 bytes. Reading 4 bytes of 0 or 4 bytes of any other number that will fit is still reading 4 bytes.

side - note: according to your prior logic, compression and pad should be omitted as well. compression is always 0x00 and pad is always 0x0000. Both are primarily useless. They can't be omitted though cause wad parsers expect their length to be there.

[Mugwump]

OK, I understand now. Thanks.

[MadGypsy]

scrollable wad view - it's currently scrolled with up/down arrow keys. I need to program an actual scrollbar.

[MadGypsy]

it works on status bar images as well. I just needed to teach my app how to center the smallest element in an entry. In other words if the image/mipGroup width is smaller than the label width...center the image/mipgroup else center the label.

[Mugwump]

Nice! I like that the view includes the submips. Also, I can't talk for other map editors but in Trenchbroom the texture browser has a white background, making the textures look too dark and not very distinguishable. Displaying them on a black background is a very good idea. I should suggest that to SleepwalkR for his next TB update...

[MadGypsy]

the background is 0x111111 so black edges are visible.

look at the background for CONCHARS in my last image (final entry in the view) and it becomes obvious that my background is not actually black.

[Mugwump]

Ah, yes. I hadn't seen that second picture when I made my previous post and what I saw was a good example of what I was talking about: the brighter colors surrounding it made the window background look darker. Zooming on it, it's pretty clear that it's actually some graphite tone. It's even more clever this way since, as you pointed out, it makes the blacks visible.

[MadGypsy]

my palette algorithm is second to none
left - original image
right - image after being redrawn against the palette

[MadGypsy]

However, not all that glitters is gold


Let's review what I am actually doing in my code so it's clear that there is no way to make this better.

My code goes over every pixel of the original image and makes the following decisions...

if ( this color has already been matched ) store palette index for this color
else
loop through all palette indexes and break the color down to RGB channels
individually subtract these RGB channels from the original image RGB channels
add the results together forming a number that represents the overall difference
if the current difference is less than the last difference - overwrite last distance and store current palette index
if at any time the current difference is 0 stop looping through the palette
when the loop is complete (regardless of how) store the original color as found in a dictionary with the palette index as it's value.

ie:
found[orig_color] = palette index

Also store the palette index in the next slot of an array that represents an 8bit image.

So, there is no way to get "better colors". The color it chooses is always the one with the smallest possible difference. I MAY be able to get slightly better results by forcing offsets to one side as opposed to treating them as absolute but, its a 256 color palette... how good can you really get it for ALL situations?

In my output panel it says "found 53291". That represents how many times my script did not have to loop through the palette. So, that is (max) 53291*256 loop iterations that my code completely skipped.

[MadGypsy]

I had an idea and it works very well but, it treats the palette differently and isn't useful for quake stuff.

There is a paletteMap function for BitmapData. It expects 4 arrays (RGBA) of 256 length where redArray[pixelRedValue] == new red value. That being said I wrote functions that convert the palette to these 4 arrays and then sorted each array from least to greatest. So technically all of the values are coming from the palette BUT there is no way to derive a palette index because each channel is more than likely picking from a different part of the palette.

[Mugwump]

However, not all that glitters is gold

Yeah, the Quake palette isn't big on blue, so it tends to make greens look more yellow. I guess you'd get better results with a more balanced palette.

Interesting how your method differs from Mankrip's Super8 engine. He uses some kind of dithering that results in more faithful colors but adds some graininess to the final image. Though TBH, I have only seen pics using QRP textures. I'd be curious to see how his engine behaves with colors like these.

Does this mean that your engine will process any texture according to the palette? In DP or QS, 24-bit textures override the palette, so they look exactly as they were made.

[MadGypsy]

top-left: Original
top-right: Original from Palette
bottom-left: Original Averaged
bottom-right: Average from Palette

[MadGypsy]

I don't think replacement textures will be a problem - no averaging on either original/paletted



it's not perfect but, I think it's pretty good for just making shit up.

[MadGypsy]

No matter what I do I don't get better results than the very first thing I programmed. I'm moving on to other stuff. Here is the final code to port an image to an array of palette indexes.

Super simple and clean.

y = -1;
while ((bmd.height - (++y)) > 0)
{
	x = -1;
	while ((bmd.width - (++x)) > 0)
	{
		pixel = (y * bmd.width) + x;
		
		orig_color = bmd.getPixel32(x, y);
		
		img_r = (orig_color >> 16)& 0xFF;
		img_g = (orig_color >> 8) & 0xFF;
		img_b = (orig_color)	  & 0xFF;
		
		last_offset = img_r + img_g + img_b;
		
		if (orig_color in found)
			bit8[pixel] = found[orig_color];
		else 
		{
			for (p = 0; p < palette.length; ++p)
			{	pal_r = (palette[p] >> 16)& 0xFF;
				pal_g = (palette[p] >> 8) & 0xFF;
				pal_b = (palette[p])	  & 0xFF;
				
				offset = Math.abs(pal_r - img_r) + Math.abs(pal_g - img_g) + Math.abs(pal_b - img_b);
				
				if (offset < last_offset)
				{	last_offset = offset;
					best = p;
				}
				
				if (offset == 0) break;
			};
			
			bit8[pixel] = found[orig_color] = best;
		}
	}
}