@everybody: Thanks for the feedback. In order to be helpful, I need the skin name you were trying to convert, the resolutions (input, output), the file name (script, bitmap, etc). Screenshots are helpful, but I can't go hunting around for a specific bitmap that looks wrong, and it would help if you gave me its name as well.
@miruim: .ui files in the common folder should be left unchanged by definition, just like the bitmaps. I suppose the ones you mentioned should be copied and converted.
@tichuiche: Skin name and resolutions, please.
@specter: Since 0.9 bitmaps are converted on resizing, not in the final step before re-zipping, that's why the bitmaps in the output folder were compressed. The source resolution bitmaps are never converted in place. Instead, they are copied to the destination and converted there. This helps contain the changes to the destination directory. If you open the bitmaps in the destination directory using the "Edit bitmap" button or iPIE, you should see that they have been resized/transformed. I'll look into the bug. Thanks for the new rules.

@gps4blackjack

@tichuiche: Skin name and resolutions, please.

data.zip = V9b all resolution
Skin = Gurjon 5.10 (last version) supported_resolutions="416_234,480_272,480_234,400_240,240_400,320_240,240_320"

before choice of resolution, first phase (unzip)

screen copy : (clic to enlarge)
http://www.casimages.com/img.php?i=0901 ... 102908.jpg

gps4blackjack,

I don't know if this matters, when I am at the bitmaps tab, that is when the bmps are still compressed. And on the bmp screen it doesn't show a before or after preview. There are a few in the directory that are decompressed and those show up as a preview. When I used ipie to decompress all of the bmps while I was at the bitmaps tab in ISW, the preview would work and I could click process and resize the bmps. It would'nt compress them after that and I would have to use ipie again.

the scrollbars are still too small. when I get some time I will compare the before and after template_800_840.ui and see what else can be added to the rules to fix that.
EDIT: the scrollbars may be OK. they are in the common of the data.zip. next version I will select to scale the bmps from the common of the data.zip.

Even at the point it is at right now, your program is a sucess. It does better than 90% of the work to convert a skin. To me that is a huge sucess.

@tichuiche: I can't seem to reproduce your error. Are you decompressing data.zip as well? Do you receive an error saying some directory could not be deleted?
@specter: I can't seem to have your problem either, all the bitmaps show ok here. Did you recently change the location where you run iSW? Do you have a convert.exe in the iSW directory? Can you run a "convert b <bmpname>.bmp" in a command line window? It might be a Vista-related rights problem (SW can't run convert.exe with full privileges and fails silently). conver.exe should aslo be allowed to write in the iSW directory, that's where it writes a converted temp.bmp.
About the scrollbars: can they be scaled with zoom, or only bitmap resizing works? Right now zoom is only used for SPRITEs, everything else is copied and resized.

@miruim: A few things (long-winded post coming ).
Bitmaps are scaled according to their size in the input resolution. However, you are trying to convert resolutions with very different aspect ratios: 480_274 to 320_240! That's why your clock looks all squished. I could make iSW try to preserve the aspect ratio, but it would not be enough, more changes will be needed to the bitmap (add background) or the script (change position) to make things work. The former might work, but will require some heavy changes. The latter requires some manual script editing on your part, because it's be very hard for me to determine inside iSW how to change the position: I would have to read the bitmap and compute the horizontal and vertical offsets. Either way, everything that overlaps with the resized bitmap will have to be changed as well (like the position of numbers on the clock).
To solve your other problem, the .ui files in the common directory would need to be processed as well (which should not be the case). To do this with the current version, you would just copy the .ui file from common to your input ui directory. Also some special rules are needed for your examples in order to properly scale the x and y values on each line. Notice there's nothing like x=..., y=..., which makes this a very special/difficult case. I'd have to make some big changes, like a different list of separators for each rule, and change the way alignment is handled. I'll think about the best way to do it for the next version (if at all). Also, it's impossible to decide which .ui files from common need to be "personalized" for each resolution. Your Becker skin makes the mistake of including resolution-dependent things in variable_def.ui, while it seems other skins don't use resolution-dependent addlistentry in definelistmodel to make lists. I could just copy all the .ui files that are not already there (appending a _XXX_YYY to the file name), but it doesn't make sense if there are no resolution-dependent things in the file. Unfortunately, automatic processing would not work (and would be too complicated to implement) on these files, you should just edit them by hand for now, and post here what works and what doesn't (if not obvious).

