Sloped stations (r15114)

[planetmaker]

I would recommend a flag for the station graphics that specifies whether that graphics set has the needed sprites for sloped stations or not.
That way, the patch could be allowed in trunk more easily since it wouldn't need graphics for it to be included.

If a gfx set doesn't have slopped station sprites, just use old behavior and show an error message. This would also prevent glitches when using graphics sets that don't have the needed sprites.

To me it this sounds like a good idea as it avoids graphical glitches and is clean. Dunno what the devs opinion is on that, though

I don't think it would hurt adding the graphics for four additional directions (16 sprites: 4 directions, 2 sprites per direction, 2 types (bus, truck)). I don't mind voluteering to create those sprites tomorrow night.

Nice! Love your graphics. Will you do default sloped train stations, too?

[FooBar]

Nice! Love your graphics. Will you do default sloped train stations, too?

In that case I have to disappoint you. I was thinking about doing them in TTD style, due to possible trunk inclusion. There will be an OpenGFX version, but only if this feature is included in trunk. Good to hear that you like my graphics though!

And yes, I could do the rail stations as well. Those will probably take a bit longer as it's a lot more sprites to draw. If those stations can be included in trunk depends on how they need to be coded: If they would need to be coded as NewStations, it's impossible to include them in the game by default. Such code cannot be in openttd(w).grf.
IMO, it would be best to introduce a new Action 05 Type for these default sprites AND introduce an extension to the NewStations specification for sloped stations. And then just deny the construction of a sloped station if the appropriate sprites aren't provided, like suggested before by coyoteelabs. However, it's not up to me to code all that.

@Wolf01:
I recommend splitting you patch in two parts: on for road stations and one for rail stations. Then try to get the easiest one included in trunk first. This makes people go "why can we have this on slopes and that not", which might get you motivated big time to complete the other one from there

[planetmaker]

Nice! Love your graphics. Will you do default sloped train stations, too?

In that case I have to disappoint you. I was thinking about doing them in TTD style, due to possible trunk inclusion. There will be an OpenGFX version, but only if this feature is included in trunk. Good to hear that you like my graphics though!

Probably I came accross a bit too demanding when asking about the stations graphics (the praise referred to all your newgrfs) In my mind I was "only" thinking of the 4 sloped versions of the default station which OpenTTD comes with by default, not of any newGRF . But then, introducing that as a newGRF only feature for stations might be both, easier and cleaner, not sure.

@Wolf01:
I recommend splitting you patch in two parts: on for road stations and one for rail stations. Then try to get the easiest one included in trunk first. This makes people go "why can we have this on slopes and that not", which might get you motivated big time to complete the other one from there

Sounds like a good plan. Small is beautiful

[Wolf01]

As I already said, splitting the patch requires first to add more code to deny one or the other station to be built on slope (ok, it is one line of code) and both patches will be incompatible with each other, and this mean that if both patches will be applied to trunk one day, the second one must revert the deny code of the first one, since the slope checking is done once for all the stations

[FooBar]

Here you go, Wolf: 16 sprites fresh out of the oven. Be careful, they might still be hot.

[Wolf01]

Thank you FooBar, now I only have to learn how to code them and use them
I think I'll do something next weekend

[Wolf01]

I tried to do something, but without any knowledge and spare time I ended up to do nothing useful
I tried to encode a grf with the pieces FooBar provided me, but the grf looks really weird, I don't know what I've done but all the sprites are cut and stretched diagonally.
If it isn't a problem, I ask somebody to encode at least the 16 pieces for the roadstops (those without the road tile) so I can at least learn how to use them via code and maybe trying to decompile and recompile the grf and see where I mistake
I hope to keep the interest for this patch alive, so maybe in future we might have this feature in trunk (I think it will be very needed if the more height levels patch hit the trunk)

[FooBar]

I can code 'em as action 5 type 11 if you like. In my opinion that would be the best way to make additional road stop graphics available to the game. Be right back...

EDIT:
Here you go. I coded it as described above. The grf works in a recent trunk, but ofcourse I'm only able to use the normal flat roadstops then.
Implementing this grf shouldn't be too hard I think. The way the sprites are displayed should be exactly the same as with the normal sprites, only now with a different offset. Good luck with this, I hope you can get it working!

