The International Simutrans Forum

Development => Patches & Projects => Incorporated Patches and Solved Bug Reports => Topic started by: Markohs on November 16, 2012, 01:39:10 PM

Title: Make world limits not forced to water level
Post by: Markohs on November 16, 2012, 01:39:10 PM
What do you think of removing the current limitation in simutrans to have map border tiles with height to water? Whoudn't it give more freedom to the map to let it have aribtrary heights? Is it hard to implement?

We can maybe remove this limit and make the map be a rectangle floating in space like SimCity does:

(http://image.gamespotcdn.net/gamespot/images/2003/pc/simcityrush4/0929/sc_screen001.jpg)
Title: Re: Make world limits not forced to water level
Post by: Fabio on November 16, 2012, 02:18:51 PM
IMHO it would be just wonderful!
Could you take care of it yourself? ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on November 16, 2012, 02:25:43 PM
Quote from: Fabio on November 16, 2012, 02:18:51 PM
IMHO it would be just wonderful!
Could you take care of it yourself? ;)

haha sure, I got this idea when checking the land display code I have to modify for the OpenGL backend. Wanted to hear oppinions about it before modifying this. ;)
Title: Re: Make world limits not forced to water level
Post by: Fabio on November 16, 2012, 02:34:30 PM
Related to this (and mentioned by Prissi in double height project thread) it would be nice to have vertical slopes textured and calculated/cropped on the fly.
Title: Re: Make world limits not forced to water level
Post by: Markohs on November 16, 2012, 03:09:29 PM
You mean the vertical walls in the boarder of the map?

Or all the slopes in-game?
Title: Re: Make world limits not forced to water level
Post by: ӔO on November 16, 2012, 03:42:47 PM
I support this. It gets a bit awkward designing hilly maps, when the edges get trimmed down, because it must touch water.
Title: Re: Make world limits not forced to water level
Post by: prissi on November 16, 2012, 04:56:29 PM
A map does not need to be edited to go down at the border, that is done by simutrans itself upon loading.
Title: Re: Make world limits not forced to water level
Post by: Fabio on November 16, 2012, 09:05:39 PM
Still it would be nice what Markohs proposes, with map edges higher than sea level.
Title: Re: Make world limits not forced to water level
Post by: Markohs on November 16, 2012, 10:26:44 PM
Yeah, will have it a look. Will simplify the opengl display of the map too.
Title: Re: Make world limits not forced to water level
Post by: Fabio on November 16, 2012, 10:41:58 PM
Quote from: Markohs on November 16, 2012, 03:09:29 PM
You mean the vertical walls in the boarder of the map?

Or all the slopes in-game?

Well, vertical walks at the map border will need to be rendered on the fly, as they could have any arbitrary height, according to the map.
Personally, I believe the game would benefit from all walls being rendered instead of coming from pngs, especially with the future double height project integration.
The only drawback would be the nice arches from pak96.comic would be lost. Maybe it could work like the oceans: rendered from textures, but if images are provided for some walls, you use the image instead of rendering it.
Title: Re: Make world limits not forced to water level
Post by: isidoro on November 16, 2012, 10:59:55 PM
Another advantage of making the world limit not forced to water level happens when you want to enlarge the map.  Current behavior produces scars where the map limits used to be...

Title: Re: Make world limits not forced to water level
Post by: Markohs on November 17, 2012, 02:03:43 AM
 Yea, many advantages and no drawbacks so far. Working on this.

Quote from: Fabio on November 16, 2012, 10:41:58 PM
The only drawback would be the nice arches from pak96.comic would be lost. Maybe it could work like the oceans: rendered from textures, but if images are provided for some walls, you use the image instead of rendering it.

Had to install the pack to see what did you mean. That pak looks great, are you refering to this?

