NML/NFO to GRF Related problem......

[Yoshi]

I think those platforms should be below street level?

[michael blunck]

[...]

Code: Select all

    7 * 62    00 04 02 01 00 08 "UDBL" 09 02 F4 03 00 00 00 00 00 10 05 03 2D 84 00 00 00 00 00 10 10 7A 2E 84 00 00 80 F3 03 00 00 00 00 00
 05 10 03 2F 84 00 00 00 00 00 10 10 7A 30 84 00 00 80

Could you spot the problem ? I suspect its due to the boundingboxes and wrong sprite placing, but I don't know how and where to change it...

Your tile layout is faulty:

Code: Select all

   7 * 62    00 04 02 01 00 08 "UDBL" 09 02
 
F4 03 00 00 
00 00 00  10 05 03  2D 84 
00 00 00  00 00 10  10 7A 2E 84 00 00 80 // <--

F3 03 00 00 
00 00 00  05 10 03  2F 84 
00 00 00  00 00 10  10 7A 30 84 00 00 80 // <--

regards
Michael

[YNM]

I think those platforms should be below street level?

Well, it should give the same appearence like FooBar Underground Metro track. (And I develop these regarding that)

@ michael blunk : thank you, I'll try to change that and see the result.

[YNM]

Sorry for doublepost appearence

@ michael blunk : hmm, your code in quote are just the same with my posted code ; still same thing.

But probably you doesn't understand what I mean and what I want....

In my attached image, you can see the purple boxes covering tiles : that is the real location of the tile of the station. I get a problem likely with sprite offset. As I'm new in NFO, I dont know yet how to change them, as NFO likely gets hard to understand by people without experience like me. (by means of using all-hex number )

Could any of you explain how to change the offset ? I get to sprite aligner to change offset and it all looks OK, but thats temporary.


EDIT : heres the fixed by sprite aligner one :

[Quast65]

You indeed need to change the offset in your code, spritealigner says X= -31 and Y= -91.
Your code for that sprite says:

Code: Select all

5 C:\Users\THINKCENTRE\Pictures\Projects\Metro_Station\metroRET_blue.pcx 169 268 01 122 64 -31 -83

Change -83 to -91 and it should be ok.

[YNM]

Oh, so thats how ? Thanks ! (well, I got all sprite have wrong offset I know how to do those in NML, but I have no idea about that in NFO )

[michael blunck]

@ michael blunk : hmm, your code in quote are just the same with my posted code ; still same thing.

That IS your code. Only re-arragend for better visibility.

But probably you doesn't understand what I mean and what I want....

In my attached image, you can see the purple boxes covering tiles : that is the real location of the tile of the station. I get a problem likely with sprite offset.

First thing to do would be to fix the tile layout, simply because both the coordinates given there, AND the sprite offsets given for the real sprites will count for the display on-screen. (Edit: sprite offsets like -91 are clearly wrong!)

As I'm new in NFO, I dont know yet how to change them, as NFO likely gets hard to understand by people without experience like me. (by means of using all-hex number )

Take a look on http://www.ttdpatch.de/grfspecs/m4nfoMa ... tions.html .
Even if you don´t use m4nfo for station coding, this should give you a better general understanding how to set up your nfo code.

regards
Michael

[Quast65]

(Edit: sprite offsets like -91 are clearly wrong!)

Well I dare to disagree

For as far as I understand the coding, the offsets depend on the sizes of the blue boxes you drawn your graphics in, so with the boxes that he uses the -91 is very logical. Correct me if I'm wrong but as far as I know it works like this:

relativeposition.png (21.2 KiB) Viewed 2091 times

[michael blunck]

(Edit: sprite offsets like -91 are clearly wrong!)

Well I dare to disagree

For as far as I understand the coding, the offsets depend on the sizes of the blue boxes you drawn your graphics in, so with the boxes that he uses the -91 is very logical.

<takes a look> Hehe, yeah. That amount of "excessive blue" is utter nonsense.

