OPENTTD Sprite Editor / Generator

[Teemes]

Thanks a lot, brupje, I will try that asap!

[Teemes]

hey brupje,

now it works like a charm! I don't know what you changed, but it definitely did it for me. Actually, I also had some blank lines in my rename.txt, which the tool doesn't like, apparently. So after I removed these, it worked fine. However, that was not the cause for the crash I experienced with the other, older, version. That one still crashes on me with the fixed rename.txt. ...

[brupje]

hey brupje,

now it works like a charm! I don't know what you changed, but it definitely did it for me. Actually, I also had some blank lines in my rename.txt, which the tool doesn't like, apparently. So after I removed these, it worked fine. However, that was not the cause for the crash I experienced with the other, older, version. That one still crashes on me with the fixed rename.txt. ...

Well I could explain, but important thing is that it works for you have fun!

[brupje]

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

Second part of page.

I am still trying to figure it out. I attached a screenshot with a red and a green rectangle. Both with offs_x=0 and offs_y=0. But they are not on the same position :S

[GeekToo]

Brupje,

It is probably caused by a difference in height of the sprites.

A quick sketch: for ground sprites the reference point for tiles is the top centre ( point A)
So, when the sprite is drawn on the screen, it must have an offset: the drawing routine does take the top left of the sprite and starts drawing the sprite. When the starting point would be A, the tile would be drawn too much to the right(half a tile). So an x_offset (negative) of half a tile is given to the drawing routine, to position the tile correctly. When you have a normal zoom sprite of 64 x 31 pixels, the offset in x is -31, and in y is 0. ( For higher zooms, multiply the numbers by 2 or 4). The x_offset is indicated by the blue_arrows( in screen coordinates).

Now, when you render a sprite that is heigher than the normal height of the sprite, because something with height(red) is drawn on it, the sprites becomes higher (black indicates the size of the sprite). The ground area does not align anymore with the normal sprites anymore. (right sprite is a normal sprite, middle sprite is a heigher sprite).
To correct this, an negative y_offset must be given (higher y value is more towards the bottom of the screen).

So when your new sprite is 64 x 36 pixels, give it a y_offset of -5.

In short: render your sprites with nominal width and give it an x_offset of -(width)/2 + 1
give it a y_offset of (nominal height-sprite height)

Nominal width and height for ground sprites are 64 x 31.

There are some exceptions for this rule, but that should give you a good starting point ( for ground sprites at least, for vehicles the reference points are different)

[brupje]

The rectangles are the same in height and width. Also they are not ground sprites, but walls of the verhicle station. Somehow the reference point of each wall seems to be different, as the rectangles are the same in height, width and offset. But I fail to see how to determine the reference point.

[GeekToo]

It's the center point of the bounding box. Try pressing Ctrl-B in the game to show the bounding boxes

[brupje]

cool, and where gets openttd the bounding box information from? the grf?

[GeekToo]

They are hardcoded in the game, though some dimensions (like the length of vehicles), can be influenced by means of newgrfs

[brupje]

hmm that means that any application other then ottd is unable to show how the sprites will be rendered ingame, will they?

[Teemes]

hey brupje,
today I rendered all zoom levels for my AEC (MPS, whatever...) bus using your python script, which worked fine. But blender_convert gave me problems again. I thought, maybe the tool would calculate the offsets for the z1 and z2 zooms automatically, as the values are roughly 1/2 and 1/4 anyway, so I made a rename.txt with the following, expecting 8(angles)*3(zoom levels)*2(render/mask)=48 files:

Code: Select all

bus_1_6
3287
-80
-50
etc. for all remaining 7 angles

That gave me 16 files in the output folder, all of the z2 level with the way too large offset for the z0 level.
So I calculated the offsets manually:

Code: Select all

bus_1_6
3287
-80
-50
bus_1_6
3287
-40
-25
bus_1_6
3287
-20
-13
etc.

Same result. Adding the matching suffix to the first line like so:

Code: Select all

bus_1_6_z0
3287
-80
-50
bus_1_6_z1
3287
-40
-25
bus_1_6_z2
3287
-20
-13
etc.

lead to blank values for the x_offs/y_offs that pngcodec added to the files, and they are not properly renamed ("fixed_bus_1_6_z0.png"as if they were not in the rename.txt)...
What am I doing wrong?! What is the correct way to edit the rename.txt to process all zoom levels? Can you please post an example, maybe the rename.txt you used for the screenshots on page one of this thread?

[brupje]

it seems that zoomlevels were a missing feature

the new version will accept offsets for the zoomlevels in the rename.txt and rename them properly.
It will accept offsets in two ways:
- just one value, -20 for example. It will use -10 for z1, and -5 for z2.
- Comma seperated values, -20,-10,-5 for example. This must be 3 values!

Hope this helps you out.

[Teemes]

Missing feature, eh? That would explain that...
Thanks a lot for the new version, brupje, works flawlessly!

[djpety94]

When release the sprite editor ? This is a big help for me!

[brupje]

Probably never as it's near impossible to create one as the offsets seem to be hardcoded in the game I'm afraid.

[mr_worf]

After a massive hiatus, I have returned with something useful for the community. I have made a working graphical openttd PNGCodec configurer for vehicles.

you can download it here: http://www.ibackus.com/OpenTTDSpriteConfig.zip
**please use backed up stuff as it will modify the original png!

It works but it is by no means complete so i consider it a beta, but you can get an idea of whats happening by downloading the vehicle attached to this reply and load it into to spriteconfigurer move it around the template (the dark area is roughly where the outer edge of the sprite should be, its not perfect yet). Save it and then use pngcodec to see that the attributes have changed. its all done using the mouse. You can use the clear button to clear the panel so you can work on another angle of the vehicle after saving.

The code is built for .net 2.0 so you will need that installed, i wouldnt be suprised if it worked with mono too.

*** Thank you to ben_robbins for the template which I hashed together from rail tiles you have released previously. ***

notes:
*This uses the extra zoom bin from geektoo.
*The Template is rough at the moment, ill probably need some template boundingbox stuff to make it more accurate.

Please let me know what you think, apologies for taking so long to reply, my life goes into overdrive often.

[Teemes]

A big thanks to you, mr. worf! Sorry I missed your recent post when it came up, but your tool could prove really useful, as the amount of photoshopping and starting/quitting OTTD that was previously required was a real pain. Haven't tried your tool under "realistic" conditions (i.e. aligning a train sprite) yet. I hope the dark ring in the template you provided will be sufficient not only to place a vehicle correctly on the tracks, but also in relation to the wagons in front and behind it.[1] I'll test your tool more thoroughly when I'll have to code an engine next.

[1]If so, add the following:

[habell]

Many thanks

It helps a lot.
I use it now to do the general coding. It think the detail will have to be done in game.

Features for later versions (if you plan one )
- Possibility to zoom in on the sprites
- Also for all other kind of sprites (maybe by using a dropdown list for the possibilities: road, train, ship, etc)
- When updateing the x and y offset manualy, update the picture