Problems with Jersey Transparency

DK....

I read your post below and for some reason am not able to reply to that message. So I'll do so here.

I am aware of the Jersey transparency problem. I only appears in the smaller mipmaps. I have also found where in the code the problem occurs. I am now trying to figure out WHY this happens so I can fix it.

Hopefully, the color quality and the transparency problem fixed in the next version (before Xmas!)

Brien, thank you so MUCH.

The transparancy has to be fixed, but I also feel the color change is very important. If the original fsh had 7000 colors I want to be able to import my bmp with very minimal color loss. I really hope this can be fixed because the program seems to reduce color for no reason and butcher the image (as seen in my pic)


I hope to hear more from you.

The transparancy has to be fixed, but I also feel the color change is very important. If the original fsh had 7000 colors I want to be able to import my bmp with very minimal color loss. I really hope this can be fixed because the program seems to reduce color for no reason and butcher the image (as seen in my pic)

Maybe the reduction in colors is due to the way that EAGE read the saved image. The new EAGE version (released tommorrow) does a much better job in reading the files. As for saving them, you can expect more than 500 colors, but you can also expect some image destruction.

The DXTC compression scheme was purchased from S3 by Microsoft. The technique compresses images by grabbing a 4x4 block of pixels and only recording the most representativeTWO colors present. When the block is regenerated at read time, two more colors are regenerated using math. So, each "read" DXTC file can only have four colors per 4x4 block of pixels. So, there is a strong chance that a great looking picture is going to look something less-than-good after it is compressed.

DXTC is "lossy" like jpeg. Both compression schemes destroy some of the image to achieve compression. DXTC achieves an impressive 4:1 compression ration.

Go here to see more techical stuff (and examples) of this kind of compression (S3TC is the same as the new DXTC):

http://www.digit-life.com/articles/reviews3tcfxt1/index.html

I guess I understand better now , but how did EA get so many colors into the originals?

I guess I understand better now , but how did EA get so many colors into the originals?

EAGE (in vers 1.0.0 & 1.0.1) didn't do a good job of reproducing the image. By using only 16 bit integers my math formulas lost a lot of precision during multiplication and division. So what you saw in version 1.0.0 was about 270 colors and about 500-700 colors in ver 1.0.1.

Version 1.0.2 has about 1200+ colors. Which I think is close to what EA accomplished in their images. I could be that my compression alogorithms need more tweaking to include even more colors in compression. I won't know until users like you give me feedback.

Brien

Glad to hear improvement and I can't wait to get the newest version.

I have a question - Is amount of colors used related to import speed and time because you should not try to sacrafice quality over speed.

Brien

Glad to hear improvement and I can't wait to get the newest version.

I have a question - Is amount of colors used related to import speed and time because you should not try to sacrafice quality over speed.

No. In fact the encoding is slow in my opinion because of the quest for quality. The reason you are seeing poor quality has little to do with the stored image. It has to do with the algorithm that EAGE uses to view the stored image.

As much as 50% of the images colors must be generated at view time. When I released EAGE with DXTC improvement, I actually thought "Who cares what it looks like when you view it in EAGE. All that matters is what it will look like in the game."

It didn't occur to me that users needed to save the viewed graphic so that they could edit it. The saved graphic has about 1200 colors or so, the viewed graphic only had 500 colors. So, in EAGE if the imported image had thousands of colors, it got compressed fairly well. But when you turned around and viewed it, you thought that what you saw was all the better it was saved... and that is just not the case.

Another problem is that the number of colors possible is restricted by DXTC compression algorithm. It depends on the image, but as much as 3/4 of the colors will be lost for very complex images. Overall, it doesn't matter much since the players are small and the image detail couldn't be seen that small anyway.

Ohh, Now I fully understand

When do you think the new fixed version of EAGE will come out