Anyway, he should first get his tile layout right, and then fix the sprite offsets, rather than trying to "arrange" the offsets in the first place. Which would only encourage the sprite sorter to complain.

regards
Michael

[jmodule]

Could any of you explain how to change the offset ? I get to sprite aligner to change offset and it all looks OK, but thats temporary.

I struggled with this for a while. Your offsets are fine, but if you don't have the correct compression setting, the extra blue space is discarded and that messes up the calculation for the offset once the sprite is drawn in game.

So, assuming you want to use Quast65's templates, go back to your realsprite definitions and change the compression (column 5) from 01 to 49 -- bit field flags for "blue is transparent," "use tile compression," and "do not crop." Then change the offsets back to what Quast65 recommended.

For example:

Code: Select all

    3 C:\Users\THINKCENTRE\Pictures\Projects\Metro_Station\metroRET_blue.pcx 9 268 49 122 64 -31 -91
    4 C:\Users\THINKCENTRE\Pictures\Projects\Metro_Station\metroRET_blue.pcx 89 268 49 122 64 -31 -91
    5 C:\Users\THINKCENTRE\Pictures\Projects\Metro_Station\metroRET_blue.pcx 169 268 49 122 64 -31 -91
    6 C:\Users\THINKCENTRE\Pictures\Projects\Metro_Station\metroRET_blue.pcx 249 268 49 122 64 -31 -91

[YNM]

Anyway, he should first get his tile layout right, and then fix the sprite offsets, rather than trying to "arrange" the offsets in the first place. Which would only encourage the sprite sorter to complain.

regards
Michael

Dare to show me how to fix the tile layout ? The m4nfo likely don't uses the all hex number, rather it likely uses something halfway between NML and NFO... And so I don't get how to do it


EDIT : @ jmodule : thanks

@ All : I'm no longer on my computer, so you may tell me something which I may understand.

[Quast65]

And as a little addition to yoursnotmine's request to Michael (because I'm also curious to understand a bit more of that particular piece of code), please bear in mind that the idea of the code I suggested in my "station tile code for dummies" thread (that is the piece of code that yoursnotmine used as his base code) is that one uses standard templates as a base for graphics (hence the use of excessive blue, it leaves room for big buildings) with also the corresponding big bounding boxes.

The idea is that one doesn't have to make changes in the code when adding more stationtiles, except for the ID's and the position of the graphics in the graphicsfile.

@Jmodule, Interesting suggestion. So does setting the compression to 49 make it easier for the game to ignore the transparant blue and therefor easier for it to place it in the game and thus making the game a bit faster?

[Michi_cc]

So does setting the compression to 49 make it easier for the game to ignore the transparant blue and therefor easier for it to place it in the game and thus making the game a bit faster?

No, it makes it slower by disallowing cropping (but unless you pass the -c option to grfcodec, there is no cropping anyway). Cropping produces smaller GRF files, but with it the offsets shown in-game will not match the ones in the NFO file.

-- Michael Lutz

[Quast65]

I see, so what is the real advantage of changing the compression to 49 then?

[michael blunck]

I see, so what is the real advantage of changing the compression to 49 then?

Well, "49" means "sprite should not be cropped" AND "sprite is in chunked data format (aka "tile compression")", i.e., preserve the "excessive blue", but compress the sprite, i.e., mostly that "excessive blue".

Although, in general, there´s no use for "excessive blue", but only for two reasons:

- to explicitly manipulate the bounding box,
- to be able to position child sprites w/r to the parent sprites.

Dare to show me how to fix the tile layout ?

Again:

Code: Select all

   7 * 62    00 04 02 01 00 08 "UDBL" 09 02
 
F4 03 00 00 
00 00 00  10 05 03  2D 84 
00 00 00  00 00 10  10 7A 2E 84 00 00 80 // <--

F3 03 00 00 
00 00 00  05 10 03  2F 84 
00 00 00  00 00 10  10 7A 30 84 00 00 80 // <--

I had marked the corrupted lines.

Code: Select all

