Newgrf Bridges suggestions

Discussions about the technical aspects of graphics development, including NewGRF tools and utilities.

Moderator: Graphics Moderators

User avatar
thgergo
Route Supervisor
Route Supervisor
Posts: 391
Joined: 29 Mar 2005 12:44
Location: Hungary

Newgrf Bridges suggestions

Post by thgergo »

The current newgrf bridges system is not very well functioning:
1. Pillar height problems, floating pillars

Bridge pillars need to stand on an edge of a tile, so I`ve found how OTTD generates this "requiement" info. So it tests the spritenumber if is it odd or even number, according to a piece of a code found in OTTD svn. I think TTDpatch uses this method too, since all looks like working in TTDpatch too. This method even not realible when a newgrf come with an odd number of reserved sprites before loading a bridge-newgrf.

Code: Select all

/* "side" specifies the side the pillars stand on.
841	     * The length of the pillars is then set to the height of the bridge over the corners of this edge.
842	     *
843	     *                axis==AXIS_X  axis==AXIS_Y
844	     *   side==false      SW            NW
845	     *   side==true       NE            SE
846	     *
847	     * I have no clue, why this was done this way.
848	     */
849	    bool side = HasBit(image, 0);
My proposal is to let this "side" information configurable with newgrf actions somehow. Action0Bridges have some unused bits for this now. When one defines a bridgepiece(a bridgetile), he defines the exact spritenumbers for "Back&Floor, Front, Pillars".

Code: Select all

The four entries are
Back&Floor, Front, Pillars, 0

Front and Pillars can be 0, meaning no sprite to draw. The fourth entry is always ignored.
So my question/suggestion is, can the 4th entry used for determinate this properity for each bridgepiece? So lets say if the this 4th entry is set to 0, then use the original method, with 1 use the northern(Up) side height, with 2 use the southern(Down) for that.

Also frosch mentioned me a halftile sprite cutter for pillars could solve all of these problems. So the first half of the sprite uses the northern side, the other use the southern.



2.More bridges, more than modifying the defaults.
Also there is a note about how this can be made in the future in the wiki:
Since TTDPatch 2.6 alpha 0 rUnknown it's possible to use more than the default TTD bridges. All ids starting with 0x0D are id allocated and property 0x00 has to be set, otherwise the bridge will be ignored. As these bridges have no old type, all properties have to be set.
Unfortunetly only TTDpatch rUnknown, or OpenTTD rUnknown have this feature yet.

3. Custom sprites for the bridge purchase dialog.
Maybe only a simple albility to assign a custom spritenumber for it?

4.Do not touch the rail bridges while modifying the roads, or vice versa.
Sprite layout (0D) can be set for one bridgepiece, but when its set, I need to define it for rail/road/mono/maglev. Its not possible to modify only one then preserve the rest! My quick suggestion: bridgepieces table have a number 0-5 middle parts 6th is for the ramps. At the noment there is no high ids used, so let those "high" ids correspond wich railtype/riad I want to modify. So the byte could be divided to two parts, the first 4 bits is storing the 0-1-2-3-4-5-6 tableid, and the second 4 bits is an "modify-this-railtype" mask. So this should be backward compatible with older bridgesets.

5.
proper action 1-2-3 implementation for bridges like stations, indrustries has. Maybe someday...

Any thoughts about this?
Image
Image
User avatar
supermop
Tycoon
Tycoon
Posts: 1057
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: Newgrf Bridges suggestions

Post by supermop »

I would generally like a richer variety of properties for bridges, not sure how well that alligns with your goal. I think we need to (eventually) be able to add an arbitrary number of bridge types via Newgrf, rather than simply replace existing slots. A personal wish for my projects would be to specify minimum and maximum heights for certain types.

Anyway, I like your ideas that. I can't do anything to help realize them, but I'll give you my vote of confidence.

Best,
Eddi
Tycoon
Tycoon
Posts: 7529
Joined: 17 Jan 2007 00:14

Re: Newgrf Bridges suggestions

Post by Eddi »

thgergo wrote:2.More bridges, more than modifying the defaults.
Also there is a note about how this can be made in the future in the wiki:
Since TTDPatch 2.6 alpha 0 rUnknown it's possible to use more than the default TTD bridges. All ids starting with 0x0D are id allocated and property 0x00 has to be set, otherwise the bridge will be ignored. As these bridges have no old type, all properties have to be set.
Unfortunetly only TTDpatch rUnknown, or OpenTTD rUnknown have this feature yet.
i have no idea what that even means... afair OpenTTD had more "default" bridges than TTDPatch, but the limit is like 16 or so.
4.Do not touch the rail bridges while modifying the roads, or vice versa.
Sprite layout (0D) can be set for one bridgepiece, but when its set, I need to define it for rail/road/mono/maglev. Its not possible to modify only one then preserve the rest! My quick suggestion: bridgepieces table have a number 0-5 middle parts 6th is for the ramps. At the noment there is no high ids used, so let those "high" ids correspond wich railtype/riad I want to modify. So the byte could be divided to two parts, the first 4 bits is storing the 0-1-2-3-4-5-6 tableid, and the second 4 bits is an "modify-this-railtype" mask. So this should be backward compatible with older bridgesets.
your idea is flawed, because it would need to account for railtypes, which now are newgrf-definable [with a railtype label, i.e. a dword]. and the whole idea of railtype was to make them more independent from bridges.
You might not exactly be interested in Ferion, but if you are, have fun :)
User avatar
OzTrans
Tycoon
Tycoon
Posts: 1512
Joined: 04 Mar 2005 01:07

Re: Newgrf Bridges suggestions

Post by OzTrans »

...
Last edited by OzTrans on 04 Feb 2012 00:30, edited 2 times in total.
maquinista
Tycoon
Tycoon
Posts: 1814
Joined: 10 Jul 2006 00:43
Location: Spain

Re: Newgrf Bridges suggestions

Post by maquinista »

Some time ago, I suggested narrow bridges:
https://www.tt-forums.net/viewtopic.php?p=779087#p779087

They doesn't allow two vehicles at the same time, but They are cheaper. Useful when You have a few vehicles and You can't spend a lot of money. :D
Image
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Newgrf Bridges suggestions

Post by eis_os »

It's nothing new that pillars are broken:
http://www.tt-forums.net/viewtopic.php?p=723207#p723207

So, newbridges TTDPatch handle id 11 and 12 as well... since two years...

The missing point is a (sane) drawing routine. Since two years TTDPatch has already id allocation code internal, but no drawing code, so it could never be tested.
http://svn.ttdpatch.net/trac/changeset/1986
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
User avatar
supermop
Tycoon
Tycoon
Posts: 1057
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: Newgrf Bridges suggestions

Post by supermop »

Maquinista, did you ever get that to work, or was it just a image mock up to make a suggestion? If such behavior is possible, I can think of a lot of interesting uses.

Best,
maquinista
Tycoon
Tycoon
Posts: 1814
Joined: 10 Jul 2006 00:43
Location: Spain

Re: Newgrf Bridges suggestions

Post by maquinista »

supermop wrote:Maquinista, did you ever get that to work, or was it just a image mock up to make a suggestion? If such behavior is possible, I can think of a lot of interesting uses.

Best,
Not, It's only a mock up made with GIMP.


Also, I'm trying to add a new bridge in TTDPatch:
http://wiki.ttdpatch.net/tiki-index.php ... on0Bridges
Since TTDPatch 2.6 alpha 0 rUnknown it's possible to use more than the default TTD bridges. All ids starting with 0x0D are id allocated and property 0x00 has to be set, otherwise the bridge will be ignored. As these bridges have no old type, all properties have to be set.
I have this code, but It doesn't work:

Code: Select all

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 7)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
  0 * 4	 12 00 00 00
  1 * 27	 08 07 "ÿÿÿÿCreated by GRDTOGRF" 00 00
  2 * 23	 00 06  08 01   0D // Covered wooden bridge
  00 00
  08 30
  09 02
  0A 79
  0B 20
  0C 51 00
  0E 00
  10 0D DC
... (Action A sprites)
 18 * 28	 04 06 80 01 0D DC "Covered wooden bridge" 00
It's a covered bridge released some years ago. I can't release it because I can't contact with their author, but I can try to redraw it myself from scratch, but first I want to try to create the NewGRF file with the old sprites.
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
User avatar
FooBar
Tycoon
Tycoon
Posts: 6559
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Newgrf Bridges suggestions

Post by FooBar »

Set a grf-id other than FF FF FF FF, preferrably according to the standard convention: http://wiki.ttdpatch.net/tiki-index.php?page=Action8 (sprite 1)

Furthermore you might want to consider using FF as language rather than 80: http://wiki.ttdpatch.net/tiki-index.php?page=Action4 (sprite 18)

NFO is not hard, but it isn't easy either :wink:
maquinista
Tycoon
Tycoon
Posts: 1814
Joined: 10 Jul 2006 00:43
Location: Spain

Re: Newgrf Bridges suggestions

Post by maquinista »

Thanks.

Now It loads, but It just replace the sprites of the wooden bridge, without adding a new bridge.
This GRF should replace the sprites of the wooden bridge and add a new bridge.

If I can load a new bridge, I will modify the action A sprites (that replaces the default wooden bridge sprites), because I want to keep the wooden bridge.
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
User avatar
FooBar
Tycoon
Tycoon
Posts: 6559
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Newgrf Bridges suggestions

Post by FooBar »

ActionA in principle replaces sprites and not adds them.

Also, to add a bridge, you need to code the spite layouts in Action0, feature 06, property 0D: http://wiki.ttdpatch.net/tiki-index.php ... on0Bridges. There is an example at the bottom of the page.

Furthermore, to add the sprites rather than replace current bridge sprites there is the rather hackish approach to replace some toyland sprites and hope noone replaces the same sprites in some other grf. Reference the toyland sprites in property 0D.
The proper way would be GRM, but it seems that that's unavailable for bridges (http://wiki.ttdpatch.net/tiki-index.php ... Management).
maquinista
Tycoon
Tycoon
Posts: 1814
Joined: 10 Jul 2006 00:43
Location: Spain

Re: Newgrf Bridges suggestions

Post by maquinista »

Yes, I know that the new sprites are loaded replacing toyland sprites.

I have modified the code. I have removed all previous sprites, now Its only a new bridge, but It does't work. :(
It should load a bridge named "Covered wooden bridge" with the sprites from tubular bridge:

Code: Select all

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 7)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
    0 * 4	 03 00 00 00

    1 * 27	 08 07 "AN" 27 32 "Created by GRDTOGRF" 00 00

    2 * 922	 00 06  09 01   0D // Covered wooden bridge
  00 00
  08 30
  09 02
  0A 79
  0B 20
  0C 51 00
  0E 00
  10 0D DC
  0D 00 07 //action 00 bridges, 01 property, 01 ID, ID, prop 0D, tableID 00, 07 tables
//table 00
0B 0A 00 00  01 0A 00 00  00 00 00 00  00 00 00 00 //rail X: Back&Floor, Front, Pillars, 0
0C 0A 00 00  02 0A 00 00  00 00 00 00  00 00 00 00 //rail Y: Back&Floor, Front, Pillars, 0
11 0A 00 00  01 0A 00 00  00 00 00 00  00 00 00 00 //Road X: Back&Floor, Front, Pillars, 0
12 0A 00 00  02 0A 00 00  00 00 00 00  00 00 00 00 //Road Y: Back&Floor, Front, Pillars, 0
17 0A 00 00  01 0A 00 00  00 00 00 00  00 00 00 00 //Mono X: Back&Floor, Front, Pillars, 0
18 0A 00 00  02 0A 00 00  00 00 00 00  00 00 00 00 //Mono Y: Back&Floor, Front, Pillars, 0
1D 0A 00 00  01 0A 00 00  00 00 00 00  00 00 00 00 //Mlev X: Back&Floor, Front, Pillars, 0
1E 0A 00 00  02 0A 00 00  00 00 00 00  00 00 00 00 //Mlev Y: Back&Floor, Front, Pillars, 0

//table 01
09 0A 00 00  FF 09 00 00  05 0A 00 00  00 00 00 00 //rail X: Back&Floor, Front, Pillars, 0
0E 0A 00 00  04 0A 00 00  06 0A 00 00  00 00 00 00 //rail Y: Back&Floor, Front, Pillars, 0
0F 0A 00 00  FF 09 00 00  05 0A 00 00  00 00 00 00 //Road X: Back&Floor, Front, Pillars, 0
14 0A 00 00  04 0A 00 00  06 0A 00 00  00 00 00 00 //Road Y: Back&Floor, Front, Pillars, 0
15 0A 00 00  FF 09 00 00  05 0A 00 00  00 00 00 00 //Mono X: Back&Floor, Front, Pillars, 0
1A 0A 00 00  04 0A 00 00  06 0A 00 00  00 00 00 00 //Mono Y: Back&Floor, Front, Pillars, 0
1B 0A 00 00  FF 09 00 00  05 0A 00 00  00 00 00 00 //Mlev X: Back&Floor, Front, Pillars, 0
20 0A 00 00  04 0A 00 00  06 0A 00 00  00 00 00 00 //Mlev Y: Back&Floor, Front, Pillars, 0

//table 02
0A 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //rail X: Back&Floor, Front, Pillars, 0
0D 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //rail Y: Back&Floor, Front, Pillars, 0
10 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Road X: Back&Floor, Front, Pillars, 0
13 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Road Y: Back&Floor, Front, Pillars, 0
16 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mono X: Back&Floor, Front, Pillars, 0
19 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mono Y: Back&Floor, Front, Pillars, 0
1C 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mlev X: Back&Floor, Front, Pillars, 0
1F 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mlev Y: Back&Floor, Front, Pillars, 0

//table 03
0A 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //rail X: Back&Floor, Front, Pillars, 0
0D 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //rail Y: Back&Floor, Front, Pillars, 0
10 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Road X: Back&Floor, Front, Pillars, 0
13 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Road Y: Back&Floor, Front, Pillars, 0
16 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mono X: Back&Floor, Front, Pillars, 0
19 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mono Y: Back&Floor, Front, Pillars, 0
1C 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mlev X: Back&Floor, Front, Pillars, 0
1F 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mlev Y: Back&Floor, Front, Pillars, 0

//table 04
0A 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //rail X: Back&Floor, Front, Pillars, 0
0D 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //rail Y: Back&Floor, Front, Pillars, 0
10 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Road X: Back&Floor, Front, Pillars, 0
13 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Road Y: Back&Floor, Front, Pillars, 0
16 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mono X: Back&Floor, Front, Pillars, 0
19 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mono Y: Back&Floor, Front, Pillars, 0
1C 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mlev X: Back&Floor, Front, Pillars, 0
1F 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mlev Y: Back&Floor, Front, Pillars, 0

//table 05
0A 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //rail X: Back&Floor, Front, Pillars, 0
0D 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //rail Y: Back&Floor, Front, Pillars, 0
10 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Road X: Back&Floor, Front, Pillars, 0
13 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Road Y: Back&Floor, Front, Pillars, 0
16 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mono X: Back&Floor, Front, Pillars, 0
19 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mono Y: Back&Floor, Front, Pillars, 0
1C 0A 00 00  00 0A 00 00  05 0A 00 00  00 00 00 00 //Mlev X: Back&Floor, Front, Pillars, 0
1F 0A 00 00  03 0A 00 00  06 0A 00 00  00 00 00 00 //Mlev Y: Back&Floor, Front, Pillars, 0

//table 06: northern end X, northern end Y, southern end X, southern end Y
86 09 00 00  88 09 00 00  85 09 00 00  87 09 00 00 //rail flat
8A 09 00 00  8C 09 00 00  89 09 00 00  8B 09 00 00 //rail ramp
8E 09 00 00  90 09 00 00  8D 09 00 00  8F 09 00 00 //road flat
92 09 00 00  94 09 00 00  91 09 00 00  93 09 00 00 //road ramp
E7 10 00 00  E9 10 00 00  E6 10 00 00  E8 10 00 00 //mono flat
EB 10 00 00  ED 10 00 00  EA 10 00 00  EC 10 00 00 //mono ramp
0F 11 00 00  11 11 00 00  0E 11 00 00  10 11 00 00 //mlev flat
13 11 00 00  15 11 00 00  12 11 00 00  14 11 00 00 //mlev rampend X, southern end Y
   3 * 28	 04 06 FF 01 0D DC "Covered wooden bridge" 00
Sorry if my english is too poor, I want learn it, but it isn't too easy.[/list][/size]
michael blunck
Tycoon
Tycoon
Posts: 5883
Joined: 27 Apr 2005 07:09
Contact:

Re: Newgrf Bridges suggestions

Post by michael blunck »

FooBar wrote: [...] to add the sprites rather than replace current bridge sprites there is the rather hackish approach to replace some toyland sprites and hope noone replaces the same sprites in some other grf. [...]
The proper way would be GRM, but it seems that that's unavailable for bridges (http://wiki.ttdpatch.net/tiki-index.php ... Management).
You´ll have to use feature 08 (general sprites) in GRM for this to work.

Using GRM for bridge sprites is strongly recommended to avoid clashes with other newgrfs using toyland sprites, e.g. for recolouring purposes.

E.g, NewStations usage of toyland sprite(s) collides with some bridge sets available. Usage of GRM-allocated sprites for stations is one of the trickiest and laboursome tasks in nfo coding, but for bridge sprites its quite easy and should be used in any case.

regards
Michael
Image
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Newgrf Bridges suggestions

Post by eis_os »

eis_os wrote:The missing point is a (sane) drawing routine. Since two years TTDPatch has already id allocation code internal, but no drawing code, so it could never be tested.
http://svn.ttdpatch.net/trac/changeset/1986
Without drawing code, a id allocated bridge won't work... (well you get the fallback type. if my code works correct)
User avatar
FooBar
Tycoon
Tycoon
Posts: 6559
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Newgrf Bridges suggestions

Post by FooBar »

maquinista wrote:I have modified the code. I have removed all previous sprites, now Its only a new bridge, but It does't work. :(
According to NFORenum, the text must be defined before you attempt to use it.

Furthermore, ID 0D cannot be used in OpenTTD. I'm not aware if it should work in TTDPatch.
I suggest replacing an existing bridge first (00 to 0C) and once that works you can try a 'new' ID. This rules out the possibility that it's the ID why it's not working.

Also, property 00 cannot be used in OpenTTD. Again unsure about TTDPatch. So try to leave that out initially as well.


And one final also: It seems that we are hijacking this here topic. I asked the moderator team for a split.
User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Re: Newgrf Bridges suggestions

Post by eis_os »

FooBar wrote:
maquinista wrote:I have modified the code. I have removed all previous sprites, now Its only a new bridge, but It does't work. :(
According to NFORenum, the text must be defined before you attempt to use it.

Furthermore, ID 0D cannot be used in OpenTTD. I'm not aware if it should work in TTDPatch.
I suggest replacing an existing bridge first (00 to 0C) and once that works you can try a 'new' ID. This rules out the possibility that it's the ID why it's not working.

Also, property 00 cannot be used in OpenTTD. Again unsure about TTDPatch. So try to leave that out initially as well.
Hmm, I am surprised that people constantly ignore me even if I have written the specs... You can only use 0D+ when TTDPatch gets a drawing routine via action2. The whole specs and TTDPatch code for newbridges is based on my work... OTTD waited for finishing the specs, that is why the specs say rUnknown, and specially "planed" feature... GRF Authors decided to not be constructive in the process defining a standard with pillar or bridge drawing code, I did hold coding on it for TTDPatch. Maybe this is more clear: ID allocation isn't in an usable state, don't use it
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image
User avatar
FooBar
Tycoon
Tycoon
Posts: 6559
Joined: 21 May 2007 11:47
Location: The Netherlands
Contact:

Re: Newgrf Bridges suggestions

Post by FooBar »

I'm not ignoring you, I'm just not looking into Patch source code as I don't understand that anyways.

rUnknown to me could mean anything from "the writer couldn't be bothered to look up the version number" to what you intended it to mean. "planned" should give a hint, but it appears that didn't get through to me.

But this time you made yourself more than clear. Thanks for your persistence :D


I also took the liberty to change the description "Since TTDPatch 2.6 alpha 0 rUnknown it's possible to use more than the default TTD bridges" a bit as, to me at least, that really sounds like if it exists.
uni657
Engineer
Engineer
Posts: 20
Joined: 30 Sep 2010 23:38

Re: Newgrf Bridges suggestions

Post by uni657 »

thgergo wrote:The current newgrf bridges system is not very well functioning:
1. Pillar height problems, floating pillars

Bridge pillars need to stand on an edge of a tile, so I`ve found how OTTD generates this "requiement" info. So it tests the spritenumber if is it odd or even number, according to a piece of a code found in OTTD svn. I think TTDpatch uses this method too, since all looks like working in TTDpatch too. This method even not realible when a newgrf come with an odd number of reserved sprites before loading a bridge-newgrf.

