News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Make world limits not forced to water level

Started by Markohs, November 16, 2012, 01:39:10 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Yona-TYT


Quote from: Sarlock on April 02, 2013, 03:08:39 AM
You're so close to the finish line now, Markohs, I can't wait to see the final product.  Great work!

@Markohs, a good job congratulations ;)





Simutrans Fan page on Facebook

sdog

Quote from: Markohs on April 01, 2013, 10:42:09 PM
Well, this thread has been open for discussion for even months before I wrote a single line of code of this patch, if someone wants to express his opinion he's free to do so.

There are  lots of threads in this forum full of discussion and opinions that don't have rendered a single line of code nor changed anything in game. I try to respect opinions expressed by everyone, but I have to accept not everyone will like the changes I made. They have their point of view, and that doesn't have to agree with mine, but it's me the one coding it. If someone wants it differently, he can convince me of it, or just code it himself.

I think I've been very receptive to all the comments anyone on this forum has made me, and have answered most of the requests I've been done. What I don't feel comfortable is when I read that my contributed work is not of the tastes of anyone, when they haven't expressed so in the past.

Anyway if many people is against this changes I have not problem retiring this patch from the code and return the game to its previous state.

I think this went perfectly in this case. There was a wide consensus this would be an improvement. I also don't think prissi's nostalgia was not meant a criticism. Worse would be if the discussion would be after a lot of work was done and the idea is turned down. The other way round, a long discussion without any changes done is also not a bad case, as it still helps to decide where not to go, or where it would be desirable to go, but the resources are not there. Afterall talk is very cheap in comparison to code.

It is a wonderful change in my oppinion. The island is at time also quite nice, but even if someone likes those, they will hardly get annoyed by the edges. IF they are, you can ask them to augment it by a waterfall, four elephants and a turtle :-)

Isaac Eiland-Hall

I think this is an awesome change...

And I agree, I don't think Prissi meant offense at all... in fact, I just was reading a thread on reddit (I'm about to post in the Community forum, so look there in a bit if you want to follow this tangent), and several mentioned that Germans tend to be rather direct. If that stereotype is true, it adds to the likelihood that no offense was meant. :)

Ters

In any case, there is always some opposition to change. Always someone who wants to take the game in an opposite direction to someone else. I think this has actually been less the case for this change than any other I can remember. Map rotation and sliced underground were probably the last comparable changes, but I don't remember those discussions, maybe I never read them.

Sarlock

I continue to be impressed with how well this community functions.  Considering how many languages, cultures and playstyles are all combined here, it is truly amazing to me that everything runs as smoothly as it does.  Conflicts exist but for the most part people are extremely accomodating and accepting of things that aren't quite to their liking... because in general this game continues to move forward in a positive, constructive manner.

Who knows where this game will be in 10 years, but with a community like this, I can certainly feel confident that wherever it goes, it will be progressive and even more incredible that it is now.

I still want to play with a 15,000x15,000 map... in a few years, that should be possible :)
Current projects: Pak128 Trees, blender graphics

IgorEliezer

#145
Quote from: Sarlock on April 02, 2013, 06:28:32 AM
I continue to be impressed with how well this community functions.  Considering how many languages, cultures and playstyles are all combined here, it is truly amazing to me that everything runs as smoothly as it does.(...)
So let's sing together!


kierongreen

Indeed - there is always a tendency to keep with what is known. I should make it clear I don't really have a view one way or another on surrounding the map with water vs the new look - really what looks best depends on the map in question.

Markohs

Np, I wasn't offended at any point. Just wanted to state clear that if I try to be verbose and keep people up to date with my screenshots and updates, it's because I need their feedback at that moment, not after all the work is done. I can accept comments after the work is done too ofc, if they are constructive. I know prissi, I think I know more or less how he thinks and this is not a problem. I was refering to other comments. :)

It's like weddings, talk now or shut up forever. :) More or less. ;)

Markohs

Well, back to topic, three things:

a) About maximum, minimum and water level. Before this patch they were hardcoded in various routines, I tried to centralize them. They are defined the same as before:

minimum: water_level -10
water_level: User defined
maximum height: 14

How do we manage this? Or we just let it be like it's now?

b) About the background. Right now it's just solid black color, and as prissi pointed out it might not look good enough on all packs, two options (not exclusive)

