General strategy for implementing new graphics - Revision history

FooBar: add nav template

2011-08-28T21:02:24Z

add nav template

← Older revision		Revision as of 21:02, 28 August 2011
Line 1:		Line 1:
			{{NFOTutorial}}

	==General strategy==		==General strategy==
	# First sprite is special, defining the total number of entries in the .grf file.		# First sprite is special, defining the total number of entries in the .grf file.

Orudge: Add TOC

2011-07-30T17:20:35Z

Add TOC

← Older revision		Revision as of 17:20, 30 July 2011
Line 1:		Line 1:
			==General strategy==
	# First sprite is special, defining the total number of entries in the .grf file.		# First sprite is special, defining the total number of entries in the .grf file.
	# Start with one or more [[grfspecs:Action7\|action 7]] entries that decide whether or not to load these graphics, for example based on the current climate.		# Start with one or more [[grfspecs:Action7\|action 7]] entries that decide whether or not to load these graphics, for example based on the current climate.

Orudge: moved GeneralNfoStrategy to General strategy for implementing new graphics: Spaces are good

2011-07-30T17:20:11Z

moved GeneralNfoStrategy to General strategy for implementing new graphics: Spaces are good

← Older revision	Revision as of 17:20, 30 July 2011
(No difference)

Orudge: Reformat and update

2011-07-30T17:19:59Z

Reformat and update