[Roujin]

I tried to do something, but without any knowledge and spare time I ended up to do nothing useful
I tried to encode a grf with the pieces FooBar provided me, but the grf looks really weird, I don't know what I've done but all the sprites are cut and stretched diagonally.
If it isn't a problem, I ask somebody to encode at least the 16 pieces for the roadstops (those without the road tile) so I can at least learn how to use them via code and maybe trying to decompile and recompile the grf and see where I mistake
I hope to keep the interest for this patch alive, so maybe in future we might have this feature in trunk (I think it will be very needed if the more height levels patch hit the trunk)

That sounds like you used a size for the pcx file grfcodec didn't like.
Try a power of two, i.e. 256 or 512, that should do fine.

[DaleStan]

The rule is "Width must be a multiple of four unless the PCX was produced by GIMP."

The offer to fix GRFCodec if someone can explain how the output of your preferred program differs from GIMP's output[0] still stands.

[0] The technical differences. Specifically, why the bytepacking differs, and how to detect this.

[FooBar]

Please also don't miss my edited post above. I attached a ready-coded grf there.

[andythenorth]

The rule is "Width must be a multiple of four unless the PCX was produced by GIMP."

Going off topic here, I use a Photoshop saved action to deal with this issue. It:
- ensures the image is a specific size (I use a standard size for sprite sheets), which is also a multiple of four.
- forces the image to an indexed palette, using a .aco file which is available for the TTD (windows) palette.
- saves as pcx
- closes the file
I keep my source in layered Photoshop files; there are many of these to prevent photoshop becoming slow, memory hungry and crash-prone, which it does when there are many many layers in a single file.

To 'export' sprites I run the saved action in a batch across my files to produce final sprite sheets. Only applies to Photoshop users, but may be a useful tip.

cheers,

Andy

[frosch]

Well, I also have only gimp, so I cannot test. But I would expect the issue to be related to

Code: Select all

Index: pcxsprit.cc
===================================================================
--- pcxsprit.cc (revision 2072)
+++ pcxsprit.cc (working copy)
@@ -326,7 +326,7 @@

        fseek(curfile, oldpos, SEEK_SET);

-       sx = header.window[2] + 1;
+       sx = header.bpl;
        sy = header.window[3] + 1;
        totaly = 0;

I.e. there can be more bytes per line than pixels. And pcx is word-aligned, so 'bpl' is always a multiple of 2, while 'window' is not. Though I cannot explain the multiple of 4 issue with that and do not know whether the patch works or is correct, but 'bpl' is never used, which is obviously wrong.

[Wolf01]

Today I tried to do something, but since I can't compile with MSVC80 I can't debug it
I really don't know how graphics are drawn and loaded from grfs, so I tried to modify here and there based on suggestions from frosch
However, if it might work, the offsets for the new sprites are clearly wrong, I did not set them right because I first wanted to see if I was able to load the sprites and then fix the positions later
I think I can't go any step further in this direction, the base code works so it is possible to have sloped stations with bad graphics, so I'm looking for a volunteer which can do the "difficult" part with me or at least teach it to me so I can do it (and teach doesn't mean change stations_cmd.cpp or increase the number of sprites in sprites.h, these are hints and they are well accepted, but they are not sufficient for me)

[Wolf01]

Updated the patch to head
I did not touch anything, the next step is to find a way to pass the "check_facing_slope" via a different parameter, maybe with flags as DC_CHECK_FACING_SLOPE, because it might be needed for a future grf which disallow a station to be placed on slopes, now it's enabled by default only for roadbays since roadbays can't be sloped (so all current non-station tiles)

I started to code the grf support for roadstops but as now it doesn't work

The game is playable with the new feature and it shouldn't have any known bug, but graphical glitches.
All stations facing a slope will be treated as sloped stations, stations perpendicular to slopes works the same as in trunk
If you don't want a sloped station just don't build a sloped station

[FooBar]

Good to see that you picked this up again, Wolf!

If you want me to do sprites for the railway stations any time soon, let me know.

[Wolf01]

The main problem now is the code, when (if) it will be ready I'm glad if you will help me with the graphics