(https://dl.dropbox.com/u/30024783/Untitled32.png)

what whould be good is implementing multiple slopes texture sources, that one can be created from a texture too
Title: Re: Make world limits not forced to water level
Post by: Fabio on November 17, 2012, 08:54:30 AM
Quote from: Markohs on November 17, 2012, 02:03:43 AMare you refering to this?

(https://dl.dropbox.com/u/30024783/Untitled32.png)

Precisely!
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on November 17, 2012, 10:48:22 PM
Quote from: Markohs on November 16, 2012, 01:39:10 PM
(http://image.gamespotcdn.net/gamespot/images/2003/pc/simcityrush4/0929/sc_screen001.jpg)
Really pretty. Having cities "growing down" the hill borders was pretty annoying. So I always start new maps with my towns away from the borders.

However, I'm not sure if vertical borders would turn out well. Think of building a tunnel next to the border.

What if only the surface were rendered over a black (or another neutral color) canvas?

Off-topic: I see a compass in Markohs' screenshot. I'd like to see one implemented in Simutrans, since I rotate the map a lot and get lost. :)
Title: Re: Make world limits not forced to water level
Post by: Fabio on November 17, 2012, 11:04:39 PM
Quote from: IgorEliezer on November 17, 2012, 10:48:22 PMWhat if only the surface were rendered over a black (or another neutral color) canvas?

If walls are made on the fly, I can see use for 3 different textures: open country walls, city walls, map border walls. We have the first 2 already, a 3rd one for the border would be sensible.

Of course this could be plain black, as plain black could be the outside tiles, just up to each pakset.
Title: Re: Make world limits not forced to water level
Post by: Ashley on November 18, 2012, 01:37:06 AM
This would be a very good change - always irritated me having the edges of the map dip down to sea level.
Title: Re: Make world limits not forced to water level
Post by: treiskin on November 18, 2012, 01:43:40 AM
Mabey we should program Simutrans so it randomly generates a terrain next to the map?
Title: Re: Make world limits not forced to water level
Post by: kierongreen on November 18, 2012, 08:17:08 AM
It may be helpful to note that my new landscape code has no limits on the cliff height it will display (although there is one line of code that fixes how high a cliff you can create)...
Title: Re: Make world limits not forced to water level
Post by: prissi on November 18, 2012, 04:12:21 PM
The problem is rather that the cliffs belong to the tile in front, where the map do not have a tile in front ...
Title: Re: Make world limits not forced to water level
Post by: Markohs on January 16, 2013, 05:44:21 PM
mmm... This is my new personal project now, will help me to understand the ground and terrain code better than I do now. I think I can reuse the climate code images to generate the borders, let's see what can be done. Autogenration of slopes too. I'll leave the compass for somebody else. ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on January 22, 2013, 04:23:06 PM
Working on this, some progress already.

On of the problems that arise with this patch is that we need to add a new concept to siutrans map settings, that's the lowest allowed level on a map. Right now I just fixed it to 10 levels under sea level, but that needs more thinking.

We also need graphics for the outside area, right now I just used outside waters graphics, but it doesn't look so good.

I'll implement removing water level height on borders now, we'll see if many problems arise (tunnels will have to be checked for example).

Just a WIP screenshot, many work still to do but well, here is is.

(https://dl.dropbox.com/u/30024783/Untitled38.png)
Title: Re: Make world limits not forced to water level
Post by: An_dz on January 22, 2013, 04:45:16 PM
Amazing, it's looking very good. You're really good Markohs.
You can try with 96comic, it doesn't use water tiles for outside.
Title: Re: Make world limits not forced to water level
Post by: Markohs on January 22, 2013, 05:33:04 PM
Thx An_dz, but Dwachs and prissi work way harder than me and program better. :)

Still much work to do, but I feel this will end looking very good.

(https://dl.dropbox.com/u/30024783/Untitled39.png)
Title: Re: Make world limits not forced to water level
Post by: Fabio on January 22, 2013, 05:35:58 PM
I would see well pure black for both outside and border wall. It would also be nice to have outside layer at the same level as the main water level.
Otherwise it's outstanding!
Title: Re: Make world limits not forced to water level
Post by: greenling on January 22, 2013, 05:54:59 PM
That look cool out.
Title: Re: Make world limits not forced to water level
Post by: Markohs on January 22, 2013, 06:10:33 PM
It will be easy to switch in-game how to display the world, right now my idea is implementing it with pure colors and allow the pakset to define wich colours to use at wich depths, including the ocean color. Maybe in the future we can implement textures too, or just draw the world on black, like floating in the space, or to not draw walls at all.

The idea is looking very similar to simcity 2, but will allow customizations on each pak.
Title: Re: Make world limits not forced to water level
Post by: Markohs on January 22, 2013, 06:17:01 PM
If you look at the screenshot I posted:

(http://image.gamespotcdn.net/gamespot/images/2003/pc/simcityrush4/0929/sc_screen001.jpg)

I want to simulate the seabed like simcity does, right now simutrans paints deep waters as darker, I want to simulate that too. Water level right now, defaults to -2, that whould be shown laterally like a small depression, and when the water is even deeper, more slopes. About the ground slice as I menctioned, I'll do something similar to the current climate code that defines intervals of heights with its textures, I'll just start with colors. SC2 looks like also applies a granular texture, we'll see if we can implement that too.
Title: Re: Make world limits not forced to water level
Post by: jamespetts on January 22, 2013, 11:18:29 PM
This is a nice idea! I agree that the tiles outside the map ought to be black or some neutral colour. If you can find a way of texturing the edges to show the sea bed and different colours for different heights of water, even better!
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on January 23, 2013, 02:23:51 AM
Quote from: Markohs on January 22, 2013, 06:10:33 PMor just draw the world on black, like floating in the space, or to not draw walls at all.
That's the one I'd pick. I feel that walls would kill a bit of the "magic" in the game that makes me believe that entire world is there, at least in my sense.

I don't want to mean that I'm against, on the contrary, surely there are people that like it (that's what makes everything interesting); a "hide/show world borders" would be welcome. :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on January 23, 2013, 08:29:53 AM
yep, makes sense. I'll do it that way. :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on February 26, 2013, 05:39:33 PM
This is taking me a bit extra time than I expected, world limits to 0 was assumed in various parts of the code and required a bit extra coding, like the lower/raise tool, the drawing algorithm and more. Not far from done now, so far disabled the slopes, that need extra codingand I still I'm unsure of how to implement.

(https://dl.dropbox.com/u/30024783/Untitled46.png)
Title: Re: Make world limits not forced to water level
Post by: Fabio on February 26, 2013, 06:12:35 PM
Lovely!
Title: Re: Make world limits not forced to water level
Post by: greenling on February 26, 2013, 06:52:02 PM
Who Markohs that looks great out.
Title: Re: Make world limits not forced to water level
Post by: Sarlock on February 26, 2013, 07:55:59 PM
Excellent!  That looks fabulous!
Title: Re: Make world limits not forced to water level
Post by: Fabio on February 26, 2013, 09:11:12 PM
This would improve greatly the maps of landlocked regions of the world (e.g. The map of Czech Republic)

Next would be non-square maps, especially (or only) maps generated with heightmaps, where a special color could specify outer tiles meant to be non playable and painted black.
Title: Re: Make world limits not forced to water level
Post by: Markohs on February 26, 2013, 11:18:45 PM
That's certainly doable, but  whould need some thinking  of how to define wich tiles are playable or not, and how to expose that to the user. I also suspect there whould be people against that idea.

We'll see,let's finish this first.
Title: Re: Make world limits not forced to water level
Post by: jamespetts on February 27, 2013, 12:08:50 AM
If it is doable without too much pain, I support Fabio's idea, not least because it might (depending on how it was implemented, I suppose) allow maps with dimensions greater than those currently permitted (by allowing large dead areas, for example).
Title: Re: Make world limits not forced to water level
Post by: Markohs on February 27, 2013, 01:24:06 AM
 Maybe not so much, because the only performance acceptable solution that comes to my mind is keeping the x*y array like it's now but marking the planquadrats that are outside the map somehow. This whould ofc save memory because that positions won't generate extra data structures, but will reside memory too, even it's low.

The only way to get around this whould be using some bi-dimensional hash structure to store the tiles, to allow constant time access to the tiles, and those nodes will have to be linked also to adjacent tiles to allow for iterative map processing (or maybe not). The gaps whould in that case not ocuppy memory in that case, but will imply recoding most of the simutrans inner functions, I'm quite sure this task whould take lots and lots of coding, maybe with little advantage compared with current implementation.

Introducing this whould also create lots of problems designing how the player can activate that disabled areas for playing, to layout them (they can default to water level, shore, be random...), this has also to be implemented in the network multiplay, re-design the mini-map, the vehicles routing... It's quite a big change, and I don't personally think it's worth the work it requires, atm. I'd focus other aspects of the game that need to be improved imho.

Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on February 27, 2013, 02:39:58 AM
Excellent!  8)

What about rivers that end at the map limits? I guess, with this new feature, rivers would be easier to be extended if the map is enlarged.

And sloped world limits would be for those players that don't want to enlarge the map, in this case the "Enlarge map" tool would be disabled.
Title: Re: Make world limits not forced to water level
Post by: Markohs on February 27, 2013, 10:52:54 PM
I post the WIP patch here for the rest of the coders to make any comments they find necessary.

All code is dirty and non optimized, and uncomplete, the only tool that can deal with borders is the raise tool, lower is not implemented still. It doesn't show world slopes neither, still needs implementation. Paining background black like we do on underground mode renders a better result, bur forces a complete screen flush each frame, and that has very bad performance . I'm posting it mainly for kierongreen to examine because it's related to his double height patch and we need to reach a consensus. And all coders interested ofc.

There were two ways to implement this, making raise/lower tools able to raise corner1, corner2 and corner3, not only corner4, or adding a row of vitrual tiles on the edge of the map, so you could raise the grid interacting with them. I chosed the first option. I also had to extend hang_t with values to nw,ne,sw and se, to indicate wich corner was to be interacted (to be able to compare to get_grund_hang()) . This decisions might have been bad decisions, any comment is welcome.

Mind it's WIP, I know many routines are not needed and are bad quality, I just need constructive comments of what you find important to consider. I implemented this without DOUBLE_GROUNDS, I hope my implementation is compatible with it.

I attach the executable for anyone to be able to test it. Please have in mind the program can crash at any moment, backup your savegames first please, I'm not responsable of any damage to them. :)

patch (https://dl.dropbox.com/u/30024783/landscape-6.patch) and executable (https://dl.dropbox.com/u/30024783/Simutrans_landscape.exe).
Title: Re: Make world limits not forced to water level
Post by: Markohs on February 28, 2013, 03:42:05 PM
New version of the patch (https://dl.dropbox.com/u/30024783/landscape-9.patch), and executable (https://dl.dropbox.com/u/30024783/Simutrans_landscape.exe), this is way cleaner. If you want to make any comment please do the sooner the better, before I write more code so I don't need to change so much. This one is much cleaner code.

Tried to change the code so it doesn't affect DOUBLE_GROUNDS too much, I assumed using the lookup_hgt was a better option than trying to get the heights manipulating hoehe and hangs. The part I'm not sure can coexist with kieron's code is:


        const hang_t::typ corner_to_raise = corner_to_operate(pos);

        const sint16 x = gr->get_pos().x;
        const sint16 y = gr->get_pos().y;
        const sint8 hgt = lookup_hgt(pos);

        const sint8 hsw = hgt + corner1(corner_to_raise);
        const sint8 hse = hgt + corner2(corner_to_raise);
        const sint8 hne = hgt + corner3(corner_to_raise);
        const sint8 hnw = hgt + corner4(corner_to_raise);


Right now corner_to_operate is:


    enum _corners {
        corner_west = 1,
        corner_south = 2,
        corner_east = 4,
        corner_north = 8
    };


Does a equivalent definition for double_grounds exists?
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 01, 2013, 05:49:48 PM
New version of the executable (https://dl.dropbox.com/u/30024783/Simutrans_landscape.exe) and patch (https://dl.dropbox.com/u/30024783/landscape-11.patch).

Enlarge map should work now and render an acceptable result, but still working on how to make it better.

Basic code is finished, I'll implement the world slopes as next step. Bug reports and comments welcome.
Title: Re: Make world limits not forced to water level
Post by: Yona-TYT on March 01, 2013, 06:28:25 PM
I test it immediately ;)
Title: Re: Make world limits not forced to water level
Post by: Ters on March 01, 2013, 06:58:27 PM
I think it looks good enough as it is. The complete world flush might be more important than walls, unless you fixed it already.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on March 02, 2013, 08:02:29 PM
Just to say I am following this, but I still have no internet access so can't see this patch in action let alone get it to work with double heights. Don't worry though, once this is in trunk, and I have internet access I'll update the double height patch :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 04, 2013, 12:49:14 PM
Okay, kieron. :)

Yea, think so, Ters, I'll just flush screen black and include it do SVN when the release is over.

New version (https://dl.dropbox.com/u/30024783/landscape-12.patch), not much changes, but this patch exposed the factory creation tool didn't check for the chosen grounds being inside map limits properly, it relied for the water to constrict factories in buildable places.

Same for roundabouts, the algorithm that built them tried to build roads around them, and now that algorithm might try to build outside map too.

Fixed, there might be more bugs.
Title: Re: Make world limits not forced to water level
Post by: Sybill on March 04, 2013, 07:33:46 PM
Hi, I tried your patch and it looks nice!
I still get graphic errors on the front sides when scrolling, but I suppose that's because it is not finished yet.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 05, 2013, 01:48:08 AM
thanks for trying it Sybill. :)

Yes, the clipping errors on from will disapear soon. :)
Title: Re: Make world limits not forced to water level
Post by: Yona-TYT on March 08, 2013, 01:10:57 AM

stops working when I generate a map in the "pak128 2.2.0 nightly"


Size : "1024x1024"
Water level:  -10
Mountain height: 320
Map roughness: 7


(http://sphotos-d.ak.fbcdn.net/hphotos-ak-prn1/542777_539992956041016_1652023564_n.jpg)
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 08, 2013, 04:12:27 AM
I tried the latest build (Reply #45), but it crashes.

(http://i.imgur.com/iQeGxPc.png)
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 08, 2013, 09:43:43 AM
@Igor: Try installing http://www.microsoft.com/en-us/download/details.aspx?id=5555 (http://www.microsoft.com/en-us/download/details.aspx?id=5555) please and let me know if that fixes the problem.

@Yona: I'm aware of that problem, I'll post a new executable here soon with the crash fixed. :)

Thanks for your testing both!

EDIT: New executable  (https://dl.dropbox.com/u/30024783/Simutrans_landscape.exe)and patch (https://dl.dropbox.com/u/30024783/landscape-14.patch).

This is close to done, just needs a bit of code cleanup and fixing the bugs that might arise, plus world slopes. The background is painted in black now.

More testing welcome!
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 08, 2013, 11:05:25 AM
Two screenshots showing the map extension now respects the old part geography to the extent of possible:
(https://dl.dropbox.com/u/30024783/Untitled47.png)
(https://dl.dropbox.com/u/30024783/Untitled48.png)
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 08, 2013, 01:09:51 PM
Quote from: Markohs on March 08, 2013, 09:43:43 AM
@Igor: Try installing http://www.microsoft.com/en-us/download/details.aspx?id=5555 (http://www.microsoft.com/en-us/download/details.aspx?id=5555) please and let me know if that fixes the problem.
Sorry for bothering you. I tried to install the MSVC package and got this message:

QuotePlease resolve the following:
A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine.
I run on MSWin 64bits.

Quote from: Markohs on March 08, 2013, 11:05:25 AM
Two screenshots showing the map extension now respects the old part geography to the extent of possible:
This is amazing o.O'
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 08, 2013, 01:29:18 PM
the new executable fails too?
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 08, 2013, 02:12:23 PM
Yes.
Title: Re: Make world limits not forced to water level
Post by: Isaac Eiland-Hall on March 08, 2013, 02:46:08 PM
Absolutely stunning. I love it! Now my only problem is I'm spoiled on Minecraft auto-expanding the world! hehe. But that's 100% impractical for Simutrans. :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 08, 2013, 02:51:07 PM
mmm... a bit clueless of what can be the problem, I think moving the msvcr80.dll file you have in the same directory to elsewere and trying to start the program can maybe solve the problem. I don't really know where the problem is. Another option whould be compiling this with MinGW like the niglies are, but I don't have the enviroment installed here in this computer, I'll try it later when I get to my other computer.

The only dll's that I have in that dir are https://dl.dropbox.com/u/30024783/pthreadGC2.dll (https://dl.dropbox.com/u/30024783/pthreadGC2.dll) and https://dl.dropbox.com/u/30024783/pthreadVC2.dll (https://dl.dropbox.com/u/30024783/pthreadVC2.dll) , even SDL.dll is not necessary. because they are statically linked I think in my enviroment. But I'm not really sure, I have so many build enviroments that sometimes I don't really know wich dependencies I'm adding. ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 08, 2013, 02:53:29 PM
Quote from: Isaac.Eiland-Hall on March 08, 2013, 02:46:08 PM
Absolutely stunning. I love it! Now my only problem is I'm spoiled on Minecraft auto-expanding the world! hehe. But that's 100% impractical for Simutrans. :)

Who knows wich cool features we can add to simutrans in the future, we'll see. ;)
Title: Re: Make world limits not forced to water level
Post by: An_dz on March 08, 2013, 03:12:32 PM
This is just amazing. Anything can be built on the corners and the terraforming tools work perfectly. The world expansion also works great. I've created myself a lake on the corner and when I expanded it, the lake was expanded a little too.

Quote from: Markohs on March 08, 2013, 02:53:29 PM
Quote from: Isaac.Eiland-Hall on March 08, 2013, 02:46:08 PM
Absolutely stunning. I love it! Now my only problem is I'm spoiled on Minecraft auto-expanding the world! hehe. But that's 100% impractical for Simutrans. :)
Who knows wich cool features we can add to simutrans in the future, we'll see. ;)
SimCity 2013 region play? :)
Title: Re: Make world limits not forced to water level
Post by: jamespetts on March 08, 2013, 03:33:25 PM
Quote from: An_dz on March 08, 2013, 03:12:32 PM
SimCity 2013 region play? :)

We can do better than that. Our servers work most of the time, and we have synchroneous multiplayer.
Title: Re: Make world limits not forced to water level
Post by: ӔO on March 08, 2013, 04:22:28 PM
Excellent work, now mountainous maps will have mountainous perimeters :D
Title: Re: Make world limits not forced to water level
Post by: Sarlock on March 08, 2013, 04:54:37 PM
Wow... this is truly wonderful.  When I get a few spare moments, I'll test it out.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 08, 2013, 05:13:43 PM
Thanks for your comments guys, another SS:
(https://dl.dropbox.com/u/30024783/Untitled49.png)
Title: Re: Make world limits not forced to water level
Post by: jamespetts on March 08, 2013, 05:22:29 PM
Ohh, I do like the edging. That is very nice.
Title: Re: Make world limits not forced to water level
Post by: greenling on March 08, 2013, 06:29:16 PM
Hello Markohs
The photo looks very good out!
Title: Re: Make world limits not forced to water level
Post by: Isaac Eiland-Hall on March 09, 2013, 12:14:17 AM
Oh, the edging is VERY fantastic. Makes the world feel like it has depth. :)
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 09, 2013, 03:40:47 AM
Quote from: Isaac.Eiland-Hall on March 08, 2013, 02:46:08 PM
But that's 100% impractical for Simutrans. :)
I have the feeling that it's not sooo true. Maybe...

Simutrans already uses some kind of seed number; the terrain can be generated upon map creation and extended manually by using map editing tools. The map could be expanded as you pan it... I don't know how Simutrans would handle non-rectangular maps. In Minecraft, the map is extended by adding 16x16x256-meter lots of terrain (a.k.a. chunks (http://www.minecraftwiki.net/wiki/Chunk)) as the player walks, the map can be larger than Earth's surface, even so only the visible chunks (those that the player can see) are loaded by the game -- it's a quite smart way of saving computer resources.

Quote from: Markohs on March 08, 2013, 05:13:43 PM
Thanks for your comments guys, another SS:
lalalah... I has a screen too... 8)

(http://simutrans-germany.com/files/upload/Simutrans+Minecraft.png)

Anyway, it's marvelous.
Title: Re: Make world limits not forced to water level
Post by: Isaac Eiland-Hall on March 09, 2013, 06:36:10 AM
Now, now, I already want SimCity in my Simutrans... having Minecraft in my Simutrans would be just....

I'd never leave the house. Ever! :)
Title: Re: Make world limits not forced to water level
Post by: jamespetts on March 09, 2013, 11:37:41 AM
Quote from: Isaac.Eiland-Hall on March 09, 2013, 06:36:10 AM
Now, now, I already want SimCity in my Simutrans...

You might be interested in the city growth related ideas on this (http://forum.simutrans.com/index.php?topic=11476.0) thread.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 10, 2013, 11:44:10 PM
For those who want to know how I did that montage:

(http://simutrans-germany.com/files/upload/Simu_MC-PaintNET.png)
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 11, 2013, 12:15:07 AM
it's actually a good idea, the problem is the random component on the pattern, I'll see what can I implement, have something almost finished.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 11, 2013, 01:44:33 AM
^ You know I was kidding, don't ya? Some of us play Minecraft and these mash-ups are kind of inevitable. :D

If you are going to implement some kind of pattern, it doesn't need to look exactly like that nor does it need to have those random generated caves shown in my montage. These caves have a purpose in Minecraft, in Simutrans they would look somewhat out of place. Players would wonder "what those thingies are doing there?". The simpler, the best.

For me, a flat dark grey with brownish borders and being able to see the depth of water masses would be enough and better fitting.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 11, 2013, 02:10:00 AM
Yes, I know you are kidding. ;)

But the thing it's that adding some variety to the slope is one thing I was thinking of, because I'd like to add soemthing sightly better than the image your showed. In fact, now sea can be deeper so we can have even deep water, so more slopes are needed there. Soon I'll have some SS to post here so you can all give your opinion. :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 11, 2013, 10:47:37 AM
Btw, wich is the program you screenshoted, Igor, Minecraft? Where can I get it? I'd like to drag some info about it.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 11, 2013, 11:33:14 AM
The screenshot I took is not from the actual game, it's a map render obtained through a 3rd party tool. Wait, let me explain each part. ^^'

Minecraft is a 3D, 1st person, sandbox construction game where players mine resources (mainly ores) and build anything such as farms, machinery, rail tracks, towns or whatever, and explore procedurally generated environments made entirely of blocks, pretty much like playing Lego, but inside it a là Lost series (after 10 minutes playing the game you'll understand the "Lost series" part).

Purchase: https://www.minecraft.net/ (https://www.minecraft.net/)
Wiki: http://www.minecraftwiki.net/ (http://www.minecraftwiki.net/)
A sample of "1st day" in Minecraft: https://www.youtube.com/watch?v=v41aZQhOcfI (https://www.youtube.com/watch?v=v41aZQhOcfI)

The map render is made with a tool, Cartograph G. Once you have created a world in Minecraft and explored it a bit, you can render top-view and isometric maps of your worlds.

Download: http://www.minecraftforum.net/topic/153066-cartograph-g-map-your-world-minecraft-14/ (http://www.minecraftforum.net/topic/153066-cartograph-g-map-your-world-minecraft-14/)

It's possible to get the source-code of the game and give a look in (programed in Java). The company that develops the game doesn't mind about it much -- as long as you don't build and publish "parallel" versions of Minecraft -- they're pretty open-minded, since it helps fan-coders to make modifications and tools for the game and spread the game even more.
Title: Re: Make world limits not forced to water level
Post by: almaf on March 11, 2013, 01:52:20 PM
Quote from: IgorEliezer on March 11, 2013, 01:44:33 AM
These caves have a purpose in Minecraft, in Simutrans they would look somewhat out of place. Players would wonder "what those thingies are doing there?". The simpler, the best.

I remember some discussion here about coal mines, iron ore mines, linked to the map (real mines from beneath the earth). Perhaps, this Minecraft style, is the way to add some "real" coal mines to Simutrans.
Title: Re: Make world limits not forced to water level
Post by: Isaac Eiland-Hall on March 12, 2013, 04:16:09 AM
In Minecraft, there are small seams of coal and iron - very small and frequent. It's not actually a good model to copy, although some inspiration might work.

There is the concept of biomes - different types of terrain. These are mathematically computated such that given a particular seed, consistent maps are generated (like maps in simutrans). The main problem right now is that there are a number of different biomes - from jungle to desert to forest to taiga (winter snow forest), and these all generate in patches. Well, that's not the problem; the problem is that they are all randomly mixed. So jungle can border taiga, for example... and desert next to forest.

So, that being said - if there was a way to automatically generate a more logical dispersion... we could have that in Simutrans - snow at some latitudes; and biomes scattered around; some mountainous, some plains; some with more rivers; some with more trees; and below them, some with coal seams and iron ore seams....

...but it would be a complete rewrite of how maps work, and so many gotchas - how to handle expanding maps, for one example.

But it also might be awesome. heh
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 12, 2013, 05:01:41 AM
Quote from: almaf on March 11, 2013, 01:52:20 PM
I remember some discussion here about coal mines, iron ore mines, linked to the map (real mines from beneath the earth). Perhaps, this Minecraft style, is the way to add some "real" coal mines to Simutrans.
The discussion that I can recall was about the position of the mines on the map. For example, coal mines would be generated according to the climate, proximity to rivers, topography etc... I think it's pretty sensible for Simutrans. In Minecraft, ores are generated according to the depth (the rarest, the deepest) and biome. Coal can be found anywhere and at any depth; iron can be found anywhere under sea level; emerald anywhere in the deepest layers and at any depth within mountainous biomes, and so on.

The thing about "real" coal mines is that, the focus of the game is transportation, I don't think the someone would also want to manage a mine or any factory of the game too. The factories pretty much put their goods in their yards and expect you (the transport company) to transport them.

Quote from: Isaac.Eiland-Hall on March 12, 2013, 04:16:09 AMThere is the concept of biomes - different types of terrain. These are mathematically computated such that given a particular seed, consistent maps are generated (like maps in simutrans).
(About biomes in MC: http://www.minecraftwiki.net/wiki/Biomes)

If someone who doesn't own Minecraft yet but wants to mess around with how Minecraft maps are generated, there's a little tool that can "preview" maps, AMIDST (http://www.minecraftforum.net/topic/626786-v2042-amidst-strongholds-village-biome-ect-finder-now-with-witch-huts/).

(http://i.imgur.com/o4ICsK0.png)

( :warning: SPOILER :warning: If you're a Minecraft player, don't use it on your world if you don't want to spoil it. :warning: SPOILER :warning: )

It's just a little EXE that doesn't require the game installed. Once you've downloaded this tool, double click the EXE, go to File > New > From Seed. Type anything; then any world type, a map will be generated out of the seed you typed. The map can extend up to 60,000,000 meters large... if you're deadly bored.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 18, 2013, 12:09:47 PM
 Since we got a release today finished, I commited the patch to SVN, next nightly will have it already.

Visuals for world slopes are not implemented in the commited version, just black background. It also causes a savegame version step since saved games will not display properly in previous versions.

Visuals for the world slopes will come next, testing is welcome.


Once kierongreen has time to review his double height patch to make int compatible with this, I'll make the necessary changes for it, ofc. ATM this patch is incompatible with double heights.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on March 18, 2013, 07:01:25 PM
Looks good so far! I took the freedom to wipe out some dead code.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 18, 2013, 10:06:20 PM
I see, thx Dwachs! :)
Title: Re: Make world limits not forced to water level
Post by: prissi on March 18, 2013, 10:43:53 PM
Wouldn't it make sense to terminate the for conditions now earlier in simview. It would save looking up nonexisting tiles, since there will be nothing drawn anyway.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 18, 2013, 10:58:21 PM
I don't know if I understand you fully on "looking up nonexisting tiles", on my secound update I changed it back to grundwasser level.

Anyway if you see anything worng, just change it as you feel, I'll just focus displaying world slopes now (I'll make it optional) and fixing any bugs that might arise and you rest of developers don't catch.

What needs to be solved is welt->get_minimumheight() and get_maximimheight(). We can maybe allow the player/pak creator to set that values. I'm unsure of how to implement it, if you want to change it, do it.

Go ahead, change it if you want. :)
Title: Re: Make world limits not forced to water level
Post by: prissi on March 18, 2013, 11:18:29 PM
Sorry, I will not be able to dig through such a patch so quickly. I mean in simview, you iterate over tiles in lines. However, as soon you reach the right border, no further tiles will appear and you can go to the next row.

Furthermore, if the skip condition never occurs, no need for drawing the black area around at all. Both should not be very difficult to implement and could improve drawing performance.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on March 19, 2013, 07:28:21 AM
The redraw-black part could be implemented as follows:
-- The ground tiles at the north and west edge draw the region above them on screen black.
-- The ground tiles at south and east edge do the same for the region below them
-- The ground tiles at the north-east and south-west corner draw the screen right and left of them black, respectively.

This could be done in simview / display_region.

For underground mode, there is no such simple receipt to black out parts of the screen.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on March 19, 2013, 07:49:20 AM
Setting the entire screen to be black is quicker than painting individual black tiles if the area is more than a handful of tiles .
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 19, 2013, 10:52:52 PM
 The algorithm is not trivial because it needs to fill a diagonal zone on screen and I doubt its performance whould be good. Anyway it would be better than this full screen darkening since most of the time the player is not on the edges of the map, I guess, and this new algorithm should not impact performance.

I wish there was some way to clear screen in an instant like glClear (http://www.opengl.org/sdk/docs/man/xhtml/glClear.xml) does, OpenGL and Direct3D clear screen before each frame and draws afterwards. Maybe there is some way to do this in the Windows and Linux backends, that would solve our problems. I just need to clear the buffer in constant time, I'll investigate if this is possible.


Edit: maybe we can use memset ? Maybe that's fast enough.
Title: Re: Make world limits not forced to water level
Post by: Ters on March 20, 2013, 06:11:00 AM
Diagonal zones? Maybe you misunderstood Dwachs, like I first did. (Unless I removed the problem by misunderstanding the second time.)

But I might have an improvement on Dwachs' idea, if the screen position of the northwestern and southeastern corner of the map can be found. Filling vertical regions is not as fast as horizontal region, but if Simutrans could clear the entire regions, from left screen edge to right screen edge down to the tip of the uppermost tile (northwestern corner), and similarly below the tip of the lowermost tile (southeastern corner), one could then use Dwachs' third rule to clear the rest, all using horizontal lines. One would however need to consider all tiles on the edge of the map, unless one it is possible to find and use the uppermost and lowermost visible tile.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 20, 2013, 08:23:17 AM
did not read dwachs post carefully enough. it makes sense, I'll try it that way.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 20, 2013, 12:31:46 PM
I've begin to implement it and to speed up the test to check if the grund_t item is in a border position I've think caching this information in a member variable, and updating it on map redimensioning, if not I'd have need to do a test each time a tile is drawn:


   is_border = pos.x == 0 || pos.x == welt->get_size().x || pos.y == 0 || pos.y == welt->get_size().y;


What do you think?

I've also thinik of making this a direction mask to indicate in wich of the dimensions this tile is a border, because it can be of two dimensions, NW,NE,SW and SE.

From this is easy, just write black to the corresponding direction as Dwachs/Ters pointed out (depends of the hang, but it's doable easy), and the normal algorithm whould just do an extra test for every displayed tile, I guess this will imply no performance diference. And it's only 8 bits extra for each grund_t in map.
Title: Re: Make world limits not forced to water level
Post by: Ters on March 20, 2013, 03:58:28 PM
It might be not just 8 bit due to alignment.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on March 20, 2013, 04:22:17 PM
Imho it is not necessary to store this information. If you like, one bit is enough: tile is on boundary or not. Then one can determine the precise boundary by looking at the position.
Title: Re: Make world limits not forced to water level
Post by: Ters on March 20, 2013, 05:48:23 PM
My impression from the latest performance problem reports is that Simutrans isn't exhausting the CPU with instructions, but possibly with data.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 20, 2013, 05:59:16 PM
well, a boolean will prolly have a size of 8 bits too at minimum I guess. It's not so important through, I can change it. What's not working so good with the algorithm is:

(https://dl.dropbox.com/u/30024783/Untitled50.png)

I'll have to detect this situation too, this is not so easy as it looks.

Oh, I wish clearing the screen to a solid color was faster... :(
Title: Re: Make world limits not forced to water level
Post by: Ters on March 20, 2013, 06:35:59 PM
Isn't that zone point 1, second clause of Dwachs' suggestion? It is also the weak spot of my improvement, though I offer two suggestions.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 20, 2013, 07:53:49 PM
 Dwachs suggestion talks about painting vertically, I implemented it horizontally, that's the problem, I misunderstood what he said, again.

As you say, I fear vertical painting is worse performance-wise, that's what I was thinking horizontally, but that exposes the problem I screenshoted above.

I still don't understand you fully on your improvement suggestion. If I understand it correctly it will only increase performance if the NW or SW corner is on screen, rest of the cases it won't improve nothing, with overhead calculations.

Yes, you can determine easly the on-screen position of the corner tiles and know if they are inside the display or not.

What you don't know, is if those tiles will be processed, it depends if the viewport contains them or not.

Anyway I think it can cause be some problems on the edges of the screen, but this is just only a gut feel. I'll see.

Sorry, will get back to this now. :)
Title: Re: Make world limits not forced to water level
Post by: Ters on March 20, 2013, 08:37:25 PM
Above a tile, you don't need to draw vertical lines, but columns of <tile width> horizontal lines down until you reach the top of the tile. That same tile's horizontal lines will then take the rest. Similarly for the bottom. The down side is that areas will be clear twice, both by the horizontal rows and the vertical columns. I don't know if you can get into the viewport a region that is neither above/below or to the left/right of any tile. I think it might happen on very small maps and/or when zoomed far out.

That my version only offers an improvement when the NW or SE corner is in view is in a sense both right and wrong. It is true that it won't do anything if these are not in view, but in all cases, it should avoid the need to do clearing in vertical columns above/below edge tiles. However, one needs to clear to the left/right of edge tiles, even if that tile is outside the viewport horizontally. If the tile is above or below the viewport, it can be ignored. Alternatively, one must clear all lines above the uppermost visible edge tile, and below the lowermost visible edge tile. I haven't looked at the code in a while, so I don't know which, if any, solution works.
Title: Re: Make world limits not forced to water level
Post by: Fabio on March 20, 2013, 08:55:21 PM
Quote from: Markohs on March 20, 2013, 05:59:16 PM
(https://dl.dropbox.com/u/30024783/Untitled50.png)

Just my 2 cents: the scroll could be limited so that at maximum scroll a map corner lies on the window border. This would reduce cases where half or more of the window view is black. Could this speed things up somehow?
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 20, 2013, 09:28:58 PM
Naj, no need to do that, the algorithm Dwachs proposed should solve all those problems.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 22, 2013, 12:48:08 PM

(https://dl.dropbox.com/u/30024783/Untitled51.png)

The same problem arises with Dwachs implementation. Imagine the viewport is in the RED square. Only the tiles under the arrows will , from right to left be processed. Areas on the yellow part doen't have a grund_t item associated so they are skipped, but are lookuped on the algorithm.

The yellow-gray area is painted in vertical stripes by the border tiles, but... who will paint the green part?

Maybe the best option will be on camera movement checking if there will be any area of the screen off-map and activate the full screen black only when necessary. That will keep performance unaffected in the player is not looking near the world limit. If he's near the map limit he'll be affected by this 30% performance hit prissi talked about. Maybe even we can activate screen darkening just 1 frame after camera darkening, and not doing it again until the camera moves.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on March 22, 2013, 01:14:22 PM
This part has to be drawn in the routines of simview.cc directly. It should be possible to  figure out the position of the green stripe on the screen.  ???
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 22, 2013, 01:33:25 PM
 What do you think of my idea of just clear the screen black on a camera movement? I that should solve all problems and has even better performance.

Only problematic when movable objects higher than a tile (planes maybe) or high buildings (we could maybe draw just one tile black on top of border tiles. On a gui element movement we should force screen black also.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 22, 2013, 04:57:54 PM
Okay, decided to implement it like this:

1) a welt->set_dirty() will trigger a whole screen clear in black, *JUST ON NEXT FRAME*, this happens on camera movement and zoom change, so it will only impact on the performance of one frame. This can be optimising checking further if the four corners of the screen are inside of the map or not, but the performance gain already is huge (will only trigger unnecessary redraws when following vehicles..
2) West and north tiles display a vertical column of wide/2 of black, for the rare case of high buildings or planes being just on the edge of the map can be over the background.
3) Right now I tag all border tiles even the N  and W ones are necessary. This is intended, S and E ones will have world slopes that I'm implementing on a separate patch.
4) Back background now I'd like to give the chance to the user/pak creator to change the desired color. I'd also like to allow him to use a image to be repeated, this will be implemented also if you don't mind.
5) I added some extra variables (a member bvariable in the view for example) that are not necessary, I'll clean up the code when I have this working.
6) the threaded version of simutrans triggers an artifact in the merge of the threads drawing area, I'm not sure of how to eliminate it atm, any idea? in the image I posted you can see it in yellow, not far from the middle of the screen.

Note: The alrogithm Dwachs and Ters posposed whould have been able to do the same, but at the end I decided to implement it like this because:

1) It's simplier.
2) Saves memory I/O bandwith.
3) Doesn't require much modifications in the display code, so should be easier to deal with.

To debug this easier borders draw in Yellow and red now, this will ofc be fixed.

Do you want me to discuss this in programmer's corner or we are ok here?

The patch  (https://dl.dropbox.com/u/30024783/landscape-performance-1.patch)and a image:

(https://dl.dropbox.com/u/30024783/Untitled52.png)
Title: Re: Make world limits not forced to water level
Post by: Dwachs on March 22, 2013, 06:24:15 PM
I do not like that you add a member variable to grund_t. It will make this structure at least 4 bytes larger (due to memory alignment). The check for border can very well be done in any of the display-methods on the fly.

About set-dirty: What happens if there are gui windows moving in the black area?

Threaded artifacts: no idea.

Edit: The hang_t::corner_* enums are misleading: It should be north-east, north-west, se, sw instead of directions n/s/e/w.

Edit2: The dirty flag of the ground tile has to be set after drawing the border regions. Then the artefacts will go away.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 23, 2013, 05:13:03 AM
Quote from: Dwachs on March 22, 2013, 06:24:15 PM
I do not like that you add a member variable to grund_t. It will make this structure at least 4 bytes larger (due to memory alignment). The check for border can very well be done in any of the display-methods on the fly.

I understand your reasons, but do you think expanding grund_t::flags from 8-bit to a 16-bit value can maybe be an acceptable compromise? I just need one bit, to indicate it's border, that's 1 operation per visible tile compared to 4 checks per tile, don't you think the trade off can be worth?

Anyway I can do it on the fly, of course. Maybe the difference it's not so big.

Quote from: Dwachs on March 22, 2013, 06:24:15 PM
About set-dirty: What happens if there are gui windows moving in the black area?

Oh right, fixing it, won't affect performance so much.

Quote from: Dwachs on March 22, 2013, 06:24:15 PM
Threaded artifacts: no idea.

Edit: The hang_t::corner_* enums are misleading: It should be north-east, north-west, se, sw instead of directions n/s/e/w.

Ok, changing them.

Quote from: Dwachs on March 22, 2013, 06:24:15 PM
Edit2: The dirty flag of the ground tile has to be set after drawing the border regions. Then the artefacts will go away.

Ok, changing this too. Thank you!
Title: Re: Make world limits not forced to water level
Post by: Ters on March 23, 2013, 08:26:15 AM
I'd go with 4 checks per tile over 1 check per tile plus 1 byte per tile until proven that it's a bottleneck. CPUs are fast, memory access is not.

grund_t is currently 20 bytes on a 32-bit architecture, which means it's perfectly aligned on a word boundary. Any new field, of word size (32-bit) or less, will bump this up to effectively 24. (On a 64-bit architecture, grund_t should be 28 bytes, which means it's got 4 unused bytes until the next word boundary at 32.)
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on March 27, 2013, 02:57:09 AM
(http://i.imgur.com/EcYiW11.jpg)

Just tried the latest nightly.

<3

As you can see, I liked it.

I noticed two things: some trees seem to be hanging off the border; if I click on the black area, the cursor can still edit/select elements of the map.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 27, 2013, 07:31:57 AM
Hi, thanks for trying it out. :)

Elements that span the lower border of the tile will be difficult to fix, I can paint it black (http://www.youtube.com/watch?v=9Uj9sduV3k8) everything that is beyond the border, but that will not be perfect neither... I'll think what can be done. :)


Wich tool are you using when selecting items in the berder tiles? upper/raise grid tool is allowed to work on borders, other tools should not be able to interact there.
Title: Re: Make world limits not forced to water level
Post by: Ters on March 27, 2013, 07:39:51 AM
I seem to remember a topic about trees and their offsets. It is probably an error in the pak, and doesn't look good when overlapping other things throughout the map either.
Title: Re: Make world limits not forced to water level
Post by: VS on March 27, 2013, 09:03:05 AM
Yes, tree offsets are the real problem here. The map edge is not responsible for that :)
Title: Re: Make world limits not forced to water level
Post by: greenling on March 27, 2013, 05:27:27 PM
Hello
The photo how igoreliezer be post have looks very good out.
Title: Re: Make world limits not forced to water level
Post by: Sarlock on March 27, 2013, 06:27:11 PM
There is a certain amount of random variability to the placement of trees, away from its original offset position.  That's why trees can be sitting in the water just off of the beach, etc.  It's a very minor cosmetic thing, I don't think it's worth trying to fix it.

Progress so far on the edges looks great!  Can't wait to see the added effect of the ground/water to it.  Great job, thusfar, Markohs.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on March 27, 2013, 06:39:22 PM
Quote from: Sarlock on March 27, 2013, 06:27:11 PM
There is a certain amount of random variability to the placement of trees, away from its original offset position.  That's why trees can be sitting in the water just off of the beach, etc.  It's a very minor cosmetic thing, I don't think it's worth trying to fix it.
If the image of the tree in the pak is centered within the tile, then the tree should not be outside of the tile.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 27, 2013, 06:59:52 PM
Quote from: Sarlock on March 27, 2013, 06:27:11 PM
Progress so far on the edges looks great!  Can't wait to see the added effect of the ground/water to it.  Great job, thusfar, Markohs.

thx sharlock, have it half implemented, but first I had to change some techical details dwachs and prissi ponted me to. soon new features will come.  :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 28, 2013, 01:58:49 AM
Dwachs, the artifacts keep coming only when simple_drawing is activated. This is very strange, since clearing the whole screen black works perfectly...


But if in grund_t::display_if_visible I set grund_t::set_flag(dirty) on the tiles I've drawn background, the artifacts come. Threaded, near the junction zone.


Had to remove the const property from grund_t::display_if_visible for this reason too, btw.


The patch here (https://dl.dropbox.com/u/30024783/landscape-performance-2.patch). If anyone has any idea of what might it be, just tell me. :)
Title: Re: Make world limits not forced to water level
Post by: TurfIt on March 28, 2013, 02:46:30 AM
Are there still artifacts single threaded? Last I looked, the tile_dirty stuff didn't appear to have the required mutexes in place... I ignored it assuming it was an intentional tradeoff speed vs glitches.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 28, 2013, 03:16:38 AM
Just tested it and no, they just show in the threaded version.

When I paint the background zones I set them dirty, it might be related to what you say.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on March 30, 2013, 03:54:49 PM
It seems that replacing display_fillbox_wh with display_fillbox_wh_clip in grund_t::display_border fixes the stripes issue. These stripes are produced by simview.cc line 221, and draw into regions that are already fully drawn.
Title: Re: Make world limits not forced to water level
Post by: Markohs on March 30, 2013, 04:09:04 PM
oooh right how could I be so stupid. This also fixes another problems I had detected. Thanks a lot Dwachs!!!!
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 01, 2013, 06:48:17 PM
Another screenshot of the work in progress, getting closer to finish this. ;)


The colors and northern border is still for debug reasons, my plan is allowing the user/pak developer to tune up those details.


(https://dl.dropbox.com/u/30024783/Untitled53.png)
Title: Re: Make world limits not forced to water level
Post by: greenling on April 01, 2013, 07:20:49 PM
Who that´s looks cool out.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 01, 2013, 07:29:04 PM
And with sightly better colors, and showing it respects night colors.


Now let's deal with water and polish the code a bit. :)


NOTE: Yes, I copied simcity 4 colors, if this is any problem with copyright I'll need someone to create a gradient of colors to use it by default on simutrans. ;)


(https://dl.dropbox.com/u/30024783/Untitled54.png)


(https://dl.dropbox.com/u/30024783/Untitled55.png)
Title: Re: Make world limits not forced to water level
Post by: jamespetts on April 01, 2013, 07:39:51 PM
Very Sim City 4!
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on April 01, 2013, 08:21:25 PM
Quote from: Markohs on April 01, 2013, 07:29:04 PM
NOTE: Yes, I copied simcity 4 colors, if this is any problem with copyright I'll need someone to create a gradient of colors to use it by default on simutrans. ;)
Doing great! Really.

Are these borders procedurally generated or made of graphic tiles? I think the pak makers will feel temped to paint the graphics for the borders, but Simutrans would require a different procedure just to tile a vertical wall.

EDIT:

That's my suggestion, the simpler the better, but not sure if it turned out well.

(http://forum.simutrans.com/index.php?action=dlattach;topic=10835.0;attach=21448;image)
Title: Re: Make world limits not forced to water level
Post by: prissi on April 01, 2013, 09:13:11 PM
Peronally, I like the old eternal islands very much, which is gone anyway.

But if you do this, then the texture must properly represent water depth, which it does not. Other than that I am not caring much about ground levels.

As a sidenote: Sicne the is arbitary clipping already in place, drawing those with a single opreation should be straigth forward at least for water.
Title: Re: Make world limits not forced to water level
Post by: Fabio on April 01, 2013, 09:26:23 PM
It looks awesome! But as Prissi said water depth would still be better. Way to go!
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 01, 2013, 09:36:31 PM
Quote from: prissi on April 01, 2013, 09:13:11 PM
Peronally, I like the old eternal islands very much, which is gone anyway.

Well, nothing stops you from lowering the borders of your maps to water level, this patch just opens new possibilities.

Quote from: prissi on April 01, 2013, 09:13:11 PM
But if you do this, then the texture must properly represent water depth, which it does not. Other than that I am not caring much about ground levels.

Yes, I will do it, I'm still thinking the best way of doing it.

Quote
As a sidenote: Sicne the is arbitary clipping already in place, drawing those with a single opreation should be straigth forward at least for water.

Yes, the plan is generate all the needed images and just displaying them with clipping. Very much similar to the climate code.

Quote from: IgorEliezer on April 01, 2013, 08:21:25 PM
Doing great! Really.

Thank you. :)

Quote from: IgorEliezer on April 01, 2013, 08:21:25 PM
Are these borders procedurally generated or made of graphic tiles? I think the pak makers will feel temped to paint the graphics for the borders, but Simutrans would require a different procedure just to tile a vertical wall.

EDIT:

That's my suggestion, the simpler the better, but not sure if it turned out well.

(http://forum.simutrans.com/index.php?action=dlattach;topic=10835.0;attach=21448;image)

Well, there are various aproaches to this I've been thinking.

The current implementation, that's my first approach is giving it a list of heights and colors, and simutrans automatically generates the world slope. For water I'd do the same, but I don't really know if it will have a good look. Water gradient whould start from bottom to top.

Right now that gradiation I showed is defined like:


grad_entry gradient[] = {
   grad_entry(0,rgb(110,90,85)),
   grad_entry(10,rgb(107,88,82)),
   grad_entry(20,rgb(109,103,115)),
   grad_entry(30,rgb(138,135,142)),
   grad_entry(40,rgb(116,104,108)),
   grad_entry(50,rgb(106,107,109)),
   grad_entry(80,rgb(106,107,109)),
   grad_entry(-1,0x7FFF)
};


The idea whould be to expose that so simutrans readed that list from a .tab file in the pak directory, or something similar.

But, as you said, I think artists whould indeed be interested to paint the world stripe themselves, that can be done too, if they supply me a vertical image (actually two, one for water and another for ground), with width of half of a tile, I can generate all the required images and variations, and use them. Maybe even if we ara supplied one image multiple of half tile's width, we can span that image even longer to create more variety, and not having such repetitive patterns.

Dunno, anyone has any comment regarding this issues? I can allways implement both options and let tyhe artists decide.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on April 01, 2013, 09:49:52 PM
Quote from: prissi on April 01, 2013, 09:13:11 PM
Personally, I like the old eternal islands very much, which is gone anyway.
If there was an option as "locked" map - a map that can't be enlarged - Simutrans could force the generation of shores near the borders.

EDIT:

Other possibility would be to have a way of setting the size of landmasses (or continents) so that they would fit in the world without touching the borders, but this is a subject for landscape generation.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 01, 2013, 09:58:02 PM
A button to force map borders to water at any moment can be implemented also.

Anyway I think not much people will share prissi's nostalgia.  but who knows. it' not very hard to implement.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on April 01, 2013, 10:09:13 PM
Quote from: Markohs on April 01, 2013, 09:58:02 PMAnyway I think not much people will share prissi's nostalgia.  but who knows. it' not very hard to implement.
Haha... good. Anyway, having nostalgia sometimes is important to keep the soul of the game.

As Jamespetts said, "Very Sim City 4!" -- it's essential that a game evolve and be expanded upon in the fields which the game is meant to but not look like another game.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on April 01, 2013, 10:21:36 PM
Igor took words out of my mouth. It's why patches that make big changes are maybe best applied after discussion.
Title: Re: Make world limits not forced to water level
Post by: jamespetts on April 01, 2013, 10:26:08 PM
Nostalgia or not, and in spite of its resemblance to Sim City 4, I rather like it: it makes it much clearer than the present system what is and is not part of the buildable world, and adds an element of polish not present in the original flat version.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 01, 2013, 10:42:09 PM
Quote from: kierongreen on April 01, 2013, 10:21:36 PM
Igor took words out of my mouth. It's why patches that make big changes are maybe best applied after discussion.

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.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on April 01, 2013, 10:46:37 PM
Oh I know the problems of leaving patches open for discussion - after all some of mine have taken over 2 years to be applied to trunk!
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 01, 2013, 10:57:23 PM
Quote from: kierongreen on April 01, 2013, 10:46:37 PM
Oh I know the problems of leaving patches open for discussion - after all some of mine have taken over 2 years to be applied to trunk!

That's one of the biggest problems imho we have. Your double height patch should have been part of this game months ago imho.


After all, most of our last releases had a few bugs (some of them not so minor) too.
Title: Re: Make world limits not forced to water level
Post by: prissi on April 01, 2013, 10:58:11 PM
Please, as mentioned before, my view is clouded by nostalgica, as I was used to this since 2000 ... I might even consider adding up a setting for paks to get a landscape down to the border with old tiles. As stated before, simutrans is about freedom. Some paks like pakHD look rellay strange with black background.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 01, 2013, 10:59:22 PM
And I have no problem helping making that possible, prissi, we just need to change the background drawing part a bit.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on April 01, 2013, 11:40:22 PM
Quote from: kierongreen on April 01, 2013, 10:46:37 PMOh I know the problems of leaving patches open for discussion - after all some of mine have taken over 2 years to be applied to trunk!

Quote from: Markohs on April 01, 2013, 10:57:23 PMThat's one of the biggest problems imho we have.
That's the one of the biggest problems that a community-run project can have; people freely decide what to do with their free time and things tend to go out of control. It'd be different (better or worse) if Simutrans were developed in a company with schedules, nasty clients making pressure and a boss with a whip... *shift eyes* ... oops. What would we prefer?

If there are dents hindering the project, once in a while discuss to spot and solve the pending issues, set priorities and focus on not letting things pile up because it creates the frustration and a feeling that you are working in the darkness.
Title: Re: Make world limits not forced to water level
Post by: Yona-TYT on April 02, 2013, 02:34:04 AM

in my humble opinion, simutrans should be more open to changes.
thus simutrans will remain live by many years  :thumbsup:





Simutrans Fan page on Facebook (http://www.facebook.com/Simutrans.BLOG?)
Title: Re: Make world limits not forced to water level
Post by: Sarlock on April 02, 2013, 03:08:39 AM
It looks fabulous!

I think the overwhelming response has been positive.  When it comes to patches that make a fundamental change to the way the game is played, I certainly think that a big discussion is necessary to get a consensus (as best you can with a large, varied group) before proceeding.  This is mostly cosmetic so it is less integral and there has been ample time during the early development process to change the direction of this effort, so I wouldn't worry, Markohs :)

And it's easy enough to turn off this graphics border option with a map that descends to water level at its borders, so it's easy enough to disable.

You're so close to the finish line now, Markohs, I can't wait to see the final product.  Great work!
Title: Re: Make world limits not forced to water level
Post by: Yona-TYT on April 02, 2013, 03:24:47 AM

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 (http://www.facebook.com/Simutrans.BLOG?)
Title: Re: Make world limits not forced to water level
Post by: sdog on April 02, 2013, 03:27:55 AM
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 :-)
Title: Re: Make world limits not forced to water level
Post by: Isaac Eiland-Hall on April 02, 2013, 05:20:41 AM
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. :)
Title: Re: Make world limits not forced to water level
Post by: Ters on April 02, 2013, 05:33:45 AM
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.
Title: Re: Make world limits not forced to water level
Post by: 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.  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 :)
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on April 02, 2013, 06:47:46 AM
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!

(http://i.imgur.com/XMbJU2n.jpg)
Title: Re: Make world limits not forced to water level
Post by: kierongreen on April 02, 2013, 07:03:43 AM
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.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 02, 2013, 07:10:32 AM
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. ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 02, 2013, 01:35:07 PM
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. :)
Title: Re: Make world limits not forced to water level
Post by: 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)?
Title: Re: Make world limits not forced to water level
Post by: jamespetts on April 02, 2013, 03:10:01 PM
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...
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 02, 2013, 03:50:17 PM
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.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 02, 2013, 04:33:58 PM
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. :)
Title: Re: Make world limits not forced to water level
Post by: Sarlock on April 02, 2013, 09:20:22 PM
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.
Title: Re: Make world limits not forced to water level
Post by: prissi on April 02, 2013, 09:22:42 PM
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.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on April 03, 2013, 04:27:33 AM
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
Title: Re: Make world limits not forced to water level
Post by: Isaac Eiland-Hall on April 04, 2013, 04:05:33 AM
I've played a ~15,000-wide map -- but it was 32 tall. :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 05, 2013, 04:55:25 PM
 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.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 05, 2013, 06:03:14 PM
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.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 05, 2013, 06:46:50 PM
ok, thanks :)
Title: Re: Make world limits not forced to water level
Post by: isidoro on April 05, 2013, 11:50:45 PM
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...


Title: Re: Make world limits not forced to water level
Post by: Markohs on April 06, 2013, 03:23:59 AM
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!
Title: Re: Make world limits not forced to water level
Post by: Ters on April 06, 2013, 08:13:42 AM
I don't like a fenced in world any better than an "oceaned in" world.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 06, 2013, 10:10:55 AM
MArkohs, you could also use the original background graphics in ground.outside.pak aka grund_besch_t::ausserhalb->get_bild(hang_t::flach).
Title: Re: Make world limits not forced to water level
Post by: Ters on April 06, 2013, 02:21:35 PM
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.)
Title: Re: Make world limits not forced to water level
Post by: kierongreen on April 06, 2013, 03:31:38 PM
Something changed recently with this patch now I get some a black square area surrounding border tiles with double heights, any ideas?
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 06, 2013, 04:13:18 PM
Thx, will have a look to this issues. I think they both have easy fixes,  I'll test it with your patch, kieron
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 07, 2013, 11:54:29 PM
I guess you are refering to this, no kieron?


(https://dl.dropbox.com/u/30024783/Untitled60.png)
Title: Re: Make world limits not forced to water level
Post by: kierongreen on April 08, 2013, 12:36:52 AM
Correct
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 08, 2013, 04:42:19 PM
(https://dl.dropbox.com/u/30024783/Untitled61.png)

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
Title: Re: Make world limits not forced to water level
Post by: Sarlock on April 09, 2013, 12:53:24 AM
I like the grey, it's easy on the eyes.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 11, 2013, 11:42:14 AM
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.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 12, 2013, 03:06:40 PM
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. ;)

(https://dl.dropboxusercontent.com/u/30024783/Untitled62.png)

The original image is:

(https://dl.dropboxusercontent.com/u/30024783/background.png)

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.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 13, 2013, 03:06:02 PM
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?
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 13, 2013, 05:38:48 PM
I'll look into it, I experienced that bug once but thought was something on my new code
Title: Re: Make world limits not forced to water level
Post by: TurfIt on April 13, 2013, 07:15:35 PM
What do you mean by setting background dirty whenever a tooltip is drawn? Forcing a complete redraw every frame when a tooltip is onscreen?

IMHO, redrawing the whole screen should be the absolute last resort. Doing so is the cause of the huge slowdown with the use_hw doublebuffering when no hardware support is exposed by the driver. The dirty tile update mechanism is vital to good performance, and needs to be extended to handle this new background mechanism IMO...

p.s.  if r6451 is meant to fix this, the game crashes immediately upon choosing a pak.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 13, 2013, 07:23:06 PM
wl->set_background_dirty(); need to be protected as

if(wl)
wl->set_dirty();

Because wl can be NULL at start


EDIT: Also


void win_poll_event(event_t* const ev)
{
display_poll_event(ev);
// main window resized
if(ev->ev_class==EVENT_SYSTEM  &&  ev->ev_code==SYSTEM_RESIZE) {
// main window resized
simgraph_resize( ev->mx, ev->my );
ticker::redraw_ticker();
wl->set_background_dirty();
ev->ev_class = EVENT_NONE;
}
}



You changed wl->set_dirty() to set_background_dirty(), I think this is not a good change, wl->set_dirty already forces a background_dirty() too.



void karte_ansicht_t::display(bool force_dirty)
...

// redraw everything?
force_dirty = force_dirty || welt->is_dirty();
welt->unset_dirty();
if(force_dirty) {
mark_rect_dirty_wc( 0, 0, display_get_width(), display_get_height() );
welt->set_background_dirty();
force_dirty = false;
}



I'll revert that change if you don't mind, I think it's incorrect.


I commited this as 6452, segfaults should have disappeared.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 13, 2013, 10:20:17 PM
Quote from: Dwachs on April 13, 2013, 03:06:02 PM
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?

Mmm... having a look to this now and I can't reproduce it.

I paint the "safety" border background with the dirty flag *OFF*, I thought that way only the really needed part (overwritten) will be flushed to screen, saving some performance, notice in grund_t::display_border the calls to display_fillbox_wh_clip have dirty set to false.

wich backend experiences the problems? I use Windows GDI (2 threads) and all shows perfect, when scrolling and when not.


This shows good:
 


(https://dl.dropboxusercontent.com/u/30024783/Untitled63.png)
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 13, 2013, 10:22:02 PM
Quote from: TurfIt on April 13, 2013, 07:15:35 PM
What do you mean by setting background dirty whenever a tooltip is drawn? Forcing a complete redraw every frame when a tooltip is onscreen?

IMHO, redrawing the whole screen should be the absolute last resort. Doing so is the cause of the huge slowdown with the use_hw doublebuffering when no hardware support is exposed by the driver.

Agree, that's why I made the optimization patch.

Quote
The dirty tile update mechanism is vital to good performance, and needs to be extended to handle this new background mechanism IMO...

p.s.  if r6451 is meant to fix this, the game crashes immediately upon choosing a pak.


I agree, but doesn't the current patch handles this already? What do you suggest?
Title: Re: Make world limits not forced to water level
Post by: TurfIt on April 13, 2013, 11:33:53 PM
I'm not really sure what the current state handles. Unfortunately I didn't have a chance to really follow development of this. It just seems like there's an awful lot of set_background_dirty() calls with the resulting fullscreen flush required. Are individual rectangles in the background being marked dirty, or just the whole thing?

Also, is the Simcity 4 view still possible? i.e. with the border showing the underground gradient. I somewhat like that better than the floating world.  And, is it possible to restore the force to waterlevel function (as an option)? Along with the old tiled display for out of bounds? I also quite like the 'old' way with the whole world shown and surrounded by dangerous shoals... beware, here be dragons!
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 13, 2013, 11:45:53 PM
Quote from: TurfIt on April 13, 2013, 11:33:53 PM
I'm not really sure what the current state handles. Unfortunately I didn't have a chance to really follow development of this. It just seems like there's an awful lot of set_background_dirty() calls with the resulting fullscreen flush required. Are individual rectangles in the background being marked dirty, or just the whole thing?

set_background_dirty()  forces  a full screen background redraw *ONLY* if it's going to be visible (the full screen is covered by tiles). That was the optimization. So, following a train (for example) won't flush screen if it's not really needed.

This background redraw *DOESN'T* mark the screen dirty. It's the world that marks screen dirty, as it was before, *BUT* all border tiles are marked as dirty each frame. So those tiles allways flush their section of screen.

But it's not the whole screen.

Quote from: TurfIt on April 13, 2013, 11:33:53 PM
Also, is the Simcity 4 view still possible? i.e. with the border showing the underground gradient. I somewhat like that better than the floating world.  And, is it possible to restore the force to waterlevel function (as an option)? Along with the old tiled display for out of bounds? I also quite like the 'old' way with the whole world shown and surrounded by dangerous shoals... beware, here be dragons!

Yes, all the posibilities you menction are possible and will be implemented. I just want to make sure what's already in trunk is stable enough to keep adding things. :)
Title: Re: Make world limits not forced to water level
Post by: TurfIt on April 14, 2013, 12:07:46 AM
Hmmm. I really need to look more into the dirty tile stuff before I can comment more...

As for the tooltip artifacts, I can duplicate that - SDL backend didn't try others. Note tooltips, not labels as shown in your screenshots.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 14, 2013, 12:30:24 AM
oooh I see, my bad, thinking how to deal with this then, there must be a solution to it. Toggling background redraw each frame when a tooltip is acive can be a solution (shouldn't be so horrible) but I'll search for a more elegant one.
Title: Re: Make world limits not forced to water level
Post by: TurfIt on April 14, 2013, 12:37:29 AM
The tooltips appear to be marking the dirty tiles correctly, the background image doesn't appear to be redrawing into those dirty sections.  I trust you've tried DEBUG_FLUSH_BUFFER? It's quite illuminating! (and shows some strange lines on the background...)
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 14, 2013, 12:58:24 AM
Thank you for the DEBUG_FLUSH_BUFFER, prissi pointed me to it time ago and I forgot it existed. Testing it now, but setting a zone dirty won't make it redraw background there, that's handled separately. I see the problem now, working in a fix. Thx. :) 

EDIT:
To force a background redraw welt->set_dirty() or welt->set_background_dirty() do the job. I also have implemented a karte_t::draw_background(x,y,xx,yy) but it's not submited to trunk yet because it's part of the next planned patch for pixmap background. But maybe it will be needed to fix this.

Anyway if you want to code something or change it somehow, ofc you can do it. I'll go sleep now, will look into this tomorrow. ;)
Title: Re: Make world limits not forced to water level
Post by: TurfIt on April 14, 2013, 01:11:37 AM
No, setting it dirty won't redraw the background. I think that's what I was getting at earlier - it should! And only redraw the section that's dirty instead of forcing a full screen update. The same applies with the window moving/resizing setting the background dirty, they also correctly set the dirty tiles and should just trigger background redraw of the dirty tile area rather than the whole screen.

Anyways, have a good night! I'm sure with the relative timezones, you'll have this all fixed before I even get up.  ;D
Title: Re: Make world limits not forced to water level
Post by: Max-Max on April 14, 2013, 10:39:52 PM
I updated the code from Trunk today and noticed some trees hanging outside the map...
Well, maybe this is PAK96.comic issue only?
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 14, 2013, 10:49:30 PM
Yes, it's a bug on the PAK. That tree can be floating on top of water too, its offset is too big.
Title: Re: Make world limits not forced to water level
Post by: Max-Max on April 15, 2013, 12:46:50 AM
Alright then :P

Your patch is coming along really nice... :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 15, 2013, 08:15:11 AM
Quote from: Max-Max on April 15, 2013, 12:46:50 AM
Your patch is coming along really nice... :)

Thx Max :)

Quote from: TurfIt on April 14, 2013, 01:11:37 AM
No, setting it dirty won't redraw the background. I think that's what I was getting at earlier - it should! And only redraw the section that's dirty instead of forcing a full screen update. The same applies with the window moving/resizing setting the background dirty, they also correctly set the dirty tiles and should just trigger background redraw of the dirty tile area rather than the whole screen.

I wish it was so easy as that, that's not possible because when a zone is marked as dirty is *AFTER* it has been already drawn, so I can't draw background there. The only solution that comes to my mind is drawing background *ON NEXT FRAME* there.

It's not a bad idea, and it might work, wl->set_dirty() draws full screen with background and individual set_dirty() only that zone, but on next frame. I'll think on this.

Quote from: TurfIt on April 14, 2013, 01:11:37 AM
Anyways, have a good night! I'm sure with the relative timezones, you'll have this all fixed before I even get up.  ;D

Not really, had a terrible headache yesterday (and not from hangover, I wish. :) )
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 15, 2013, 11:27:10 AM
Fixed @64456 .

I forced the check to redraw background on tooltip, Dwachs solution. Shoudn't impact performance since it will only redraw when background is visible, and most players don't look at borders while playing.

To implement this optimally I'd need to keep dirty background tiles structures, like current implementation of dirty tiles. That implies more code more bugs and extra maintenance. I didn't discard yet toggling a background redraw in that precise area after it's flushed to the framebuffer, even I suspect it whould cause artifacts specially in threaded mode.

But current implementation works at acceptable performance, it's simple and clean, and doesn't leave artifacts.

Since future improvements (like OpenGL or SDL2) can make future screen clear/redraw trivial in performance, I think this should be enough.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 16, 2013, 05:59:34 PM
After a formula nightmare I found the way to align background with the camera. I implemented a background of arbitrary dimensions, so, the artist can choose to make a pattern that will align to world limits or not (If he respects the proportion between height and width of the basic tile or not). The greater the image, the greater the performace the code will have.


Just some questions:


I see makeobj supports images up to 256, it's possible for any pak to include a image of arbitrary dimensions? I made my tests with a 128x128 image:


(https://dl.dropboxusercontent.com/u/30024783/Untitled64.png)


Another issue: PUSH_CLIP corrupts the clipping when in multithreaded code, I think. I tried to protect my new function with a mutex, but corruption keeps coming (only when simple_draw gets activated). I guess I'll have to protect with a lock PUSH_CLIP itself (with exit POP_CLIP ofc). Any ideas?


EDIT: I made some on-screen debug console to help me debug this, do you want me to polish it a bit so we all developers can use it? We can activate it just when DEBUG is defined.
Title: Re: Make world limits not forced to water level
Post by: Ters on April 16, 2013, 07:30:36 PM
Is the formula you mention the formula for finding the screen position of a tile? I've been struggling with that too, but have yet to get it to match up properly vertically when zooming. The formula is from "zeiger" drawing in simview.cc, but still.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 16, 2013, 09:50:36 PM
Yes, all those screen to map and map to screen calculations.

One day we should document this properly because those calculations are splattered around the code in different aproaches and maybe making them as inline functions will improve the usability and readibility of the code by huge amounts.

I have identified:

screen -> tile coords:

karte_ansicht_t::display
karte_ansicht_t::display_region
karte_t::get_ground_on_screen_coordinate (this one I just modularized because it was inside karte_t::move_cursor (move_zeiger before)
karte_t::draw_background (my new function, still not in trunk)

tile -> screen coords

zeiger code in karte_ansicht_t::display as you mentioned, plus the loop on ground tiles.

Found quite ilustrating the old comment

   /*
   * berechnung der basis feldkoordinaten in i und j
   * this would calculate raster i,j koordinates if there was no height
   *  die formeln stehen hier zur erinnerung wie sie in der urform aussehen

   int base_i = (screen_x+screen_y)/2;
   int base_j = (screen_y-screen_x)/2;

   int raster_base_i = (int)floor(base_i / 16.0);
   int raster_base_j = (int)floor(base_j / 16.0);

That is the base formula used everywere before passing for the programmers that optimized it in the past. The 16.00 I'm not sure but maybe original simutrans only suported 16 pixel width images.


There is also all the logic related to height of the grid/tiles. Those offsets can be resolved with something similar to:



const int hgt_step = tile_raster_scale_y( hgt * TILE_HEIGHT_STEP, raster_tile_width);


About aligning in different zoom levels, I'm having exactly the same problem, I wanted to end investigating this tonight, but I higly suspect the calculations have to have in mind all offsets ( ij_off and fine offsets x_off and y_off) are relative to the CENTER of the screen, so you need to take that into account.

I think the key is expressed here in ansich::display:


   const int i_off = welt->get_world_position().x - disp_width/(2*IMG_SIZE) - disp_real_height/IMG_SIZE;
   const int j_off = welt->get_world_position().y + disp_width/(2*IMG_SIZE) - disp_real_height/IMG_SIZE;
   const int const_x_off = welt->get_x_off();
   const int const_y_off = welt->get_y_off();


That moves offsets to the center of screen I think.
Title: Re: Make world limits not forced to water level
Post by: prissi on April 16, 2013, 10:47:14 PM
The 16 is form 64 tiles (rasterweite/4)
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 17, 2013, 06:08:33 AM
Quote from: Markohs on April 16, 2013, 05:59:34 PM
Another issue: PUSH_CLIP corrupts the clipping when in multithreaded code, I think.
Thats true. Where is it used in the display code?

One place I remember: vertical clipping to prevent houses, trees shine through bridges (simplan.cc somewhere). But this needs a fix, as it also clips airplanes flying over them.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 17, 2013, 04:57:59 PM
 Bogh, having trouble having the grid aligned on all zoom levels.

It's strange but on all zoom levels the camera moves sightly in some directions, that's a bit weird because on all games I remember zoom is done either on the center of screen or where the mouse is poiting.

Whould be great deciphering how it exactly determines wich is the exact coordinate that will be the center of the image, and how does that change with zooming.

One thing that confuses me is ij_off, not pointing to the real center tile on screen (or a corner) but somewere near it (sometimes 2 or 3 tiles away from the real center of screen, the fine offsets don't compensate this).

Still working on this, I guess there is something I didn't understand yet.
Title: Re: Make world limits not forced to water level
Post by: Ters on April 17, 2013, 06:07:52 PM
Using the zeiger code, I've got my OpenGL rendered surface tile grid aligned with the normally rendered map horizontally, but not vertically. The vertical thing might have to do with the height scaling, but most afternoons after work, I don't feel like doing more coding that day.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 17, 2013, 10:51:06 PM
same problem here,  doesn't match vertically. looking at zeiger atm
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 17, 2013, 11:32:44 PM
Oh, it actually worked!! I was not using view_ij_off, just ij_off! zeiger code was very useful.

Thanks!

I'd like this camera position simplified some day if possible, and zooming always to the center of screen. Anyway just because I got too many projects atm, I'll let it be this way, for now.



I suspect I'm not the only one that finds current zooming a bit weird. :)


I'm pretty sure your vertical align problem comes from height management, but check you use get_view_ij_offset and get_world_position, both are needed.
Title: Re: Make world limits not forced to water level
Post by: Yona-TYT on April 18, 2013, 01:08:01 AM

Quote from: Markohs on April 17, 2013, 11:32:44 PM


I suspect I'm not the only one that finds current zooming a bit weird. :)






I would like to be able to zoom in cursor position :thumbsup:
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on April 18, 2013, 01:46:10 AM
Quote from: Yona-TYT on April 18, 2013, 01:08:01 AMI would like to be able to zoom in cursor position :thumbsup:
Markohs, no escaping. ;)
Title: Re: Make world limits not forced to water level
Post by: Ters on April 18, 2013, 04:30:38 AM
I'm using get_view_ij_offset. The strange thing is that my misalignment is less than a tile, so I don't think the error is in koord values. The misalignment also scales proportionally to the zoom, it doesn't jump randomly around like it did last week.
Title: Re: Make world limits not forced to water level
Post by: Fabio on April 18, 2013, 09:40:49 AM
Zooming with mouse wheel should center on cursor, IMHO.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 18, 2013, 10:53:11 AM
Yep, I agree, but the amount of code needed to change that is quite big (and possible bugs) . We'll try to adress that sometime after this patch.

Quote from: Ters on April 18, 2013, 04:30:38 AM
The strange thing is that my misalignment is less than a tile, so I don't think the error is in koord values. The misalignment also scales proportionally to the zoom, it doesn't jump randomly around like it did last week.

Maybe you are scaling y_off x_off fine offsets? That's expressed in just on screen pixels and should not need to be multiplied by anything.

*I THINK* ;)
Title: Re: Make world limits not forced to water level
Post by: Fabio on April 18, 2013, 11:29:57 AM
A kludge could be when zooming center the view to cursor then zoom...
Title: Re: Make world limits not forced to water level
Post by: Ters on April 18, 2013, 03:13:18 PM
The code I use is this:

const koord cpos = -welt->get_world_position() - welt->get_view_ij_offset();
const sint16 cx = (cpos.x-cpos.y)*(IMG_SIZE/2) + const_x_off + (IMG_SIZE/2);
const sint16 cy = (cpos.x+cpos.y)*(IMG_SIZE/4) + ((display_get_width()/IMG_SIZE)&1)*(IMG_SIZE/4) + const_y_off;

The part with IMG_SIZE/2 is to get the upper point of the tile, not the upper-left corner of the screen-aligned rectangle surrounding it.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 18, 2013, 05:51:38 PM
Having another look to this, I still have the bug in some zoom levels, my code is equivalent to yours except with the IMG_SIZE/2.

Anyway it should not be a problem because we are experiencing vertical align problems.


I just get align problem on one zoom level, of 1/4 of width difference, rest looks ok.


   const int wi_tile = (int) get_tile_raster_width();
   const int he_tile = (int) wi_tile/2;

   const int wi_bg = (int) get_tile_raster_width();
   const int he_bg = (int) get_tile_raster_width();


   const koord diff = koord(0,0) - get_world_position() - get_view_ij_offset();
   const sint16 x = (diff.x-diff.y)*(wi_tile/2) + x_off;
   const sint16 y = (diff.x+diff.y)*(wi_tile/4) + ((display_get_width()/wi_tile)&1)*(wi_tile/4) + y_off;



This sucks a bit, doesn't it? :)


What do you refer by "the upper point of the tile" ? Oh, I see, you mean the middle point on the tile upper part
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 19, 2013, 03:43:29 PM
I guess I'll get some solution to this some day, but can't find it yet.

So I'll post the patch here and a background tile so if anybody wants to test himself, just do it, maybe you catch the bug.

The bug must be in karte_t::draw_background , dunno where.

The background tile is 128x128, it's suited for pak128 but I guess it can work on any pak128 variation too.

https://dl.dropboxusercontent.com/u/30024783/background-8.patch (https://dl.dropboxusercontent.com/u/30024783/background-8.patch)
and
https://dl.dropboxusercontent.com/u/30024783/ground.Outside.pak (https://dl.dropboxusercontent.com/u/30024783/ground.Outside.pak)

and the executable (https://dl.dropboxusercontent.com/u/30024783/Simutrans_background.exe) for the curious.

I know the code is far from optimized btw, I just want it to do the job correctly now.

I also know having the image in ground.outside.pak offset is crappy idea maybe too, and that moving the screen too much corrupts the clipping, it goes away when simple drawing is disabled.

I just want to know why the background doesn't align perfectly to the world grid, it just fails in one zoom level, on rest it looks ok.

Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 19, 2013, 04:22:19 PM
Quote from: Markohs on April 19, 2013, 03:43:29 PM
I just want to know why the background doesn't align perfectly to the world grid, it just fails in one zoom level, on rest it looks ok.
It looks like accumulated round-off error due to the image size is 128 * 4/3 is not an integer.

Edit:
Using this in display_background reduces the error:

   const int he_bg = (int) get_tile_raster_width() & (~3);

The reason for this is: in simview.cc, the y-screen coordinate is increased by raster_width / 4, so the increment for the background should be four times this value, which is not equal to raster_width but 4*(raster_width/4), the expression above.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 19, 2013, 04:34:02 PM
ooooh, right, I see when this fails get_tile_width marks 170, and that's rounded from 170,66666666666666666666666666667.

Maybe rearanging this calculations I'll get rid of that error, I'll see what can I do.

Thanks a lot Dwachs, really helpful as usual!! :)

What I don't know yet is why this doesn't happen on other parts of the code.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 19, 2013, 04:36:32 PM
Did you saw my edit?
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 19, 2013, 04:41:00 PM
yes, thx :)

EDIT: If I understand correctly, with your modification, the minimized error it has now it's due to the accumulated error in the modulus in the vertical paiting (the %he_bg), one pixel for every painted tile.

Do you think this error will be acceptable? It's very small...
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 19, 2013, 04:59:56 PM
It seems to be just one pixel off, this is acceptable. I do not know, where this difference does come from. Maybe this is caused by some round-off 'bug' in the (original) drawing code.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 19, 2013, 05:16:42 PM
Quote from: Dwachs on April 19, 2013, 04:59:56 PM
It seems to be just one pixel off, this is acceptable. I do not know, where this difference does come from. Maybe this is caused by some round-off 'bug' in the (original) drawing code.

I think it comes from the modulus I apply to the coordinates to get the start of the pattern.

Anyway if the image that's defined it's a multiple of the basic tile dimensions, this error should not show, I think.

Okay, thanks a lot again Dwachs. :)
Title: Re: Make world limits not forced to water level
Post by: Ters on April 19, 2013, 05:54:27 PM
My problem was not related. I just had to throw (get_base_tile_raster_width() - IMG_SIZE)/2 into the mix. Reminds me of math back at school, when we sometimes got the right answer, except that it was twice or ten times as big (or small) as the correct answer. So we just multiplied (or divided) by two or ten to get the right answer, without really knowing why. (This wasn't on exams of course. There were no correct answers in the back of the book then.)
Title: Re: Make world limits not forced to water level
Post by: prissi on April 19, 2013, 08:31:06 PM
Ters, this appears only a certain screen sizes. Markohs could be lucky and this is then zero, if we are talking about the same offset. When there is an uneven number of tiles for the screen, the it was centered. (Actually this code still stems mostly from Hajo ... )
Title: Re: Make world limits not forced to water level
Post by: Ters on April 19, 2013, 09:33:58 PM
Quote from: prissi on April 19, 2013, 08:31:06 PM
Ters, this appears only a certain screen sizes. Markohs could be lucky and this is then zero, if we are talking about the same offset. When there is an uneven number of tiles for the screen, the it was centered. (Actually this code still stems mostly from Hajo ... )

I'm not sure whether you're referring to the problem Markohs had, or the one I had. My point was that they seemed to be unrelated problems. His problem seems to be related to a single zoom level, while my problem scaled linearly with zoom factor, being only correct at 1:1.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 20, 2013, 03:48:09 AM
Quote from: Ters on April 19, 2013, 05:54:27 PM
My problem was not related. I just had to throw (get_base_tile_raster_width() - IMG_SIZE)/2 into the mix. Reminds me of math back at school, when we sometimes got the right answer, except that it was twice or ten times as big (or small) as the correct answer. So we just multiplied (or divided) by two or ten to get the right answer, without really knowing why. (This wasn't on exams of course. There were no correct answers in the back of the book then.)

Well, yes. :)

At first design I just copied code around and found result was more or less accurate, but needed some adjustments. Multipled, divided, truncated, added 1... Nothing worked perfectly. Then I decided to understand the algorithm and write from scratch. Better result but not perfect either, more adjustments, factors, trying... ;) Then you point me to zeiger and same cycle again hehe. :)

Until Dwachs came with that!
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 22, 2013, 05:05:36 PM
State of the patch:

https://dl.dropboxusercontent.com/u/30024783/background-9.patch (https://dl.dropboxusercontent.com/u/30024783/background-9.patch)

I'm substituting PUSH_CLIP by add_poly_clip, Dwachs code, that's used on dinge drawing and should not be affected by this code, that's called in display_boden(), I think that will get rid of clipping corruption.

1) Right now I get background from ground.outside.pak but that restricts max image size to the pak size. I'm thinking in reading it from ground.background.pak , with arbitrary size. Anyone against this?
2) I added all the code to karte_t , but thought on creating simbackground.cc with background_t , do you think it's a good idea or it's ok like this?
3) I cached some calculations in karte_t, to save time when redrawing, I guess that's ok too.

Comments welcome.
Title: Re: Make world limits not forced to water level
Post by: prissi on April 22, 2013, 08:47:50 PM
Just very short remarks without reading your patch in depth.

add_poly_clip is magnitudes slow than normal clip. Be careful to not become slower than even before when always drawing full screen.

The drawing should go to simview.cc. That should not be hard to do. (Ok, maybe a slight change needed to gui_worldview?)

And finally a remar on your comments:
/**
* Updates cached values required for background display.
*/
void update_background_cached_values(bool changed_zoom=false);

The comment in this case does not explain anything at all. (Same as the comments at the background variable btw.) It just repeats the name.

Same for
@name Background management
*       This (These!) variables are related to the background displaying.
* @note width and height are stripped of their lower 2 bits because routines in simview.cc use divisions by
* 2 and 4 of this value. This causes align problems at zoom level 3 to 4.

But why or related in what way is still completely unclear ...
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 23, 2013, 01:12:52 AM
Quote from: prissi on April 22, 2013, 08:47:50 PM
Just very short remarks without reading your patch in depth.

add_poly_clip is magnitudes slow than normal clip. Be careful to not become slower than even before when always drawing full screen.

Okay will look into it.

Quote from: prissi on April 22, 2013, 08:47:50 PM
The drawing should go to simview.cc. That should not be hard to do. (Ok, maybe a slight change needed to gui_worldview?)


Well, grund_t also calls this draw background, but ok, will see how can manage it.

Quote from: prissi on April 22, 2013, 08:47:50 PM
And finally a remar on your comments:
/**
* Updates cached values required for background display.
*/
void update_background_cached_values(bool changed_zoom=false);

The comment in this case does not explain anything at all. (Same as the comments at the background variable btw.) It just repeats the name.

Same for
@name Background management
*       This (These!) variables are related to the background displaying.
* @note width and height are stripped of their lower 2 bits because routines in simview.cc use divisions by
* 2 and 4 of this value. This causes align problems at zoom level 3 to 4.

But why or related in what way is still completely unclear ...


Well, I'll take it as a compliment of my function names being well chosed and expressive... ;)


But ok, you are right, I'll add more detail, not so much to turn it to a novel but I'll add more detail. :)


Thanks for having a look! :)
Title: Re: Make world limits not forced to water level
Post by: prissi on April 23, 2013, 08:36:14 AM
Then maybe do the drawing in grund_t, or planquadrat. I would like to avoid another place where drawing happens. The code is alrady quite complex. It may be an ugly thing to say, but maybe really going back to your first optimisation to draw all the background only when something is visible is the better way in terms of complexity versus gain.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 23, 2013, 09:02:53 AM
Quote from: prissi on April 23, 2013, 08:36:14 AM
Then maybe do the drawing in grund_t, or planquadrat. I would like to avoid another place where drawing happens. The code is alrady quite complex. It may be an ugly thing to say, but maybe really going back to your first optimisation to draw all the background only when something is visible is the better way in terms of complexity versus gain.

Yep, was thinking that too.

I'll first try another concept, remove background drawing in grund_t (safety borders) and just leave full screen background draw when visible (once), plus modifying the dirty tile concept that's now:

1) mark dirty
2) copy to screen

To:

1) mark dirty
2) copy to screen
3) drawn background on that zone, so next redraw it's ok.

I think it can work, having it a look.
Title: Re: Re: Make world limits not forced to water level
Post by: prissi on April 26, 2013, 09:34:46 PM
The code has a big problem with tile heights !=16, pakTTD for instance.

EDIT: Also removing the ticker leaves artifacts now.

EDIT2: I changed the code to tilewise drawing only, and removed all the background dirty stuff. Found no artefacts, but please test again.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 28, 2013, 04:53:57 PM
dunno if the way you decided to implement this is the best, really, prissi, it's slower than my solution, and it leaves artifacts anyway. It also makes impossible to implement a background image. I don't really like how the code looks right now.

Whoudn't just have been better fixing the border background code that I submited?

It has bugs, too, just raise/lower tiles at the border of the world, and you'll see .

(https://dl.dropboxusercontent.com/u/30024783/Untitled68.png)

Why do you draw at grundwasser leveloutside the map? Now it can be any height.




                else {
                    // outside
                    const sint16 yypos = ypos - tile_raster_scale_y( welt->get_grundwasser()*TILE_HEIGHT_STEP, IMG_SIZE) + (IMG_SIZE*3)/4;
                    display_fillbox_wh_clip( xpos, yypos, IMG_SIZE, IMG_SIZE/4, umgebung_t::background_color, force_dirty );
                }


I might be wrong, but I think you assume the tile will be at water level, and it doesn't really need to be.
Title: Re: Make world limits not forced to water level
Post by: prissi on April 28, 2013, 09:53:00 PM
Which it is slower. You drew infinite band and cleared all the screen. It would have been fine with one of them. Anyway, your calculation created lots of artifacts with half tile height or pak64. I would be perfectly fine with that too. However, then the fuss in grund_t is not needed at all, so just get rid of this. Shortest and still no big impact I would say.

Without grundwasser, then the top would generate artefacts. Can be removed of course, it was just a continuation of the existing code. Try next submit with the attached pak64 savegame. It has all artefact creating stuff I could think off.
Title: Re: Make world limits not forced to water level
Post by: TurfIt on April 29, 2013, 01:13:43 AM
The ingame cursor can get stuck on the map when you rapidly move the real cursor off the map onto the background region. If you then activate the selected tool, it does work at this stuck position.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 29, 2013, 07:40:22 AM
 mmm... I'm a big lost now.

So you removed the background drawing in grund_t but the full background redraw and dirty background marking mechanism is preserved?

Well, if whould be great is that was enough!

But looking at your savegame, a few extra changes are needed somewere, because:

(https://dl.dropboxusercontent.com/u/30024783/Untitled69.png)

The one in the "follow" screen just needs that area being flushed with background, and the one in the southern border, a background_mark_dirty on modification of a south or east grid position.

I can fix them, if you want it, or you can fix yourself, as you wish.

You are right, my code in grund_t was not necessary if this works.

Quote from: TurfIt on April 29, 2013, 01:13:43 AM
The ingame cursor can get stuck on the map when you rapidly move the real cursor off the map onto the background region. If you then activate the selected tool, it does work at this stuck position.

That can be fixed too, if when toggling the tool, we check if it's a grid or tile tool, and if the last known position is invalid, we move it to the nearedt allowable position. It can be fixed.
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 29, 2013, 04:06:08 PM
Well, nevermind, I fixed the bugs and commited to svn @6484, I hope you don't mind.

I define karte_ansicht_t::display_background as you suggested some posts ago to move display code to the view. Right now it's just a call to a fillbox but will be more complex on my next patch.

EDIT: Regarding turfIt menctioned bug, this solves the problem:

https://dl.dropboxusercontent.com/u/30024783/background_prissi.patch (https://dl.dropboxusercontent.com/u/30024783/background_prissi.patch)

But I'm unsude if applying it or nowt because it doesn't solve another problem I detected, and that's after a grid node it's raised on the edge of the map, the cursor (zeiger), it's not updated of it's z-coord before the frame display comes, so you can see the arrow on the old z-position. This doesn't happen just on the border, it happens in the wole map, allways has been that way, it's just conflicting with prissi's aproach to this, because the zeiger was overdrawn before, each frame. But because it looks somewhat network related, I didn't dared to change further.

(https://dl.dropboxusercontent.com/u/30024783/Untitled70.png)

I can try to do it anyway (modifying zeiger after the tool has done the "work", comments welcome.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 29, 2013, 06:39:30 PM
your patch does not look like it could ruin network mode ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 29, 2013, 07:15:30 PM
yep, up to that I know, but I'll need to move zeiger after werkzeugt_t::work (or whatever it's spelled, sometimes german drives me mad ;) ). Moving zeiger won't break networkmode? I'll need to increment/decrement it's z value.
Title: Re: Make world limits not forced to water level
Post by: Dwachs on April 29, 2013, 07:44:18 PM
Quote from: Markohs on April 29, 2013, 07:15:30 PMMoving zeiger won't break networkmode?
No, its position is taken during the reaction on mouseclick (somewhere in simworld.cc, interactive_event ?).
Title: Re: Make world limits not forced to water level
Post by: Markohs on April 30, 2013, 06:29:04 PM
Okay, third version of the patch to fix the current artifacts:

https://dl.dropboxusercontent.com/u/30024783/background_prissi-3.patch (https://dl.dropboxusercontent.com/u/30024783/background_prissi-3.patch)

Lots of changes, lower/raise tool's position now updates the cursor pointer immediately after using. Not only on world borders, on the whole map. Now when you raise/lower, the pointer will move instantly to the vertex that will be affected if you use the tool again. It was a bit strange how it worked before, because if you just re-clicked without moving the mouse pointer, you could end raising a vertex that was not expected (the cursor was not over it). And as a side-effect, now the pointer won't be drawn over background.

Looks like the stripes painted on grund_t cleaned more than we thought (at least me), this still fails (using a construction tool too near of the border):

(https://dl.dropboxusercontent.com/u/30024783/Untitled71.png)

I guess at this point, forcing a background redraw after cursor moves from a border position, it's mandatory too.

I know I changed quite a lot of things but believe me, there was not better way of doing it, (or I coudn't find it).

Comments welcome, as allways.

EDIT: the bug was easy to fix, https://dl.dropboxusercontent.com/u/30024783/background_prissi-4.patch (https://dl.dropboxusercontent.com/u/30024783/background_prissi-3.patch) , anyone finds more artifacts?
Title: Re: Make world limits not forced to water level
Post by: prissi on April 30, 2013, 10:28:05 PM
Sorry, I just submitted five lines in zeiger_t, which took care of the background. But those are obviously not updating the cursor position.
Title: Re: Make world limits not forced to water level
Post by: TurfIt on April 30, 2013, 11:57:00 PM
Shadows should be clipped to the tile edge rather than being cast into the void.. IMHO that looks just plain wrong.

I can still make the cursor get stuck in the middle of the map by rapidly moving it from a ground tile to the background. Clicking to activate a tool then executes it once before the cursor disappears entirely.
If I move the cursor off map slow, it gets stuck along the edge. Then clicking with a tool executes every click. Ingame cursor should become invalid whenever the real cursor is off the map IMO, and prevent map altering tools from operating.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 01, 2013, 01:34:51 AM
@prissi: ah, ok, then my modification to zeiger.cc is not needed, removed it, your modification does the same.
@TurfIt:
  about shadows: I fear clipping just the shadow it's not possible, after all it's just part of the image itself, how do you distinguish wich part of the image is just shadow and wich is the actual tree spanning to the top of the tile? No idea, I don't really know much of how dings are drawn still (we can maybe just implement that on baum.cc), just know a bit of the landscape code. Anyone has any idea on how to implement that without consuming too much CPU? It's a similar case than someone mentioned here some weeks ago, that in some pak some trees have offsets so big that span to the tile in the south, in that case trees float in space.

  about the cursor:

I think this fixed all the issues:


void karte_t::move_cursor(const event_t *ev)
{
   if(!zeiger) {
      // No cursor to move, exit
      return;
...
   const koord3d pos = get_new_cursor_position(ev, wkz->is_grid_tool());

   if( pos == koord3d::invalid ) {
      zeiger->change_pos(pos);
      return;
   }


updated patch:

https://dl.dropboxusercontent.com/u/30024783/background_prissi-6.patch

I think I can just commit it tomorrow, unless someone finds a bug or has more comments. :)
Title: Re: Make world limits not forced to water level
Post by: TurfIt on May 01, 2013, 01:41:11 AM
re shadows: I thought they they were drawn seperately, like back/front images. Obviously not possibly when they are one image. doh.
Title: Re: Make world limits not forced to water level
Post by: greenling on May 01, 2013, 08:03:08 PM
Wooh those projekt goes forward that i me wonder. :o
Title: Re: Make world limits not forced to water level
Post by: prissi on May 01, 2013, 08:14:22 PM
If the background color is set to black, the shadow problem is solved immediately...

I am not sure that a valid zeiger pos is not assumed at more positions. Lets try this out.

By the way, I just remembered, why the cursor pos was not updated. That stemmed once from the massive flattening options by keeping the old coordinates. But it might well be already obsolete. But dragging a plateau should still work, or?

EDIT: Why the extra code in raise_to? This routine is already relatively slow for higher hills. Given also the low frequency for the raising or lowering of tiles by AI or user, I would just trigger the whole background dirty for any such operation.
Title: Re: Make world limits not forced to water level
Post by: jamespetts on May 01, 2013, 08:35:15 PM
Quote from: prissi on May 01, 2013, 08:14:22 PM
If the background color is set to black, the shadow problem is solved immediately...

I am definitely in favour of this - the black background looks rather better than the grey version that I have seen.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 02, 2013, 12:32:06 AM
Quote from: prissi on May 01, 2013, 08:14:22 PM
If the background color is set to black, the shadow problem is solved immediately...

About the default color in background: it's already able to be modified in each pak's simuconf.tab, or by each player manually ofc.

Dunno, I personally like this gray and don't mind the shadow errors. If I had to decide a color myself I'd use a super-bright disgusting yellow color to force pak creators to decide the color that suits better for their pak. ;)

If you want to change it, go ahead, I don't mind. :)

Quote from: prissi on May 01, 2013, 08:14:22 PM
I am not sure that a valid zeiger pos is not assumed at more positions. Lets try this out.

I just commited the patch, with 2 extra changes that set cursor to koord3d::invalid in certain circunstances. Coudn't find any bug.

Quote
By the way, I just remembered, why the cursor pos was not updated. That stemmed once from the massive flattening options by keeping the old coordinates. But it might well be already obsolete. But dragging a plateau should still work, or?

You mean clicking a raise_lower tool and without unclicking drag the mouse to make flat terrains? If you refer to this, yes it's working right now, tested yesterday and just tested again. If you don't mean that I don't really understand what you said. :)

Quote
EDIT: Why the extra code in raise_to? This routine is already relatively slow for higher hills. Given also the low frequency for the raising or lowering of tiles by AI or user, I would just trigger the whole background dirty for any such operation.


mmm... you are right, changing it. It was because of its recursive nature, raising (60,60) in a 64x64 map could potentially end raising border tiles, and wanted to just mark dirty then. But since this is a user-triggered acction, won't affect performance marking background dirty each time a player uses the tool.

Changed, all commited to @6495

@greenling: I don't really understand what you said, sorry. :)
Title: Re: Make world limits not forced to water level
Post by: An_dz on May 02, 2013, 12:58:44 AM
Quote from: Markohs on May 02, 2013, 12:32:06 AM
@greenling: I don't really understand what you said, sorry. :)
He tried to say:
"Wooh This project got more development than I thought so."
Title: Re: Make world limits not forced to water level
Post by: TurfIt on May 02, 2013, 01:37:42 AM
Detection of the mouse cursor in the background region only works when the world meets the background at sealevel. If the ground is higher, there's a misalignment between the mouse cursor and ingame cursor at the boundary.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 02, 2013, 11:22:25 AM
mmm... can't reproduce what you say, TurfIt, it works good here...

Wich pak you use and in wich border did you try? east/south? Or north/west? Wich tool you were using? I tried pak64 and pak128, with inspect and raise tool, and on all corners and all looked good to me... :?

Dunno if I understand you fully, on raise/lower tool it's normal to get a misalign because it will move to the closest vertex, and on tile tools, I allways got the one under the mouse pointer. I tested Windows GDI version btw. might it be the default system mouse pointer graphic your system uses it's not aligned to the one the system sends to the application?
Title: Re: Make world limits not forced to water level
Post by: TurfIt on May 02, 2013, 11:46:53 AM
It was pak64, WinSDL, south border. Inspect tool.
If the mouse cursor was over the map, the tool would correctly highlight the ground tile the cursor was over, and move the highlight to the next tile as the cursor moved over the boundry.
If the mouse cursor was off the map, but within ~1/2 a tile of the edge, the onmap tile was still highlighted, but now moving the cursor parallel to the edge of the map was resulting in the highlighted being off set from the cursor position. The higher the ground tile above the water surface, the worse the offset. If the water was at the edge, moving the cursor off the map would stop the highlight - correctly detected cursor off map.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 02, 2013, 12:31:47 PM
hhmmm... I see it now. I'll have it a look haven't checked the code yet again, my guess is this one is not easy to fix.

But height makes the difference, you are right, the problem is almost for sure in karte_t::get_ground_on_screen_coordinate ,  I'll try to figure out how height affects this... Not so easy because that algorithm is basically the same (I just changed a few lines), and I *think* that bug already existed in old versions of simutrans. Just now it's noticeable because we hide the cursor now.

But I'll see what can I do. :)

It's not a killer bug, difference is not huge.

EDIT: Okay, I know where is the problem now and how to fix it. It was indeed a bug introduced by me. It doesn't really happen on borders, it happens anywere in the map.

But I'm not really sure if previous code before my intervention had a "gap", where the game coudn't find a matching tile under the pointer. I think it did, just wasn't so obvious before. Now that TurfIt pointer me to it, I see it everywere. ;) I'll fix tomorrow.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 03, 2013, 05:46:01 PM
The reason the intersection algorithm sometimes does not return the tile in wich mouse pointer is over it's ilustrated in this image I made to understand the problem better:

(https://dl.dropboxusercontent.com/u/30024783/selection.png)

The zone not colored between the blue and red zones, it's the zone the algorithm will fail to return a ground tile. That's because the shape of the tile it's assumed to be rectangular (well, a diamond), while it's not. I'm still thinking how to fix this, any ideas?

My current implementation searchs for a extra tile with height+1 in addition to the coloured one, but that's not 100% sasisfactory, and creates the bug Turfit described. But creates more problems too.

This is not a new algorithm, it's the same we have been using for years.

It's all in karte_t::get_ground_on_screen_coordinate
Title: Re: Make world limits not forced to water level
Post by: Dwachs on May 03, 2013, 06:58:43 PM
I do not have any idea how to solve this.  Keep in mind that there are (valid) situations, where the pointer is not over a tile (if it is over a vertical wall).
Title: Re: Make world limits not forced to water level
Post by: An_dz on May 04, 2013, 07:41:53 PM
How the code that generates the grid borders work? Can't it be used to check these slope tiles?
Title: Re: Make world limits not forced to water level
Post by: Ters on May 04, 2013, 10:54:34 PM
If you're referring to the tile grid Simutrans has been able to display for as long as I've played it, those are just images like everything else.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 06, 2013, 08:01:17 PM
Yep, an_dz, can't be used for that.

Well, I made a fix that eliminates most of the error TurfIt discovered. On flat tiles cursor will disapear as the mouse gets on background, and on slopes, the range it's decreased sightly, but still extends a some pixels.

https://dl.dropboxusercontent.com/u/30024783/cursor_fix.patch (https://dl.dropboxusercontent.com/u/30024783/cursor_fix.patch)

If you don't mind I'll commit it and consider it as fixed to the extent it can be fixed. ;) It's a very small diference, and fixing it I fear whould require more CPU.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 07, 2013, 08:38:26 PM
I'm making some experiments and wanted to try a 512x512 image as background, but when generating the pak:


F:\makeobj>Makeobj.exe pak512
Makeobj version 53 for simutrans 111.2 Nightly and higher

Makeobj version 53 for simutrans 111.2 Nightly and higher
(c) 2002-2006 V. Meyer , Hj. Malthaner, M. Pristovsek (markus@pristovsek.de)

Image size is set to 512x512
writing invidual files to ./
   reading file ./background.dat
   writing file ./ground.Background.pak
      packing ground.Background
WARNING: ignoring alpha channel
ERROR: packed image size (263680) exceeded 65535 bytes!


Well, no problem I'll try a 256x256, but... why this limitation? bild_t::len is a 32-bit value, can I remove this limitation in makeobj or it's there for a reason?

The image is this one for the case someone is interested, and has a better idea (with gimp source)

https://dl.dropboxusercontent.com/u/30024783/bg/Sin%20nombre.xcf

(https://dl.dropboxusercontent.com/u/30024783/bg/backgroundnew.png)

Title: Re: Make world limits not forced to water level
Post by: Dwachs on May 08, 2013, 08:14:07 AM
It seems that this range check in image_writer.cc is out of date. I think it can be removed safely as all related data structures are uint32.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 08, 2013, 09:38:04 AM
Thanks!
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 08, 2013, 11:13:37 AM
Two screenshots with the work in progress, it's looking good in my oppinion! With the world slope will look way better.

Comments welcome as allways. :)

(https://dl.dropboxusercontent.com/u/30024783/Untitled72.png)
(https://dl.dropboxusercontent.com/u/30024783/Untitled73.png)

EDIT: Modified the code to allow for bigger images in pak files, it's uploaded to trunk, if someone needs a new executable of makeobj for windows, I have built this one:

https://dl.dropboxusercontent.com/u/30024783/bg/makeobj.exe (https://dl.dropboxusercontent.com/u/30024783/bg/makeobj.exe)

It's compiled using MSVC 2012, you you might need to install:

http://www.microsoft.com/en-us/download/details.aspx?id=30679 (http://www.microsoft.com/en-us/download/details.aspx?id=30679)

Source and .dat for the file:

https://dl.dropboxusercontent.com/u/30024783/bg/background.zip (https://dl.dropboxusercontent.com/u/30024783/bg/background.zip)

Executable:

https://dl.dropboxusercontent.com/u/30024783/bg/Simutrans.exe (https://dl.dropboxusercontent.com/u/30024783/bg/Simutrans.exe)

Copy ground.Background.pak to your pak folder to activate this.

Source patch: https://dl.dropboxusercontent.com/u/30024783/bg/bg.patch (https://dl.dropboxusercontent.com/u/30024783/bg/bg.patch)

known issues:
- You need to change zoom once to activate this
- Mini-viewports in vehicle frames and inspected places, draw the scaled version of BG when they should do the unscaled, and with correct offset
-coordinates are not allways updated corectly
Title: Re: Make world limits not forced to water level
Post by: prissi on May 08, 2013, 08:42:15 PM
Somehow this is again very close to the initial outside images ;)

But as art is in the eye of ... Well, maybe peole are tuned down form so many logos from internet adds. But somehow I cannot get very warm with this. I would rather see the proposed landscape forms. (Would need 5 images for all slopes, and maybe also some climate dependent ones.)
Title: Re: Make world limits not forced to water level
Post by: Ters on May 08, 2013, 09:05:27 PM
Having a grid in the background image just looks plain odd, unless terrain is forced to the same level at the edges. Not necessarily water level, but a level the grid is aligned with.
Title: Re: Make world limits not forced to water level
Post by: jamespetts on May 08, 2013, 09:41:11 PM
Would these new graphics be compulsory, or are they pakset dependent? Plain black would be preferable to this look, I think.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 08, 2013, 09:52:09 PM
I'm not a graphical artist, I'm pretty sure we have people in the forum that will make a better job than me on that, my version is just a demo of what can be done.

@prissi: By "the proposed landscape forms" you refer to the world slice slope?
@ters: well, you have to think world slopes are still missing, when they are implemented (soon I hope), it will all look better. Anyway it's alligned atm, at certain levels, just the grid line it quite thick and maybe I didn't aligned it 100% perfectly in the .png. But it aligns with flat world borders, at certain heights.
@jamespetts: No, it will be optional. Like the current solid background color, that can be changed in the pak .tab file, You can not define this image and simutrans will revert to the solid color version. The same goes for the future world slopes.

My idea is to make all this features optional. And after I implement world slopes I'll plan how to implement the old landscape again, so people can enforce the world to be like it was before.
Title: Re: Make world limits not forced to water level
Post by: prissi on May 08, 2013, 10:17:32 PM
Well currently the grid seems to be not favourable by the last three posts ... If you intend to add something like this, I would rather suggest using the outside image for tiling. If a pakset than want borders, they could be added directly to the outside pak.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 08, 2013, 10:56:28 PM
Quote from: prissi on May 08, 2013, 10:17:32 PM
Well currently the grid seems to be not favourable by the last three posts ... If you intend to add something like this, I would rather suggest using the outside image for tiling.

Ok, I understand that, but that forces the outside image to be the same size than a basic ground size, horizontally. I thought allowing a bigger image size would give greater flexibility so every artist can implement whatever he likes. If he designs the image like I did, he can draw a grid, but he's also free to use a sea image, with no grid, ofc. Given the grid it's aligned to the image at -2 level (grundwasser), he can choose whatever he likes. A sliced world floating on top of water will look quite weird too, if borders are not forced to water level.

Bigger image will give better performance to the background redraw, too.

Hm... will think about this.

Quote from: prissi on May 08, 2013, 10:17:32 PM
If a pakset than want borders, they could be added directly to the outside pak.

I don't understand this, you mean "if the pakset creator wants a grid he can draw a grid to the ground.Outside.pak" ?

Images using the old "outside" graphics, doesn't this look even weirder?

(https://dl.dropboxusercontent.com/u/30024783/Untitled75.png)
(https://dl.dropboxusercontent.com/u/30024783/Untitled74.png)
Title: Re: Make world limits not forced to water level
Post by: prissi on May 08, 2013, 10:59:15 PM
If you draw two lines on the outside image, you would get a grid. Try pak96 outside image. pak.Mars had also a black outside tile, if I remember.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 08, 2013, 11:01:54 PM
yes yes, pak96.comic has it too. But you can also draw it on the background image, it's the same, no? And the bigger the image, the lower image_displays, thus more performance.
Title: Re: Make world limits not forced to water level
Post by: prissi on May 08, 2013, 11:07:40 PM
The original code did already draw tile size tiles (ground.outside.pak must be tile size). This is done in the threaded code, thus I would not expect my impact. I could be done again there again. (I would do it however at ground water level, like the old code.) If done only outside, it would again emulate a cut out feeling.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 08, 2013, 11:17:34 PM
 I don't know, prissi, I'd personally prefer allow giving the artist the flexibility of supplying a image of whatever size he wants, with grid or without grid, and use it in the background code than going back to a tile-shaped image, and just drawing it like the old code does.

I see no advantages on your approach, it's slower and makes a size mandatory. And it's harder to implement in the future OpenGL code too.

But ofc, we can do it that way if you all want to.
Title: Re: Make world limits not forced to water level
Post by: An_dz on May 09, 2013, 04:17:46 AM
Here's my test with the background code, something a little like SimCity:
(http://img42.imageshack.us/img42/585/bhav.png)
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 09, 2013, 07:21:28 AM
thx an_dz :) what size is that background image?
Title: Re: Make world limits not forced to water level
Post by: Dwachs on May 09, 2013, 08:19:16 AM
Something completely different: Currently it is possible to scroll the map such that nothing of the map is visible anymore, this was not possible before this change.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 09, 2013, 02:13:25 PM
Nope, it's allways been possible, I just checked 112.2 and 112.0 and you can drag outside the map.

Or I did something wrong in the check or it's in my game settings, or I didn't understand you. :)

If I did understand you, not being able to drag screen so much as only background is visible is a desired feature, it's a still to be implemented feature. :)
Title: Re: Make world limits not forced to water level
Post by: An_dz on May 09, 2013, 02:38:54 PM
Quote from: Markohs on May 09, 2013, 07:21:28 AM
thx an_dz :) what size is that background image?
256
Title: Re: Make world limits not forced to water level
Post by: Ters on May 09, 2013, 02:45:53 PM
Quote from: Markohs on May 09, 2013, 02:13:25 PM
Nope, it's allways been possible, I just checked 112.2 and 112.0 and you can drag outside the map.

I don't think it has always been possible, because I was surprised when I found that I could do that a while back. Although I don't remember exactly when I did that, I think that it was before I built Simutrans with these changes.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 09, 2013, 02:57:53 PM
@ters: I remember the same but the fact it's old versions allow scrolling outside the map now. So aliens altered all our memories with some weird device or something it's happening here. Just can't explain why. Any ideas?

Quote from: An_dz on May 09, 2013, 02:38:54 PM
256

If you want the image to align to the world I think it needs to be a dimension multiple of the pak size, so if you are using pakcomic.96 you can use 96, 192, 384, 768 ... Height and width can be different too, you can maybe try a 768x192 version, just remember to invoke makeobj with the higher of the both, "makeobj pak768" in that example. If you tested other variations I'd be happy to see them.

I fixed the misalign in the grid when zooming, and the bug at start, now only mini-renders are failing.

New executable: https://dl.dropboxusercontent.com/u/30024783/bg/Simutrans.exe
Title: Re: Make world limits not forced to water level
Post by: Ters on May 09, 2013, 03:23:20 PM
112 isn't that old. It might easily be a year, or even more, since I last tried to scroll outside the world. So there are a lot of changes to go through to find the culprit.
Title: Re: Make world limits not forced to water level
Post by: An_dz on May 09, 2013, 04:31:04 PM
Quote from: Markohs on May 09, 2013, 02:57:53 PM
If you want the image to align to the world I think it needs to be a dimension multiple of the pak size
I saw no differences, at least with this image.

Quote from: Markohs on May 09, 2013, 02:57:53 PM
If you tested other variations I'd be happy to see them.
I just made it slightly lighter to match more the comic style.

I attached the image if you want to build the background and debug your code.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on May 09, 2013, 05:38:17 PM
Quote from: Markohs on May 09, 2013, 02:57:53 PMNew executable: https://dl.dropboxusercontent.com/u/30024783/bg/Simutrans.exe
I got Runtime error. R6034. All required dll's are in the simutrans folder. :<
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 09, 2013, 05:40:57 PM
did you put ground.background.pak in the pak folder? it doesn't start without it atm.

Well, looking further looks like it's something derived from visual studio, I'll compile using mingw, wait a bit plz. :)
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on May 09, 2013, 06:11:21 PM
Now I did, but the error still persists.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 09, 2013, 06:16:20 PM
There you have, this should work with no problems.

https://dl.dropboxusercontent.com/u/30024783/bg/sim.exe (https://dl.dropboxusercontent.com/u/30024783/bg/sim.exe)

If it doesn't work, try to download again same file in 5 mins, I just uploaded to dropbox and it might be giving you an older version.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on May 09, 2013, 06:35:44 PM
It started up. But it crashes if I zoom in while hovering the cursor over the "space", the background thing, in max window.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 10, 2013, 11:45:44 AM
Oh, I see, found the bug, fixing it. Thx. ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 10, 2013, 03:33:31 PM
How strange, this bug only appears to show when compiled with mingw , on Visual Studio never fails, dunno how to debug this, I'll try to learn how gdb works... :)
Title: Re: Make world limits not forced to water level
Post by: Ters on May 10, 2013, 04:08:37 PM
Sounds like the kind of bug that might go into hiding when compiled in debug mode.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on May 10, 2013, 04:13:56 PM
Quote from: Markohs on May 10, 2013, 03:33:31 PM
How strange, this bug only appears to show when compiled with mingw , on Visual Studio never fails, dunno how to debug this
What a bugging situation: this is the kind of bug that bugs me up a lot. D*** bugs! :>
Title: Re: Make world limits not forced to water level
Post by: Dwachs on May 10, 2013, 04:16:39 PM
Markohs, can you post an updated patch?
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 10, 2013, 04:22:00 PM
Quote from: Ters on May 10, 2013, 04:08:37 PM
Sounds like the kind of bug that might go into hiding when compiled in debug mode.

Yes, thought on taht too, but mscv on release produces a binary that doens't fail either.

I tried to debug using mingw and gdb, it's impossible to hit control-C to stop the program on bug (the bug causes invinite loop). To debug it, I have to start the program manually and attaching to the program using "gdb --pid=9700" externally. This works, and the proigram stops execution, but when I try to debug, stepping doesn't take me out of internal functions.

It's strange, dunno how can I debug this. I hope it's just my way of compiling it that's causing the bug... I don't know how someone can develop and debug using mingw, it's horrible. It's way slower compilating, the console doesn't allow copy/paste...

I understand gcc is multi-plattform and tools are great on a linux machine, but in Windows it just sucks. ;)

(https://dl.dropboxusercontent.com/u/30024783/Untitled77.png)

Posting a patch now, Dwachs, gimme a few mins. Thx. :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 10, 2013, 04:26:49 PM
https://dl.dropboxusercontent.com/u/30024783/newbg.patch (https://dl.dropboxusercontent.com/u/30024783/newbg.patch)

You also need ground.Background.pak in your pak directory, you can get inside this file:

https://dl.dropboxusercontent.com/u/30024783/bg/background.zip (https://dl.dropboxusercontent.com/u/30024783/bg/background.zip)

To reproduce the bug, you need to move 100% outside the world limits and zoomin/zoomout continously with the mouse wheel, if it doesn't fail after a few secs, move the camera a bit and keep doing it. It's a bit random.

I know the code it's not ready for inclusion and needs some tweaking, but why does this bug exist?

I compiled it without MULTI_THREAD, btw.
Title: Re: Make world limits not forced to water level
Post by: TurfIt on May 10, 2013, 09:54:08 PM
The problem appears to be the chosen image - zoom in and once recoded, run lengths > 512 are being created. That exceeds the max for the asm version of display_img_nc(). The recoding routines should be changed to respect the limit. _nc() is too performance critical to change IMHO.

EDIT: also, if I open any gui window (nowhere near the background), the background is being continually painted..
Title: Re: Make world limits not forced to water level
Post by: Ters on May 11, 2013, 07:40:57 AM
Is it still that performance critical? All indications I have seen lately is that Simutrans is I/O bound, not CPU bound. Potential low performance platforms today are likely non-x86 anyway.

But how can one recode differently? The run lengths are alternately transparent (skip) and non-transparent (copy). A zero length transparent run (except the first) is a marker for end of line. It is therefore not possible to split a non-transparent run into two runs without altering the image to insert a single transparent pixel between them. Or have I missed something?
Title: Re: Make world limits not forced to water level
Post by: Dwachs on May 11, 2013, 10:14:06 AM
As Turfit said, only the assembler code assumes runlengths<512. Hence only the assembler code needs fixing...
Title: Re: Make world limits not forced to water level
Post by: Ters on May 11, 2013, 11:05:55 AM
The way I understood TurfIt, the assembly must remain unchanged, and a maximum non-transparent run length less than 512 pixels enforced.
Title: Re: Make world limits not forced to water level
Post by: prissi on May 11, 2013, 02:41:28 PM
Most places in Simutrans is not too CPU critical; yes but unfourtunetly exactly this routine is where simutrans spend (in assembler form) about 20% of its time. This this is indeed some of the place which is. Allowing for larger length will mean that less of the code fits into the caache, and might reduce the gain of the assmbler code. (This needs to be checked of course, it is just a feeling.)

However, I fail to see the need of images larger than 500 pixels. Less than three of those will fit on a normal screen side by side!
Title: Re: Make world limits not forced to water level
Post by: Ters on May 11, 2013, 03:02:23 PM
Quote from: prissi on May 11, 2013, 02:41:28 PM
However, I fail to see the need of images larger than 500 pixels. Less than three of those will fit on a normal screen side by side!

But images less than 500 pixels wide become more than 500 pixels wide when zooming in.
Title: Re: Make world limits not forced to water level
Post by: TurfIt on May 11, 2013, 04:04:09 PM
display_img_nc() is *the* CPU hog affecting framerate. Many areas of Simutrans have the CPUs stalled waiting on memory access, this isn't one of them.
timing:

sync display
code pathms/frame
asm16.7
USE_C17.5
USE_C ALIGN18.2
USE_C WHILE17.7
NOTE: this is the total time spent in sync_step display - the % difference in just display_img_nc() is obviously much greater. 

asm is the default when compiled 32-bit on GCC.
USE_C is presumably close to what MSVC gets ( I need to still use ALIGN_COPY as display_fb_internal() USE_C code makes unwarranted assumptions that the GCC optimizer trips over. USE_C path in display_img_nc() is ok, but still normally forced to ALIGN_COPY for some reason, I bypassed the force for this...)
USE_C ALIGN_COPY is what you get on 64-bit  (or 32-bit GCC if explicitly told to USE_C)
USE_C WHILE is me replacing memcpy in the ALIGN_COPY with a simple while instead. memcpy will not inline when placed there, and function call overhead is huge in that loop. The while loops ends up vectorized to SSE2 instructions by the optimizer.

The vast majority of runlengths are <=4, and almost none > 12. I'm sure that's why this totally unrolled loop of MOVSDs works so well (I actually get a further speedup with MOVSWs!), and the compliers tendancy to try for larger moves is counter productive - the MOVDQAs from the while loop.

IMHO, the fix should be for the coding routines to check the runlen limit, and error there instead of the crash in _nc(). _nc() works good for the typical Simutrans graphics, so for the background display, create new display code in simgraph designed for long runlens leaving the existing alone.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 11, 2013, 04:44:46 PM
I'll say another of my crazy ideas, but...

Whoudn't be even better to have the image loaded uncompressed in-memory (without rle) and use SSE/MMX routines to do all the display?

This can be implemented in various ways, we can leave the image compressed to save memory, but on first usage, we just uncompress it and work with the uncompressed image instead.
Title: Re: Make world limits not forced to water level
Post by: TurfIt on May 11, 2013, 04:56:17 PM
Doesn't sound crazy to me...  ;D
Any idea what the impact on memory requirements would be?
And there's the risk of turning back from CPU bound to memory bandwidth bound...
Title: Re: Make world limits not forced to water level
Post by: Ters on May 11, 2013, 05:10:48 PM
For my current OpenGL project, I have uncompressed images. For pak64, this occupies 96 MB, although there is a lot of empty space, both because I round the texture up to a power-of-two and because I need to have all images at full width and height. Before I had to add the empty space (but still power-of-two), I think it was 24 MB.

This is however unscaled images. With images scaled up when zoomed in, the size will quickly become quite huge. Even more so with pak128 or pak192. There might still be Simutrans players with 1 GB RAM or less. These also have limited, or perhaps no, SSE. MMX might be universally available by now.
Title: Re: Make world limits not forced to water level
Post by: prissi on May 11, 2013, 08:04:23 PM
The RLE is actually not a compression, rather an optimisation. It just skips. Faster than not accessing display at all is not possible. Moreover, the images are RGB 555. I doubt that this can get much speedup using MMX commands.

During the last round of optimisation we tried MMX code. But it was slower, maybe due to the fact it needs at least 64 bytes or it is slower. With the 8-24 mentioned above it did not speed up.

If you blow up most images to tilesize x tilesize (and ignore that there are some larger ones), you will end up with images that are about 4 to 6 times larger (for vehicles) or 2x larger houses, so much more cache misses. I am also curious how you would implement the transparency there. But here I confer I might have completely misunderstood what you what to do.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 11, 2013, 08:04:56 PM
We can allways implement some kind of uncompressed images memory collector, that every 2-4 mins, deletes uncompressed images that have not been used.
Title: Re: Make world limits not forced to water level
Post by: Ters on May 11, 2013, 10:07:51 PM
Quote from: prissi on May 11, 2013, 08:04:23 PM
During the last round of optimisation we tried MMX code. But it was slower, maybe due to the fact it needs at least 64 bytes or it is slower. With the 8-24 mentioned above it did not speed up.

This code might be in some kind of sweet spot where whatever speed-ups one can get from rep movsw or MMX simply goes to waste in the logic needed for starting up and winding down. Since both at their core move relatively big chunks of data (according to an Intel manual I found, rep movsw actually ends up copying bigger pieces of data at a time than the w suggests), and the actual data is not a whole number of such chunks nor chunk-aligned, they need to start and end with some smaller moves. The Intel manual suggest rep movs would be best for almost a hundred elements or more.

The question is how much the loop would suffer from another if delegating runs of more than 512 pixels to less optimized, but more capable copy code. Or maybe the recoding could flag troublesome images, so that the switching between optimized and more capable code is done just once outside the loops. register_image also scans through all loaded and generated images and so could set this flag should an image have too long runs even from the start.

Quote from: prissi on May 11, 2013, 08:04:23 PM
If you blow up most images to tilesize x tilesize (and ignore that there are some larger ones), you will end up with images that are about 4 to 6 times larger (for vehicles) or 2x larger houses, so much more cache misses. I am also curious how you would implement the transparency there. But here I confer I might have completely misunderstood what you what to do.

There is another (http://forum.simutrans.com/index.php?topic=11796.0) entire topic devoted to what I'm up to.
Title: Re: Make world limits not forced to water level
Post by: prissi on May 11, 2013, 10:19:22 PM
Back to the original topic: I submitted a patch which uses the existing slope for an earth border. It can be disabled/enabled via simuconf.tab. Same for tiling.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 12, 2013, 12:42:47 AM
No background image nor world slope. Well, I guess I can consider my project ends here then. :)

btw, it has a bug, the routines in simview won't draw the borders of the tile that don't have their top visible:

(https://dl.dropboxusercontent.com/u/30024783/Untitled78.png)


Scroll sightly down and:

(https://dl.dropboxusercontent.com/u/30024783/Untitled79.png)
Title: Re: Make world limits not forced to water level
Post by: TurfIt on May 12, 2013, 01:06:48 AM
Bugs not withstanding, I don't see this as necessarily the end of your project. Simply the option to make things look more like they used to was added with the old ground outside tiling.

The background image I'm not keen on, but as an option why not...
And if by world slope you mean that simcity4 look, I'd very much still like that as an option.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on May 12, 2013, 01:40:36 AM
I like the effect of having earth borders. These are slightly broken for double height tiles at present though so will look at that in morning.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on May 12, 2013, 10:12:52 AM
Fixed display_border for DOUBLE_GROUNDS


void grund_t::display_border( sint16 xpos, sint16 ypos, const sint16 raster_tile_width )
{
if(  pos.z < welt->get_grundwasser()  ) {
// we do not display below water (yet)
return;
}

const sint16 hgt_step = tile_raster_scale_y( TILE_HEIGHT_STEP, raster_tile_width);

// fixme for double slopes!
static sint8 lookup_hgt[5] = { 6, 3, 0, 1, 2 };

if(  pos.y-welt->get_size().y+1 == 0  ) {
// move slopes to front of tile
sint16 x = xpos - raster_tile_width/2;
sint16 y = ypos + raster_tile_width/4 + (pos.z-welt->get_grundwasser())*hgt_step;
// left side border
sint16 diff = corner1(slope)-corner2(slope);
image_id slope_img = grund_besch_t::slopes->get_bild( lookup_hgt[ 2+diff ]+11 );
#ifndef DOUBLE_GROUNDS
if(  diff  ) {
diff = abs(diff)-1;
}
else if(  corner2(slope)  ) {
// no difference but a slope at the front => need an extra flat height step
diff = -corner2(slope);
}
diff ++;
// ok, now we have the height; since the slopes may end with a fence they are drawn in reverse order
for(  sint16 zz = pos.z-welt->get_grundwasser();  diff <= zz;  diff ++  ) {
display_normal( grund_besch_t::slopes->get_bild(15), x, y, 0, true, false );
y -= hgt_step;
}
#else
diff = -min(corner1(slope),corner2(slope));
sint16 zz = pos.z-welt->get_grundwasser();
if(  diff < zz && ((zz-diff)&1)==1  ) {
display_normal( grund_besch_t::slopes->get_bild(15), x, y, 0, true, false );
y -= hgt_step;
diff++;
}
// ok, now we have the height; since the slopes may end with a fence they are drawn in reverse order
while(  diff < zz  ) {
display_normal( grund_besch_t::slopes->get_bild(19), x, y, 0, true, false );
y -= hgt_step*2;
diff+=2;
}
#endif
display_normal( slope_img, x, y, 0, true, false );
}

if(  pos.x-welt->get_size().x+1 == 0  ) {
// move slopes to front of tile
sint16 x = xpos + raster_tile_width/2;
sint16 y = ypos + raster_tile_width/4 + (pos.z-welt->get_grundwasser())*hgt_step;
// right side border
sint16 diff = corner2(slope)-corner3(slope);
image_id slope_img = grund_besch_t::slopes->get_bild( lookup_hgt[ 2+diff ] );
#ifndef DOUBLE_GROUNDS
if(  diff  ) {
diff = abs(diff)-1;
}
else if(  corner2(slope)  ) {
// no difference but a slope at the front => need an extra flat height step
diff = -corner2(slope);
}
diff ++;
// ok, now we have the height; since the slopes may end with a fence they are drawn in reverse order
for(  sint16 zz = pos.z-welt->get_grundwasser();  diff <= zz;  diff ++  ) {
display_normal( grund_besch_t::slopes->get_bild(4), x, y, 0, true, false );
y -= hgt_step;
}
#else
diff = -min(corner2(slope),corner3(slope));
sint16 zz = pos.z-welt->get_grundwasser();
if(  diff < zz && ((zz-diff)&1)==1  ) {
display_normal( grund_besch_t::slopes->get_bild(4), x, y, 0, true, false );
y -= hgt_step;
diff++;
}
// ok, now we have the height; since the slopes may end with a fence they are drawn in reverse order
while(  diff < zz  ) {
display_normal( grund_besch_t::slopes->get_bild(8), x, y, 0, true, false );
y -= hgt_step*2;
diff+=2;
}
#endif
display_normal( slope_img, x, y, 0, true, false );
}
}
Title: Re: Make world limits not forced to water level
Post by: prissi on May 12, 2013, 08:32:01 PM
Thank kieron, submitted.

And personally I would not mind for a proper earth cut. I played a little around with graphics, but nothing I had was looking nicely. That could be entire due to my skills.

And without you this whole thing would not have taken off at all. Be proud of it!
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 13, 2013, 09:02:41 AM
mmm... I'll focus earth cut then, but I think I'll go back to the background image in the future maybe, drawing outside with a outside tiled ground-shaped image it's too limiting I think.

What I'm unsure is if implementing the ground cut as a list of height-color , and generate automatically the slopes on init like the climate code does or requiring the pak creators to supply a cut image.

I'd go for the list first, I guess, it's easy to implement, and I'm not really sure if our artists want to create the slopes manually.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on May 13, 2013, 10:12:58 AM
To be honest textured cliffs and artificial slopes is probably the way things should be headed.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 13, 2013, 10:27:18 AM
You mean generating the world slope in a similar way the climate code does? Requiring the pak creator to supply textures and generate a vertical stripe to use as border? If that's what you are suggesting, I can agree with you.

You can also make that list of heights, to refer to a solid color *or* texture.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 13, 2013, 11:14:55 AM
Elaborating this a bit more:

The slope *NEEDS* to be dynamic if it's to be implemnted, because the user can change water level and maximum height, so just allowing a variation of the sliced slope it won't be enpough, since we need to generate a full slope on map creation, I think. Also underwater slope needs graphics too, since from grundwasser (defaults to -2), to min world height level, (-10 or so), we need to show some seabed graphics,  to show variations on ocean level (comes to my mind the waters closer to the water level will be lighter blue, and deeper waters, will have to look more dark.

Have a look at simcity example, the one I planned to look similar to, and maybe my explanations make more sense. :)

Sometimes I'm very bad explaining myself, I'm sorry. ;)

(http://image.gamespotcdn.net/gamespot/images/2003/pc/simcityrush4/0929/sc_screen001.jpg)

Also examples of what I implemented so far in my tests, solid color:

(https://dl.dropboxusercontent.com/u/30024783/Untitled49.png)

And gradient (needs work, still, doesn't implement ocean)

(https://dl.dropboxusercontent.com/u/30024783/Untitled54.png)

About graphics for the non-world zone, I can just use prissi's implemented algorithm but at min_world_level, and not un water_level, now. It will look good enough. Even I'd like some day in the future to re-visit background image, but I'm not sure since it wasn't very welcome, even through I liked An_dz idea very much:

(http://img42.imageshack.us/img42/585/bhav.png)

What I'd also like is your double height patch implemented in trunk already, so I don't need to write two versions of this and just worry about the new situation.
Title: Re: Make world limits not forced to water level
Post by: kierongreen on May 13, 2013, 11:31:12 AM
Yep applying a texture to slopes is what I had in mind, with different textures for different depths and transitions between them. You wouldn't need an option for solid colours as you could use solid colour textures.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 13, 2013, 11:38:42 AM
Well, implementing both should be no problem I guess, since I can write generic code that interpolates two colors, and in the case of solid color I just get a fixed number as a parameter, and in the texture case, just the pixel that's in the corresponding position. I *think* it's easy to do.
Title: Re: Make world limits not forced to water level
Post by: IgorEliezer on May 13, 2013, 07:12:52 PM
Quote from: Markohs on May 13, 2013, 11:14:55 AM
(...)even through I liked An_dz idea very much:
*pic*
What if instead of a "square" grid it were a diamond grid? Like the tiles in the game.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 13, 2013, 07:27:25 PM
Well, the thing is it can be whatever the artist wants to be, that's good part of that implementation. I just supplied the chance for the artist to design whatever he wants to be.
Title: Re: Make world limits not forced to water level
Post by: prissi on May 13, 2013, 09:06:08 PM
You can get the diamond grid already using outside tiles and switching them on in you pakset.
Title: Re: Make world limits not forced to water level
Post by: An_dz on May 14, 2013, 12:25:57 AM
2 issues I found:
1. This is probably easy to correct, slope tools don't work on map borders. It's a little weird be able to create a mountain but not a simple slope.

2. 96comic have a different slope image. Rather than using images 8/19 bottom texture as images 4/15 it uses the same top texture. And it looks little weird in the world borders, I changed the code to only use images 4/15 on border and images 5/16 to all other heights. Here's the result:
(http://img69.imageshack.us/img69/1686/borderh.png)
It looks smoother, but since only 96comic have textures like described it's the only affected pakset.

Extreme easy and simple change:

Index: grund.cc
===================================================================
--- grund.cc (revision 6516)
+++ grund.cc (working copy)
@@ -971,7 +971,12 @@
diff ++;
// ok, now we have the height; since the slopes may end with a fence they are drawn in reverse order
for(  sint16 zz = pos.z-welt->get_grundwasser();  diff <= zz;  diff ++  ) {
- display_normal( grund_besch_t::slopes->get_bild(15), x, y, 0, true, false );
+ if (zz == diff) {
+ display_normal( grund_besch_t::slopes->get_bild(15), x, y, 0, true, false );
+ }
+ else {
+ display_normal( grund_besch_t::slopes->get_bild(16), x, y, 0, true, false );
+ }
y -= hgt_step;
}
#else
@@ -1010,7 +1015,12 @@
diff ++;
// ok, now we have the height; since the slopes may end with a fence they are drawn in reverse order
for(  sint16 zz = pos.z-welt->get_grundwasser();  diff <= zz;  diff ++  ) {
- display_normal( grund_besch_t::slopes->get_bild(4), x, y, 0, true, false );
+ if (zz == diff) {
+ display_normal( grund_besch_t::slopes->get_bild(4), x, y, 0, true, false );
+ }
+ else {
+ display_normal( grund_besch_t::slopes->get_bild(5), x, y, 0, true, false );
+ }
y -= hgt_step;
}
#else
Title: Re: Make world limits not forced to water level
Post by: kierongreen on May 14, 2013, 06:44:10 AM
This change will be moot once double heights are introduced anyway.
Title: Re: Make world limits not forced to water level
Post by: An_dz on May 14, 2013, 01:31:43 PM
I see, double heights don't have this double size images, it uses a single image per height.
Can't new image slots be used to add a top and bottom image? These would increase in only 4 images.
pak128 and pak96.comic would lose their top or bottom textures with this.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 14, 2013, 04:46:08 PM
5 bit per color won't allow for much gradient unfortunately...

(https://dl.dropboxusercontent.com/u/30024783/Untitled80.png)

Without textures this won't look very good.

EDIT: choosing levels a bit better, well, doesn't look so bad, but without textures it doesn't feel similar to the rest of the map, this needs texturing.

I'll implement seabed first and then texturing.

(https://dl.dropboxusercontent.com/u/30024783/Untitled82.png)
(https://dl.dropboxusercontent.com/u/30024783/Untitled83.png)
Title: Re: Make world limits not forced to water level
Post by: sdog on May 15, 2013, 02:25:09 AM
wouldn't a bit noise be enough to make the cut's face look good?
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 15, 2013, 07:58:06 AM
mmm... yes, it can work, something like a lightmap... I'll make some tests. :)
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 17, 2013, 04:42:39 PM
I made a lightmap fast implementation and it doesn't look bad, but I'm having some problems. Two questions:

On the climate code, calc_water_level() generates all required images, and stores them in ground_bild_list, a slist. Ok, it's needed to remove them on next re-generation, but I can't see at wich point in the code they are added to "static const grund_besch_t *border;", that member variable is inited to NUL, and I'm unable to see in wich part of the code it's assigned to some kind of complex structure, that's able to contain various bild_besch_t, that are later used in grund.cc . I guess it's obvious but can't  see where is that mechanism, anyone can point me what's behind this?

Another thing, it's I thought, related to PIXVAL values, that if the bit 15 in that value was set to 0, I caould treat just each component as 5 bits and be safe from special colors. Looks like not, because I'm getting dark blue pixels on the generated images. I'm wrong or the bug is anywere else?

(https://dl.dropboxusercontent.com/u/30024783/Untitled84.png)

It might be a bug somewere in the way I generate the image because when I zoom too much I get a crash, so I'm clearly doing something wrong. But what are those dark blue pixels doing there?

I'll show my code if you want, but I'd prefer to not do it so because I'm still ashamed of its quality, it's the first time I explore this part of the code and it's quite complex. It's full of tweaks and tests.

Thx. ;)
Title: Re: Make world limits not forced to water level
Post by: Ters on May 17, 2013, 04:54:35 PM
I assume that when you are referring to bit 15, you are counting from 0. What do you do if this bit is actually set? Special colors have a tendency to sneak into images from time to time.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 17, 2013, 05:07:09 PM
Well, yes, the highest weight bit in a 16-bit number, bit 15. :)

Well, I think I remember that all special colors had that bit set to 1, and that the ones with the bit to 0 are the actual game colors, that will get dark if you adjust night level. I just designed the routines that generate images to output pixels like 0RRRRRGGGGGBBBBB  and assume the color will be correctly treated.

I just basically generate a world slope that will cover the highest allowable slope in-map, with a color gradient, and then I apply a lightmap pattern to give it some texture. I mix both values with this routine:


static PIXVAL map_color(PIXVAL map, PIXVAL src){
   if(map==0) {
      return 0;
   }

   uint16 rc = red_comp(map);
   uint16 gc = green_comp(map);
   uint16 bc = blue_comp(map);

   uint16 rs = red_comp(src);
   uint16 gs = green_comp(src);
   uint16 bs = blue_comp(src);

   // overflow safe method ...
   uint16 rcf = (rc*rs)/31 & 0x1F;
   uint16 gcf = (gc*gs)/31 & 0x1F;
   uint16 bcf = (bc*bs)/31 & 0x1F;

   return (bcf)|(gcf<<5)|(rcf<<10);


}


The 1f masking it's not necessary I think, but put it the re to be sure...

The three missing routines are actually the same macro kierongreeen uses in the climate code.


#define red_comp(pix)         (((pix)>>10)&0x001f)
#define green_comp(pix)      (((pix)>>5)&0x001f)
#define blue_comp(pix)         ((pix)&0x001f)
Title: Re: Make world limits not forced to water level
Post by: Ters on May 17, 2013, 05:33:26 PM
So no color values come from loaded images? Because if they do, I would suspect that that image contains special colors. It does not appear that special colors in the source image files have the same value as they do when found in PIXVAL variables in the game, so that is something to look out for in that case.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 17, 2013, 05:37:01 PM
oh, that makes sense. the lightmap comes from a file, i'll have it a look thx. :)
Title: Re: Make world limits not forced to water level
Post by: Dwachs on May 17, 2013, 07:01:20 PM
Quote from: Markohs on May 17, 2013, 04:42:39 PM
I made a lightmap fast implementation and it doesn't look bad, but I'm having some problems. Two questions:

On the climate code, calc_water_level() generates all required images, and stores them in ground_bild_list, a slist. Ok, it's needed to remove them on next re-generation, but I can't see at wich point in the code they are added to "static const grund_besch_t *border;", that member variable is inited to NUL, and I'm unable to see in wich part of the code it's assigned to some kind of complex structure, that's able to contain various bild_besch_t, that are later used in grund.cc . I guess it's obvious but can't  see where is that mechanism, anyone can point me what's behind this?
There is this magic behind:

static spezial_obj_tpl<grund_besch_t> grounds[] = { ...
    { &grund_besch_t::borders, "Borders" }, ...

Afaik, these entries are assigned in grund_besch_t::register_besch(), which calles ::register_besch(), which is the method in spezial_obj_tpl.h
Title: Re: Make world limits not forced to water level
Post by: Ters on May 17, 2013, 07:11:34 PM
That is a common way for Simutrans to find mandatory besch-es by the way.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 19, 2013, 11:23:39 PM
Hummm.. you are right, the problem is the lightmap contained special colors, now looks better:

(https://dl.dropboxusercontent.com/u/30024783/Untitled85.png)

The crash on zoom in is as usual on last problems I use to face, a limit in simutrans code data types. Since the default slope I'm creating it's 416 pixels high and on big zoom levels I'm overflowing some limit, a 16-bit number I think.
Title: Re: Make world limits not forced to water level
Post by: prissi on May 20, 2013, 04:36:05 PM
I think there is no need to change the texture below 5 levels below the surface or so. (Most people will no look this deep, or?)
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 20, 2013, 04:57:33 PM
yep, prissi, I was thinking 4 or 5 levels under water too. there are just 3 depth levels in water,  so more than 5 are too much.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 28, 2013, 04:29:19 PM
I'm having problems as usual with this, have been hours trying to debug this with no success.

The image has no special colors, the generated slope has no special colors, I think the encoding is correct, but this still crashes on zoom-in, and I can't understand why. If anyone wants to have a look at this, I'd appreciate it, I'm quite sure it must be a stupid error but it's driving me crazy.

The slope is about 64x420 pixels, this should not be of any problem for simutrans to manage, but rezoom_img it's giving segfaults. I'm a bit desesperate and cluesless of where can the problem be. I know the implementation it's dirty and hackish, but I can't see any reason of why this shoudn't work.

I tested this on pak128.

https://dl.dropboxusercontent.com/u/30024783/slopes/segfault.patch
https://dl.dropboxusercontent.com/u/30024783/slopes/ground.LightSlope.pak
https://dl.dropboxusercontent.com/u/30024783/slopes/world-slope.png
https://dl.dropboxusercontent.com/u/30024783/slopes/world-slope.dat
Title: Re: Make world limits not forced to water level
Post by: Ters on May 28, 2013, 04:57:52 PM
The thing that goes kaboom when I try this (with pak64) is attempting to free the memory pointed at by zoom_data. I haven't had time to find out more than that yet.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 28, 2013, 05:13:09 PM
Yea, same on pak128, somehow the heap gets corrupted I guess because it's writing out of bounds. But why?
Title: Re: Make world limits not forced to water level
Post by: Ters on May 28, 2013, 06:22:33 PM
Sometimes my breakpoints in rezoom_img won't trigger at zoom_factor 0. If they do, freeing crashes then, if not, it crashes when I zoom back to zoom_factor 1. Most of the time I get a crash with a "complete" stack trace, but sometimes I get a trunkated one.




UPDATE:
I found something. rezoom_img() allocates two buffers of equal size (size), baseimage and baseimage2. If first writes to baseimage, then reads from baseimage and writes to baseimage2, then reads from baseimage2 and writes to baseimage, before copying from baseimage to a perfectly sized newly allocated final block of memory. However, at the third step (baseimage2 -> baseimage), baseimage is too small. When doing ((uint8*)dest) - baseimage when y=592, I get 60486, but size is only 60480. zoom_factor is 1 at this point, and y is supposed to continue up to 624.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 28, 2013, 07:34:59 PM
mmm.... Thx, that is certainly the cause of the heap corruption. Now I just need to know why it's writing more bytes that's supposed to, but it's indeed a very nice find. Thanks a lot Ters!

I checked and the re-compressing of the image doesn't render any transparent void zone that causes an exess size in bytes because of the RLE, neither could identify any special color being generated... But somehow the rezoom it's generating more bytes that's supposed to.
Title: Re: Make world limits not forced to water level
Post by: Ters on May 28, 2013, 07:39:47 PM
The question is whether it writes more bytes than it should, or if it supposes that there are fewer bytes needed to represent the image than can be safely assumed.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 29, 2013, 02:23:36 PM
It was indeed understimating the potential size of the image once recoded, I guess the algorithm never failed so far because simitrans had no scalable full solid images in any pak but my wild guess is this whould happen on all fully non-transparent images (just on those the height is more than 2 times taller than wide). Or even in a fully patterned image (one pixel transp, one solid pixel, one transparent, one solid...)

The "bug" come from simgraph16.cc, line about 1364:


// thus the unpack buffer must at least fit the window => find out maximum size
size_t new_size = newzoomwidth*(newzoomheight+6)*sizeof(PIXVAL);
size_t unpack_size = (xl_margin+orgzoomwidth+xr_margin)*(yl_margin+orgzoomheight+yr_margin)*4;


In my code, the image was about 32 x 620 pixels. The formula is not enough for the potential size of that image:

size_t new_size = newzoomwidth*(newzoomheight+6)*sizeof(PIXVAL);

I don't understand where that +6 comes from, but in a fully solid vertical stripe the correct size is:

size_t new_size = (newzoomwidth+3)*newzoomheight*sizeof(PIXVAL);

At zoom level 1, 3/2 zoom base_w 64 base_h 416  => w = 96, h = 624

size_t new_size = newzoomwidth*(newzoomheight+6)*sizeof(PIXVAL) => 120960 bytes buffer

at the end of the function zoom_len: 123552 -> We wrote out of bounds

with

size_t new_size = (newzoomwidth+3)*(newzoomheight)*sizeof(PIXVAL) => 123552 bytes buffer , no segfault


+3 because it will come as 0x0000 clear pixels, 0x0040 color run and 0x0000 to mark the end of the line.

A image could potentially be even larger if it used a pattern on transp-notransp pixels, that whould be, (I think)

size_t new_size = ((newzoomwidth*3/2) +1)*newzoomheight*sizeof(PIXVAL);

But I don't really think such a image exists anywere in simutrans, but who knows.

What do you think, am I right or have mislooked something?

Thanks for your help Ters! :)

Anyone knows where does that +6 come from? Because if it's for the extra bytes a rle-encoded image might add in respect a non-rle encoded one, maybe the safest definitive formula might be:

size_t new_size = (newzoomwidth+3)*(newzoomheight+6)*sizeof(PIXVAL);

But is this really necessary? I tested with just the +3 and all seems to work good...
Title: Re: Make world limits not forced to water level
Post by: prissi on May 29, 2013, 02:48:53 PM
Since it is only for rezooming, using the maximum possible size with transparency is probably even better to fix this once and for all. The pixl/transparent/pixel is used very frequntly in shadows of trees.
Title: Re: Make world limits not forced to water level
Post by: Markohs on May 29, 2013, 04:01:01 PM
Commiting this to trunk if nobody says the opposite soon then:


         // thus the unpack buffer must at least fit the window => find out maximum size
         // Note: This value is certainly way bigger than the average size we'll get,
         // but it's the worst scenario possible, a sucession of solid - transparent - solid - transparent
         // pattern.
         // This whould encode EACH LINE as:
         // 0x0000 (0 transparent) 0x0001 PIXWORD 0x0001 (every 2 pixels, 3 words) 0x0000 (EOL)
         // The extra +1 is to make sure we cover divisions with module != 0
         // We end with a oversized buffer for the normal usage, but since it's re-used for all rezooms,
         // it's not performance critical and we are safe from all possible inputs.

         size_t new_size = ( ( (newzoomwidth*3) / 2 ) + 1 + 2)*newzoomheight*sizeof(PIXVAL);
Title: Re: Make world limits not forced to water level
Post by: Max-Max on June 04, 2013, 07:50:52 PM
Quote from: Markohs on May 14, 2013, 04:46:08 PM

I'll implement seabed first and then texturing.

(https://dl.dropboxusercontent.com/u/30024783/Untitled83.png)

Is this with texture or auto generated? In any case I like this version most :thumbsup:
Maybe this can be the fallback if there are no special images defined in the pak for "map walls"?
...or configurabel like textured map walls on/off...
Title: Re: Make world limits not forced to water level
Post by: Ters on June 04, 2013, 08:26:53 PM
It's the troublesome texture I had to help debug above. Looks a bit different since that screen shot, as can be seen in later screen shots.
Title: Re: Make world limits not forced to water level
Post by: Markohs on June 05, 2013, 07:42:23 AM
that's the slope without a lightmap applied.  You can achieve the same effect with a 100% white lightmap. lightmap is important because south slope it's suposed to receive more sun than east one, simutrans sun comes from south.

on my last screenshots my lightmap was too dark, I made a much lighter version I'll show here soon
Title: Re: Make world limits not forced to water level
Post by: Max-Max on June 05, 2013, 02:13:06 PM
Looking forward to this implementation, looks really nice  :thumbsup:
Title: Re: Make world limits not forced to water level
Post by: Markohs on June 07, 2013, 02:04:24 PM
 While developing this, I noticed there are not much image creation and management routines in the game, just like the climate code does, this patch needs to create new images each time the world is created. kierongreen aproach to this was duplicating the image and rotating it if necessary. It's all implemented around bild_besch_t::copy_rotate.

I need to create *new* images, with arbitrary size and recode them using them the RLE, do you think it's a good idea to place this routines in bild_besch_t , routines that accept a uncompressed buffer and compress it or it's not the right place to code this?

Just asking, I'm doing it that way, but wanted to hear your oppinions for the case you point me to a better solution. We could maybe implement that in simgraph16.cc (rezoom routines are there), or in a new collection of routines called bild_tools::* or image_tools:: . Dunno.
Title: Re: Make world limits not forced to water level
Post by: prissi on June 07, 2013, 08:41:13 PM
The world limit should be also part of the ground images, imho. I would reuse the code from there. (And it generates new images, by combining three images or four.
Title: Re: Make world limits not forced to water level
Post by: sdog on June 07, 2013, 11:05:29 PM
112.3 is already in an official package for arch.
i've just started it up and had a look at it for a moment, it really looks good. Thanks a lot Markohs et al!
Title: Re: Make world limits not forced to water level
Post by: Markohs on June 08, 2013, 01:56:14 AM
Thx sdog. :)

@prissi: Okay, I'll try to mimic ground images code then. My initial approach is just one image per slope, no need to add even more images to simutrans if I can avoid to, we have more than enough. ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on June 25, 2013, 03:57:54 PM
It's been some days since I coded something, back to war. Not much to show, I just added a few routines to bild_besch.cc to create images on the fly from a buffer. At calc_water_level I get wasserlevel = -82 now, I think a change in trunk changed this, I was getting -2 before, this makes the tripe too long.

The display has clipping and display errors, but it's a first step. For the curious developers, here is the code, comments welcome ofc.

https://dl.dropboxusercontent.com/u/30024783/worldslope-merged-double4.patch (https://dl.dropboxusercontent.com/u/30024783/worldslope-merged-double4.patch)
Title: Re: Make world limits not forced to water level
Post by: Markohs on June 28, 2013, 10:43:03 AM
Still full of errors, but some progress:

(https://dl.dropboxusercontent.com/u/30024783/Untitled87.png)

I thought it was as easy as single height paks had 1 tile height step difference in the y axis, I was wrong. I have to fix this. Also have to find a place to do this so wasserlevel is not -81. Still WIP ofc. https://dl.dropboxusercontent.com/u/30024783/worldslope-merged-double6.patch (https://dl.dropboxusercontent.com/u/30024783/worldslope-merged-double6.patch)

Offsets and east border is obviously very wrong now atm. ;)


(https://dl.dropboxusercontent.com/u/30024783/Untitled88.png)



(https://dl.dropboxusercontent.com/u/30024783/Untitled89.png)
Title: Re: Make world limits not forced to water level
Post by: jamespetts on June 29, 2013, 09:54:55 PM
Despite the bugs, looking good!
Title: Re: Make world limits not forced to water level
Post by: Dwachs on July 12, 2013, 08:13:56 PM
There is this bug report:

http://forum.simutrans.com/index.php?topic=12135.0

The reason is: loadingscreen_t does not set the world's background dirty. It cannot as it does not know of any world.

How to fix?

Move the background-dirty stuff to simgraph? Add karte_t* static member to loadingscreen_t?
Title: Re: Make world limits not forced to water level
Post by: Ters on July 13, 2013, 09:28:27 AM
A loadingscreen_t doesn't appear on its own. Something is causing it to appear. I think it might be better to mark the world as dirty further down the stack, though that might be quite some way away in the network code.

This is something that would have benfited from a global world, although loadingscreen_t would have to be a bit careful, because I don't think there is any world at all when it is first used.
Title: Re: Make world limits not forced to water level
Post by: Markohs on July 15, 2013, 10:13:04 AM
mmm... well, yes, setting world dirty makes sense, and it's what should be done. Ofc the world *might* not exist on a loadingscreen_t destroy.

If we are going to turn the world a global variable or a singleton (I don't know if there is a consensus in that issue), just mark the world dirty. I'd go this way, static karte_t::singleton->set_dirty()

*but* if this are not the plan, I'd just add karte_t * to the loadingscreen_t::loadingscreen_t(karte_t * world) constructor allowing it to be NULL, and just marking dirty if the world exists.

I don't like loadingscreen being a class, forcing a creation/destruction leads to issues similar to this one, but well, we have it like is now, and the only two options are those I exposed.

I can implement it, ofc, wich one do you prefer? ;)
Title: Re: Make world limits not forced to water level
Post by: Markohs on July 16, 2013, 11:49:19 AM
Seeing noone wants to give his opppinion, I'll implement this adding the function to simwin.h, we have the world accesible in that file. it's the easiest solution and makes enough sense, until we decide if we want to make the world a global variable (I'd take this option), a singleton or keep having the possibility of having multiple simulated worlds in-game.
Title: Re: Make world limits not forced to water level
Post by: Markohs on July 16, 2013, 12:03:57 PM
Commiting this to trunk soon if noone has something to say about it. ;)

https://dl.dropboxusercontent.com/u/30024783/ls_bug.patch
Title: Re: Make world limits not forced to water level
Post by: Ters on July 16, 2013, 02:10:51 PM
Using the world the window manager already knew about was a good idea.
Title: Re: Make world limits not forced to water level
Post by: Markohs on July 16, 2013, 03:35:39 PM
Thx Ters, I think it's the simplest solution and less intrusive one. Let's see if someone has something alse to say about it and I'll commit.
Title: Re: Make world limits not forced to water level
Post by: prissi on July 16, 2013, 04:04:52 PM
Do it, such a function may be handy also for other occasions.
Title: Re: Make world limits not forced to water level
Post by: Markohs on July 16, 2013, 04:34:47 PM
Commited @6591
Title: Re: Make world limits not forced to water level
Post by: Max-Max on October 08, 2013, 04:08:55 AM
how did this end? Are there new ground images for this?
Title: Re: Make world limits not forced to water level
Post by: Markohs on October 08, 2013, 06:59:44 AM
nope, I paused development on it. It was a complex addition, not only required implenting in game image creating,rle compression and register  (I see you implemented that in your code) but drawing that slope with diagonal clipping, and modifying the world drawing algorithm in a way that didn't affect performance,  wich I was unable to realize.  It also required deep water altering tools. The thing is having prissi's simple and good looking world slopes implementation I'm not so sure if this is a good idea. I was also quite exhausted of this, so decided to look elsewhere for a while and look back to it later. Why do you ask?  wanna have it a look yourself?  I can post the WIP patch, iirc it segfaulted a lot and needed a lot of extra work, but the slopes were cool looking.
Title: Re: Make world limits not forced to water level
Post by: Max-Max on October 08, 2013, 01:36:09 PM
I have not gone beyond the GUI stuff yet, I'm still 100% on themes and GUI. There is still a looot of things to do. It goes kind'a slow because I have to wait for the trunk merge after each submitted patch.

Well, your project looked so nice and I was only wondering what happened to it. usually it is a good thing to focus on something else for a while, then suddenly out of the blue the solution pops up!
Title: Re: Make world limits not forced to water level
Post by: prissi on October 08, 2013, 09:09:34 PM
One could still use a texture which is blending a color depending on the depth. On a black background it does not alter color, so one would only need slopes. (One may even blend slopes for the moment.
Title: Re: Make world limits not forced to water level
Post by: Markohs on October 08, 2013, 09:25:01 PM
Yep, that's what I implemented so far, prissi, but it's incomplete.