The International Simutrans Forum

 

Recent Posts

Pages: 1 [2] 3 4 5 ... 10
11
Bug Reports / Fast Forward Hard-coded Cap (glitch?)
« Last post by TheArchitect on Yesterday at 01:42:38 PM »
Hey guys, I've started making some config.tabs and pushed the game... Then I found several glitches regarding time acceleration which you may not be aware of:

As I developed my own config for Simutrans 64, on Steam, the issue arose that I could never get the game to fast forward faster than around 150x, that is despite putting numbers up to 25k on the config file. At first I thought it was an optimization issue, but my CPU is only being used around 10%, and so I decided to try and hold "." to speed up the passage of time and eventually reached speeds of 750x without a hitch. Therefore I assume that, somewhere in the code, is a cap on how fast the Fast Foward button goes. Could someone confirm and, if easy to fix, remove said cap from the game?
(edit: it should be noted the 150x cap happens regardless of map size or complexity and is independent from frame-rate)

Another interesting issue regarding time is that when accelerating time using "." vehicles start breaking speed records at ever increasing pace; In fact, I had several vehicles go some 40% or more above their max speed, such as a carriage team making 36km/h!
Hopefully, that rounding error can also be addressed in a future update.

Hope this report is useful, thanks for developing such a fun game!

PS: here are some images to illustrate:




12
Yokoze "crazy" development series, by 128Na(maybe most famous Simutrans play video creator in Japan). Maybe Japanese addon developer that influenced by 128Na are majority.
https://www.youtube.com/playlist?list=PLf07Y1TVCC6bxzzbAmbYPuCCdJ7fm9Int

13
Community Discussion / Re: fanzine, doujin creation,etc. of Simutrans
« Last post by rapidliner on Yesterday at 03:34:00 AM »
「自由町-Simutransの世界へ」(written in Japanese, by MARK(Twitter:mark8629))
This is a fanzine of Simutrans that distributed at Comic Market 93(2017-12-29 to 2017-12-31), Tokyo.
It's writing about introduction, creation of addon, and histry of Simutrans.

https://twitter.com/SeasideExp/status/954709738100420613
This is Japanese commentary about "自由町-Simutransの世界へ" by しーさいど(Twitter:SeasideExp).
14
Community Discussion / fanzine, doujin creation,etc. of Simutrans
« Last post by rapidliner on Yesterday at 03:25:26 AM »
This is a thread that talking about fanzine, doujin creation, etc. of Simutrans.
15
Quote
update_underground_intern is called from world_xy_loop with the SYNC_X flag set. That ensures thread 1 is finished with tiles that thread 2 is dependent on before thread 2 can proceed.
Yet...
Quote
Every now and then trunk also displays the chopped portal.
So honestly I am not sure. Still if one were to switch to a pure rectangular area based update and take the 50% more tile updates one could probably factor in an extra column/row to avoid this and iterate in correct order.
Quote
Simply using the estimated_min and _max values that are used to setup the preparation map for the iteration range seems to work ok; There are extra offscreen tiles checked, but the speedup from sequential access seems to make up for that. The iteration could be easily skewed into parallelogram reducing the extra tiles since the camera is at a fixed angle.
Problem is that elevation changes what tiles are visible on screen so unless one does what is currently done or take the extreme bounds one will end up potentially missing tiles. If one keeps it square one can also remove the need for the prep map entirely and instead use a prep area and only update the difference. More tiles prepared but very little overhead if drawing static terrain.

Quote
Bulk operation are way faster with packed bits, write one word and 32 tiles cleared/set all at once...
Except when processing with multiple threads since the memory model requires whole bytes be modified, or worse. Or when dealing with partial clears since then both a read and write are required with some masking logic. Also I would imagine that the memory bandwidth used of ~64kb per frame read when far zoomed out with pak64 was trivial compared with the potentially 4MB+ written and read to draw the screen in case of a dirty screen at any zoom level.

Quote
Packed bits support multithreading as well as bool arrays. Even with bools the threads need to be spaced far enough apart that they're not working on the same cachelines anyways.
Except that the initial idea of having the draw threads process them would not result in a single thread processing 32, 64 or however many tiles next to each other. Hence why they were avoided. Until I found out that idea would not be viable.
Quote
Another option is to just size the preparation map to cover then entire map. If packing the bits, you'd end up with 2M to cover a 4k x 4k map.
Which goes back to the original problem of coupling a visual operation to map dimensions. Performance for changing to underground mode or slice should not directly depend on map size.

Quote
Just because the back image dependance spoils your plan doesn't make it a bug. You clearly don't like it, but do you have some other algorithm in mind?  How is a tile supposed to know if it's blocking the view of a tile behind if it doesn't know what's on the tiles behind?
It is doing any of this to start with? Look at underground slice view and you can see objects behind what is meant to be solid wall... For example place a 4 high wall of artificial wall in front of a rail line with trains and change to a slice just below the surface of the wall. You will see both rail line and trains through the wall.

I tried to find an example of it hiding something as it did say it did so with the one test of the calculate back wall method. However I did not even notice visual changes in a fairly complex map when the entire test was disabled from calculate back wall method. I am guessing that pak128 tunnel might mechanically require it, but I am unsure as to what it exactly is.