1) Allow the pak .tab fie defining another color, so each pak can use a color that suits better to the style.
2) Allow the pak to define a image that will be used as a pattrn for the background, a rectangular image that will be repeated across the background. That will allow getting back water and inslands to simutrans, plus other patterns.

c) About the world slopes, as I expressed before my first implementation is just generating them programatically from a list of depths and colors, the intermediate points are interpolated colors between the defined ones.

But I fear this implementation might be not enough, even it's required for the case the pak doesn't supply extra information. But we have to allow the pak designer to paint the borders, my suggestion is opening the possibility to the pak designer to supply two vertical stripes of ground and water borders, I can generate the needed slopes programatically form this. Is there any comment about this?

Go, want to hear your oppinions on this. :)

Sarlock

Re: A) Is the limitation of 24 heights a gameplay limitation or a data limitation?  24 isn't an even amount of bits, so it makes me curious as to where that number comes from.
Likewise, is there a reason to force water to a minimum of 4 levels on a map or can we have 24 different levels of ground and no water?  (or 23 ground + 1 water)
Or is this because drawing the tiles that high causes problems (especially with planes)?
Current projects: Pak128 Trees, blender graphics

jamespetts

I think that allowing pakset authors to define images, with what you have now, or something very much like it, in default of the definition of those images is the way to go. As Prissi pointed out, Pak.HD would look much better if images were allowed to be defined. Would it also be possible to have a single large image instead of a tiled image? It is conceivable that a pakset author one day would want an image of a gigantic turtle atop an outsized elephant...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Dwachs

Quote from: Sarlock on April 02, 2013, 02:35:02 PM
Re: A) Is the limitation of 24 heights a gameplay limitation or a data limitation?  24 isn't an even amount of bits, so it makes me curious as to where that number comes from.
Likewise, is there a reason to force water to a minimum of 4 levels on a map or can we have 24 different levels of ground and no water?  (or 23 ground + 1 water)
Or is this because drawing the tiles that high causes problems (especially with planes)?
The pure data limit would be from -128 to 127.

Large height differences would mean graphical errors (with planes or very high buildings). To be honest, I cannot remember what exactly was the problem. Maybe remove this limitation and see what happens? Bugs can be fixed afterwards ;)

I would also like to set the water level to be exactly zero ... This can be done in a normalization step after world generation.
Parsley, sage, rosemary, and maggikraut.

Markohs

A single large image whould not be a good idea since the map can be of various sizes, so the image should be huge, I don't see it. I think only a tiled repeating pattern should be allowed. The background is to be scrolled too, ofc.

About your comments on height, I believe what Dwachs says it's true but fixing whould close the door to move water level dynamically if some day we desire to do so, I'm not sure... More thoughts? :)

Yes, we can allways remove the limit and see what happens. :)

Sarlock

I'd be curious to know what all of the potential graphical problems could be from a removal of the height limitation to its data limit.  I believe I saw it mentioned somewhere in the past that drawing airplanes would be an issue.  With kieron's half-height patch, being able to have twice as many heights (or more) to a map to keep the altitude limits the same would be wonderful.  One could make some incredible maps with high mountainous terrain and present a real challenge to the player to try and navigate a way through it with switchbacks and tunnels.
Perhaps with Markohs' patch to allow heights to carry right to the map borders, some of the potential graphical issues with higher map heights has been resolved.

Having a tiled repeating pattern defined by the pakset would allow for an easy way to revert back to the original look of the game: create a map with edges at water level and use a black tile pattern and it will look just as it did before.
Current projects: Pak128 Trees, blender graphics

prissi

Very simple: If you have an elevation of 14 or more, then stuff at the bottom may not be drawn correctly, i.e. skyscrapers with three or more stories will jump out/into view when scrolling and stuff like this.

IgorEliezer

