[Discussion] Object Length

Hack · Post by **Hack** » 15 Nov 2004 09:53

I'm having a tough time trying to get around the clipping issue when using near-scale rollingstock. By "near-scale": something shortened along its y-axis so as to better match Lomo's existing stock, yet close enough in proportions so as not to look stupid - 80% seems to be an acceptable compromise for passenger and freight cars, with 10% to 20% reduction for locomotives. The following example should help you better visualize what I'm referring to:

100% Y-Axis Scale: (exact scale - 23x118 pixels)

80% Y-Axis Scale: (ideal, but produces clipping issues - 23x92 pixels)

70% Y-Axis Scale: (looks odd, but no clipping issues when reduced - 23x80 pixels)

I know of 3 parameters that control the size of the sprites used in Lomo:

field_24[0]:
- length
- field_1

sprites[0]:
- bogeypos

At my best guess, length and field_1 control the object's front and rear spacing, and that it might have to do with half of the total length (in pixels) of the actual sprite. The number contained in bogeypos is completely a mystery, as it doesn't appear to have anything to do with pixels or feet, nor is it centered on the object unless length and field_1 are in set properly.

FWIW (and as far as I can tell), a properly set object should have one coupler touching the border of the display window when purchased; have its bogeys in the correct position; and have 3-pixels of spacing between the end coupler and the text description.

I've played with different values in all three variables with interesting effects for each. However, I haven't been able to nail down exactly how one variable affects another. Sometimes I manage to get close, but never exact, and it's my opinion that getting the values correct will help overcome the clipping in the game. Remember, I'm just guessing here.

Comments?

scrat · Post by **scrat** » 15 Nov 2004 11:35

I would like this answered as well, cause it driving me insane.

I usually set 'lenth' and 'field_1' to 30 (regardless of the actual length) and then use the bogeypos to regulate distance between units. I'm aware this is a lazy man's solution. This method works especially well with multiple sprite units.

EDIT: Before the next NL Vehicle release, I'm going to overhaul all the graphics (again) to see if I can tackle this problem. I'll keep you informed of my progress in this thread.

Post by **PikkaBird** » 15 Nov 2004 16:20

Basically, as far as I can tell, length and field_1 are how far in from the ends the bogies are shifted. bogeypos is the overall length of the vehicle. The coupler points are positioned "bogeypos" apart, and centred halfway between the bogies. Making a vehicle with off-centred bogies and which couples accurately at both ends is just about impossible! The measurement numbers seem to be arbitrary.

70%, for British stock at least, seems to be the correct length.

The clipping is not fixable; the default graphics have the same clipping problems. The closer to the end of the cars the bogies are, the less it will clip, which is probably why your longer vehicles have more problems.

scrat · Post by **scrat** » 15 Nov 2004 21:16

Thanks, Pikkabird. This explains a lot and is definitely something I can work with.

Hack · Post by **Hack** » 17 Nov 2004 00:41

One of my main concerns about getting this right the first time, is that updates to the models don't appear to have an effect on those already placed on the map. I haven't checked, but perhaps lifting them from the rails and replacing might fix where an upgrade has been done. What I did see though is that the set needs to be sold and re-bought - basically resetting the variables used in the set to the new values in an update.

scrat · Post by **scrat** » 18 Nov 2004 22:41

Lift and place again makes the graphics conform to the setting as defined in the (new) .dat.

Question to PikkaBird: When discussing the field "bogeypos" in the sprite array, you state that "The coupler points are positioned 'bogeypos' apart". Is this measured in pixels?

The reason I ask is that when I take the length in pixels of the sprite as displayed in the purchase window, the values seem to be way off and I have to multiply by (approx) 1.41 to get it reasonably right.

Post by **PikkaBird** » 19 Nov 2004 01:07

scrat wrote:Is this measured in pixels?

No. Like I said, the measurement numbers seem to be arbitrary.

NashLee · Post by **NashLee** » 19 Nov 2004 09:45

Hack wrote:One of my main concerns about getting this right the first time, is that updates to the models don't appear to have an effect on those already placed on the map. I haven't checked, but perhaps lifting them from the rails and replacing might fix where an upgrade has been done. What I did see though is that the set needs to be sold and re-bought - basically resetting the variables used in the set to the new values in an update.

Can you tell me how to get the train like your icon??thanks.

squishycube · Post by **squishycube** » 19 Nov 2004 10:32

Don't throw this topic off-topic! This sort of thing should be PM'ed.

scrat · Post by **scrat** » 19 Nov 2004 11:19

PikkaBird wrote:No. Like I said, the measurement numbers seem to be arbitrary.

I know, mate. Pixels * 1.41 seems to work just fine at the moment.

Post by **PikkaBird** » 19 Nov 2004 12:47

scrat wrote:I know, mate.

Then why did you ask the question?

scrat · Post by **scrat** » 19 Nov 2004 15:02

PikkaBird wrote:
scrat wrote:I know, mate.
Then why did you ask the question?

Heh. I was kinda hoping you had a theory about it.

