Network Diagram Tool Integration in Simutrans

[yorkeiser]

@Markohs: you're nice, but til now it seems to me a quite poor job, I'd like to have more experience on sources... Let's say it's a beginning

@Vonjo: Many thanks also to you, also for your good changes on the Java version.
In the first attempt I made, the lines were effectively drawn on the minimap (I didn't even know how to fill a white minimap ) but the result was a not readable map: too many colors, a great confusion. Consider that simutrans has only 255 colors if I didn't misunderstood the code (and I don't know if you can use even them all) so it's difficult to make differences between map objects and lines, as I did in the Java version that uses a 24 bit palette. If Simutrans supports alpha channel for colors (transparent colors) I can try to draw a lightly transparent map and full colors for lines, that could maybe be a good compromise.

[Markohs]

If Simutrans supports alpha channel for colors (transparent colors) I can try to draw a lightly transparent map and full colors for lines, that could maybe be a good compromise.

Atm simutrans blending routines don't support an alphachannel, but, in my oppinion (and this has to be considered by prissi and the developers), I think it whould be a good idea if your code just did the output in 32-bit RGBA so we could mix it with the other map.

The OpenGL backend whould be able to mix that image with the rest in hardware, and we could implement a sofware routine that did the same, for the rest of backends.

But that's just a suggestion, let's hear what the rest  of developers think about it.

[isidoro]

Very nice work, yorkeiser!

My opinion is that I wouldn't mind very much about a certain implementation of graphic primitives, just encapsulate them in methods: draw_ellipse, fill_background, etc.  Use these methods and, once done, those methods may be changed to more optimal routines, or even make them dependent on the backend, as Markohs suggests.

[yorkeiser]

Update:
- removed terrific ovals for city bounds, not really useful imho
- hidden vehicles when in map/graph viewing
- drawn dotted lines for non-rail lines (implemented a routine for custom line dotting)
- when you hover the mouse on a stop, a label displays line name+stop name (as for "Show schedule" functionality)
- first conversion of code for "rail graph" functionality

Here are some preview pictures, just to show how the map is displayed after those updates and with different background choices: white background, black background, existing map background. In my opinion white background is by far more readable, however I'd like to hear what you think. This function seems to me having already a good performance, being map drawn immediately. Probably I have to add a better color cycling, cause I notice a great number of yellow lines, thus I suppose that yellow is assigned to different colors in Simutrans' palette









Finally, a preview of the map graph constructor, that's still in an early stage of development; actually this function seems to have serious performance issues, cause it freezes map for one/two seconds when building the graph on an average computer. It seems strange to me, because its java counterpart was quite immediate, however I must investigate how simutrans calls that routine, and in addiction code is not really optimized.

[Carl]

Looking very good!

[rsdworker]

wow - that's looks easier for me to compare and make notes

[Fabio]

Very promising!

Could you use a single coordinate for each station? You could pick the one with the station name label.

Station served by more than one line should have a bigger circle painted, as they are interchanges, whereas the small square is good for secondary stops.

does it show only pax lines?

[yorkeiser]

Could you use a single coordinate for each station? You could pick the one with the station name label.

A single coordinate is already used, but it's not the one with the station name, it's the coordinate in the schedule (e.g. when you open line schedule, for every stop in the schedule you see Station name + coordinate -> that coordinate is used)

Station served by more than one line should have a bigger circle painted, as they are interchanges, whereas the small square is good for secondary stops.

This is a very very nice idea. Theorically it could be implemented with no problems, but I'm afraid of performance issues: I actually don't save stops in any structure, I simply read player's schedules, read stops in the schedule and plot them, so I've no memory of what has been plotted. To fulfill your request, I think I would have to store stops to be displayed in some data structure, saving also stop's name, and then count lines entering/exiting in every stop NAME (not coordinate, because two schedules can enter in the same multi-tile station with different coordinates) and thus choose the right mark (square, big square, circle etc). Really interesting, I'll do a think about this.

does it show only pax lines?

It shows all lines returned by:
welt->get_spieler(i)->simlinemgmt.get_lines(0,&lines);
I think this should return schedules of all types; I couldn't test on my savegames cause I only play pax games, however some developer can easily answer to this.

[Fabio]

Single coordinates: I see you're using the one in schedules. Problem is that multi platform stations have different coordinates for coming and going, so lines are not that nice, e.g. between Modena and Reggio.
If you stored a SINGLE coordinate and lines for each station, this problem could be addressed together with the interchange one.

[Carl]

Even single platform stations can have different coordinates for coming and going, assuming that the single platform occupies more than one tile.

[rsdworker]

@Milko: it depends on the community's interest. I can always use my programs; if others are interested, I can publish them also for others
And in addiction, you can refer also to Vonjo for the external version, he's already well-worked on it: until no one makes money on the code (and I don't see how to make money with this), everyone is free to modify and compile his version, or ask for changes on the "official" version.
I think external version will stay alive for a while, because actually I don't know if train graph functionality can be implemented internally without affecting performance, but i also think that using only xml savings can seriously affect its usefulness, if you can have an internal version that does the same thing.

nice so i can test the internal one?

[yorkeiser]

@rdsworker: surely I could compile a custom version and provide for testing, but before doing this you need to ask prissi, cause I don't know Simutrans' redistribution policies and I'm not an "official" developer

@fabio: now I understand what you mean. Map viewer wasn't originally designed with this in mind (map graph has this concept, indeed), but I agree with you that this could be a nice improvement. I have to see how this affects performance.
Also consider that line between Modena and Reggio, in reality are two different double lines that run in parallel: they are drawn with the same yellow color only for bad color cycling, they would have to be different in colors. With the modification you propose, only one line would be plotted, cause they always start and end in the same stations. Map graph indeed has the feature of drawing parallel lines, but for doing this I have to build a preventive structure mapping a node-arc graph, which affects performance. However, I repeat, your idea is clear and well-thought, I must to do a thought about how this can be realized with few cpu time 

[kierongreen]

To allow people to test I would suggest that you post a patch file showing the changes you have made to the sourcecode. You can provide an executable for people unable to compile their own version too if you wish. This would satisfy the simutrans licence conditions (you can read the full list in it if you want, there is an option if you don't want to provide the patch file for some reason).

[prissi]

You could also base the sizue of a station on the number of halt tiles or the number of convois departed. THose statistics are avalable (also the lines have a number transported and number of convois in the statistics). The number of lines at a stop are available too, just look at the station-details frame.

[yorkeiser]

@kierorgreen: I can't automatically create a patch file because I work off cvs (due to my network limitations, I can't access it). I surely can create a txt file telling where to put changes (99% in karte.cc), but I don't think this is really handsome, and mostly this part is still under heavy development, so I think it wouldn't be really useful manually writing a patch that would be already outdated tomorrow. However, if you think this can be useful, I'll produce the .txt

@prissi: this is also a very good idea. Depending on the approach you choose, you can consider a station bigger/more relevant than another, and mark it on the map, according to:
- Morphologic reasons
  + having rail connection
  + rail/bus/air or other interchange (more line types in a single station)
  + number of lines connected (haltestelle_t::get_connections() could be the right method?)
  + number of tiles
- "Business" reasons
  + number of vehicles, or passengers, or cargos (you need a weighting function between pax and cargos, and in addiction the threshold must be related to time and other stations, because 1000 pax departed in the beginning of the game is not the same than 1000 pax after 200 years)

Of course anyone could have a different idea/preference about this; and of course, every opinion is welcome

Finally, this is how map looks using station center coordinates rather than schedule coordinates, as fabio suggested

[prissi]

Since you know interconnections, color local lines (only connected to one large hub) with short ratios to stops/distance) in each city (hub) with the same color sequence, and have a second color scheme for long distance lines. THat way they would look at least consistenctly