Code: Select all

/* "side" specifies the side the pillars stand on.
841        * The length of the pillars is then set to the height of the bridge over the corners of this edge.
842        *
843        *                axis==AXIS_X  axis==AXIS_Y
844        *   side==false      SW            NW
845        *   side==true       NE            SE
846        *
847        * I have no clue, why this was done this way.
848        */
849       bool side = HasBit(image, 0);
Hello, thgergo. You can take a look at my Bridge Pillars Fix patch here: http://www.tt-forums.net/viewtopic.php?f=33&t=50306 (only 1st and 5th stages of the patch will influence NewGRF bridges)
In this patch, test for the bit 0 of the image remains only for non-central parts of the suspension bridges. Do you have any ideas how to remove it completely or it isn't necessary?

Code: Select all

p = tileh_bits[HasBit(image, 0) * 2 + axis];
User avatar
thgergo
Route Supervisor
Route Supervisor
Posts: 391
Joined: 29 Mar 2005 12:44
Location: Hungary

Re: Newgrf Bridges suggestions

Post by thgergo »

At the noment I see the best solution for this, is frosch`s "halftile" cutting algorithm. I try to explain how this would work in the attached picture.
1: The Original (TTD?) way. As you can see the pillars are just an attachment to the front sprite. At this time, the bridges had to be 1 unit high. No fancy higher bridges. With this you would never meet a problem, like "how to place this type of pillar sprite to a sloped sprite?"
But after that, with the introduction of higher bridges in TTDpatch, this problem have arised. I dont know how this was, but I think thats why we got that ugly code in the OTTD too.

Code: Select all

bool side = HasBit(image, 0);
This works good with suspension bridges, or other large gapped bridges, if it gets the corrent even or odd spritenumber for each pillar tile.

2: In my set TBRS I have worked around this behavour. The pillars arent placed on a tile, instead they are placed on a corner. This done by simply the pillar sprites are simply overlapping to the other tile. This seems doesnt generate glitches at the noment.


3: Cut the pillar sprite into two sub-sprite, if the land under the bridge is sloped. Only the last height needs to be chopped.

With implementing this, it would be compatible with all current newgrf bridgesets. Also it could be used for correct the original base sets pillars.
Attachments
pilar chopping.png
pilar chopping.png (61.97 KiB) Viewed 4945 times
Image
Image
uni657
Engineer
Engineer
Posts: 20
Joined: 30 Sep 2010 23:38

Re: Newgrf Bridges suggestions

Post by uni657 »

Thanks for explanation, but it's already done in my patch (using halftiles).

Sadly, fixing pillars that are already fixed by TBRS breaks them (i.e. for bridges that replace TTD tubular bridges). Also TBRS suspension bridge pillars are looking strange, but only for Y axis bridges, probably this is due to infamous "HasBit(image, 0)" thing. By this I don't mean that TBRS bridges are wrong, just informing in former case, and trying to find cause in later case.
Last edited by uni657 on 14 Oct 2010 18:11, edited 2 times in total.
Post Reply

Return to “NewGRF Technical Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest