[UNIV] New Tram Tracks Development

[FooBar]

It'll run with OpenTTD nightly only anyway and by the time you release your set, most players will have a compatible version. You should be ok and a note in the ReadMe should help too.

That's true. I added a notice instead of an action7 for OTTD. Patch is unable to load the grf if one's using the wrong version.

They should only change the GRFID when absolutely necessary; and that is rare.

OK, that's a good thing. Then I don't have to update my set if someone else updates his/hers.

___________________________________
New Version Released!
I have a new version to show you all!

Whats new?
- Updated track sprites to solve some glitches.
- Updated default road sprites to solve glitches with updates track sprites.
- All new single-sided poles for overhead wires.

See the first post for downloads and additional information.

I also discovered another error in OTTD. This has been solved today since r10549.

Please don't look for thinner poles as they're not done yet and note this is an alpha release. Please post all your comments (especially on corner-wires).

I'm also looking for a new name for the set, because it's not just grass tram tracks anymore (and I think that's a stupid name anyways). Any suggestions?

[OzTrans]

... Please post all your comments (especially on corner-wires).

Nice job ... but, the corner pole stands in the middle of the road, if the tram tracks veer off.

Why, are you including the 'original' temperate road tiles ? Tram tracks should be happy with any road surface.

... I'm also looking for a new name for the set, because it's not just grass tram tracks anymore ...

Just, 'Tram Tracks', 'Alternate Tram Tracks' or 'Updated Tram Tracks'.

[XeryusTC]

Some of the corner poles are in the middle of the road.

[FooBar]

I too noticed that. It will be fixed in the next version. Stupid me, can't remember why I put that pole there in the first place

The reason why I included the default road tiles might be explained by the attached image. There's some dark stuff -remains of the underlaying road tiles- visible along the upper edge. That could be solved by widening the tramtrack-overlay, but that would introduce a serious glitch at tunnel entrances (the same sprites are used for straight track and track in tunnel entrances). The only solution I could come up with was editing the default road sprites and including them.


Some other news: thinner poles are done too, but I'm having serious issues with Action7. Currently, I have this:

Code: Select all

	// skip below 114(72h) if parameter 00 == 1
1 * 6 07 00 01 \7= 01 72
3 * 3 05 0B 71
    //bunch (71h) of real sprites for 2px poles

	// skip below 114(72h) if parameter 00 =! 1
1 * 6 07 00 01 \7! 01 72
3 * 3 05 0B 71
    //bunch (71h) of real sprites for 1px poles

In words that should read something like "if parameter 1 is equal to 1 skip the 2px poles, if parameter 1 is not equal to 1 skip the 1px poles".
It works fine, but only if a parameter is set. If the parameter is omitted, it gives me 1px poles, where I expected to have 'em 2px.
Maybe I'm doing something horribly wrong, but I can't figure out what. What I want is this: "If and only if parameter is equal to 1 give me 1px poles, otherwise 2px poles". How can I get it working correctly?

[DaleStan]

You're not reading the action 7 documentation closely enough. The detail you're missing is "If [the variable is] a GRF parameter that wasn't specified in the newgrf(w).cfg file ... the action 7 or 9 is ignored and no sprites are skipped".

The easiest solution is just to swap the two sprite blocks. A more elegant solution would be to use an action D with <op> 80.

[FooBar]

Thanks for pointing my nose in the right direction, DaleStan. I really should learn to read more carefully .

I guess I go for the more elegant solution, because I don't think it's useful to overwrite a set of sprites twice.

[FooBar]

I'm sorry for the double post, but I want to raise an unread post flag to get a little attention for the release of a new version.

New version Released
This time I added the thinner poles! Also moved the third pole in corners to the side of the road, even used an existing pole in most cases.

Downloads are as always available in the first post. I also added an entry to GRFCrawler.


Another something... If I want to support all climates + new terrain + Japan terrain (toyland is not a climate) AND have the option to switch between the two types of poles, I end up with (5*2=) 10 times Action5, all with 113 sprites and loads of duplicate sprites in the final grf file. Is there a way of losing those duplicates, of do I just have to face the fact that the grf in the end will reach about 1MB in size?

[OzTrans]

... If I want to support all climates + new terrain + Japan terrain (toyland is not a climate) AND have the option to switch between the two types of poles, I end up with (5*2=) 10 times Action5, all with 113 sprites and loads of duplicate sprites in the final grf file. ...

That is about right, you'll have 1,130 sprites, a lot of duplicates and a size of about 750 kBytes. But that does not really matter, only 113 sprites are going to be selected at any one time.

[FooBar]

OK. So if there's no other way to do it, i'll do it this way.

Pretty weird that original graphics can be replaced one at a time if you want to, but TTDP specific graphic sets need to be replaced as a whole. Should it be too hard to let Action5 behave like ActionA? I'm gonna suggest that, if not done already

[OzTrans]

... original graphics can be replaced one at a time if you want to, but TTDP specific graphic sets need to be replaced as a whole. Should it be too hard to let Action5 behave like ActionA? ...

That should be possible and could of course be handy, especially when you don't want to change some of the sprites. If you do have to include all of them, Mr Copyright may raise its ugly head, because you have someone else sprites in your GRF. As for waisting CPU cycles and/or memory usage, I don't think this is a problem as Action-5s and Action-As are only dealt with at game start, save game load and pressing the apply button in the GRF status window.

[DaleStan]

As for waisting CPU cycles and/or memory usage, I don't think this is a problem as Action-5s and Action-As are only dealt with at game start, save game load and pressing the apply button in the GRF status window.

That covers CPU, but what about memory?
Every sprite always has to be loaded, and I suspect that every real sprite that was not skipped with a 9 consumes a sprite slot. (And the skip/no-skip status of a 9 is not usually something you want to be adjusting at runtime.)

[OzTrans]

... Every sprite always has to be loaded, and I suspect that every real sprite that was not skipped with a 9 consumes a sprite slot.

If I have different Action-5s, defining the same type of graphics; then surely skipping all (with action-9s) but the one I really want to be applied, at any given activation stage, I only load sprites for one set. But, even if I were to load set of sprites for the same type of graphics multiple times, then every time the same sprites get overwritten. Or do I create a new block of sprites each time, the old one remains unused and memory gets fragmented ?

Question. At game start, I load one set of sprites. Lateron in the game, the player presses the apply button, and due to differing game year a different set is loaded. What happens to the first set ? Does the 2nd set load over the first one ? Does the 2nd set get loaded into a new block and the first one is ignored but still there ?

[FooBar]

Getting closer to version 0.4 status update

I'm currently developing support for both sub-arctic and sub-tropical climates. Sub-arctic is fine, but sub-tropical is a pain in the ***. When you have a look at the image attached below, you'll see that it looks pretty crappy. The only solution I came up with is redoing all the default road sprites, but they'll end up looking flat (second attachment).

Does anyone have a better solution?
Please note that tram track sprites are always an overlay on top of road sprites. It's not possible to use the full size of one tile for the track overlays without introducing severe graphical errors at tunnel entrances. The current overlay-tracks (third attachment) are as wide as possible whilst keeping tunnel entrance glitches to a minimum. Any suggestions?

I'm also awaiting permission to use parts of Jezulkim's Japan Set terrain and Kolijn Wolfaardt's New Terrain. As soon as I get the requested permission I'll add support for those terrains. The sprites are done (but will not be included without permission).
Are there any other terrain sets which someone likes to see supported? Please let me know and I'll see what I can do


Support for non-default road sets will be even more difficult than supporting sub-tropical climate (although Japan Set road support will be fine). My current aim will be to automatically disable default roads as soon as a non-default road set is active. Solving glitches will be a bit more difficult. I guess graphic artists are not too keen about me cropping all their shiny roads



Version 0.4 will be released as soon as permission is aquired. I'll wait till friday for a reply. If none, I'll start spamming the development topics to request permission. Stay tuned all, and don't forget to read the above and start suggesting

[wallyweb]

Does anyone have a better solution?
Please note that tram track sprites are always an overlay on top of road sprites.

Pardon my ignorance but I always thought that an overlay was just that ... a graphic with a transparent background that overlays any other graphic such that the other graphic will show through. If the tram track sprites are transparent except for the tracks, shouldn't any road show through without your having to redraw them?

[FooBar]

[quote="wallyweb"]...a graphic with a transparent background that overlays any other graphic such that the other graphic will show through...quote]That's quite true, indeed. That's also why my track overlays contain grass: it hides the road sitting underneath.