<groundsprite>
{<xoffset> <yoffset> <zoffset>  <xextent> <yextent> <zextent>  <buildingsprite>} 80

The m4nfo likely don't uses the all hex number, rather it likely uses something halfway between NML and NFO... And so I don't get how to do it

Well, it´s all there - just read. Take a look at the examples.

regards
Michael

[YNM]

Let me think of it :

Code: Select all

F4 03 00 00 -> is this is groundsprite  ?
00 00 00 10 05 03 2D 84 -> xoffset yoffset zoffset  ?
00 00 00 00 00 10 10 7A 2E 84 00 00 80 -> xextent yextent zextent buildingsprites  ?

I would feel so helped if you explain over this.


O/T : Now 00:15 local time - had to sleep....

[Quast65]

Code: Select all

F4 03 00 00 00 00 00 10 05 03 2D 84 00 00 00 00 00 10 10 7A 2E 84 00 00 80 F3 03 00 00 00 00 00 05 10 03 2F 84 00 00 00 00 00 10 10 7A 30 84 00 00 80

As far as I know:

Code: Select all

F4 03 00 00 = groundsprite East-West direction
00 00 00 = xoffset yoffset zoffset Backgroundsprite E-W
10 05 03 = xextent yextent zextent Backgroundsprite E-W
2D 84 00 00 = buildingsprite
00 00 00 = xoffset yoffset zoffset Foregroundsprite E-W
10 10 7A = xextent yextent zextent Foregroundsprite E-W
2E 84 00 00 = buildingsprite
80 = End of spritelist for this tile
F3 03 00 00 = groundsprite North-South direction
00 00 00 = xoffset yoffset zoffset Backgroundsprite N-S
05 10 03 = xextent yextent zextent Backgroundsprite N-S
2F 84 00 00 = buildingsprite
00 00 00 = xoffset yoffset zoffset Foregroundsprite N-S
10 10 7A = xextent yextent zextent Foregroundsprite N-S
30 84 00 00 = buildingsprite
80 = End of spritelist for this tile 

There are two things that might be wrong:
- first of all the values of the xextent yextent zextent are not the precise measurements of the graphics that have been drawn. But that is done to make a "universal" piece of code, to make it easier to code. If this causes major problems with the spritesorter, please let me know.

- The number of the buildingsprite. To be honest I don't know exactly what this does... If anyone has more info about this, please share that with us.

Apart from these two things I can't see anything fundamentally wrong...

[jmodule]

These are the comments I used to figure out the station layout:

Code: Select all

    F4 03 00 00 // ground sprite for X tile
    00 00 00 // x,y,z offset of bounding box
    10 05 03 // x,y,z extent for bounding box
    2D 84 00 00 // north X sprite (842D = first in action 1 list)
    00 00 00 // x,y,z offset
    10 10 08// x,y,z extent
    2E 84 00 00 // south X sprite (842E = second in list)
    80 // end of building sprite list

The difference from what you show is the bounding box extents. For the south sprite I changed the z-offset to 8 pixels instead of 122 (0x7A) pixels.

Take a look at the attached files. I modified your NFO example earlier in the thread so that it ignores the extra space in the sprite template. I drew a pink box around the outside of the coordinates I used in the real sprite line in the NFO. If you do that, you no longer have to worry if grfcodec is going to crop the sprite and so the in-game offsets will match what you need in the NFO. It also means your offsets change considerable (at least the y-offset does). Instead of -91 I used -3 (and -9).

Hope that helps.

[michael blunck]

[...] The number of the buildingsprite. To be honest I don't know exactly what this does... If anyone has more info about this, please share that with us.

The first sprite in the associated sprite block is (always) numbered 0x042D (this once was an original TTD sprite), i.e. LSB -> "2D 04". In the example, it has bit15 set as well -> 0x842D, which means it would be displayed in company colour, if drawn using the cc colour range.

regards
Michael

[YNM]

Wow, thank you all for describing those numbers !
Can't use my computer now... I'll try it when I able to use it...