missing shores

[BigBB]

Hi all artists,

how you know (or not) I wrote the completely shore patch which make it possible that OTTD draw corner shores (the new sprites in lepkka's newWater newGRF).

So my 'completely shore' patch isn't into the trunk, that is why I decided to make a much better patch (for interested people: FlySpray-task with full description).

For this patch I need a few sprites, ten for each climate: eight 'corner shores' which are added by action 05-0D too (e.g. in lepkka's newWater newGRF (which atm. only work on TTDP)) and two canyon shore sprites (which will be a new OTTD feature, as well as for action 05-0D which supported now (which my patch) too 18 instead of 16 sprites). The order of these 10 sprites are (to see in the picture, EW and NS are the two canyon shore sprites): SLOPE_STEEP_S, SLOPE_STEEP_W, SLOPE_WSE, SLOPE_STEEP_N, SLOPE_NWS, SLOPE_ENW, SLOPE_SEN, SLOPE_STEEP_E, SLOPE_EW, SLOPE_NS. And these sprites must fit with the current/original ones!

For the temperate climate you can see (in the pic) that I drawn an example. But I'm no artist so here is now my question: is there anyone who can please help me and draw these sprites (of course as open source sprites)? The chance that this (patch AND sprites) will be get into trunk is big (I've talked with belugas over that (a little bit)).

shore.png (239.04 KiB) Viewed 10554 times

shore.pcx

please use this, if you want to edit

(49.62 KiB) Downloaded 224 times

If you are interested to have a part of you (hopefully) permanently into the game source please help and answer me. If you need a temp-way to test your sprites, this will be possible and I will give you a patch/exec for that.

If you want to drawn anything, please use the pcx file, the png-files are only here to have something to look .

Regards,
BigBB


Here you see the game without (left part) and with (right part) my example sprites:

[BigBB]

If you need a temp-way to test your sprites, this will be possible and I will give you a patch/exec for that.

Okay, here is a patch file with that the corner and canyon shores will be flood. This patch is only for people who want draw these shores to test their sprites. So please don't tell me that the flooding is weird, it's no trunk modification .

Regards,
BigBB

[skidd13]

Here you are.

[DeletedUser5]

Something that looks weird for me.

uhh.png (55.94 KiB) Viewed 10247 times

But then, it's good patch - I just can't wait to see that patch in trunk. It looks beautiful.

[skidd13]

Something that looks weird for me.

uhh.png

But then, it's good patch - I just can't wait to see that patch in trunk. It looks beautiful.

Should be fixed with my sprite update.

[BigBB]

The sprites looks really good, thanks skidd13 for drawing them.

Here a pic with all sprites in use:

Something that looks weird for me.

No, that's okay. It's the green tile border of the original sprite in trg*r.grf and not changable (but much better with skidds sprites).

But then, it's good patch - I just can't wait to see that patch in trunk. It looks beautiful.

Thanks, but don't forget: this is a patch with three parts. The current one (step 1) only include the possibility to show these tiles and fix a general action 05-0d problem. To flood these tiles is step 2 and 3. This is to make the patch small and clear.

Regards,
BigBB

[lepkka]

Happy to hear you keep working on this BigBB
skidd13, let me suggest everything one pixel back, (a water pixel in the corner of the sprite)

[BigBB]

Happy to hear you keep working on this BigBB

Of course . Have you seen, newWater newGRFs can have 18 sprites, too. With action 07-9D and 07-A1 (IIRC) can you make a grf that have for TTDP 16 and for OTTD 18.

skidd13, let me suggest everything one pixel back, (a water pixel in the corner of the sprite)

The upper and lower pixels can not be fix, because it's from the original sprite 4064 above and 4065 below.

[skidd13]

Happy to hear you keep working on this BigBB
skidd13, let me suggest everything one pixel back, (a water pixel in the corner of the sprite)

There is no sand pixel in the top of the sprite. But maybe if I add an extra water pixel at top and at bottom, the sand might be removed by overdrawing it .

EDIT:
This should do the trick. Marked additional pixel line with a red pixel.

EDIT2:
nfo patch added

[skidd13]

Double post...
Attatched preview of the fixed. Only the lower sand border remains.

[BigBB]

Attatched preview of the fixed. Only the lower sand border remains.

Hmm, for me looks so:

Maybe it's luck if the pixel will be overdrawn or not...

Edit: now with your new shore.nfo works

[frosch]

I want to suggest a different method: It would be nice, if the shore sprites would be drawn as overlays on top of the normal landscape sprites, and the water-sprite. That way one could replace water, shore and normal landscape independent from each other.
Plus the SLOPE_NS, SLOPE_EW shores could be created from the overlays for SLOPE_NWS, SLOPE_WSE, SLOPE_NES, SLOPE_WSE, when canyon-flooding is disabled.

This would of course break some TTDP compatibility, but perhaps it is at least possible for the added SLOPE_NS, SLOPE_WE shores. (Btw: I guess the 10 sprites version in your patch is not TTDP-Action5-Handler compatible. I think you are only allowed to add sprites at the end, and the sprites must remain in their order no matter how many are specified. But of course I am not a TTDP-dev.)

The attachment is created using skidd's sprites from above.

[Zephyris]

I would like to see that...

[BigBB]

I want to suggest a different method: It would be nice, if the shore sprites would be drawn as overlays on top of the normal landscape sprites, and the water-sprite. That way one could replace water, shore and normal landscape independent from each other.

Nice idea, I have this idea for roads and rails already.

(Btw: I guess the 10 sprites version in your patch is not TTDP-Action5-Handler compatible. I think you are only allowed to add sprites at the end, and the sprites must remain in their order no matter how many are specified. But of course I am not a TTDP-dev.)

Wrong, it's complete compatible. Do you really think, that I make something which dont work with that? Here a sreenshot with the current version of my patch and loaded newWater (you can see the missed NS and EW shores in this newGRF, will be not replaced)

wrong.png (23.3 KiB) Viewed 9240 times

And with an action 07-9D and 07-A1 can a patch writer make a newGRF compatible to TTDP. And btw.:the shore NS and EW sprites are at the end and I haven't change the order. Have a look into the code first ...

Regards,
BigBB

[skidd13]

I want to suggest a different method: It would be nice, if the shore sprites would be drawn as overlays on top of the normal landscape sprites, and the water-sprite. That way one could replace water, shore and normal landscape independent from each other.

Theoreticaly yes, but you have to keep in mind that not only the sand is added. I added some additional shading at the sand border which will look strange if the ground tile changes. Then you'll need 2 sprites per tile. One sand and one shading, which will indeed break compatibility to TTDPatch, and that shouldn't be done.

[frosch]

BigBB: You got me wrong. Sorry, if I offended you.
I was talking about the support to only load the 10 missing sprites. These 10 sprites are not the first 10 sprites of the 16 and 18 sprites versions of the action5.
I extracted the 10 sprite action5 from you openttdw.grf and created a separate newgrf, that I loaded into TTDP. The behaviour of TTDP is to ignore the action5 as it specifies to few sprites. So it does not directly break compatibility. But I assume, if the TTDP people want to also implement the 10 sprites version, they will get into trouble.
Of course if you define, that this 10 sprite version must not be used by newgrfs with the exception of openttdw/d.grf, then I guess everything is fine.

[BigBB]

I was talking about the support to only load the 10 missing sprites. These 10 sprites are not the first 10 sprites of the 16 and 18 sprites versions of the action5.

The 1, 6, 8, 11, 12, 14, 15, 16 (, 17, 18) sprite. To have compatiblity with the 16 (and my new defined 18) sprites action 05-0D, can these places not be changed. These 10 sprites must allways fit with the original ones and will be only used if no newWater newGRF (17 and 18 if a 16 sprites newGRF) is loaded. If a standart newGRF loaded these sprites (how you suggested) will be replaced by the new one.

I extracted the 10 sprite action5 from you openttdw.grf and created a separate newgrf, [...]

That would be much easier, download the shore.pcx and shore.nfo from the FS link and edit the head of the nfo file voilà: a stand alone 10 sprites newWater newGRF .

[...] that I loaded into TTDP. The behaviour of TTDP is to ignore the action5 as it specifies to few sprites. So it does not directly break compatibility. But I assume, if the TTDP people want to also implement the 10 sprites version, they will get into trouble.

Of course ignore TTDP it. IIRC they do it in the same manner how OTTD: if the sprite count is wrong, don't load. And if the TTDP devs want to include these ten sprites they can not break the order or they break the compatiblity with the standart newWater newGRFs. So they must find a way to include them on the 1, 6, ... position how I must do.

Of course if you define, that this 10 sprite version must not be used by newgrfs with the exception of openttdw/d.grf, then I guess everything is fine.

Why should ?

Regards,
BigBB

PS to a mod: since this isn't an artist search, more a development discussion: is it maybe better to move this thread to the development section ?

[LordAzamath]

BigBB, I'm a little confused now...this is supposed to be the new version of Completely Shore, yes? But as the other patch has seen the light of trunk, do you still develop this? Because if you do and there is a possibility that it'll get to trunk once then the 8 bpp replacement project must provide those missing sprites too, doesn't it?

Regards. Lord

[DaleStan]

[...] that I loaded into TTDP. The behaviour of TTDP is to ignore the action5 as it specifies to few sprites. So it does not directly break compatibility. But I assume, if the TTDP people want to also implement the 10 sprites version, they will get into trouble.

Of course ignore TTDP it. IIRC they do it in the same manner how OTTD: if the sprite count is wrong, don't load.

Um... No.
If the sprite count is too small, load, but don't attempt to access. If the sprite count is too large, load, and ignore extraneous sprites
TTDPatch can load one action 5 of each type. A second one will be loaded, and will replace the old one. This is why action 5s never grow sprites except at the end of the block.