[Fabio]

Much better now! Thanks!

[yorkeiser]

Since you know interconnections, color local lines (only connected to one large hub) with short ratios to stops/distance) in each city (hub) with the same color sequence, and have a second color scheme for long distance lines. THat way they would look at least consistenctly

Sorry prissi, probably this is due to my english lacks, but I'm not sure I understood what you mean... All bus lines departing from an hub would have to be colored with the same sequence of colors? E.g. HUB1 -> line1 red, line2 blue, line3 yellow; HUB2-> line1 red, line2 blue, line3 yellow?

[VS]

Perhaps prissi meant that instead of coloring each line differently, you can color them according to some "locality weight"...

[prissi]

@yorkeiser:
Yes exactly this is what I meant. THus you can optimise a sequence of colors for good visibility. Maybe even a second sequence for trams, and one for trains ...

[Fabio]

I guess he means exactly that.

Another few suggestions (more will follow as I think of ):

(1)
Line styles:
- trains, trams, monorail could be 2 px wide solid line
- busses could be 1 px wide solid line
- ships could be dashed lines (color: shades of light blue [IT:azzurro], like Catania Cremona, cosenza, Vicenza urban lines)
- air could be dotted lines, possibly curved (beziers lines, Timothy could help you on that?) (color: shades of light blue [IT:azzurro], same as for water)
- cargo and mail: shades of gray (style according to transport type); they could be optionally disabled.

