Difference between revisions of "General strategy for implementing new graphics"

From TTWiki
Jump to navigationJump to search
m (3 revisions)
(Reformat and update)
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]]

Revision as of 17:19, 30 July 2011

  1. First sprite is special, defining the total number of entries in the .grf file.
  2. Start with one or more action 7 entries that decide whether or not to load these graphics, for example based on the current climate.
  3. After the action 7 entries, define your GRF ID with action 8.
  4. Then define one or several 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.
  5. Start a block of new graphics with an 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).
  6. After action 1, give 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.
  7. After all action 2 entries, use 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

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 (www.cygwin.com), or from activestate.com or 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 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.