I wish a dat entry pakset_size=xxx to override makeobj command line pakxxx in order to be able to have different pak size in the same folder (e.g. GUI)
In time this could also mean that double clicking makeobj compiles with default settings the active folder.
Well paksize only tells you about image size. The actual pak size is irrelevant. In this light, it is rather a parameter to the images, and should be probably called rather "imagesize=" It still has the same problem as images and dat are not physically connected, but might be better than the pak commandline obtion. But Fabie, please to proper extension thread and do not clutter here.
And you can have as many different paksizes in one folder also now, since you can specify what dat to work on. This has no connection whatsoever.
Well VS's python script assumes the same image size for all files in the same folder, but clearly this is not makeobj's fault.
From a maintainer's point of view this would be a very useful extension.
Also double clicking makeobj exe would be possible as it might be considered as
makeobj ./ ./
and therefore work smoothly...
I am not denying this, just was asking for getting its own thread.
If dats could have arbitrary imagesize= then there would be no need for tilecutter, which would eliminate the need to keep "composed" and "split" png files separate. Makeobj would split 2x2 or even 5x5 buildings into tiles as appropriate. Even for large buildings, you would need only to specify a single (row, column) based on the imagesize in the png, instead of the profusion of values needed now. This would greatly simplify creating and maintaining paks, wouldn't it?
Please, read what has been suggested. Imagesize is the size of individual images, which is set by the pakxxx parameter of makeobj. I.e. 64 pixel for pak64
Automatic cutting buildings automatically is almost impossbile when there is height, or foreground involved, or an l or H shaped structe is wanted. Also only buildings need cutting. Furthermore it is almost impossible to find an image which arbitary imagesizes in a random image. You would have to specify x,y pair of the outline. This is why tilecutter uses interactively defines buildings areas.
Anyway, please keep it one request at a time.
When I was adding the DEBUG param to makeobj I realised that the PAK-size param only tells makeobj what the cell size are for all images read. In the end this is irrelevant for the packed image itself.
I came across the same idea to insert a new pak size in the dat file. It could be done something like this:
cell_size = 64
image[..] = ...
...
cell_size = 128
image[..] = ...
...
The new cell_size (pak size) would be valid from the cell_size statement until the next cell_size.
But pak size is constant across all dat/pak files in a pak set. So any overrides can only work for GUI-related images/objects.
Airplanes use a 176 size in pak128, and ships as well IIRC. Power lines and rivers use a size of 160. All this beside GUI.
Considering how every piece of logic I've seen in Simutrans operates on the pak set, I would have thought that any images bigger than that would certainly cause some kind drawing error. My OpenGL rendering thing also assumes nothing is bigger than a tile, although it has other issues that likely means a full re-thinking is in order.
Ways have sometimes small glitches fixed on scrolling the map, vehicles are flawless. Obviously one needs careful offsetting, but it's pretty straightforward.
cell_size should only apply to a single object and otherwise the default from the commandline is taken. (The latter is anyway file wide.) For a cell parameter for the whole dat file I would rather propose global_cell_size.
(Btw cell_size is a much better name for it. Thanks!)
I was suggesting that a cell_size parameter can be inserted many times into the .dat file and that new cell_size will be the new size. I find this very useful because usually graphics are grouped around the same image atlas, hence using the same cell_size.
Before any cell_size has been encountered, the PAK param is used. This will ensure backward compatibility and still give the flexibility to switch between different sizes in the same dat file.
It will introduce state into the dat file, which I'm sceptical of.
I agree cell_size should be per object it shouldn't be a state remembered between objects (this could cause bugs).
Absolutely. It should be per object, before image reference. If missing or put after the first image the command line default is used, if command line parameter is missing it defaults to 64.
Hello Fabio
Have you take a view on the png and dat from pak128.britain there are pngfiles in it they are bigger than 176 pixel.
@Fabio: In connection with this issue, I think there is a bug in pak128.newlandscape (r1310). In pak128.bat,
cd ..\ships-cargo
..\..\makeobj.exe pak128 ../../simutrans/pak128/ ./ [...]
cd ..\ships-ferries
..\..\makeobj.exe pak128 ../../simutrans/pak128/ ./ [...]
should say:
cd ..\ships-cargo
..\..\makeobj.exe pak250 ../../simutrans/pak128/ ./ [...]
cd ..\ships-ferries
..\..\makeobj.exe pak250 ../../simutrans/pak128/ ./ [...]
It prevents the ships to be built altogether.
Quote from: greenling on November 10, 2013, 02:45:16 PM
Hello Fabio
Have you take a view on the png and dat from pak128.britain there are pngfiles in it they are bigger than 176 pixel.
Indeed, they have a tile size of 250px!
Quote from: isidoro on November 11, 2013, 12:37:52 AM
@Fabio: In connection with this issue, I think there is a bug in pak128.newlandscape (r1310). In pak128.bat,
cd ..\ships-cargo
..\..\makeobj.exe pak128 ../../simutrans/pak128/ ./ [...]
cd ..\ships-ferries
..\..\makeobj.exe pak128 ../../simutrans/pak128/ ./ [...]
should say:
cd ..\ships-cargo
..\..\makeobj.exe pak250 ../../simutrans/pak128/ ./ [...]
cd ..\ships-ferries
..\..\makeobj.exe pak250 ../../simutrans/pak128/ ./ [...]
It prevents the ships to be built altogether.
It should be correct in trunk (pak128/) r1310.
pak128.newlandscape folder will soon be deleted, after some more tests of the merged trunk.
Thank you for spotting!
If you are using the latest makeobj, I recommend to run it with "makeobj verbose pak..." which prints out unneccessary or mispellt lines.
Hello Fabio
Quote from: Fabio on November 11, 2013, 06:23:12 PM
It should be correct in trunk (pak128/) r1310.
pak128.newlandscape folder will soon be deleted, after some more tests of the merged trunk.
Thank you for spotting!
I have view on pak128 commit 1310 and i get scratch attack on my head i'm afraid the errors there are.
Paramter cell_size now incoporated on a per object basis