Started by Mak, November 24, 2020, 10:41:21 PM
0 Members and 1 Guest are viewing this topic.
Quote from: Mak on November 25, 2020, 02:10:22 PMThank you for the support and for the svn link. It might prove useful at a later stage, but right now, I'll try just to separate rendering logic and ignore GPU completely.Right now I'm just wondering is there any technical reason to keep option for using only single thread. How I imagined implementing this, at least two threads are necessary. I'm sure I'll have more questions along the way.
Quote from: jamespetts on November 25, 2020, 02:14:49 PMHaving an option for a single thread can be very useful when debugging threading specific problems, although providing that the multi-threaded simulation code (as opposed to graphics code) can be compiled as single threaded to diagnose losses of synchronisation with the server caused by multi-threading, it may be worth losing this if this project can really be achieved.
Quote from: Mak on November 25, 2020, 02:25:33 PMOk, maybe the semantics for single threaded can change a bit into single threaded within any of the main two threads (render and game), i.e, those threads won't spawn any new threads.
Quote from: ceeac on November 25, 2020, 05:13:44 PMThe two-threaded approach is inflexible; IMO a better approach would be to think in terms of "tasks" (an abstract work item to be processed) and "task graphs". Any thread can process any queued task. For example, if the render task depends on the update task, it does not matter if you have 1 or multiple threads, the tasks are always processed in the correct order. This can also be applied to sub-tasks that are spawned as the update and render tasks are processed.
Quote from: jamespetts on November 25, 2020, 08:09:23 PMAlthough this does not apply to the graphical code, beware that any simulation code multi-threading needs to be completely deterministic, or else network games will not be able to stay in synchronisation. This is relevant to any more general overhaul of the threading architecture, and is the reason that the multi-threading of the simulation element is constrained and sometimes somewhat unusual in implementation.
Quote from: prissi on November 26, 2020, 01:23:17 AMBut updating the screen without moving vehicles first is also useless in terms of display smoothness.
Quote from: prissi on November 26, 2020, 02:07:24 PMThe graphics are only demanding when zooming out a small tile set like pak64, so that a lot of tiles are visible.
Quote from: Antarctica on November 28, 2020, 10:37:49 PMI don't understand much about 2D rendering, but the guys who developed Factorio got it right I think. IIRC they only use 2D models ("sprites") and they can render quite a bunch of those without delaying simulation too much. They wrote about some of that in their "Factorio Friday Facts" blog articles, but I didn't understand everything. But when I played factorio for the first time in August, I thought about how bad other 2D games actually perform - besides Simutrans also Age Of Empires 2 especially, where 300 archers firing already make the game nearly unplayable.
Quote from: prissi on November 29, 2020, 12:02:15 PMThe solution, implemented in the old Simutrans3D brach was to have all images in a big texture, to avoid loading images from and to the graphics board, which would take more time than software rendiering. (Since the PCI bus is slower than the memorz access.)