Our ReVolt Pub

As the patch 512 will be integrated in the upcoming version of WolfR4, it reminds me I was thinking about releasing the little texture resizer tool I previously wrote to create easily 512x512 textures from existing 256x256 textures.
For example, this tool was used to create the 'Set of 512x512 textures' I'm providing on my website to be used in conjunction with the 512 patch.
But I was using this tool without GUI and all that kind of user friendly stuff, like saving settings to ini file, error managment, etc, so I had to write all these boring parts before releasing it.

I think it should be done in the coming days. For now, here is a screenshot:

Looks cool man, I'll be waiting, hehe.

Nice to hear Jig, lol now all my manual re-sizements must have been a waste of time. Well, at least I can improve some of the textures better manually than a program can per automatique.

Anyways, I hope that your tool will make the 512patch more popular - both for track makers and racers. What's most boring? HUD positioning or the last boring parts of the Re-Volt Texture Re-sizer?

That's done.
The first release of RVTexturesResizer can be downloaded from my re-volt webpage.

It still lacks a proper documentation, and the tool was not that much polished, but it should be working. I have chosen to release it now, and add missing stuff eventually, rather than waiting still more...

Here is an extract of the readme file:

readme file wrote:This tool is intended to be used with the 512 patch. It will resize the
re-volt textures and create the appropriate mipmaps textures (.bmq files).

Install:
Extract the downloaded archive content in the Re-Volt directory (recommended
but not mandatory, as another directory could be used).
Set options (default ones should be ok) and use the 'Proceed' button. Answer
'Yes' to the next question and the texture resizement process will begin.

Warning: We there is more than about a hundred textures to resize, it can take
quite a long time to complete.
Warning: The directories browsing (looking for textures) and the resizement
process can't be interrupted.


Uninstall:
Unistall is not really possible, but you can go back to a state very similar
to before RVTexturesResizer was run following this procedure:
- Run RVTexturesResizer with texture size set to 256 and mipmap count set to 2
(don't use the "quick refresh mode" option).
- Then you can delete all the 'bm_' files in the re-volt directory (and its
subdirectories). You can use the Windows search function: search for *.bm_ and
delete all found files).

urnemanden wrote: What's most boring? HUD positioning or the last boring parts of the Re-Volt Texture Re-sizer?

Well, the HUD positioning, definitely...

wow, great job again jig. thanks for the tool in all track makers' name!

I just have a few suggestions, even tho I don't expect you to update the RVTextureResizer.

Drag N' Drop feature
If a texture is dropped towards the exe, it automatically creates a re-sized version of it, depending on the .inf file.

Save as BMP
Since it doesn't spare me much time using the tool, when it saves in png, compared to when I re-size manually, I would like to be able to choose between these two formats.

Replace original textures option
Will overwrite all textures that might be named the same.

Again, thank you for a nice tool. I will use it to re-size tracks I test out from RVZT

