News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Tile cutting in Makeobj

Started by jamespetts, January 31, 2011, 10:28:05 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

A conceptually simple request but one that I suspect may take quite a bit of work (having not looked into the graphics code, I can't comment on how much), as the title suggests, there would be great benefit to pakset maintainers, and, indirectly, players if the cumbersome and difficult process of cutting tiles could be integrated automatically in Makeobj rather than have to be handled through external applications. The necessity to cut tiles adds a high barrier to entry for those seeking to make building graphics of more than one tile square, and can be most offputting for aspiring graphics contributors, even with helpful utilities such as TileCutter.

As noted above, I appreciate probably not a simple request to implement, but its great benefit makes it worth at least some consideration; there is, in any event, no harm in asking :-)
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

This cannot be done easily; especially with fore and background graphics, a designer really needs to know what he is doing. And I imagine the comment on people who get their ships chopped ...

VS

Of all the object types, only houses could be automated. But you can't guesstimate the pixel-precise offsets required since the ground tiles need not be filled completely. Still, cutting might integrate at that level, where you'd have all numbers prepared beforehand.

Of course, the coordinate system syntax used now is inadequate for that... hm...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

Designers really need to know what they're doing to use TileCutter, though, don't they?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

wlindley

Such a change could ease the graphic process tremendously, as there would be no need for intermediate .png files made by intermediate programs.  Also surely makeobj can understand transparent layers to eliminate the main color frustration.  Support.

Ashley

Quote from: jamespetts on January 31, 2011, 11:50:32 PM
Designers really need to know what they're doing to use TileCutter, though, don't they?

Sometimes it's a good idea for people to know what they are doing. There is only so much cluelessness that you can work around.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

jamespetts

Quote from: Timothy on February 03, 2011, 07:48:14 PM
Sometimes it's a good idea for people to know what they are doing. There is only so much cluelessness that you can work around.

That may be true, but if people equally need to know what they are doing if tilecutting is and if it isn't included in Makeobj, that isn't a reason not to include it in Makeobj - indeed, quite the converse if there are other benefits (such as productivity) of doing so.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ashley

The original version of TileCutter was a command line tool. The GUI version came about because the job of tile cutting is almost impossible without it. I mean, you could produce a command-line tool to do it (and indeed, TileCutter can operate from the command line to an extent) but it wouldn't simplify matters at all.

If you're looking for automation TileCutter has a mode where it'll take in a project file (which you make using the GUI) and then operate from the command line to output an updated version of the graphic. This can be integrated into pakset maintenance to automate output if need be. Indeed, if you want a one-step scripting step from source images to pak file TileCutter can already do this.

I don't believe you could integrate the functionality of TileCutter into Makeobj without also implementing a GUI, and then you'd just be reimplementing TileCutter.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

VS

#8
Timothy, you have that horrible habit of making my posts redundant just as they are about to be submitted ;D Posting anyway, cut to 5% original text.

One would still need a preview program to help with setting up the cutting, so why not cut there and keep the status quo.




edit: One particularly nasty/elegant way to deal with this would be using the multi-tile graphic as a single sprite at different pak size :P IIRC redraws are bounded to changed areas, so there wouldn't be any overhead from having a large sprite. I can imagine other issues though...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

Timothy,

ahh, perhaps you misunderstand my request: the suggestion is not to do exactly the same as tile cutter, but make tile cutting in that way unnecessary. In other words, producing graphics for multi-tile buildings should, as far as the user is concerned, be exactly the same as producing graphics for single-tile buildings.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

VS

James - I'm not sure if I interpret what you write your way or my way, but I'm beginning to see something... Still, any possible implementation would greatly differ under the hood, so there might be as well an entirely new new tool. No sense trying to graft that onto current system (which is strongly interlocked with dat syntax).

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Ashley

Ok, but how do you propose achieving that? Either we keep the current system of buildings being made up of multiple tiles (in which case you need a program like TileCutter) or you move to a single-sprite approach like VS suggests. That should be quite possible to do I suppose (though I am thinking there may be a lot of issues with alignment and so-on when you start to talk about non-square buildings especially).

I'm not saying it's a bad idea - if it could be done in a completely automatic (magic) way then it'd make the process a lot easier. I am just wondering exactly how it would be done. The original version of TileCutter attempted to use a degree of magic to work out the shape of a building from the dimensions it presented rather than presenting the interface to let you just specify how it should be. I think that this approach could work if you put enough time into considering all the possible cases.

Does anyone have any more detailed ideas about how this could be achieved?
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

jamespetts