(2)
City names could be drawn ATOP lines

(3)
Lines could have rather strong colors (e.g. red, orange, yellow, darker blue, darker green, purple)
Feeder lines (connected to a single hub, like city lines connected to a railways station), could have the same color of the main line, but lighter and slightly desaturated. Or they could have a different set of colors, like Prissi suggested.
Maybe we could set a list of desired colors, then arrange them is nice-looking sets.

(4)
What are the 2 bus lines north of Arezzo and west of Napoli and Potenza? Are they serving attractions?

[yorkeiser]

@prissi, having said that the actual color sequence must surely be changed (actually I trivially cycle on all colors from 0 to 255), maybe this solution could take to lines color flattening, depending on morphological structure of the network?
I try to explain what I'm figuring: I often have a main train line that connects X cities, and a bus line for every city, mainly in earlier stages of the game (<50 years). With this solution, I would have (let's say) a blue train line and X red bus lines, sometimes very near each other, and maybe this could take to confusion and not good distinction of different lines. Even if you have 4/5 bus lines per hub, you use a short range of colors (4/5) for near regions of the map, while you ignore other 250 colors...
Of course this is stricly related to the network morphology, and any user has his different game style that affects it.
However, this is only a theorical thought, I haven't a clear vision of the result with such an implementation...

@fabio:
1) these are all really good suggestions and I want to try implementing them. My only doubts are related to beziers: I don't know how they could affect performance, consider that lines are redrawn every x frames

2) I strictly agree

3) Good idea, as prissi's one (both strategies are very valid), but there are the same doubts related to risk of local transportation confusion, as I said replying to prissi

4) They are two passenger tram lines serving factories in the northern

[Fabio]

New Integration thread in Projects board... now waiting for news

[yorkeiser]

Thanks fabio, I think it was a good idea to split threads for the two tasks.
From tomorrow, I'll be away some day and go to center Italy to see my family for easter holidays (if they didn't forget me yet...), so I think I'll have no much time to work on this until next week. However, at least I'll have some news about development to fulfill new requests, I'll immediately post an update.
Meanwhile, whoever has some requests or suggestions about network drawer, feel free to post them here, I'll read them at my return.
Cheers, and good easter!

[Fabio]