Re: Drag N' Drop feature
I have never implemented any drag & drop stuff yet, maybe it could be usefull, though RvTR is currently designed to work with directory, I don't know if I can easily add support for files.
Are you sure it would be a real benefit for the user, compared to using only directory? (I don't want to spend time on it only for the pleasure to add new gadget ).

Re: Save as BMP
In fact, the BMP/PNG selection seems buggy. RvTR can work with PNG files because I have designed it with png texture support in mind. But normaly it should not use PNG format for now. I have already noticed some troubles with PNG, but I though it came from my re-volt installation, which has became quite messy with all the tries and tests I have done...
To make it clear, it should save in BMP format, and if it doesn't do so, it's a bug that I have to fix.

Replace original textures option
That one, I don't really understand, unless RvTR is not working like I expected.
RvZT works that way:
At first application, it create a .bm_ file, which is an unmodified backup of the 256x256 texture files (bmq file are not backuped). As the resizing process is not "lossless", it's good to keep an unmodified texture (RvTR will uses this texture for each new resizing job, for example if you decide to re-launch it with different parameters).
Then RvZT will create all needed BMP and BMQ files, overwritting the original textures.

But maybe it's the above PNG saving bug that leads you to ask for this option...

Re: Drag N' Drop feature
I would find it very useful, especially if I also was able to set a parameter called "x2" to make the size of the bitmap double as big. Then I could manually detach all textures from bitmaps and re-size them easily by using RvTR, so I could merge them together again and in that way prevent nasty transitions between the textures.

Re: Save as BMP
Well, here it only saves as PNG and sometimes it makes the texture 1024x1024 if I use one mipmap level and at 512 pixel size.

Re: Replace original textures option

Jig wrote:But maybe it's the above PNG saving bug that leads you to ask for this option...

Correct, as I never saw RvTR re-size to bmp format.

Re: Drag N' Drop feature
I'll maybe add it in next release. But just to be sure: you're talking about draging images files (from the explorer), not about draging images content from an image editor, aren't you?
About the "x2" parameter, I don't think I'll add it, that's not the way RvTR works. It is designed to reach an absolute target size (eg. 512px), not to use a relative zoom factor (like 2x).
If you're ready to detach all textures by hand, maybe you'd better do all the resizing process with your image editor instead of using RvTR. The only thing you'll lose by not using RvTR is the black-transparent pixels "smart resizing"...

Re: Save as BMP
PNG saving is definitely a RvZT bug. I'll release an update soon.
The 1024x1024 bug is weirder, I'll try to check that too.

Re: Drag N' Drop feature
I mean files from the explorer, yes. I personally find that easier because I necessarily doesn't want all the textures re-sized (Those texture that doesn't fit the whole bitmap will get re-sized manually).
Luckily about the black-transperant pixels, I found a neat solution, where I use a plugin called "Alias". I then set the tolerance to 128, so all transparent pixels with a value less than that, will get deleted. Whether it's just as good as RvTR's smart resizing, I don't know tho.

Re: Save as BMP
I'll promise to test it out, when that update is released then