← Older revision		Revision as of 17:19, 30 July 2011
Line 1:		Line 1:

	'''''General strategy for writing NFO files'''''

	=General strategy for implementing new graphics=
	# First sprite is special, defining the total number of entries in the .grf file.		# First sprite is special, defining the total number of entries in the .grf file.
	# Start with one or more [[Action7\|action 7]] entries that decide whether or not to load these graphics, for example based on the current climate.		# Start with one or more [[grfspecs:Action7\|action 7]] entries that decide whether or not to load these graphics, for example based on the current climate.
	# After the action 7 entries, define your GRF ID with [[Action8\|action 8]].		# After the action 7 entries, define your GRF ID with [[grfspecs:Action8\|action 8]].
	# Then define one or several [[Action0\|action 0]] entries, that (possibly among other things) set the vehicle sprite IDs to FD (trains) or FF (all other vehicle types). Only vehicles with these sprite IDs will be using the new sprites.		# Then define one or several [[grfspecs:Action0\|action 0]] entries, that (possibly among other things) set the vehicle sprite IDs to FD (trains) or FF (all other vehicle types). Only vehicles with these sprite IDs will be using the new sprites.
	# Start a block of new graphics with an [[Action1\|action 1]] (sprite block) entry, followed by the actual sprite data. Ideally, you put the graphics of all vehicles together in this one sprite block, taking note of what sets of sprites have what number (as determined by their position in the block).		# Start a block of new graphics with an [[grfspecs:Action1\|action 1]] (sprite block) entry, followed by the actual sprite data. Ideally, you put the graphics of all vehicles together in this one sprite block, taking note of what sets of sprites have what number (as determined by their position in the block).
	# After action 1, give [[Action2\|action 2]] (cargo ID) entries for each different combination of vehicle and cargo type. The cargo IDs should start at zero and be numbered consecutively.		# After action 1, give [[grfspecs:Action2\|action 2]] (cargo ID) entries for each different combination of vehicle and cargo type. The cargo IDs should start at zero and be numbered consecutively.
	# After all action 2 entries, use [[Action3\|action 3]] (veh ID to cargo ID maps) to specify what cargo IDs are to be shown for which vehicle and which cargo types.		# After all action 2 entries, use [[grfspecs:Action3\|action 3]] (veh ID to cargo ID maps) to specify what cargo IDs are to be shown for which vehicle and which cargo types.
	* small remark by George

	~~For~~ My LVs I use a bit different sprite orders. First I define groups of sprite blocks ~~ ~~of graphics. Then I combine them with action 3. And then I specify action 0 and 4 for the object, that uses that graphics.		Small remark by George: for My LVs I use a bit different sprite orders. First I define groups of sprite blocks of graphics. Then I combine them with action 3. And then I specify action 0 and 4 for the object, that uses that graphics.

	==Dealing with the sprite numbers and pseudo-sprite blocks==		==Dealing with the sprite numbers and pseudo-sprite blocks==

	It can be quite a chore to make sure that the sprite numbers increase by one, and that you have the correct length for the pseudo-sprite blocks. Currently, GRFCodec has only limited parsing capabilities, so you need to make sure that they are indeed correct. As of GRFCodec version 0.9.4, you can specify a sprite number of ~~"~~-1~~"~~, which turns off the number checking for that sprite. The following sprites still need correct numbers (unless they also have ~~"~~-1~~"~~ as the number), and the sprite length still needs to be specified.		It can be quite a chore to make sure that the sprite numbers increase by one, and that you have the correct length for the pseudo-sprite blocks. Currently, GRFCodec has only limited parsing capabilities, so you need to make sure that they are indeed correct. As of GRFCodec version 0.9.4, you can specify a sprite number of "-1", which turns off the number checking for that sprite. The following sprites still need correct numbers (unless they also have "-1" as the number), and the sprite length still needs to be specified.

	===renum.pl===		===renum.pl===

	One help in this task is a Perl script called renum.pl, which is included in the TTDPatch source archive. If you haven't heard of Perl before, it's a powerful programming language that you can get for free. For example, you can install it with the Cygwin packages ([http://www.cygwin.com\|www.cygwin.com]), or from [http://activestate.com\|activestate.com] or [http://perl.com\|perl.com].		One help in this task is a Perl script called renum.pl, which is included in the TTDPatch source archive. If you haven't heard of Perl before, it's a powerful programming language that you can get for free. For example, you can install it with the Cygwin packages ([http://www.cygwin.com/ www.cygwin.com]), or from [http://www.activestate.com/ activestate.com] or [http://www.perl.com/ perl.com].

	If you have written a .nfo file, but it doesn't have the right numbers for the sprites or the lengths, run the renum.pl script like this:		If you have written a .nfo file, but it doesn't have the right numbers for the sprites or the lengths, run the renum.pl script like this:

	-+perl renum.pl ~~<~~ your.nfo ~~>~~ yournew.nfo+-		<tt>perl renum.pl < your.nfo > yournew.nfo</tt>

	It will take the your.nfo (substitute your actual filename), and write yournew.nfo with correct sprite numbers and pseudo-sprite lengths.		It will take the your.nfo (substitute your actual filename), and write yournew.nfo with correct sprite numbers and pseudo-sprite lengths.
Line 32:		Line 27:
	===NFORenum===		===NFORenum===

	Another program that can be used is [http://www.tt-forums.net/viewtopic.php?t=11711\|NFORenum]. This program does understand strings, and is run like this:		Another program that can be used is [http://www.tt-forums.net/viewtopic.php?t=11711 NFORenum]. This program does understand strings, and is run like this:

	-+renum your.nfo+-		<tt>renum your.nfo</tt>

	You may also drag and drop your nfo file onto the NFORenum executable.		You may also drag and drop your nfo file onto the NFORenum executable.
Line 41:		Line 36:

	As with renum.pl, the format of the nfo needs to be correct for this to work properly.		As with renum.pl, the format of the nfo needs to be correct for this to work properly.
			[[Category:Tutorials]][[Category:GRF Tutorial]]

Orudge: 3 revisions

2011-06-12T19:08:50Z

3 revisions

← Older revision	Revision as of 19:08, 12 June 2011
(No difference)

George at 08:00, 5 December 2005

2005-12-05T08:00:41Z

← Older revision		Revision as of 08:00, 5 December 2005
Line 10:		Line 10:
	# After action 1, give [[Action2\|action 2]] (cargo ID) entries for each different combination of vehicle and cargo type. The cargo IDs should start at zero and be numbered consecutively.		# After action 1, give [[Action2\|action 2]] (cargo ID) entries for each different combination of vehicle and cargo type. The cargo IDs should start at zero and be numbered consecutively.
	# After all action 2 entries, use [[Action3\|action 3]] (veh ID to cargo ID maps) to specify what cargo IDs are to be shown for which vehicle and which cargo types.		# After all action 2 entries, use [[Action3\|action 3]] (veh ID to cargo ID maps) to specify what cargo IDs are to be shown for which vehicle and which cargo types.
			* small remark by George

			For My LVs I use a bit different sprite orders. First I define groups of sprite blocks  of graphics. Then I combine them with action 3. And then I specify action 0 and 4 for the object, that uses that graphics.

	==Dealing with the sprite numbers and pseudo-sprite blocks==		==Dealing with the sprite numbers and pseudo-sprite blocks==

dmccoy at 03:32, 17 November 2005

2005-11-17T03:32:04Z

New page

'''''General strategy for writing NFO files'''''

=General strategy for implementing new graphics=
# First sprite is special, defining the total number of entries in the .grf file.
# Start with one or more [[Action7|action 7]] entries that decide whether or not to load these graphics, for example based on the current climate.
# After the action 7 entries, define your GRF ID with [[Action8|action 8]].
# Then define one or several [[Action0|action 0]] entries, that (possibly among other things) set the vehicle sprite IDs to FD (trains) or FF (all other vehicle types). Only vehicles with these sprite IDs will be using the new sprites.
# Start a block of new graphics with an [[Action1|action 1]] (sprite block) entry, followed by the actual sprite data. Ideally, you put the graphics of all vehicles together in this one sprite block, taking note of what sets of sprites have what number (as determined by their position in the block).
# After action 1, give [[Action2|action 2]] (cargo ID) entries for each different combination of vehicle and cargo type. The cargo IDs should start at zero and be numbered consecutively.
# After all action 2 entries, use [[Action3|action 3]] (veh ID to cargo ID maps) to specify what cargo IDs are to be shown for which vehicle and which cargo types.

==Dealing with the sprite numbers and pseudo-sprite blocks==

It can be quite a chore to make sure that the sprite numbers increase by one, and that you have the correct length for the pseudo-sprite blocks. Currently, GRFCodec has only limited parsing capabilities, so you need to make sure that they are indeed correct. As of GRFCodec version 0.9.4, you can specify a sprite number of "-1", which turns off the number checking for that sprite. The following sprites still need correct numbers (unless they also have "-1" as the number), and the sprite length still needs to be specified.

===renum.pl===

One help in this task is a Perl script called renum.pl, which is included in the TTDPatch source archive. If you haven't heard of Perl before, it's a powerful programming language that you can get for free. For example, you can install it with the Cygwin packages ([http://www.cygwin.com|www.cygwin.com]), or from [http://activestate.com|activestate.com] or [http://perl.com|perl.com].

If you have written a .nfo file, but it doesn't have the right numbers for the sprites or the lengths, run the renum.pl script like this:

-+perl renum.pl < your.nfo > yournew.nfo+-

It will take the your.nfo (substitute your actual filename), and write yournew.nfo with correct sprite numbers and pseudo-sprite lengths.

Note that the format of the nfo needs to be correct for this to work properly; in particular, the sprite numbers and pseudo-sprite lengths must already be *there* (as dummy numbers), but they need not be correct. Also, renum.pl does not understand strings. Decode with -t and do not use strings if you plan to use renum.pl.

===NFORenum===

Another program that can be used is [http://www.tt-forums.net/viewtopic.php?t=11711|NFORenum]. This program does understand strings, and is run like this:

-+renum your.nfo+-

You may also drag and drop your nfo file onto the NFORenum executable.

Again, substitute the actual filename; that file will be rewritten with a correct sprite 0, correct sprite numbers, and correct pseudo-sprite lengths. NFORenum also does some checking of your code, and will complain if it finds something it thinks is wrong.

As with renum.pl, the format of the nfo needs to be correct for this to work properly.