Happy Easter to you, too, and for all people celebrating it!
(I'll be away a week as well)

[yorkeiser]

Some update, just to show that work is still in progress Focusing on line drawing, these are the main changes:

- Added simple bezier drawing routine for air lines
- Different line styles: rail line drawn as 5 pixels solid line, tram line 3 pixel solid line, bus line 1 pixel solid line, air line 2 pixel dashed bezier curve , other lines 3 pixel dashed line
- Different stop styles: rail 5 pixels square, others 3 pixel square
- City names are now on top of other graphic items
- Stop squares have now player's color (useful, I think, to recognize lines belonging to different players in multiplayer maps)

Todo: many things, beginning from a better color cycling strategy, but I'm experiencing enormous difficulties to implement a strategy based on morphology as fabio and prissi suggested, because of actual line plot strategy, that is sequential.
However, here's a preview of actual version, just to show new look, and beziers drawing

[Markohs]

Good work!

[Markohs]

oh, btw, yorkeiser, I did a doxygen documentation generation time ago that might be useful to you, it's here

[yorkeiser]

REALLY useful Markohs, thanks! For non-experienced simutrans coders it can really save much time.
One question: class/interface/method descriptions were added by you or are automatically generated from comments that are already in source code?

[Markohs]

REALLY useful Markohs, thanks! For non-experienced simutrans coders it can really save much time.
One question: class/interface/method descriptions were added by you or are automatically generated from comments that are already in source code?

Glad it's useful to you.

The comments are generated automatically from the code comments.

It's javadoc style, on top of a definition comment like this (note the two asterisks at the beggining of the code /** ):

Code Select Expand


/**
* verbose description of the function
*@param a description of a
*@param b description of b
*@return desctiption of return value
*/
int examplefunction(int a,int b){
}


You can also  comment class members, variables, class definitions...

[Fabio]

Very, very beautiful!

Some notes:
- Stops should always be on top of lines, check Milano2 railway station to see what I mean.
- show schedule / mostra programmi option might be obsolete after your improvement, so it might be dropped altogether or made use your drawing routines.
- Cities / Città button could be made an independent option, to show city names or not whatever button is selected (enabled by default).
- airports and could use 9x9 squares
- what about using circles instead of squares?
- you could try, instead of white background, a semi-transparent (75% opaque)  white layer drawn above normal map.

Thanks for your work!

[yorkeiser]

Thanks fabio In reply to your notes:
- There must be a little bug, because as far as I've seen it's the only station "masked" by line... mmh I have to investigate
- I think actual line drawing of "show schedule" can surely be improved, but I also think this functionality is very useful in order to find a single line on map. Map viewer instead gives a "general" schema of the network, but can't actually help you finding single schedules on map. I think this feature surely deserves a deeper discussion involving also other users
- Do you mean I can add a toggle button (near "show schedule" etc...) to show/hide cities? If so, it could be a good idea, but we'd have to think how that new button behaves on other minimaps (cities, pax, stop status etc)
- Very good idea (in fact, airports are generally more relevant than train stations in real world). I also thought we could use a special symbol instead of the square for airports, as I've often seen on maps, eg a stylized airplane.
- Circle drawing is slightly more expensive in cpu time than square drawing, and usually there are many stations on the map, so this can affect performance. Of course I admit that circles probably would give the map a better look
- I already asked if that is possible, but I was answered that simutrans doesn't support alpha channel (transparent colors). However, when in game mode you can effectively have some transparency (eg for station covering) so I think there is probably a way to "simulate" transparency. But I need the help of someone more experienced than me to understand how to achieve color transparency on minimap, if it's possible.

Many thanks for your (wagon of) ideas, you're giving an enormous contribution to development and graphical improvement

[Markohs]

About the alpha channel, prissi/Dwachs knows better than me, I was just looking that part of the code still for the CEGUI backend. And on CEGUI, it's possible to have various RGBA layers on top of the other, that's why I suggested you creating it. In wich file/fclass did you hooked your current code? I'll have it a look while prissi/dwachs say something.

[yorkeiser]

@Markohs
I've put graphical primitives in simgraph16.cc (there are already other primitives, as display_direct_line()), while map drawing (players/schedules/stops cycling and primitives calls) is done in karte.cc, class reliefkarte_t, method void zeichnen(koord pos)

[Dwachs]

as to transparency: there are this blend-something functions in simgraph16.cc: They draw something on top of something else and create transparency effect. So transparency is controlled by the upper layer (let the lower layer shine through). One cannot however control this by the lower layer (ie make the upper layers transparent). I hope this helps.