Re: Drag N' Drop feature
Well, I began to implement it yesterday, to see how it work, etc., and in fact I don't think I'll add it:
Like I explained above, RvTR will work from the BM_ file when it this file exists. But if a user drags a BMP file, what does he expects? (read slowly what's following if you really want to understand )
1. that RvTR will resize the corresponding BM_ file (because normally, it's alway the BM_ file which is used as the source image). But if you have edited the BMP file instead of the BM_, the BMP content will be overwritten by the BM_ (so modifications will be lost).
2. the RvTR will resize the dragged BMP file. But it means that it has to overwritte the BM_ file, and overwritting a backup file is no good. We can imagine not to overwritte the backup file, but as this is the file used by default on each next resizing process, if some days later you decided to resize all textures in the directory, BM_ file be used and BMP file will be overwritten, and modifications will be lost...

The only good way would be to use [answer '1.' above], and that the user takes care about editing only BM_ file, not BMP... it's quite complicated.

I hope you've understood why it implementing support for files instead of directory can lead to inconsistencies. Of course, I still could add support for dragging directories, but I don't think that was what you wanted...

@Urnemanden
Drag and drop feature doesn't seem to be an appropriate solution (see my previous post), but I have another idea that could help when you want to resize only part of a texture:
I've added a button to manage clipboard. You set the resizing factor, you press the button, and the image in clipboard get resized, and is pushed back into the clipboard. Then you can paste it back into your image editor...
I think it could do the job.

That's even nicer. I would certainly find that useful!

urnemanden @ Jun 1 2010, 05:21 PM wrote:That's even nicer. I would certainly find that useful!

I hope so...

I have updated RVTexturesResizer.
It can be downloaded from my re-volt webpage.
Here is the changelog:

changelog wrote:* Release:10-06-01
Mod: A lot of code have been reworked, I can't list all modifications.
     Some bugs were fixed. I hope none were introduced.
Fix: Images are now properly saved in BMP, not in PNG.
Add: "Resize Image in Clipboard": this command allows to resize any image
     with a given ratio (ratio is a power of 2, for example: 2, 8 or 0.5).
     In the Images Editor of your choice, you select an image or a portion of
     an image and copy it in the clipboard.
     In RvTR, you set the resizing factor, you press the button: the image
     in the clipboard is resized and pushed back into the clipboard.
     Now you can paste it back into your image editor...

As I have never noticed that it saves in 1024x1024 when I ask 512x512 (as Urne reported), I don't know if it has changed with this release. Urnemanden, if you still see this bug, please keep me informed.

Sorry jig, but the Re-Volt Texture Re-sizer still creates png's, bm_'s and bmq's only. I neither managed to find out how to use the new paste feature, but that could as well of course just be me who seems to be rather stupid when it comes to GUI's. =P

urnemanden @ Jun 1 2010, 11:13 PM wrote:Sorry jig, but the Re-Volt Texture Re-sizer still creates png's, bm_'s and bmq's only.

Well, I can't believe it...
It's really strange, all seems ok here, I don't know what to check. Maybe I'll send you directly some test versions by email, and you'll tell me if that changes someting.

I neither managed to find out how to use the new paste feature, but that could as well of course just be me who seems to be rather stupid when it comes to GUI's. =P

No problem, but I don't know what I can say more than in the changelog...

1. In the image editor of your choice, you select an image or a portion of an image and copy it in the clipboard.
2. In RvTR, you set the resizing factor, you press the "Resize Image in Clipboard" button: the image in the clipboard is resized and copied back into the clipboard.
3. Now you can paste the resized image into your image editor...

And sorry for the stupid question , but I have a doubt now. Are you actually running RvTR Release date: 10-06-01 ?

Jig wrote: And sorry for the stupid question , but I have a doubt now. Are you actually running RvTR Release date: 10-06-01 ?

That's a good question. See, Chrome actually just showed me a cache-copy of what your link is refering to, and so if I pressed "download", I would get the old version of the re-sizer. Thanks for mentioning a date, I wouldn't have found out otherwise =P

Everything works alright now, I tested both the re-sizing and the clipboard re-sizement (indeed useful!). I also tried to reproduce the 1024bug, but I was at the moment not able to get the same bug as previously. As I am going to use this tool more often now, I will tell you when I notice something

urnemanden @ Jun 2 2010, 02:14 PM wrote:

Jig wrote: And sorry for the stupid question , but I have a doubt now. Are you actually running RvTR Release date: 10-06-01 ?

That's a good question. See, Chrome actually just showed me a cache-copy of what your link is refering to, and so if I pressed "download", I would get the old version of the re-sizer. Thanks for mentioning a date, I wouldn't have found out otherwise =P

Everything works alright now, I tested both the re-sizing and the clipboard re-sizement (indeed useful!). I also tried to reproduce the 1024bug, but I was at the moment not able to get the same bug as previously. As I am going to use this tool more often now, I will tell you when I notice something

This is why I use the beloved "clear cache after close" option, surely Chrome has this, right?

Actually no. Chrome still lack a few practical features/options, but luckily it isn't that bad, that it doesn't fit well as a browser for me

I had noticed this cache issue, when I modify a page, I have to refresh the page cache (with [Ctrl+F5] on Firefox) to see the modification. As I had not removed the previous RvTR zip file from my server, you could still download it if you browser had my old webpage in its cache.
I have no idea if there is any trick to avoid that kind of issue, for example, to indicate that the page content has been modified and force the browser to update its cache...
But at least, I'll now think about removing immediately the old file, so that you can't download it thinking it's the good updated one.

Anyway, I'm glad to see that the updated RvTR seems to work nicely.

It's been a while since last time I manually re-sized something (your tool's automatique is great, so I am only doing things manually if that track is going to stay in my collection permanently). I did try doing the clipboard-method and it works quite well. It is fastly done, Ctrl+C -> Press a button -> Ctrl+V

The only thing I noticed was the white fill, that seems to replace transperancy, when running a not-so-squared selection through your tool.







I also tested a semi-transparent color, and the same white seems to replace transperancy in that case as well. Perhaps it's a limit of the texture re-sizer, but I practically doesn't know anything about how the clipboard works and such, just thought I would give you a notice.

Neighbour re-size at low resolution
Another bug I just found - perhaps it was on purpose, but in that case I don't see the advantages other than there it might be faster to re-size. I tried out re-sizing it with the bilinear filter in P.NET itself, but the same bug doesn't appear.



Suggestion: Keyboard shortcut
Just a thought. It could be nice if I could do all the re-sizements by Keyboard (Ctrl+C -> Alt+Tab -> Keyboard Shortcut -> Alt+Tab -> Ctrl+V).

Thanks for the tool, it's wonderful

urnemanden @ Jun 23 2010, 07:16 AM wrote:The only thing I noticed was the white fill, that seems to replace transperancy, when running a not-so-squared selection through your tool.
[...]
I also tested a semi-transparent color, and the same white seems to replace transperancy in that case as well. Perhaps it's a limit of the texture re-sizer, but I practically doesn't know anything about how the clipboard works and such, just thought I would give you a notice.

It's a normal behavior, because this tool works with 24bits image (re-volt textures are in 24bits). If you supply a 32bit image, the tranparency layer is removed (to give a 24bit image), and the color that results probably depends on the image editor you're using.

Instead of using transparent zones, try to fill them with pure opaque black color (0,0,0). I think it should work nicely, because black is well preserved when resizing with this tool.

Neighbour re-size at low resolution
You're right. Resizing a 86x86 pixels area seems to be done with a smooth interpolation, while for a 85x85 area, there is no interpolation (for a rectangle area, values seems different).
Unfortunately, it seems to be a bug in the implementation of the resizing function integrated with the programming language I use. I can report the bug, but there is no hope it could be fixed quickly. I'll try to see if there is a possible workaround, but I don't think so.

Keyboard shortcut
I'll see if I can add it.

Hi!
Nice tool Jigebren...
I have created bitmaps resizer (to 512x512 resolution) and it is in my WorlDO tool...
I wanted to fix that what posted Urnemanden and I think I will do that...

Jig wrote: It's a normal behavior, because this tool works with 24bits image (re-volt textures are in 24bits). If you supply a 32bit image, the tranparency layer is removed (to give a 24bit image), and the color that results probably depends on the image editor you're using.

Instead of using transparent zones, try to fill them with pure opaque black color (0,0,0). I think it should work nicely, because black is well preserved when resizing with this tool.

The selections I showed does not contain any transparent pixels - it's the bilinear filtering that makes them, when my selection aren't rectangular. And yea, I could select what I need re-sized -> Copy it -> Create a new layer -> Move the layer behind the actual layer -> Paste my selection -> Add black color instead of transparent pixels -> Select the whole bitmap -> Copy the whole bitmap -> Run it through the clipboard re-sizer -> Paste it again -> And flatten it as you suggest even tho I would prefer 32bit support for the clipboard re-sizer instead. =P

Re: Neighbour re-size at low resolution
Thanks for looking into it

kriss wrote:I have created bitmaps resizer (to 512x512 resolution) and it is in my WorlDO tool... smile.gif
I wanted to fix that what posted Urnemanden and I think I will do that...

Feel free to do as you please Kriss but IMO, it would be better that you concentrate your effort on features that doesn't already exist, instead of duplicating a tool I'm still working on...

@urnemanden

24bits/32bits
I now understand better what you mean by 'running a not-so-squared selection through your tool' (looking at your scrennshots). Sorry, but it's not easy to follow exactly someone else mind...
I'll see, maybe I could add automatic conversion of tranparent pixels (in 32bits) to black pixels (in pure 24bits).
But I'll probably have trouble managing the case of colored semi-transparent pixels (imagine for example that you use a curvilinear smoothed selection...).

Re: Neighbour re-size at low resolution
It's almost confirmed that it's a bug from the integrated resizing function I use (ie. in the programming language). Unfortunately, it means that I can't do anything about it, except hope that it will be fixed in the next version of the language. I don't feel like trying to import this function from other libraries or with windows API.

Keyboard shortcut
Done. I have added [Alt+C] to perform resizing of the clipboard.

Re: 24bits/32bits
Sounds like a good start, but actually I am not sure that's the biggest deal, since all pixels inside the re-sized selection is semi-transparent. If they were left semi-transperant, I could just in the end, duplicating the layer a couple of times, till the pixels are totally opaque and ready for saving.

Oh, and nice choice of keyboard shortcut.

Re: Neighbour re-size at low resolution
I have been suggested a workaround for this issue. I'll try to implement it in the next RvTR version.

Re: 24bits/32bits
Ok, I have spent a lot of time with this issue.
In fact, it's quite complicated.
My point of view is that resizing algorithm (like bicubic) were not really designed to work with 32bits image...

32bits image have 4 layers. One with Red, one with Blue, Green, and one with Alpha (transparency). I think resizing is currently done on each layer separately.
When you delete a part of an image, the Alpha layer area is set to full tranparency, but there is still a color information in other layers (generally set to White color).
Imagine we have a red figure with a transparent hole in it.
When resizing this figure, it will create on the edges a smooth transition on the alpha layer (from opaque to transparent), and a smooth transition the color layers (from red to white). Thus the white that were previously invisible (in the deleted zone where alpha layer was previously set to transparent) now become visible in the small transition zone where it mixes with red (on the edges).

Now, maybe you could try in your image editor and don't see that smoothing issue on the edges. I can't find any info on this, but I'm now almost sure some image editor have a special trick for this. When a pixel is fully transparent, and only in that case, its color is simply not mixed with bordering pixels...
But as soon as the pixel is not fully transparent anymore, then the edge colors get smoothed/mixed again.


Well, I hope it's intelligible...

Now, about the Urne's issue:
If you replace transparent zone with black opaque color like I said above, then a 'special advanced feature' of RvTR will prevent colors on the edges to be mixed with the black color.
In fact, I had already thought about this issue when designing RvTR, so it is already implemented. You could try, I think it will be ok.
If like you said, it's too complicated for you to remplace Tranparent by Black pixels, then I could consider implementing it automatically in a future version. But in each case, the resulting image will have only black pixels (when you paste it back in your editor), transparency being converted to black, it can't/won't be restored.

Feel free to do as you please Kriss  but IMO, it would be better that you concentrate your effort on features that doesn't already exist, instead of duplicating a tool I'm still working on...

Okay, Jigebren...

Suggestion: bitmap Drag n' drop
Could do some stuff easier when you need to re-size gfx'es, where there are different sized bitmaps in the folder too.

Sorry Urne, I'm currently focusing on WolfR4. But I'll keep you informed when I have time to look at this this tool anew...

I have found that this tool is very useful when re-sizing down as it leaves very sharp results compared to my own image editor of choice and they look better on the track screen in-game. So I just thought I would drop by with a few bug reports - I know you and huki is quite busy with 1.2 though so I don't expect you to fix them anytime soon.

Left and right edge blends
This is the only issue I have when re-sizing down from Clipboard. Take a look at the two pictures below. The artifact is visible on 256x256.
512x512
256x256
This issue also exist when re-sizing up.

Rainbow colors in the upper right corner
Some textures seem to be getting a mark in the upper right corner of different colors. A squary piece of noise. The two examples below demonstrates this.
original
re-sized

FYI: this only happens when scaling up. I can conclude from testing that is doesn't seem to matter matter what dimensions the rectangle has. Even a square 128x128 texture seem to be haunted by these rainbow colors, heh.

That's all from here.

Thanks for the report Urne.
Well, as you said, I don't have much have time to check that... Anyway, I'm afraid it would be above my ability:
Those issues probably come from the library used in PureBasic, and there's very few I could do about it. PureBasic support and development are currently very slow, so I wouldn't expect it to be fixed even after an appropriate bug report.

I could try to use an external image processing library through a .dll but it would probably be way more complex than using the internal functions. Not sure it's worth the pain.

But I'm surprised you can't get the same sharpness when sizing down in an image editor BTW. The smoothing is probably a simple bilinear or bicubic stuff, which is very likely available in any descent image editor...

Paint.NET which is my preferred image editor delivers less sharp and more anti-aliased results - looks great when viewed at 100%, but when stretched up like it is in the track preview in Frontend it's all a blurry mess.

Anyway you are absolutely right. I tested Gimp and it seems to deliver the same sharp result. I suppose I will save your tool for the re-sizing up only, then. Fortunately I seem to be able to avoid artifacts by creating an RGB(0,0,0) outline around the object I re-size.