Have a look at the attached screenshot. There are some fences too much (marked red) and some are missing (marked green).
== small red circle: behind such slopes fences are drawn (dont ask me why;) )
== green circles on the first hill (the upper one): the respective tile has already some backimage shown, so no fences are drawn. The current implementation is: for one tile either foundation backimages or fences are shown north/west of the tile. [Sidenote: foundation graphics can contain fences]
== small red circle on the bridge: should be easy to fix by checking ways and ribis
== green circles on the second hill: the fences are drawn, but with the wrong height-offset, they are hidden by the slope
Now I noticed, that in pak96.comic fences are only shown on the upper two sides of an tile. What is the reason for it?
The fences must be present in the graphics for the wall. Which seems to be not the case in pak96. The logic behind is: either fences or walls are drawn, hence fences have to be included in the wall graphic to prevent people to fall of the cliff ;)
It's still part of the p96c-to-do-list. Please be patient with the fences.
By the way, gerw... Your screen was taken from an old version of p96c. The pink slope walls were replaced by now. :)
Just try the latest version (https://sourceforge.net/project/showfiles.php?group_id=196471&package_id=260290).
The glitches presented in the first post are partly due to the current implementation of the background images.
I want to propose a slightly different scheme to be used in the code and maybe afterwards in dat/pak-files. For each side of the background one can distingiush 16 different images (16*16=256 both sides -> one byte in memory).
No Configuration Natural Fence Comment
0 no background image
1 _ only fence, downward slope behind
2 / y y upward slope
3 / n y
4 \ y y downward slope
5 \ n y
6 - n n one full slope, no fence, bridge ending on this slope
7 - y y one full slope
8 - n y
9 / y y one and a half slope ...
||
10 / n y one and a half slope ...
||
11 \ y y one and a half slope ...
||
12 \ n y one and a half slope ...
||
13 - n n double full slope, no fence, bridge ending on this slope
||
14 - y y double full slope
||
15 - n y
||
Fence=(y) means the graphic is allowed to contain an additional fence above the slope
=(n) graphic must not have a fence since bridge ends on this slope
Natural=(y) stone-like graphics
=(n) concrete-like graphics
..Number 6 and 13 (bridge end slopes) can only have one of this graphics modes. Imho this is no restriction since the slopes are constructed by the player and thus are of natural type.
Number 1 (a fence is there) can be used as a flag to indicate the presence of a fence, the actual offset and slope of the fence is then determined by the slope of the tile.
For some paksets (eg pak64, pak.german), the sprites 6 and 13 must be produced from existing ones (delete fences). Fences on slopes (not plain horizontal) are also not present in current simutrans.
Any comments appreciated :)
Well, but any extension of the values stored in grund_t will increase the amount of memory for a map by 25% which was the main reason to have fences. (And they were introduced to see which flat slopes are actually elevated slopes, and that purpose they save well, imho.)
EDIT: just had a look: displaying the back fences correctly is extremely simple. Cehck next nightly.
I did only propose a slight renumbering of the backimages. The memory consumption is not increased.
Curretnly we have two blend of 11 backimages 11*11=121 that fits onto a byte. I count 15 backimages, which would require more. Or did I made a mistake?
My proposal:
6*2 slope backimage
1 fence
2 backimage slope without fence
1 no back image
---
16 per side
16*16 = 256 -> 1 byte
The 11 backimages you mention contain some unused slots (2,6,9,10). They were reserved for double-height slopes, but not used in current simutrans. Double-height code does not compile for me.
Double height works only with predefined tiles, thus the current climate system would need 87 light tiles instead 16. Thus one can think of removing the code completely. (Most of the compile errors are actually from the error directive, thus to stop people doing this without knowing what to do.)
And the fences should be on nature tiles as on city house tiles, since thore were for visibility. Simutrans should start without fences, so it is up to the pak author to provide some or not.
But I still do not completely understand you proposal. Maybe show it with some images?
The current implementation has several limitations:
- The backimages are both (left/right) either natural slopes, brick slopes, or fences. This leads to the glitches in the picture marked by large green circles on the upper hill.
- There is no distinction between slopes with fences and without fences, since sometimes the slope graphic contains already fences (pak64, pak.german). This makes it impossible to fix completely the fence-across-way-for-bridges-ending-on-vertical-slope-bug.
- This is no limitation but a missing feature: Fences on ground tiles are always drawn on the tile base (no height offset, no fences along hills).
The current implementation is developed for 2*11 back images, however only 2*6 are used. This leaves some space that my proposal will exploit:
The second point in the list above can be fixed by introducing backimage slope tiles that do not contain fence graphics (for diff_from_ground =(1,1)(2,2), number 6 and 13 above). These graphics are needed for natural slopes only. Index 0.2 and 0.7 in the graphic on the wiki.
The third item in the list can be implemented separately: The backimage contains the information 'There is a fence on the tile', and then the fence graphic can be chosen based on information of the current tile (slope, fundament or not) only. This needs extra graphics for fences along edges of hills (4 in total).
How is the information stored in one byte? For each side (west / north) 16 different values can be set:
2*6 slope backimages (possibly with fences, the same graphics as now)
2 slope backimages without fence (natural slopes: one or two full height steps)
1 as flag 'fence present'
1 as flag 'no backimage'
These are 16 different values for one side, leading to 16*16 = 256 for both sides.
http://simutrans-germany.com/wiki/wiki_img/source/ls-brickslope.png
Fences and tile backsides are seperate for left and right. Same for the natrual and brickslope. Hence I am a little lost with your comment. I agree that the fences at vertical slopes may disturb bridges. However, this is anyway considered a hidden and not official feature, like the harbour tunnel too.
But if one say one will never ever use double heights again, then there are 4 free bits which could give a bitfield for each fence corner. With such a system, in principle fences along railsways and so on would be possible too ...
Since the fences have been introduced to mark flat tiles in places, without border, the need of a fence for the slopes sidewall was not there (and imho still is not there for that purpose). However, the missing fence at the backside is really an issue, but please confer to the current revision in the trunk.
If on decides to have fences for all directly (like at the side of tracks) then of course 6 for each direction would be needed. Maybe this would give the greatest flexibility of all.
EDIT: spelling
Quote from: prissi on February 20, 2009, 08:32:39 PM
Fences and tile backsides are seperate for left and right. Same for the natrual and brickslope.
No, this is not the case. If one of the back images is a wall, no fence is shown on the other side. If one of the walls is made of bricks, the other will be shown with bricks!
See the if/else blocks in grund_t::display_boden.
With the current system one cannot change this.
I see. Well then probably the fences as bitset for each fence (even the front) would be the bet way out then and would allow also for fenced railway lines and so on.
Fences for fields!
What is the status of double heights - somewhere far in the future, or failed?
Well, you need insanly lot of textures and only rarely a doubleheight slope will appear at normal roughness levels: Imho too much gain for too little gaming experience plus.
Quote from: prissi on February 20, 2009, 11:22:23 PM
Imho too much gain work for too little gaming experience plus.
;)