Have another look at this attachment and I might be able to explain things a bit better:

[DaleStan]

Off-road trams are drawn over a road sprite? I find that surprising.

[wallyweb]

ok .. now when is the track overlay placed on top of the road?
A. Is it done by the artist when he draws the sprites?
Or
B. Is it done at the grf level by an action code?
Or
C. Is it a combination of A and B where the artist draws the track onto a road sprite and then the grf code overlays that sprite onto a non-track road sprite?

[FooBar]

The correct answer is B. Actually, the game puts things on top of each other, nothing you can change about that trough GRF.

@DaleStan:
Me too when I first discovered that. If that wasn't the case, the creation of my grf was pretty easy.
(Can this behavior be changed?)

[wallyweb]

The correct answer is B. Actually, the game puts things on top of each other, nothing you can change about that trough GRF.

@DaleStan:
Me too when I first discovered that. If that wasn't the case, the creation of my grf was pretty easy.
(Can this behavior be changed?)

Ok ... thanks for your patience.
Now, if it is B and it Is done at the grf level by an action code, I assume that the tram track sprite does not include the road surface but rather it overlays the road surface sprite. If this is the case and the tram track sprite is transparent except for the tracks, what does it matter what is underneath the tram track sprite? Whatever is underneath will show through the transparency, would it not?

[stevenh]

Off-road trams are drawn over a road sprite? I find that surprising.

DaleStan, You've seen enough of my code to not find that surprising.....

The issue was snow tiles/climates/etc.... it was a neater and actually pretty-nice-looking answer to just draw the appropriate road tile underneath (since the off-road tram tiles didn't take the full width nor have the appropriate landscapes around them)