Transport Tycoon Forums

Hi,

I've been working the last few days on an application that will allow us to make sprite generation for openttd a little easier.

The basic idea is to drag and drop finished blender renders onto the panels and use a mouse to move them to the correct x/y_offs position. Currently I have the ability to remove/add/delete tEXt chunks from the pngs and the ability to load vehicle tiles onto the sprite panels and move them about with the mouse. Other things that need to be done are trimming of pngs, tar generation etc etc.

I'm also planing for it to generate the all the nessesary sprites for each zoom level.

great! where did you write it in?

C# i guess? check out my posting in the .blend thread. the source code contains trimming functions

Awesum, anything to get rid of the tedious alignment work will be really helpful.

Yes its all C#, trimming functions you say? ill have a look at that!

also my python script can handle mutiple zoom levels, maybe we can adjust our tools to make a easy sprite conversion procedure?

Yep, i wasnt aware of the python script u made!( its such a massive thread) But anything that can be done to stream line the process is good news for us, I totally agree with you.

great! have you thought about a solution to handle mask images?

Its possible to overlay lots images ontop of one another in the spritepanel control they can be moved individually, some logic would need to be added to save the offsets for the masks, ill need to investigate how masking coordinates differ from a normal sprites, would it be possible to attach them to a sprite so they share the x_offs?

mr_worf wrote:Its possible to overlay lots images ontop of one another in the spritepanel control they can be moved individually, some logic would need to be added to save the offsets for the masks, ill need to investigate how masking coordinates differ from a normal sprites, would it be possible to attach them to a sprite so they share the x_offs?

as I understand it the masks do not need an offset. Their size is equal to the corresponding image. But their image format is somewhat special. png8, I believe. Something C# does not support out-of-the-box

Very nice work Mr_Worf,

Every tool that can help to make the 32bpp graphics creation process easier is very welcome !

I was also thinking about the app generating some sort of manifest which would group each sprite set and contain details on what sprite direction they represent etc . similar to a project file in VS or Jbuilder it could be loaded and saved and compiled into a tar or continue to be tweaked.

I better get cracking..

I tried to get C# save to 8 bit png, but the results are disappointing to say the least. by default c# will not save anything other than 32 bpp. With other libraries I get diffrent results variing from gray images to errors

I'm down to writing png files myself or forcing ottd to accept gif files

CS-SDL might have the required functions for PNG loading.

Wow, that is looking very promising indeed! Even just the ability to align and pngcodec sprites by point-and-click would be really helpful. Any chance of you releasing a "feature-incomplete-pre-alpha" of some sort for us to play around with ?

Ok got the mask gif files working now, dirty hack but working

[EDIT] I updated the files to include support for rename.txt and correct company colors. The screenshots are not updated.

I'll explain the procedure in two posts using the attached file demo.blend.

When you open demo.blend you will notice 6 cubes, three on each side. Look at the python window and change
the line RootPath= "c:\\ottdrender\\" to a directory more appropriate. Hit Alt-p. The script will render 4 frames * 3 zoomlevels * 4 angles = 48 images. The filename will be something like <name of the blenderfile>_<frame nr>_<layer nr>_z<zoom level>.png

After a while the specified directory will contain a lot of image looking like screenshot-2.

Think that are enough images? No, we still need the mask images. Back to blender, edit the material for the middle cubes (the blue ones) to be shadeless. In the python script, change the lines
to
Hit alt-p again, and 48 more images should be rendered in the directory. See screenshot-3. That's it for this step.

Next step, converting the images to something usefull in ottd. You will need .net installed for this to work!

Create in the output dir a file rename.txt. This file should contain 4 lines of text for each image.
for example
This file will enable the utility to rename the files correctly and assign the offsets by calling pngcodec.

Download blender_convert.rar and extract the files to a directory. Go to command prompt (start -> run -> cmd). cd to the specified irectory. Execute the following command:
for example blender_convert c:\ottdrenders\demo\

When the program is done, you will have even some more images! 48 to be excact, empty images will not be converted. See screenshot-5. All images are put in the output directory.

That's it. Copy the files to the correct location and you are done

@brupje:

as said in the other thread, a big THANKS for your Blender Python script. However, I've run into problems using your blender_convert tool. Screenshot of error attached. A quick internet search indicates that it may be a problem caused by a recent (Nov 07) Microsoft security update for .net, which changes the way certain unicode characters have to be adressed (then again, maybe not. I can hardly code... )
It also causes an exception, code: 0x0434f4d.

Can you look into this problem? I'm really intrigued by the description of the tool you gave, would make sprite generation much faster!

Teemes wrote:@brupje:

as said in the other thread, a big THANKS for your Blender Python script. However, I've run into problems using your blender_convert tool. Screenshot of error attached. A quick internet search indicates that it may be a problem caused by a recent (Nov 07) Microsoft security update for .net, which changes the way certain unicode characters have to be adressed (then again, maybe not. I can hardly code... )
It also causes an exception, code: 0x0434f4d.

Can you look into this problem? I'm really intrigued by the description of the tool you gave, would make sprite generation much faster!

I was not able to reproduce the problem, but I probably did find the code causing it. You can try the attached executable/source to see if it works for you.

Can somebody explain to me how the offsets in the PNG files are used? They don't seem to fit?

See:
http://wiki.ttdpatch.net/tiki-index.php ... ht=palette

Second part of page.