I don't know exactly how such a thing would be achieved, as I've never looked into the graphics code. I realise that it would be quite a bit of work to implement, but it would confer such a large advantage (to remove the need for manual tile-cutting) that even quite a large amount of work would be worthwhile. I don't know enough to know whether the suggestion is practical or not, and if it's not so be it, but the benefit of it being carried into effect are sufficient warrant suggesting it in the hope that there will be a way of implementing it that will work satisfactorily.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

wlindley

#13
Seems pretty simple to me.  An building in a .dat file would use an extra parameter on Dims, and continue specifying the x,y offsets using the current coordinates.  It's just that the size of the source rectangle pulled from the .png, instead of being the pak's tile size, would be "tilesize + ( EWsize * tilesize / 2)" wide by "tilesize + ((NSsize + Heightsize) * tilesize / 2)" tall.  (Or do I have EW/NS reversed?) The .dat would look like:
Dims=EWsize, NSsize, Heightsize, nOrientations
BackImage[Orientation][AnimationOrder][Snow]=image.x.y
FrontImage[Orientation][AnimationOrder][Snow]=image.x.y


makeobj would then chop the source rectangle into squares of the pak's tilesize.  Note this means that in pak64, for example, a 2x2 building in the .png would be 64+32 pixels wide, the 32 pixels to the right being ignored.

I would also like makeobj to merge the optional FrontImage atop the BackImage.  For shops that differ only in the awning color, there would just be a single building plus overlays for the various awnings (awning as Front, building as Back for shops that face the viewer, vice versa for those facing away).  The same awnings could be used for several generations of different buildings, without having to redraw everything. Or the same tanks could be used atop several different versions of a factory.

For example, a 2x2 building with regular height and four orientations would simply have:

Dims=2,2,1,4
BackImage[0][0][0]=images/supermarket.0.0
BackImage[1][0][0]=images/supermarket.0.2
BackImage[2][0][0]=images/supermarket.2.0
BackImage[3][0][0]=images/supermarket.2.2


One .png file, easily edited, and no intermediate files to worry about.

Furthermore, makeobj could scan the output, and eliminate duplicate output tiles, re-mapping them to reduce .pak size -- it might already do that.

Dwachs

As I understand the original request, I think it can implemented.

QuoteFurthermore, makeobj could scan the output, and eliminate duplicate output tiles, re-mapping them to reduce .pak size -- it might already do that.

Afaik there is no such logic implemented. Makeobj could even warn about duplicate pixels in back and front image as at least one of them is wrong or redundant.
Parsley, sage, rosemary, and maggikraut.

Fabio

Quote from: VS on February 03, 2011, 09:57:59 PM
One particularly nasty/elegant way to deal with this would be using the multi-tile graphic as a single sprite at different pak size :P IIRC redraws are bounded to changed areas, so there wouldn't be any overhead from having a large sprite. I can imagine other issues though...

This sounds VERY interesting to me.
It would be worth to try drafting pros and cons.

prissi

I do not think, incorporating automatic tiling is a goo idea (as well as only single tiles) because


  • using single tile has several problems. Most severe is a wrong working of the clipping.

  • many graphics have fore- and background images. No way to guess which part is which automatically (see the pak64 oil rigg)

  • tile origin must be still at a certain position, which is dependent on the pixel size. Or you have to define the original interactively, but then better use tile cutter from the beginning.

  • impossible to guess intended tile sizes with transparent grounds

  • some single tile objects are intentionally larger than a tile

  • handling of forground animations etc. cannot be easily automated

  • Only extension buildings, attractions, and factories are tiled. This is small number of the total objects in the game.

I would agree with Timothy: Replicating tilecutter is not very useful, apart from portability issues. Moreover, you usually also need to use shades for converting objects. So you use anyway some tools.

Concerning duplicated images: Simutrans will only load images that are unique. They are discarded at runtime, since the same image can be part of different paks, where automatic removal cannot work. Moreover disc space is much more available than main memory. (Usually simutrans discards less than 100 images.)

Ashley

Quote from: prissi on February 04, 2011, 10:30:01 AM
I would agree with Timothy: Replicating tilecutter is not very useful, apart from portability issues. Moreover, you usually also need to use shades for converting objects. So you use anyway some tools.

A word on portability, TileCutter being written in Python can be run on most platforms.

Deduplication of images is a feature which could be built into TileCutter if there is enough demand for it (I had planned on doing this when I added support for animation).

If there are any features which would improve TileCutter and make it work more usefully then please do mention them, I'm happy to take a look.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.