Topic: Batch Png to Fsh tool (Read 52886 times)

null45 · « **Reply #40 on:** June 24, 2010, 11:29:04 PM »

It should be a bit sharper than GetThumbnailImage, I am actually using the second highest quality setting because the highest quality setting seemed to blur.

ebina · « **Reply #41 on:** July 10, 2010, 08:56:46 AM »

I use version 1.4.4.6 on Windows 7 x64. If I enable Compress dat and/or Fshwrite compression, and processed images by using Save dat, the tool generates FSH of file size 0. Everytime file size of zoom3 textures generated from the same images becomes 0. Redoing images themselves didn't help. Due to those failed FSHs I cannot save a .dat file after changing TGIs in the Reader. Also the Reader crashes by clicking them.

This is contents of Test3_Compress dat_Fshwrite compression.dat in the archive.

I realized that Process button doesn't bring up the problem. Although some manual processes will be needed in the Reader, I'm going to use it for redoing those failed FSHs as a temporary solution.
For testing, I uploaded problematic images, and some .dat files that include failed FSHs. Could you take a look at these? http://www.mediafire.com/?gjqmvg0yqoj

null45 · « **Reply #42 on:** July 10, 2010, 09:59:20 PM »

Strange it seems to be an issue with way DatGen saves the dat, why it would only affect one file I have no idea.

Tarkus · « **Reply #43 on:** July 10, 2010, 10:10:45 PM »

I used to run into a similar issue with PNGs that were mostly transparent with the previous version. It seems to have gone away with the latest version and with Fshwrite Compression checked.

-Alex

null45 · « **Reply #44 on:** July 20, 2010, 09:12:43 PM »

With those files the compression only seems to add to the file size at zoom 3 and below, and due to the way DatGen saves the files into the dat Fshwrite compression is useless when using the "Save dat" function.

The new dat saving code should hopefully fix both of those issues.

File version updated to 1.4.4.7.

ebina · « **Reply #45 on:** August 13, 2010, 05:42:27 AM »

Thank you for the update (and sorry for the late reply). I tested the same images in 1.4.4.7. The new version seems to not create bad FSH.

Quote

...and due to the way DatGen saves the files into the dat Fshwrite compression is useless when using the "Save dat" function.

In 1.4.4.6 the option certainly reduced file size, so I don't think that it was useless. But since I can use the tool without minding the bug 1.4.4.7 is a lot better to me.

Error message appears when I checked both compression options in 1.4.4.7. As you mentioned that Fshwrite Compression is useless when using "Save dat", I know checking both options is meaningless, the error can be prevented by not checking the option. I just wanted to let you know a new error.

I googled and found the translation below. I'm not sure if it is correct or not.

Quote

Destination array was not long enough. Check destIndex and length, and the array's lower bounds.

null45 · « **Reply #46 on:** August 19, 2010, 01:30:40 AM »

That bug should hopefully be fixed, and the Mipmap saving should also be slightly higher quality.

File version updated to 1.4.4.8.

Lowkee33 · « **Reply #47 on:** September 21, 2010, 12:27:10 PM »

Excellent Program! I just started making textures and I don't even know what I would do without this.

Is there a maximum amount of files/size that this can make?

I am new to making images (just played with something other than MSpaint for the first time today) and I am wondering what the best quality would be. I am making 1024x1024 terrain textures.

null45 · « **Reply #48 on:** September 21, 2010, 10:58:15 PM »

Quote

Is there a maximum amount of files/size that this can make?

It would run slower on larger files but should work fine.

Quote

I am new to making images (just played with something other than MSpaint for the first time today) and I am wondering what the best quality would be. I am making 1024x1024 terrain textures.

Fshwrite compression for the DXT1 or DXT3 images would be smaller in size than the 24-bit or 32-bit HD textures but some data would be lost during compression.

null45 · « **Reply #49 on:** November 09, 2010, 08:48:47 PM »

Updated to work with images 64x64 or smaller.

The busy cursor will now be displayed during long operations and processing should be faster for the alpha of larger images.

File version updated to 1.4.4.9.

Lowkee33 · « **Reply #50 on:** December 03, 2010, 01:05:05 PM »

A lowly request... It appears to not like files with extensions that are capital letters.

null45 · « **Reply #51 on:** December 03, 2010, 05:15:57 PM »

That bug and a bug with the command line processing fixed, file version updated to 1.5.0.0.

FlyHigh · « **Reply #52 on:** January 01, 2011, 03:52:21 PM »

Hi everyone.

I'm new to PNG2FSH so this might have a simple answer.
I'm getting this error message whenever I check the 'Automatically process Mips'

What am I doing wrong?

Also, is it too much to ask if you could make a tutorial for the tool?

Thanks

null45 · « **Reply #53 on:** January 02, 2011, 01:25:26 PM »

What is the size of the image you are trying to process?

The "Parameter is not valid" error is a problem with GDI+, unfortunately it does not say what is wrong with the parameter.

FlyHigh · « **Reply #54 on:** January 02, 2011, 01:30:27 PM »

I've tried both a 600x600 and a 256x256

Lowkee33 · « **Reply #55 on:** January 02, 2011, 02:47:45 PM »

For automatically processing mips I believe you need 128x128. I don't think 600x600 would ever work for this program, as the textures need to be squares with a length of a binary amount of pixels to work in SC4. (1,2,4,8,16,32,64,128,256,512...)

FlyHigh · « **Reply #56 on:** January 02, 2011, 02:53:38 PM »

Isn't 128x128 the same as SC4Tool? I decided to use png2fsh because I need more detail on base textures for zoom 6. However I will try to work with the sets of px you've mentioned and report back

null45 · « **Reply #57 on:** January 02, 2011, 04:54:18 PM »

Quote from: Lowkee33 on January 02, 2011, 02:47:45 PM

For automatically processing mips I believe you need 128x128. I don't think 600x600 would ever work for this program, as the textures need to be squares with a length of a binary amount of pixels to work in SC4. (1,2,4,8,16,32,64,128,256,512...)

600x600 would work, but only if you were using Hardware Rendering.

The "Parameter is not valid" error is now fixed.
File version updated to 1.5.0.1.

Lowkee33 · « **Reply #58 on:** January 23, 2011, 11:49:36 AM »

Thanks for the great work and support Null45

I've started using this program for large amounts of files at a time, namely 168 files that come to 126mb. The program works just fine with this, but I have some feedback.

Processing these files takes some time, and so does the saving post processing. Could the "save as" function ask for a file name before it starts processing?

I run dual core, and while processing this program uses 100% of the CPU (good). However, while saving the file, it only uses 50%.

Can we get a progress bar?

Thanks again.

null45 · « **Reply #59 on:** January 23, 2011, 10:12:35 PM »

Quote from: Lowkee33 on January 23, 2011, 11:49:36 AM

Processing these files takes some time, and so does the saving post processing. Could the "save as" function ask for a file name before it starts processing?

That would make more sense than the current method, why process the files if the user cancels the "Save Dat" dialog.

Quote from: Lowkee33 on January 23, 2011, 11:49:36 AM

I run dual core, and while processing this program uses 100% of the CPU (good). However, while saving the file, it only uses 50%.

Can we get a progress bar?

The processing runs in the background so it would tie up the second core and keep both cores at 100%, during saving it would only keep the first core at 100% meaning only 50% of the CPU's capacity would be used.

A status bar displaying the progress of the processing has been added, and the "Save Dat" dialog will prompt for a file name before processing.

File version updated to 1.5.0.2.

Menu

Author Topic: Batch Png to Fsh tool (Read 52886 times)