One thing you can do is the following: copy variable_def.ui into your input resolution, append _XXX_YYY to its name, and add the following rule:
addlistentry="|prompt
Then, when processing, you will be asked what to put on each addlistentry. Pull out a calculator, compute the scale factors, and change the x and y values at the end of each line, as well as the ALIGN+ values.
It seems like a lot of effort for one particular case, so I suggest just copying/renaming, and then manually editing it yourself.

OK, i downloaded it again and extracted it into a new directory. works this time. wierd but good. =)

Great, looking forward to a new 800_480 diMka skin .

gps4blackjack,

can you update isw to process the .vpr files in common and move them to the 800x480 like you are with the .spr files. that will fix quite a few items.

Here are some issues I found after converting with ISW:
this line was missing the zoom=2000, that is why the compass was so small.
<SPRITE xxx y=10 z=10 h=30 w=126 attach_sprite_provider="other.attach_linear_compass($linear_compass.bmp,navigation.car_heading)">

also on this line, the $rpprg.bmp needed to have the $ removed. the bmp was resized from common but the $ was still left.
<HSCROLLBAR xxx y=8 z=10 h=30 w=126 min=0 max=1 invert bmp="rpbcg.bmp" sprind="$rpprg.bmp" valuemodel="navigation.time_to_destination_int" disable alpha=35>

here are two templates from the scroll bars. removing the $ fixes their size correctly.
<TEMPLATE csuszka_small x=486 z=500 bmp="$fable_scrollbg_small.spr" sprind="$fable_scrollbtn.spr">
<TEMPLATE csuszka x=200 z=500 bmp="$fable_scrollbg.spr" sprind="$fable_scrollbtn.spr">


can be added to rules.ui: vRouteProgress.set |number:scaleY

There is still a small button on the dimka screen. It is because the code that switches and selects the bmp is in the common folder. so it uses the common size. right now, the only way i know to fix it is to resize the bmps in the common folder.

It may make your program simpler and more compatible if you process all the files in the common in the same way as you do the 800x480. just resize everything. Then remove the other resolutions from the skin and only support the converted resolution. Since anyone wanting to create a skin only wants one that works with their resolution. It would be simpler and easier to maintain. Instead of just adding 800x480 to the info.ini file, remove everything but 800x480. But then you only need to do that when someone is using resolution specific code in the common folder ui files. dimka only has 1 thing in there. just something to consider. It is getting closer. I still have a couple of things to figure out.

gps4blackjack,

I posted an 800x480 dimka skin. http://www.igo8mods.com

The speed indicator is still off. It looks like the code that handles the location is in the navigatemap.ui file locaed in the common folder. There may be a way to get it to look correct without modifying the common ui files. This is still an early release, but it is usable.

EDIT: did another test and renamed common to 400_240 and processed it and used those files with the real 400_240 files. When I used those files, it fixed the speed display and the converted skin looks very good. Still needs some minor updates. I will try to post it tonight. if you don't want to add a way to process the common folder, it is not a problem and is easy to work around. It might be a lot of work for you to write the code to do it. It really isn't that hard to do it manually.

Here is an alpha release of the dimka/megaduck99/specter skin for 640x480 and 800x480 (NATIVE RESOLUTIONS). It is based on version 1.19. It still needs work, but it is usable.

http://www.igo8mods.com/diMkaspecter800v91e.zip

New version, 0.92: http://www.igo8mods.com/sw/iGoSkinWizard_0.92.zip

Change Log:
- option to copy/process scripts from common
- option to keep aspect ratio
- option to only include output resolution in saved zip
- also copy and process .vpr files
- some other GUI changes
- changes in Rules.ui (introduced findnumber as rule item type)

I might have introduced some errors with the last change, please check and post feedback. Also, there seem to be a lot of common directory bitmaps to resize... don't remember seeing this many before. I did make the rule parser look for multiple bitmaps on the same line, so that may be the reason.

Wow, that was fast. I'll do some converting and testing this evening and let you know.

Well, I gave up on making the keep aspect ratio fill the background (too hard), and just let it be with the "you may need to edit the scripts" caveat.
If no serious bugs are found, I'll make a 1.0 final version, maybe write a guide (or let specter do it), and share the source on request. I'd love to do a skin editor instead, but have no time and it wouldn't pay the bills .

One small typo in the Zip section: "Covert".

Thanks. Please experiment with all the features and report any bugs you find.