Quote from: Sarlock on April 02, 2013, 06:28:32 AM
I still want to play with a 15,000x15,000 map... in a few years, that should be possible :)
Kinda off-topic: I tried to generate a 4096x4096 map (it's the maximum size for squared maps), but my computer didn't like the taste and said "no way!". :E

Isaac Eiland-Hall

I've played a ~15,000-wide map -- but it was 32 tall. :)

Markohs

 Questions: To allow the pakset to define a background color I guess the better option is adding a configuration option to simuconf.tab, no? Will that be saved to savegames? I planned to add it to settings_t::parse_simuconf and add it to umgebung_t.

Is this the best way of doing or I'm missing something? If we plan to allow the player changing this color, I guess It will be saved to setting.xml, no?

If the player is to be able to select a color, shoudn't we implement a widget for the user to select it visually like the one Hajo/Spike implemented? That code is out of our reach, I *think*. Can't we re-implement something like that? Is a good idea taking his code for our project?

Thanks.

Dwachs

The background color can be read from simuconf.tab as any other setting. It does not need to be saved. And it does not need to be changed by some fancy gui element imho.
Parsley, sage, rosemary, and maggikraut.

Markohs


isidoro

I've got the chance to check this patch when checking kierongreen's one about half slopes and lakes, and I like it very much too.

One suggestion, though: in the implementation I saw, there were no tiles showing the terrain cut at the borders and I had a feeling of emptiness.  I don't know if when proper tiles are there, that would change or if the following suggestion is appropriate: to draw a white dashed line on the terrain at the borders o a kind of fence (maybe only on the two furthest borders), or...  maybe it makes no sense...



Markohs

That's actually a very nice and original idea. It makes sense. I'll think about how to implement it... Looks like a good addition.

Thanks isidoro!

Ters

I don't like a fenced in world any better than an "oceaned in" world.

Dwachs

MArkohs, you could also use the original background graphics in ground.outside.pak aka grund_besch_t::ausserhalb->get_bild(hang_t::flach).
Parsley, sage, rosemary, and maggikraut.

Ters

I was just trying out the OpenGL backend and noticed that there seems to be some incompatibility between it and this. From the looks of it, it had to do with the double-buffering nature of the OpenGL backend. Only one of the buffers get cleared, while artifacts from previous frames remain in the Void in the other buffer. (The Void being the replacement for the Encircling Sea of the previous cosmology of Simutrans.)

kierongreen

Something changed recently with this patch now I get some a black square area surrounding border tiles with double heights, any ideas?

Markohs

Thx, will have a look to this issues. I think they both have easy fixes,  I'll test it with your patch, kieron

Markohs

I guess you are refering to this, no kieron?



kierongreen


Markohs



Added a setting to simuconf.tab to allow to change background color. I decided to change default color to a grey that looks better to my eyes, if many people is against this color we can change it.

The setting is "background_color"

As any other setting in simuconf it's first read from $PROGRAMPATH/config/ and later can be overrided by the PAK file in pakname/config/simuconf.tab

Available in next nightly @6442

Sarlock

Current projects: Pak128 Trees, blender graphics

Markohs

About the textured background, I'd prefer top not use grund_besch_t::ausserhalb because that image is tile shaped, and has transparent background, I'd rather prefer:

1) Make background code a responsability of karte_t:: and move the code there. But do you think this is a good idea? Should I keep the code in grund_t? Background is not strictly ground. I can also create background_t. In fact I prefer creating a new class, but I know you don't use to like adding new classes, what do you prefer?
2) Define a new object, optional in pak, called backgroundimage , if it's defined the background will be tiled with it, it must be a rectangular image, with no transparencies. If it exists, simutrans will use it, if not it will fall back to solid background color (the one already implemented).

Even that image is a regular rectangle, artists can draw a tile on it, and knowing the image will be tiled across background, they can achieve the old efect too. It can be maybe of arbitrary size or a multiple of the tile size, so they maybe want to add logos and whatever they want. They can create a image in such a way that aligns to world tile limits.

Markohs

#172
Have this close to ready to use, for the tests I had to improvise a image myself, as you can see I'm not very talented to draw... I'll leave that graphics to our artists because my image sucks. ;)



The original image is:



I know the graphics are not well alligned still, working on that... Thought this image was funny enough to show. ;)

EDIT: If someone fancies making a nice image to test in pak128 just send me it, any shape is acceptable, but dimensions have to multiples of 128. 128x128, 512x512 or 1024 x 256 for example.

Dwachs

There are still problems with the gray background not set dirty: if tooltips are over the background, they leave traces. Not sure how to solve this. Of course, we could set the background dirty whenever a tooltip is drawn. Would this be a performance bottleneck?
Parsley, sage, rosemary, and maggikraut.

Markohs

I'll look into it, I experienced that bug once but thought was something on my new code