Oneirocrat · Post by **Oneirocrat** » 19 Nov 2004 18:04

Disclaimer: I have no idea what I'm talking about...

1.41 could arise as the square root of two - the length of the diagonal of a unit square.

Could it be due to a correction factor within the game, for the difference between displaying the sprite side-on in the purchase window, and diagonally in the isometric view?

scrat · Post by **scrat** » 19 Nov 2004 18:20

Well spotted.

Deriving from this, we can state that 'bogeypos' = Round(Squareroot (((horizontal length in pixels)^2) *2))

That works for me.

I've taken a good look at how PikkaBird set his values for the Turbotrain and have copied the method, since it seems to work so well.

For example, the ICM0 'Koploper' EMU-3:

Code: Select all

	<structure name="field_24[0]" size="6">
		<variable name="length" size="1">0</variable>
		<unknown name="field_2" size="1">255</unknown>
		<unknown name="field_3" size="1">255</unknown>
		<variable name="spriteind" size="1">0</variable>
		<unknown name="field_5" size="1">178</unknown>
	</structure>
	<structure name="field_24[1]" size="6">
		<variable name="length" size="1">0</variable>
		<unknown name="field_2" size="1">255</unknown>
		<unknown name="field_3" size="1">255</unknown>
		<variable name="spriteind" size="1">1</variable>
	</structure>
	<structure name="field_24[2]" size="6">
		<variable name="length" size="1">0</variable>
		<unknown name="field_2" size="1">255</unknown>
		<unknown name="field_3" size="1">255</unknown>
		<variable name="spriteind" size="1">128</variable>
		<unknown name="field_5" size="1">178</unknown>
	</structure>
	<structure name="sprites[0]" size="30">
		<variable name="numdir" size="1">64</variable>
		<unknown name="field_1" size="1">32</unknown>
		<unknown name="field_2" size="1">1</unknown>
		<variable name="vehtype" size="1">1</variable>
		<variable name="numunits" size="1">1</variable>
		<unknown name="field_5" size="1">1</unknown>
		<variable name="bogeypos" size="1">134</variable>
		<bitmask name="flags" size="1">
			<bit name="hassprites">1</bit>
			<bit name="bit_3">1</bit>
			<bit name="reversed">0</bit>
		</bitmask>
		<variable name="spritenum" size="1">0</variable>
	</structure>
	<structure name="sprites[1]" size="30">
		<variable name="numdir" size="1">64</variable>
		<unknown name="field_1" size="1">32</unknown>
		<unknown name="field_2" size="1">1</unknown>
		<variable name="vehtype" size="1">1</variable>
		<variable name="numunits" size="1">1</variable>
		<unknown name="field_5" size="1">1</unknown>
		<variable name="bogeypos" size="1">130</variable>
		<bitmask name="flags" size="1">
			<bit name="hassprites">1</bit>
			<bit name="bit_1">1</bit>
			<bit name="bit_3">1</bit>
			<bit name="reversed">0</bit>
		</bitmask>
		<variable name="spritenum" size="1">0</variable>
	</structure>

It corners beautifully. (I'm almost ready to write a VB proggie to create a vehicle from scratch).

Hack · Post by **Hack** » 19 Nov 2004 18:32

Great - now I gotta' do math again - yuck.

Post by **PikkaBird** » 19 Nov 2004 23:58

Cool.

scrat · Post by **scrat** » 20 Nov 2004 11:54

I'm making good progress on the vehicle generator. I have written a module that scans a sprite folder (.png files) and automatically generates the appropriate xml, taking sprite dimensions into consideration. (I had already written a macro that could handle Oppie's sprite size to save me some headaches, but not everybody uses the same size). I'll make this available ASAP, cause it's a nifty time saver.

EDIT: Alpha version 0.01. No error checking. Just select a folder containing your sprites, and will generate the sprites xml. (I will only support MODders).

http://www.buzzing-bumblebee.fiberworld ... /lm_vc.rar

As an example, what it can do:

Code: Select all

	<sprite id="134" xofs="-120" yofs="-120">
		<bitname="hasdata">1</bit>
		<bitname="chunked">1</bit>
		<bitname="copy">0</bit>
		<pngfile>C:\\JKE\\My Projects\\lm_vc\\NLDE1\\134.png</pngfile>
	</sprite>
	<sprite id="135" xofs="-120" yofs="-120">
		<bitname="hasdata">1</bit>
		<bitname="chunked">1</bit>
		<bitname="copy">0</bit>
		<pngfile>C:\\JKE\\My Projects\\lm_vc\\NLDE1\\135.png</pngfile>
	</sprite>
	<sprite id="136" xofs="-9" yofs="-6">
		<bitname="hasdata">1</bit>
		<bitname="chunked">1</bit>
		<bitname="copy">0</bit>
		<pngfile>C:\\JKE\\My Projects\\lm_vc\\NLDE1\\136.png</pngfile>
	</sprite>

Transport Tycoon Forums

[Discussion] Object Length

[Discussion] Object Length

Can you tell me how to get the train like your icon

Who is online