paved roads

Post by **yobbo** » November 21st, 2005, 4:14 pm

So, I finally made some neater edges I'm relatively happy with.

I'd be happier if the game would accept my 5-sided transitions

(I even made a 6-sided one, am I keen or what).

I made them all hexy 'cos I think it's kawaii.

I'd be ultra mega super duper happy if I could upload the tiles, but The Board says it's out of space

. Was it something I did?

Post by **freim** » November 21st, 2005, 4:17 pm

hmm, interesting. This one fits to overlap more terrain I think, although that would make it very wide... we should have a new WML macro to make roads, eg. "connected tiles". Maybe it could be drawn as the bridges?

That would req. that we fix the annoying "fixed bg tile" issue though.

Post by **Neoriceisgood** » November 21st, 2005, 4:46 pm

I absolutely love it.

Post by **torangan** » November 21st, 2005, 5:06 pm

I think it looks very nice, it's just a bit too wide with the way transitions are drawn in this screenshot.

Tux2B · Post by **Tux2B** » November 21st, 2005, 5:12 pm

Maybe there could be a bridge that would fit that new kind of road. The bridges we now have don't look good at all with the new road.

Emmanovi · Post by **Emmanovi** » November 21st, 2005, 6:16 pm

Tux2B wrote:Maybe there could be a bridge that would fit that new kind of road. The bridges we now have don't look good at all with the new road.

It looks OK to me...

-> What i might be working on · Post by **Eleazar** » November 21st, 2005, 6:29 pm

I'm curious as to how you pulled off the straight edges-- good work.
Though i think (with an expanded terrain alphabet) there is room in Wesnoth for both kinds of stony terrains.

Post by **freim** » November 21st, 2005, 8:30 pm

To clarify what I meant: I would like to see how this turned out if it where drawn like the bridge is now. This is because I find the road nice looking, but a bit wide with this trans and I think it would look better if a bit narrower.

This way we could make other nicer versions of roads also that would "go through" a bg tile instead of being an entire tile itself.

Atm they would need to have a fixed bg though, like the bridge, but this is a limitation we want to remove anyway.

Oreb · Post by **Oreb** » November 21st, 2005, 8:59 pm

looks to sharp for me

hands · Post by **hands** » November 21st, 2005, 9:11 pm

I think it looks good. There are cases where your road could be used very nicely as-is (especially for indoor-type scenarios), but I think that it is too wide for most maps unless you want to rename it as highway or something.

frame wrote:To clarify what I meant: I would like to see how this turned out if it where drawn like the bridge is now. This is because I find the road nice looking, but a bit wide with this trans and I think it would look better if a bit narrower.

This way we could make other nicer versions of roads also that would "go through" a bg tile instead of being an entire tile itself.

Atm they would need to have a fixed bg though, like the bridge, but this is a limitation we want to remove anyway.

Are you thinking that roads and bridges could fit within the same subset of tiles? By using a two-letter terrain system (sorry to bring this up again), roads and bridges could both use "/" "" "|" keys to indicate directions for single-tile width roads. The second letter would then be available to reference 52 different directional road/bridge/"some future need" terrain types. That would definitely change the direction of road development a bit.

Post by **turin** » November 21st, 2005, 10:12 pm

Roads meet, combine, split, whatever more often than bridges do. If we want to convert roads to the current bridge methodology, we would need not only symbols for running N-S, NE-SW, NW-SE, but also symbols for N-NE-SE, N-NE-S, N-NE-SW, N-NE-NW, N-SE-S, N-SE-SW, N-SE-NW, etc.

It would make much more sense to either leave them as they are, or come up with an algorithm thatwould just pick the right tile to use for each of the situations listed about, but have the same letter ("R") for each.

Post by **freim** » November 21st, 2005, 10:15 pm

turin wrote:Roads meet, combine, split, whatever more often than bridges do. If we want to convert roads to the current bridge methodology, we would need not only symbols for running N-S, NE-SW, NW-SE, but also symbols for N-NE-SE, N-NE-S, N-NE-SW, N-NE-NW, N-SE-S, N-SE-SW, N-SE-NW, etc.

It would make much more sense to either leave them as they are, or come up with an algorithm thatwould just pick the right tile to use for each of the situations listed about, but have the same letter ("R") for each.

That was the idea.

Post by **turin** » November 21st, 2005, 10:18 pm

I read it badly.

However, if we are going to create an algorithm that will determine the sides to use, why wouldn't we use it for all road variations, including the "/", "\", and "|"? It doesn't make sense to me to have 4 different letters for a terrain type that would only need 1. Especially since the way the editor currently works, you would need to change what terrain you were selecting every time you wanted to make a road curve.

Post by **freim** » November 21st, 2005, 10:23 pm

turin wrote: I read it badly.

However, if we are going to create an algorithm that will determine the sides to use, why wouldn't we use it for all road variations, including the "/", "", and "|"? It doesn't make sense to me to have 4 different letters for a terrain type that would only need 1. Especially since the way the editor currently works, you would need to change what terrain you were selecting every time you wanted to make a road curve.

Yeah, it should be changed like that. I don't know how hard the WML for this stuff would be though. Thats a question for Ayin I guess.

Post by **Quensul** » November 22nd, 2005, 2:42 am

I'm (slowly) converting Wercator from Perl to C++, in order to make a few special effects easier to do and get the codebase rationalized. As a result, I'll eventually (eh, say a month or two - real life's been crazy busy) have GPL'd C++ code to take a Wesnoth map (or a connected chunk of tile coordinates) and return a Bezier curve spec.

I doubt this would be useful unless you're planning a *much* more drastic overhaul of the terrain code than it looks like, but I thought I'd let you all know just in case. Let me know if it'd be handy, and I can try to speed things up some.