Quote from: yorkeiser on January 31, 2011, 11:39:17 AM
Still here with a passenger-only network. [...]
Here's the schema of the network, automatically generated by a Java tool I'm writing - I always dreamed that the built-in map viewer could show all the lines on the map and mark them with different colors ;D
(http://simutrans-germany.com/files/upload/LineMapper3_Thumb.png)
(http://simutrans-germany.com/files/upload/LineMapper3.png)
In this map, thicker lines are railroads, normal lines are surface lines (buses and monorails), dotted lines are sea lines.
Quote from: fabio on January 31, 2011, 02:47:46 PM
There is already a function to show a selected line on minimap. Could it be possible to patch the program to display them all at once?
Quote from: yorkeiser on January 31, 2011, 03:38:10 PM
Yes, you're right Fabio, and I think it would be very easier to write an internal class/function/plugin that already has access to the variables it must use, rather than using an external tool that relies on the binary format of the .sve file, that besides is quite cryptic and can change in the future. However, the functionality would have to draw on a white (or however monochromatic) field, otherwise i think it would result unreadable. I don't know if this is actually possible; it seems to me that at the moment the various map visualizations are always drawn above the classic map background (greens for terrain, blue for sea and greys for cities/roads), isn't it ?
I copy here this request: as there is already the function to show the selected line on minimap, could it be possible:
1- an option to display ALL lines on minimap
2- an option to "hide" the minimap itself with solid colour and display only the lines (or another statistic es. passengers, industries, etc...)
3- an option to export the current minimap view (including options 1 and 2) as PNG
Developers' heads will now explode :o
I support it. It's a simple and cool way to display important info for players.
On a minimap this is probably not very well visble. Other than that, if you are not caring about straightening or any other beautifying, it is very simple (and visially ugly). It was discussed a lot, but aparently the code to straighten and make more beautiful abstract network maps is not yet released in a useable format out there.
Let's say this (without straightening) would be already a good piece of cake, which could keep players content for a while :)
maybe also thickening the line from 1 px to 3-5 px would improve the general look of it.
Also "hiding" minimap with a background solid colour (mostly, white) shouldn't be difficult and would already improve things widely.
If you do a c++ version, it would be something to integrate into simutrans ...
Is it possible to port code from Java to C++ in a convenient (!= rewrite from scratch) way?
Adding this tool to the game would be an awesome addition!
This surely could be integrated in simutrans, because I don't use Java-specific libraries - except java swing for drawing on screen, of course -, I only use ArrayLists, custom classes and simple mathematical instruments.
However, I really don't have the knowledge to port it into simutrans, not for the language (I'm quite able to write c++) but because it would take me too much time to understand the architecture of the program and where to code what.
If someone wants to try for it, of course I'm fully available to share the application's code.
@fabio: I think the major problem here is not code-porting, but code integration. This is a stand-alone program that uses two main structures (one for cities, one for lines, that has a sub-structure for storing lists of stops), and all the code uses those structures as an input. I don't know how simutrans stores those data. Another problem could be performance: actual diagram routine is quite expensive in cpu time: in c++ it surely would be lighter, but it could give problems having the game that runs in background.
Quote from: fabio on March 09, 2012, 11:51:38 AM
Is it possible to port code from Java to C++ in a convenient (!= rewrite from scratch) way?
Adding this tool to the game would be an awesome addition!
Maybe the better approach would be a way to convert sve savegames to their xml equivalent, so external tools can work with them.
Or come up with specs for the sve format.
Whoudn't be great to be able to generate and display this graphs in-game and be able to export them as .png from inside the game? Shoudn't be too hard to adapt your java program to C++ code, maybe.
Quote from: fabio on March 16, 2012, 12:12:43 PM
:thumbsup:
We just need someone to help integrating with the existing code... do you volunteer? ;)
Actually, I was thinking on trying it, since the CEGUI project is giving me lots of insights of simutrans code, this could be interesting for me to go even deeper. I'll have it a look, but I don't promise anything, yet. Maybe not the train line diagram, but the map layout one looks interesting. :)
Quote from: Markohs on March 16, 2012, 12:26:46 PM
Actually, I was thinking on trying it
and you got a preemptive +1 in helpfulness, as I really hope to see that in the game one day ;)
yorkeiser, I can't see the source files anywere, just the .jar, are you sharing your code in some open license? :) Just to have somewere to start from.
EDIT: Thx, fabio. :)
Quote from: Markohs on March 16, 2012, 12:36:52 PM
yorkeiser, I can't see the source files anywere, just the .jar, are you sharing your code in some open license? :) Just to have somewere to start from.
EDIT: Thx, fabio. :)
Markohs, I don't actually publish the code in the jar since this is still a work in progress, the code is very far from being finished (and cleaned).
However, as I said, I gladly share the code and help/support whoever wants to try to import this into simutrans.
If you send me a private message with your e-mail address, I'll be happy to send you the jar with included sources ;)
Quote from: Markohs on March 16, 2012, 10:57:28 AM
Shoudn't be too hard to adapt your java program to C++ code, maybe.
It's easier than the other way round. But be careful, Java programs are full of "new" operators, but you must find out where to put the "delete" operators in the transformed code, because Java has garbage collection and C++ has not (by default). It can be tricky to determine the lifetime of all objects correctly.
Just got the source code from yorkeiser. Currently focused in the OpenGL backend and some other things, I'll have it a look when I got some time. If any other developer is interested to have a look to the code or wants to take this extension request, send me a PM. :)
It would be most likely best to have it anyway as a simutrans dialoge. Then it could also make line in the thickness of the transport of the line, indicate lines with no free capacity and so on and user interaction is there too.
It's a kind of intimidating task, at least it looks so to me. I have ported C and C++ code to Java in the past, not the other way round, but it was a quite tedious undertaking. Java to C++ should be a bit easier, but still - you must change each and every call to a Java standard library to something that is available in C++ and the ST runtime environment.
Also there are idioms that work well in one langauge but badly on the other, and so to have a good implmentation, it needs to change more than just translating the syntactical constructs.
If it was easier, I'd start to port Simutrans to Java, since I can develop much quicker in Java than I can develop C++.
Hi Hans, you're right, it surely is not so easy in general.
However consider that in a similar tool, most of the library calls rely on the graphic aspect/event handling, but I don't think this part must to be ported to Simutrans, because these are related to the structure of this program, that is a stand-alone application. Maybe only simple evens, like line toggling.
Draw operations only involve string, line, rectangle and oval design: I think you already have routines to draw these objects in Simutrans, cause they already are displayed on the map. So, I think it would be enough to change graphic calls with the standard ones you already use in simutrans.
Data structures are simple arrays of objects, that are already supported by c++, they only must be mapped with the ones Simutrans already uses (I suppose that in Simutrans there is already a list/array for cities and one for lines).
The most problem, I think, could be to delete objects, cause c++ has no native garbage collection, as far I know.
I don't know, maybe a JavaSimutrans would be really slower than the c++ version... On the other side you're right, a managed language lets you be more productive (less code to be written), there's no doubt.
The slowdown varies a lot. Some code that ported from C to Java 1.1 saw a slowldown of a factor of 40 (but Java 1.1 had no JIT yet), some other code was almost as quick in Java, because Java itself hands a lot of work to native libraries. If it wasn't such a huge endeavour I'd try it, I think the slowdown wouldn't be so bad and Simutrans would get access to good networking and UI toolkits for almost free.
Simutrans' graphics operations are somewhat limited. I think line drawing exists nowadays, but I'm not sure if I came across code for circles and ellipses yet. But those are fairly easy to add if they are missing, you are right there.
C++ needs additional libraries to retrofit garbage collection. It's a programmers choice to use them or not. They are from boost, so I'd expect good quality of the libraries and the APIs.
Markohs sure has the skilsl and knowledge to port this tool to Simutrans, but I think he is busy with implementing an OpenGL rendering backend currently. That for sure will have useful graphics primitives, though.
Quote from: Spike on March 27, 2012, 11:56:01 AM
The slowdown varies a lot. Some code that ported from C to Java 1.1 saw a slowldown of a factor of 40 (but Java 1.1 had no JIT yet), some other code was almost as quick in Java, because Java itself hands a lot of work to native libraries. If it wasn't such a huge endeavour I'd try it, I think the slowdown wouldn't be so bad and Simutrans would get access to good networking and UI toolkits for almost free.
Simutrans' graphics operations are somewhat limited. I think line drawing exists nowadays, but I'm not sure if I came across code for circles and ellipses yet. But those are fairly easy to add if they are missing, you are right there.
C++ needs additional libraries to retrofit garbage collection. It's a programmers choice to use them or not. They are from boost, so I'd expect good quality of the libraries and the APIs.
Markohs sure has the skilsl and knowledge to port this tool to Simutrans, but I think he is busy with implementing an OpenGL rendering backend currently. That for sure will have useful graphics primitives, though.
Yep, now I'm busy on other projects but it's on my TODO list (ordered in priority):
- help prissi multithreading the display of simutrans to get profit from multicore CPU's
- optimizing the OpenGL backend
- This project
- Complete the CEGUI project
- Render simutrans with 3D acceleration.
So, if someone else has the time to start this meanwhile, I don't have any problem with anyone else starting this. I have the source code here, but I can share with any developer.
Are you up for the task, Hajo? :)
Isn't Simutrans already based on OpenGL? I always downloaded SDL version, that would have to be based on OpenGL, as far as I know.
I know there's also a "native" version for win, and I sincerely ignore what it uses for drawing (win APIs?), but I never understood why you provide two versions (maybe retro-compatibility?)
Quote from: yorkeiser on March 27, 2012, 12:15:35 PM
Isn't Simutrans already based on OpenGL? I always downloaded SDL version, that would have to be based on OpenGL, as far as I know.
I know there's also a "native" version for win, and I sincerely ignore what it uses for drawing (win APIs?), but I never understood why you provide two versions (maybe retro-compatibility?)
no, sdl doesn't use opengl. the opengl backend exists but gives little to zero performance gain over sdl/native, and requires a decent videocard to run. so better not release it, since it doesn't do anything the others can't. Yet.
but it's in the svn, if you want to try it.
Quote from: Markohs on March 27, 2012, 12:09:50 PM
Are you up for the task, Hajo? :)
I don't really know. I have my Iron Bite project, and pak48.Excentrique, and some other toy projects of mine. I'm not into the big simulaton sort of playing, so I don't need or miss such a tool in Simutrans myself. It's kinda cool, but I guess I need more motivation to really work on something. So the answer is most likely "at the moment rather not".
Currently, I can't find an easy way to translate the code to Simutrans. Because:
1. This tool reads from savegame file instead of memory/simutrans object.
2. it uses java's own graphics classes to draw the map and diagram.
Fixing those things is just like work from stratch.
The easy way is by putting a button in Simutrans, which simply save the game, then execute this tool.
If you (or anyone) know how cities and lines are mapped in simutrans' memory (= in which data structures) I can begin translating the code you need.
I also need to know how to draw at least lines, strings and squares, and in which graphical context.
Even if someone gives me a reference to the c++ source that draws the minimap in Simutrans, I can give it a look
Quote from: yorkeiser on March 27, 2012, 03:52:07 PM
If you (or anyone) know how cities and lines are mapped in simutrans' memory (= in which data structures) I can begin translating the code you need.
[...]
I guess the problem is again German. ;)
Otherwise, it is fairly easy...
In
simcity.h, you can find class stadt_t (city), with all its properties, methods, accesors, etc.
The array
weighted_vector_tpl<stadt_t*> stadt; in
karte_t(map) in
simworld.h is where all cities are stored.
karte_t is a singleton pointed by
welt and pretty accesible everywhere.
Lines are dealt with with class
simline_t in
simline.h. Although handles are used to use them of type
linehandle_t. All line handles are stored in member
all_managed_lines of class
simlinemgmt_t in
simlinemgmt.h. There is one of these variables for each player (class
spieler_t in
player/simplay.h). Finally, players are stored in array
spieler[MAX_PLAYER_COUNT] in the map.
Many thanks isidoro, your explaination was superb ;) Yes, you're right, for non-german speakers it's a little confusing when you read the code, however google translator helps.
One more question: I still can't figure out where the minimap is drawn, can you help me to understand which class and file does this?
reliefkarte_t in the file gui/karte.* There are two redraw options, one is using long cases per tile (which you do not want) and the other draw overlay in releifkarte_t::calc_map(). Some fast operations are also done in reliefkarte_t::zeichnen(), but those are redone every frame and should be rather fast.
You are welcome, yorkeiser. As to your question, prissi also gave a superb answer.
Update:
thanks to isidoro's and prissi's useful hints, I began understanding something (not so much til now...) in the code. I progress quite slowly, since my c++ knowledge is quite rusted and simutrans sources are huge and partly german, however I succeeded having some results: here's a preview of what I did til now
(http://simutrans-germany.com/files/upload/MapViewerInSimutrans.png)
Actually this is the "simple" functionality, the one that shows lines on the map. There's still much work to do on this, e.g. hiding vehicles, write a routine to print dotted lines, and much more.
Instead I need MUCH more time to convert and optimize the functionality that builds the simplified network graph, even if I can succeed in that.
If some more experienced SimDeveloper wants to continue this work, I gladly share code, as done previously with the java vesion.
ZOMG!!!!
This is unbelievable, it's VERY, VERY nice!!!!
Ottimo lavoro, yorkeiser, very good job!
I just wonder, are those blue circles for cities needed? Maybe they could be filled in solid (light) color.
Great job. ;)
Many thanks Fabio, you're too generous ;D
Ovals would have to represent city limits, but effectively are really ugly, and apart this the oval routine would have to be rewritten cause it uses floats and sin() and cos() functions, that are not really optimal. Let's say it was just an attempt to write a graphical routine using Simutrans' primitives. Maybe filled ovals could let the map be less readable, however I will make some attempts and see the result. However, as I said, ovals are a little isle in the OCEAN of work to do on those functionalities.
P.S. I'm not in the developer team and don't absolutely want to overtake anyone: I know there's already an official request about the conversion of the MapViewer and some developer (maybe Markohs?) had taken this task for future development. This is, let's say, a simple programming exercise that I'm making to understand Simutrans' internal structure; however, I hope this could be useful for whoever will like to continue (and maybe publish one day) this task.
WOW. Finally...
It is fantastically superb. :o
I agree with fabio. The city circle is not needed IMO.
Why not put in on the existing mini map, so it has road and island image?
@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.
Quote from: yorkeiser on March 30, 2012, 04:10:04 PM
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.
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.
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
(http://simutrans-germany.com/files/upload/MVwhite.png)
(http://simutrans-germany.com/files/upload/MVblack.png)
(http://simutrans-germany.com/files/upload/MVmap.png)
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.
(http://simutrans-germany.com/files/upload/MG.png)
Looking very good! :)
wow - that's looks easier for me to compare and make notes
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?
Quote from: Fabio on April 02, 2012, 10:23:25 AM
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)
Quote from: Fabio on April 02, 2012, 10:23:25 AMStation 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.
Quote from: Fabio on April 02, 2012, 10:23:25 AM
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.
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.
Even single platform stations can have different coordinates for coming and going, assuming that the single platform occupies more than one tile.
Quote from: yorkeiser on April 02, 2012, 11:08:12 AM
@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?
@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 ;)
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).
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.
@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
(http://simutrans-germany.com/files/upload/MVSingleLines.png)
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 ;)
Much better now! Thanks!
Quote from: prissi on April 02, 2012, 03:13:14 PM
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?
Perhaps prissi meant that instead of coloring each line differently, you can color them according to some "locality weight"...
@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 ...
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?
@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
New Integration thread in Projects board... now waiting for news ;)
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!
Happy Easter to you, too, and for all people celebrating it!
(I'll be away a week as well)
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
(http://simutrans-germany.com/files/upload/MVbezier.png)
Good work! :)
oh, btw, yorkeiser, I did a doxygen documentation generation time ago that might be useful to you, it's here (http://dl.dropbox.com/u/30024783/Simutrans/doxy/html/annotated.html)
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?
Quote from: yorkeiser on April 11, 2012, 03:23:14 PM
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 /** ):
/**
* 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...
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!
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 ;)
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.
@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)
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.
so the map is drawn each frame?
And yea, blending layers by fixed amounts is already possible using pix_blend75_15... etc
The lines need only be redrawn upon schedule_counter in welt is advanced. Otherwise not lines were changed for sure. Thus a slightly time consuming inital drawing routine is ok; as long as the points or whatever is cached.
In the beginning I tried to put code inside calc_map(), but what I drawed from there was overwritten by the rest of the map (grass, seas, cities), so I temporarily moved it inside zeichnen(). Doing so, also allows me to test performances of the routine.
Of course I know it's not the ideal place to put this code because map viewer really doesn't need fast refresh, even if at the moment I didn't notice any performance issue (in fast forward mode I have the same speed factor than with other minimaps, also on quite complex maps).
I think in the final version we'd have to precalculate all coordinates, store them, draw stored coordinates and only at some large intervals (eg 30 seconds) or for some events happening, recalculate everything. No need to say, I have no idea how to achieve this refresh in simutrans architecture.
However, let's make things step by step: where do you think it would be the optimal place for the code that spools lines and calls graphic routines?
Is there any drawing routine that isn't called at every frame but has reference to minimap panel and is already used to draw on it?
EDIT: I read prissi's post. What if a schedule is only updated ? (e.g. adding a station to a schedule). Is there any event fired?
Since those "events" (increaseing schedule counter) are to notice the stations that the connections need updates, any relevant change (beyond waiting times) must give updates. In debug mode, you will see a star repc. a cross near the time acceleration indicator in the lower right.
Ok, I edit here to not post a new message. After further investigation, I noticed that it would be nice to put drawing code in calc_map(), that is called, as far as I can see, when you press a minimap button or change zoom level. But doing so I encountered a great problem:
all map modes implemented in calc_map() call set_relief_farbe_area() method, which draw on *relief. If I write on relief, in fact I have no overwrite issues.
The problem is that all graphic primitives I need are implemented in simgraph16.cc (display_direct_line(), display_pixel()...), and they write on *textur, not on *relief.
Now, if I call the primitives I need from calc_map(), they are drawn for a moment, then overwritten by *relief. If I skip relief drawing, lines are overwritten and nothing is plotted (the result is a totally green map). It seems that *relief masks *texture, on which rely graphic primitives.
In fact, as I can see, map modes that need to draw only full rectangles (calling set_relief_farbe_area) are in calc_map(), while map modes that need to draw single lines (as city limits mode) are in zeichnen(): it seems like program is not designed to call graphic primitives from calc_map().
Can anyone solve this, or at least explain me panel drawing pipeline, if I'm (probably) missing something?
Quote from: yorkeiser on April 12, 2012, 08:59:31 AM
Many thanks for your (wagon of) ideas, you're giving an enormous contribution to development and graphical improvement ;)
Well, I try to contribute as I can, I'm glad you value my suggestions. This tool might really add a lot to the gaming experience.
Quote from: yorkeiser on April 12, 2012, 08:59:31 AM
- 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
I agree. We need a public debate about it, after this project is released.
Quote from: yorkeiser on April 12, 2012, 08:59:31 AM
- 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)
No, I mean to *remove* the existing Cities/Citta' button and add a *new* Show Cities toggle option, so that city names are shown/hidden no matter what other button is chosen (Map view, Tracks/binari, Speed limits/limiti velocita', cities, pax, stop status etc...)
We could do the same with City limits/Limiti citta'. Those two can be handy also when specific views are chosen, instead of being a view on their own.
Quote from: yorkeiser on April 12, 2012, 08:59:31 AM
- 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
Not necessarily. Being so small, we don't need real circles, but pre-calculated pixel maps could suffice.
E.g.
Bus stops (3 px)
XXX
XXX
XXXRail Station (5 px)
XXX
XXXXX
XXXXX
XXXXX
XXX Airports (7 px)
XXX
XXXXX
XXXXXXX
XXXXXXX
XXXXXXX
XXXXX
XXX I would also distinguish stops served by only one line from those served by multiple lines (hubs)
E.g.
| | | Stop (1 line) | | Hub (2 lines or more) |
| | Bus/Tram/Monorail/Other | | 3 px | | 5 px |
| | | |
Airports could have an airplane icon near, harbours an anchor or a ship. Those symbols should be already present in GUI symbols, as they are used e.g. in schedule dialog.
Monorail lines (and stations) should use same style (for lines and stops) as trams; maglevs same as trains IMHO.
Another idea:
Colours would be nicer if persistent between sessions. Could each line object store its color? This way, colours would be assigned when creating/updating a line and the network morphology would be better analyzed in this moment instead of drawing time. It could also be possible for the player to customize a line color -- if wanted -- from line management dialog.
First the relief map is copied to screen. On that you can call whatever method you like in zeichnen. The reason is, that calculation the map means touching every tile which is very time consuming.
If you have a list of coordinates, then you could calculate those list only when needed, and then just draw them in zeichnen every time. That is fast enough imho.
@prissi
ok, it's clear. So I'll initialize coordinates in some place and draw them in zeichnen. I think doing like this wouldn't cause performance trouble, due to the fact that there are no problems also now that coordinate calculus and drawing are both done in zeichnen.
@fabio
- about removing city button and replacing with a toggle button: I support this solution, but this is out of MapViewer's development scope. As a temporary alternative, maybe I could use actual behavior of other minimaps also for map viewer, that is showing city names only if CTRL is being pressed
- about circles: it's definitely a good idea and I'll work on it together with the implementation of airport/harbor symbols (they're all pre-calculated bitmap masks): I didn't think about using precalculated graphics, and instanly get afraid of perfomances issues a general circle routine could cause
- also hubs being greater based on lines entering in the station is definitely a very good idea. The problem is that I actually couldn't find in class haltestalle_t a method that returns the number of schedules to which a station belongs, so I actually I'm making distinction between greater/smaller stations based on line types served by that station (1 line type -> small station, 2 or more -> hub); train and airport stations are bigger than others. I agree with maglevs behaving like trains (I often ignore them because I use pak128 for development...), and also for trams/bus/monorail in the same category (local transportation). The number of optimal pixels (3,5,7 and so on...) is to be refined, I think the best way is to produce some screenshots with different solutions, show them, and then hear for others' opinions
- Persistence of line colors is not achievable as far as I know, unless we add color information to the schedule, and thus probably change savefile format (and I think this is far beyond objectives of this integration). A simple hack could be to write a routine that associates line color (that is substantially a number) to some unchangeable feature of the schedule, as its internal id or maybe its name, that is not supposed to change often. By example: color = internal_id % max_colors_for_this_line_type.
I would suggest focussing on the actual line creating part. About triggering of recalculation and so on, you could leave this also to the dev team for the final integration.
Personally, before this gets to abstract, just post a patch. Others may then also improve it, so we can jointly work on it. IT is done also with many other patches.
Also please do not get overboard by side options. First the basic function as a patch, so we are sure this work is not lost and can be tested with many complex and simple maps. All the other goodies can be added later ...
For isntance, at a certain point I am sure we have to drop lines, which has stops too close to each other. And so on, and then the issue of making the lines more straight and so on.
Quote from: prissi on April 13, 2012, 09:35:22 AM
I would suggest focussing on the actual line creating part. About triggering of recalculation and so on, you could leave this also to the dev team for the final integration.
Line creating part is quite simple, as I intended it: for every player - for every schedule - for every station in the schedule, draw lines between stations, draw station spots. My main adding was to add primitives to draw different line types (dotted, bezier curves).
The main part left to do is to store lines/stations infos in some structure rather than recalculating them at every frame, but if you agree I'd leave this task to development team, that know program's flow structure.
Quote from: prissi on April 13, 2012, 09:35:22 AM
Personally, before this gets to abstract, just post a patch. Others may then also improve it, so we can jointly work on it. IT is done also with many other patches
As I told some posts above, I work off svn (I can't access it due to my network limitations), so I don't know how to automatically produce a patch. However, my sources are quite independant from the rest of the program, so what I can do, is to post my added parts, and in which file they go (mainly some methods in simgraph16.cc, the simple code to add a button in minimap, and the main calculus/drawing routine in reliefkarte_t::zeichnen()). All my code is stand alone, it isn't mixed with actual sources for external integration purposes.
Quote from: prissi on April 13, 2012, 09:35:22 AM
Also please do not get overboard by side options. First the basic function as a patch, so we are sure this work is not lost and can be tested with many complex and simple maps. All the other goodies can be added later ...
Why are you afraid for work getting lost? I won't disappear, and however I think developers wouldn't loose too much time to re-do this work ;)
prissi, I never claimed to develop MapViewer by myself, it must be done by development team, I told it in the beginning of this thread. This thread/task was only born to see if integration was possible and its possible results/enhancements; let's say what I did is a preview of the official implementation. My main concerns were about performance and mainly how graphics could appear in a small 256 colors mini-map, rather than in a full screen, 32-bit colored application. So actual side options, as you called them, in my point of view are the main task of this thread: share ideas with others of how things could be done, code them to see their graphical result, hear judgement and new ideas, and restart. Otherwise, my task here is finished: from now, if you want real integration as I do, you (we) have to wait for someone in the development team to take charge of the real implementation, and I surely support this and am available to share code, ideas or anything you ask.
Just share the modified files then. I would be very interesting (and many other too I suppose) to test them over the weekend. If there is a concrete patch/implementation etc. it is much easier to discuss.
Here are the files I modified.
For ease of read and use, I enclosed code added by me between lines:
//yorkeiser begin
//yorkeiser end
There's only a row I had to modify, it's after comment:
//yorkeiser inline
Code added is quite dirty, many lines are commented, variables declared where they wouldn't have, lacking optimization etc.. but I don't mind, it's not intended to be a release, only an idea of what can be done.
This worked quite well. Just airlines tend to go into strange directions ... Thank you very much!
Attached at patch, that uses a slightly dimmed world map. But this view is currently VERY cpu consuming, from 12% CPU to 100% single core usage with developed maps ...
EDIT: not sure, this version here seems not so CPU hungry. Still investigating.
Quote from: prissi on April 13, 2012, 10:49:44 PM
This worked quite well. Just airlines tend to go into strange directions ... Thank you very much!
I didn't notice strange behaviours, can you please post a screenshot so I can see if I have any idea of what happens? The only issue I know is that Bezier curves routine must be enhanced, because it actually draws starting and ending with fixed directions (beziers need a tangent direction where they start and one where they end - Cx, Cy, Dx and Dy parameters in draw_bezier()). But those directions wouldn't have to be fixed, they would have to be parameterized with the direction defined by starting point and ending point of the arc.
You're welcome, but you don't have to thank me: I had much fun from simutrans until its really early versions, so if I can even do the smallest thing to repay the community for their work and can help improving the game, I do it happily.
P.S. Even with the non-optimized version I didn't notice strange cpu overload: development was done on a normal 2.67 Ghz quadcore laptop, maps tested have ~2000 vehicles, ~150 lines, pak128 open r1150.
Try this map (pak64 with food chain)
http://www.physik.tu-berlin.de/~prissi/simutrans/The%20World-V2-102-2.sve
All airlines have a kink near mUrmansk or the noth pole. (Might be due to cold war still in progress on this map ;) )
I can't succeed loading that map on my development version, even importing last pak64 that works fine on latest nightly (r5636). However if you talk of "kinks" I suppose it just depends on that issue (but it really isn't an issue, the routine isn't complete yet) about tangents I told in the previous post. If you can post a screenshot, it would be helpful in order to investigate/replicate the issue on my test version (pak128).
P.S. Or maybe you simply have to provide a "War-free mode" in Simutrans ;)
You need to load pak64 with addons ...
Here is the screenshot.
Is there an all-inclusive download link for pak64+addons? I didn't find one on the forum, and since I don't follow pak64, I'd need a whole life to manually get the single add-ons, even if the problem is related to that and not to the version I use for debug, that I took from the aburch repository a month ago.
However, from what I can see from your screenshot, that is quite compressed, I only notice spikes in the north, and they're due to that problem of the beziers' tangent. Tangent is actually defined as (50,50), so it's a vector that points at South-East. In fact, all beziers (=airport lines) enter and exit from airport spots in south east direction, that is visually ugly. Entering/exiting directions would have to be parametric with the direction of the line, wouldn't have to be fixed as they actually are.
If there's another problem, I can't really see from the picture, maybe you can try to take a closest (more zoomed) screenshot and not compress it (save as .png). In the meanwhile, I'll try to get this savegame to work on my version.
P.S. This map is REALLY complex and there are MANY airlines, and bezier's drawing is slower than line drawing. Bezier curves actually are drawn as 32 segments polylines, I think that performance could be enhanced lowering this value to 8 or 16 segments, because every segment calculus involves some multiplications, as well as shifting.
P.P.S: World colors seem to me very nice, now it definitely looks very better than my version with white background
@yorkeiser
realy,realy great job!!!
The only thing i am missing is the save as .pdf, so you can put it on a stick and go to a copyshop for a printout at DIN A3.
(gave them the small finger and they try to get the hole hand ;) )
@prissi
Nice Map. But why you put Adler-Personenwagen to the trains to limit the speed to 50 km/h? Is the Trans-Sib realy that slow? Smolensk-Moskau is ~ 100 Km/h. And you have VT/VB98 running, but i can't find them in the depot ???
THis is the convoi replacer with stuff of vehciles not in production any more. This map is not from me, the original is on the old forum. It has several stuff missing, hence the random replacements.
EDIT: Version with very much cleaned up code. Using the control key, you can toggle between display by all colors or only line with player colros (most useful on servers). It will also ignore waypoints for line display.
Quote from: Randy007 on April 16, 2012, 04:50:40 PM
realy,realy great job!!!
The only thing i am missing is the save as .pdf, so you can put it on a stick and go to a copyshop for a printout at DIN A3.
(gave them the small finger and they try to get the hole hand ;) )
Many thanks Randy ;)
I don't plan writing a pdf exporter (unless MANY users require it), but If you check the thread related to the external map viewer (http://forum.simutrans.com/index.php?topic=9514.msg90289#msg90289), and you can use it, Vonjo added a feature for exporting your map diagram into a .png file.
Once you saved your .png, the internet provides you a lot of image->pdf converters; try to google "png to pdf", there is various stuff related and some converters seem to be free. I never used this kind of stuff, so I'm sorry, I cannot be more helpful.
The kinks in the world map were due to waypoints. I removed waypoints, since this is anyway a schematic map, not a schedule.
EDIT: Attached a version which only uses diagonals.
I had no much time to see this stuff, however I was trying to parameterize the function that draws airlines, to remove those horrible spikes.
The idea is to sum normal and tangent vectors in the vertexes of the arcs in order to find a sort of 45° vector, then shrink those vectors to not make a too "large" curve. Essentially I removed the 4 parameters that were defining fixed starting and ending directions for curves, and now it's the function itself that calculates those directions.
I tested it on two maps and seems to me giving better visual results, so I post here the code of the new function so whoever wants can give a try.
You also have to change the calls to draw_bezier(), removing the four parameters = 50, and of course fix simgraph.h changing the method's signature.
void draw_bezier(KOORD_VAL Ax, KOORD_VAL Ay, KOORD_VAL Bx, KOORD_VAL By, const PLAYER_COLOR_VAL colore,short draw, short dontDraw)
{
KOORD_VAL Cx,Cy,Dx,Dy;
//part changed
KOORD_VAL normalX,normalY,directionX,directionY;
normalX=(Ay-By)>>4;
normalY=(Bx-Ax)>>4;
directionX=(Bx-Ax)>>4;
directionY=(By-Ay)>>4;
Cx=Ax+normalX+directionX;
Cy=Ay+normalY+directionY;
Dx=Bx+normalX-directionX;
Dy=By+normalY-directionY;
//end of changes
int a,b,rx,ry,oldx,oldy;
//fixed point: we cycle between 0 and 32, rather than 0 and 1
for (int t=0;t<=32;t++)
{
a = t;
b = 32 - t;
if (t>0)
{
oldx=rx;
oldy=ry;
}
rx = Ax*b*b*b + 3*Cx*b*b*a + 3*Dx*b*a*a + Bx*a*a*a;
ry = Ay*b*b*b + 3*Cy*b*b*a + 3*Dy*b*a*a + By*a*a*a;
//fixed point: due to cycling between 0 and 32 (2<<5), we divide by 32^3=2>>15 because of cubic interpolation
if (t>0)
if (!draw && !dontDraw)
display_direct_line(rx>>15,ry>>15,oldx>>15,oldy>>15,colore);
else
display_direct_line_dotted(rx>>15,ry>>15,oldx>>15,oldy>>15,draw,dontDraw,colore);
}
}
Those spikes were due to waypoints in the north. It was actually really cold war ... Now the rouinte ignores waypoints.
I find that waypoints be don´t remove out the Map.
Waypoints make the Navigation lighter.
Incorporated; some details will be polished and the symbols will be taken from images later.
The network of all passenger will be displayed, if the passenger button is dest is selected together with show schedule (and of course no schedule is visible). Same for mail and for freight. This allows to see those networks seperately. With control pressed, the player colors will be used (useful for netowrk display).
Thanks for the inspiration and first implementation!
Downloaded last nightly: prissi, you did a great work. Diagonalization works well, adding player colors is really useful. I only noticed some little problems:
- diagonalization works badly in isometric mode
- when holding ctrl, player lines have 2/3 colors and not only one player color: is this done by purpose?
- large diagonal lines (train lines) result to be less thick than horizontal and vertical ones: if you used my routine for thick lines, I think that when drawing in diagonal direction, a couple of other single lines would have to be added in order to draw a thicker line
- this is only a personal opinion: main hubs spots (largest circles) imho could be slightly reduced, 3 or 4 pixels less in diameter. Smaller and greater circles also would have to be centered better respect to lines entering in them, because they seem slightly shifted towards north and left, respect to lines.
However, these only are small details: still amazing!
Without you it would not have started. So this goes also to your back.
The thick lines and the centering issues are is straight from you code ... I will look into them. Maybe even revise the thick line drawing code a little, as for vertical lines the rectangles acan be used.
I was also thinking about only a single color for the player view (the second darkest maybe). Now it cycles through 5 player colros.
@prissi
As I can see, Bresenham circle routine draws circles with diameter of (radius*2)+1.
For radius, you're passing 5 for hubs and 3 for smaller stations, and it results in circles with respectively 11 and 7 pixels diameter. Previous version, which used fixed graphics, was using 5 pixels diameter for smaller station and 9 pixels for hubs. I suggest trying to decrease radiuses to 4 and 2 respectively, and see how it looks.
About non-centered lines: my thick lines routine isn't actually centered around its vertexes P1 and P2 (station coords): it first draws a single line from P1 and P2 (this would be centered), then shifts one pixel to the right (or bottom, depending on the inclination of the line) and draws another line, and so on, until it reaches its thickness. So in actual version it will always be shifted on the right or on the bottom, respect to its real vertexes. To center it, method should be modified in order to start not from P1.x but from P1.x - line_thickness/2 if it's shifting horizontally (P1.y-line_thickness/2 if shifting along y axis); same for P2.
Also, for diagonals it would have to draw some more lines, I think thickness*sqrt(2) lines approximately, because shifting is done in horizontal or vertical direction, not in diagonal direction that is longer by sqrt(2) factor.
Wow, it's great! A dream come true.
I tested it very briefly, this is my first feedback, based on today's nightly.
- UI is very clever, but not so intuitive, it might be rethought later. E.g. remove Line net button; when Show schedules is selected, all legend buttons are disabled ("greyed out") but pax, mail, freight, Cities and city limits; if none is selected, show all, if one is selected, show only that one.
- Stations look great this size! I wouldn't rescale them. Also the background is awesome
- The palette of colors for lines seems a bit dull...
- If I have 2 lines sharing the same tracks, only one is displayed. E.g. Line 1: A-B-C-D; Line 2: E-B-C-F Between B and C only line 1 is shown. I would suggest all lines between 2 stations are shown, maybe enlarging the line and painting it in different colors (e.g. line 1 is red and line 2 is blue, both train: between B and C draw a 10 px line made of 5 red lines and 5 blue ones.
Quote from: Fabio on April 18, 2012, 02:37:42 PM
- If I have 2 lines sharing the same tracks, only one is displayed. E.g. Line 1: A-B-C-D; Line 2: E-B-C-F Between B and C only line 1 is shown. I would suggest all lines between 2 stations are shown, maybe enlarging the line and painting it in different colors (e.g. line 1 is red and line 2 is blue, both train: between B and C draw a 10 px line made of 5 red lines and 5 blue ones.
This is not immediate to achieve because a line has no memory of how other lines are done: lines are drawn player by player, schedule by schedule.
A simple solution could be to save an array of stop connections for every rail arc (id station 1, id station 2) and, before painting the arc, control if there was already an arc connecting two stations, and if so shifting the arc to be drawn. I did something similar in the external tool.
This is a simple thought, prissi surely can have a smarter solution
The line net button shows all lines; and if you have a single schedule selected, it will be still normally overlaid. I would rather add also tooltips to those buttons.
Displaying parallel lines in not trivial; especially since also lineless convois are also displayed, i.e. an additional line per lineless convoi, and lines go back and forward. If those would be also displayed, it will get very crowded. (I tried this, but it was really bad on ring lines.)
One might achieve this by first iteration over all schedules, then built connections out of those, and then finally draw them. Hmm, this sounds like very time consuming.
Ok, fabio, I added also offset for parallel lines. This concludes my work on the line mode. There are still some workplaces (like larger station symbols when many lines in in parallel) but those are quite difficult.
I will rather focus on the buttons in the minimap as many of those are rather obsolete and are in not particular order at all (just pasted to then end ... )
Just checked this on a nigtly and I want to congratulate yorkeiser and prissi for such a nice and great addition to simutrans, it looks great.
I tested again: it's simply awesome!
It might be tweaked some more, but right now it's simply amazing.
Thanks a lot, Prissi and Yorkeiser!
@prissi & yorkeiser
it's nice to read this thread, it really shines through how much you are enjoying this. really a cool project.
Awww.. Simutrans is now becoming too much awesome. Remove it now!
Just kidding. Network diagram is simply great.
(OFF-TOPIC: how about to implement 1:8 Zoom? It's because I'd like to view the bus lines in the cities. ;) )
Sorry, Im just freshman. Can you tell me, how does network model work? What I have to do to set up in game? What I have to download and where I should it save it?
Thank a lot
Welcome to the forum!
The network tool is integrated in the last two releases of Simutrans. So nothing to download. Just view the minimap, press the show selections button and enable the network check box.
Im so sorry, that I dont understand your instruction -_-
I cant find this tool integrated in map. Id like to have my system like this one:
http://forum.simutrans.com/index.php?action=dlattach;topic=9514.0;attach=17882;image
but in my simutrans 111.2.2 r5583 I can choose only one line to show in minimap.
I want to see all my lines on minimap and with colors as above.
Please, could you help me?
If you see one line only then the Lines dialog will be open. Close it, and if necessary, set networks off and on again. Then you will see all the lines.
You need the newest version of simutrans, 111.3.1. Then just press "selections" and the checkbox next to "networks." You can press freight, passenger, and mail to see only that particular network, and press control to see networks by player.
Thanks a lot. :) It works :) Newer version is that solution.