That's the way iSW is (supposed to be) doing it, so... I guess take a look at the Gurjon skin, but I think even diMka has some zooms someplace. Use TotalCommander to search in files.

PS: Yay, 100 WRZ$

That's the way iSW is (supposed to be) doing it, so... I guess take a look at the Gurjon skin, but I think even diMka has some zooms someplace. Use TotalCommander to search in files.

PS: Yay, 100 WRZ$

i will try some more. dimka does it like this:
<SPRITE xxx x=0 y=1 z=2 bmp="$tmc.spr" phasemodel="*.icon_phase" visiblemodel="!*.single_icon&!ui.vOnFlyover" zoom=800>

it is at the end of the line in every case. that may have been the problem.

gps4blackjack

Please, take a look at this 2 images..
there are something that fails in the conversation.. really dont know what, but.. you´re the man. As you see, there are not aligned collums. you know why in one case it happens and on the other menu everything is perfect ??

Regards

probably something in the template_xxx_yyy.ui file

The best fix would be to look at the template_xxx_yyy.ui in the data.zip to the resolution you are creating. Then take the template_xxx_yyy.ui file you are using an input into ISW and compare it to the one in the data.zip. If you can compare those files you can find out what changes where made for the skin you are trying to update. Then only change those lines in the template_xxx_yyy.ui you created for your resized skin. hope that makes sense.

it is at the end of the line in every case. that may have been the problem.

I think, this not a reason. In gurjon works lines like:
<SPRITE xxx bmp="$StrNMap.bmp" zoom=2000 alpha=32 x=0 y=442 z=0>
<SPRITE xxx x=782 y=112 z=23 alpha=8 bmp="$recalc.bmp" zoom=1200 visiblemodel="!ui.vOnFlyover">
<SPRITE xxx x=786 y=186 z=23 alpha=8 bmp="$bluetooth_on.bmp" zoom=1200 visiblemodel="!ui.vOnFlyover">

how can I automatically decide which bitmaps to just copy? Some (car icon, etc) might indeed be fine, but others (buttons) won't. Won't they look too small in the case you're talking about (200% zoom)?

It seems in vga folder bitmaps already 2x bigger, so just enough to copy over without any modification. In my gj conversion workflow I first resized all bitmaps (iPIE decompress, gimp resize script, iPIE compress) and then just copy over from vga folder.

So, when is vga folder activated? When "vga=1" in sys.txt, or...? Does "vga=1" have other effects?
And how come there are (ex: diMka) 320_240 and 240_320 folders inside of it? Are those equivalent to regular 640_480 and 480_640 (not present)? If not, what is the difference? In the case of diMka, it seems to just have some bitmaps, and no scripts.

And... 2000 and 1200 in your gj examples seems pretty high, does that mean it's actually 200.0%, so the number is actually in tenths of a percent?

So, when is vga folder activated? When "vga=1" in sys.txt?

Yes.

2000 and 1200 in your gj examples seems pretty high, does that mean it's actually 200.0%?

Yes.

When vga=1, then igo looks if vga folder exists and using bitmaps from it (without resizing). If vga folder does not exists- using bitmaps as usual and in case highres=1 resize bitmaps.

Good example of vga structure You can find in original gurjon skin: http://www.gurjon.com

I still don't quite understand...
Does zoom not work when "vga=1"?
And, for example, is the "\vga\400_240" folder used for 800_480 when "vga=1"? Is the sys.txt value still "800_480" then?

One possible bug.
Regarding replacing numbers. Rules.ui file:

Code: Select allnGPSViewGlobeCX=|ifnumber:replace:{108}
nGPSViewGlobeCY=|ifnumber:replace:{94}
nGPSViewGlobeRX=|ifnumber:replace:{60}

Original ui file:

Code: Select all<var nGPSViewGlobeCX=75>
<var nGPSViewGlobeCY=88>
<var nGPSViewGlobeRX=54>

and output looks like this:

Code: Select all<var nGPSViewGlobeCX=10>
<var nGPSViewGlobeCY=9>
<var nGPSViewGlobeRX=6>

Next version will have the bug fixed for "replace{}" rules. It took me a while to figure out you came up with new rules. Any reason why the original "ifnumber:ScaleX" and "ifnumber:ScaleY" rules are not valid? Are the values in percent again?
Anyway, in this case, the rules should be "prompt" if you want to have control over the replacement value.

I still don't quite understand...
Does zoom not work when "vga=1"?
And, for example, is the "\vga\400_240" folder used for 800_480 when "vga=1"? Is the sys.txt value still "800_480" then?

if you running 800x480 with these settings:
resolution_dir="400_240"
and highres="1"

it will use the \vga\400_240 files (since they are already double sized)

But if you are using:
resolution_dir="800_480"
and highres="0"

it will not use the \vga files because it will assume that the 800_480 directory already has the appropriate files. It will only use the VGA directory when using highres="1".

If that was the case, then what use is the "vga=1" switch?

if you running 800x480 with:
resolution_dir="400_240"
highres=1
and not setting to vga=1

then it will use the \400_240 files and double images

But if you are using:
resolution_dir="400_240"
highres=1
vga=1

then
it will use the \vga\400_240 files without scaling if exists (since they are already double sized).

With this way we can improve skin's look (thanks to vga feature), but all other things (not covered by skin and absent bmp's in vga) are still upscaled (menu, for example).
This is main reason why I took real 800x480 skin converting job.

New version, available at http://www.igo8mods.com/sw/iGoSkinWizard_0.9.zip

Change Log:
- many improvements and bugfixes
- support for internal conversion of multipal bitmaps (iPIE no longer needed)
- fixed some transparency issues, but in some cases the magenta transparent color still blends with the foreground
- fixed zoom feature, it was not working at all
- .spr files now copied and converted when scaling files from "common" directory

PS: Specter, thanks again for the website, and... please update .

Just a note: Many memory errors are due to directories not being deleted when they should, so heed the warning messages telling you to delete from Explorer.

Well, for the first time since I started this project I decided to try it out for myself, with the latest diMka skin. I got a ffui error </layer> missing message (it'd be interesting to hear what you did, Specter, to make the older version work). But, with iSW things should be a lot quicker, so I hope that's of some help. Looking forward to a working 800_480 skin - the reason I started this in the first place!