As mentioned before the entire draw process is very arcane and cryptic at times. For example why does it even need to pre-compute back walls when it still has to compute them at draw time? The pre computed ones only cover 2 height, with any extra height, eg to support 4 high artificial wall, having to come from the draw time computation which is drawn below the pre-computed back walls. Computing these back walls at draw time is not trivial either as it still has to look up corners of at least 2 other tiles which likely are not sequential memory reads.
Quote
Doesn't the preparation map need to be invalidated upon map rotation? (or rotated along with the tiles)
Not entirely sure. As far as I am aware multiplayer maps cannot be rotated. Single player maps when rotated should be recomputing the entire map as before so technically all tiles are prepared afterwards. This change was specifically targeting underground mode performance for now because that is a huge problem with Simutrans Extended which uses the same/similar code for changing underground mode and level.

I will look into moving the system to a purely prepared area based system. This should almost completely remove the memory bandwidth usage outside of actual tile preparation. One can also add sufficient buffer tiles that hopefully the masking occurs correctly. This may mean preparing more tiles but otherwise it would have considerably lower overhead and do so more efficiently at times.
16
Pak128.German / Re: Shipyard and Floating Dock in different water areas
« Last post by makie on July 18, 2018, 11:21:28 PM »
I have the same Problem.

First, dig a trench. From the sea as far as possibles.
I do not want to destroy the high speed track.
There is a need for a tunnel.
 
Yes the ship sections fits. The Tunnel is bigger as it looks.
 
In open terrain you can dig a canal again.
But the airport and a big city block the way. Here again only a tunnel helps
 
We continue in the underground.
 
We are lucky, in the middle of the city springs a river. This can be expanded as a channel without demolishing houses
 
Upstairs, can you see the tunnel portal? No?
 
I hide the houses. :D
 
continued ...
17
Since I haven't been here in a long time, I've noticed that over the past few years this game's community has been slowly shrinking. I remember seeing some form of forum post count for X year list sometime before I almost completely forgot about Simutrans, and that the 2017 forum post count was only in triple digits roughly around december.

18
Bug Reports / Re: Terrible performance changing undergroud view mode or slice level.
« Last post by Ters on July 18, 2018, 07:55:51 PM »
Would be nice if operating systems would expose some nice low latency way to wake threads.
I know at least Windows has gotten something that is at least more light-weight than the old ones. However, the biggest hurdle is probably that you need to wait for the scheduler to reschedule. Running the scheduler too often is also bad for performance (and power consumption for idle cores). Maybe thread pools work rather well in this regard, as they can pick a new task when the previous one ends, in user space. But you need to keep them fed all the time, or the thread goes to sleep or is even killed, which means it takes time to get it going again. However, a thread pool that is willing to trade CPU cycles for performance could always busy-wait.
19
I do not see how this dependency was handled before seeing how update_underground_intern was called by multiple threads covering separate map areas. Unless you are trying to say there was some kind of overlap hoping that the result was consistent enough to work?
update_underground_intern is called from world_xy_loop with the SYNC_X flag set. That ensures thread 1 is finished with tiles that thread 2 is dependent on before thread 2 can proceed.


In the patched main_view_t::display(), //prepare view area, the tiles are being updated in screen coord order (diagonal across the map). What was the rationale for that?
To know what tiles needed to be computed and only compute them. Otherwise it would have to prepare tiles that will not be drawn.
Simply using the estimated_min and _max values that are used to setup the preparation map for the iteration range seems to work ok; There are extra offscreen tiles checked, but the speedup from sequential access seems to make up for that. The iteration could be easily skewed into parallelogram reducing the extra tiles since the camera is at a fixed angle.


Packed bits would potentially be faster for pure testing, but might be slower for setting (both read and write) as well as for clearing areas (both read and write 1 byte at a time, no bulk memory set operation).

At the time I designed the structure I was considering that updating could possibly be performed multi threaded. Packed bits do not support multi threaded updating due to the underlying memory model.
With the dirty tiles, it was found a bool array is faster if you look only at the time to perform operations on it. Once you look bigger picture, the larger memory footprint results in an overall slowdown to the screen update. I expect the same holds true here. Bulk operation are way faster with packed bits, write one word and 32 tiles cleared/set all at once...
Packed bits support multithreading as well as bool arrays. Even with bools the threads need to be spaced far enough apart that they're not working on the same cachelines anyways. Being lazy and relying on the cpus cache coherency logic is way too slow.  But, updating such a small area is not a good candidate for multithreading anyway - the main thread would be done it's work before the helpers even got woke up to start. Would be nice if operating systems would expose some nice low latency way to wake threads. Then these high core count cpus might be worth something (for game logic type stuff, not e.g. image processing which is trivially parallelizable).


Under what conditions was this tested?
Still camera zoomed out. i.e. This is the slow down from just checking the prepartion map. Panning is subjectively more jittery than before (the buggy frametiming routine doesn't help here...), not sure how to setup a repeatable test to properly measure. But not going to until the dependance issue is solved.


I could add this optimization and it should mostly remove the overhead when the camera is not panning or invalidated.
Sensible. No need to check what can't have changed.

---
Another option is to just size the preparation map to cover then entire map. If packing the bits, you'd end up with 2M to cover a 4k x 4k map.

---
Just because the back image dependance spoils your plan doesn't make it a bug. You clearly don't like it, but do you have some other algorithm in mind?  How is a tile supposed to know if it's blocking the view of a tile behind if it doesn't know what's on the tiles behind?

----
Doesn't the preparation map need to be invalidated upon map rotation? (or rotated along with the tiles)
20
Hi there,
The elevated rail and road are adapted from other people's addons (although the rail one is, I think, far enough removed to be considered my own work).

The double tracks are my own work and are available here: https://forum.simutrans.com/index.php/topic,12225.0.html

Let me know if you need any of the related files.
Pages: 1 [2] 3 4 5 ... 10