The International Simutrans Forum

 

Recent Posts

Pages: 1 ... 7 8 9 [10]
91
If the pakset contains so small vehicle that it could not load at least one unit of any good, I would consider that a pakset bug.
Not "any" good, but a specific good of the category it's supposed to carry.
With your idea, consider three different piece goods: A weights 500kg and needs 1m², B is very heavy, 2t on 1m², while C is eg. a car, 1t, but needs 8m². An early ox cart might realistically carry good A, but not goods B or C. However, it would still be a piece good vehicle, with B and C being piece goods, and you get to a situation where a piece good vehicle can't carry a single unit of a piece good.
In order not to create what you call a "pakset bug", the pak creater would be forced to make the ox cart capable of carrying 2t weight and 8m² space. Which, beside allowing one unit of B or one unit of C, also allows four units of A. Quite the ox cart! [and an extreme example]


Anyway - don't dismiss the option of additional good categories. If you had two piece goods categories, you could still make sure that real vehicles play to their strenght. If in reality it can carry a lot of weight but doesn't offer much space, it's in the "heavy" category. You get the gameplay element of needing to use different vehicles for gold bars and pillows without a danger that they accidentially ruin you while transporting the wrong thing, so it's much friendlier to beginners. Meanwhile, nothing about the program has to change. It's unexpected, some might say unrealistic, but it's no more an approximation than the category system as a whole (EVERYTHING is piece good if you put it in a box - eg. tank containers)
92
Simutrans Extended Development / Re: Core performance improvements
« Last post by Mak on November 26, 2020, 12:45:21 PM »
What I have in mind right now (disregarding multithreaded game loop) are two possibilities:

1:
  • Run game loop iteration
  • Copy what is currently in viewport to a buffer
  • Render the buffer and continue game loop

2. Have two world instances: one for rendering and one for game loop
  • Run game loop iteration
  • Calculate diff from the last iteration
  • Apply diff to rendering world instance
  • Render what is currently in buffer and continue game loop

I think the UX would be better with option 2, but that would mean that RAM consumption would probably be significantly higher. I'll have to investigate and test.

But updating the screen without moving vehicles first is also useless in terms of display smoothness.

It isn't. You still need to be able to scroll the map and run the animations for other things, like pedestrians, smoke and water. These might not be the most important things, but they provide better user experience.

Additionally, once everything else is set up, it starts to make sense looking into how to optimize/parallelize game loop calculations.
93
Bug Reports / Re: Large convoi (and other lists) almost unresizable
« Last post by prissi on November 26, 2020, 07:07:33 AM »
Ok, heavy EDIT!

I tried also some caching. I noticed that during one resize event before the next draw the gui_scrollpane_t::set_size is called 20x times, but only 4 times after your optimisation. I think you did a good job already.

I noticed, clicking on the resize button (but not resizing) enlarged the convoi to the max width (seen by the loading bar).
94
Bug Reports / Re: Large convoi (and other lists) almost unresizable
« Last post by Dwachs on November 26, 2020, 06:35:18 AM »
Pak-selector is fixed in r9448, calls to duplicate components are caught in r9449.  Still the list is not as reactive as it should be. Edit: with optimized build it is acceptable.

What do you mean with "Now even updating the slider seems to call the scrollpane in all tabs." ?

I tried caching some stuff within gui_aligned_container, but it did not work. Scrolled lists appeared empty.
95
Bug Reports / Re: Large convoi (and other lists) almost unresizable
« Last post by prissi on November 26, 2020, 05:33:04 AM »
Unfortunately, with these cahnges the modal pak set selector at the beginning does no longer show up and simutrans freezes.

Maybe a gui_aligned_container_t should cache its min/max size unless there was a draw or an add/remove component call. Because the five tabs in the convoi list have all the same container but it seems that it is called five times when resizing. This of course implies to remove the const from all get_min_size() calls.

Or at least teh scrollpane should cache the minimum size before each draw event. Now even updating the slider seems to call the scrollpane in all tabs.
96
Simutrans Extended Development / Re: Core performance improvements
« Last post by prissi on November 26, 2020, 01:23:17 AM »
Also the vehicle movement is connected to the game logic, since there are signals etc. Thus a deterministic threading without wasting most of performance on waiting is quite a challenge and probably rather require a total rewrite of Simutrans. But updating the screen without moving vehicles first is also useless in terms of display smoothness.
97
Pak128 / Re: Snow view
« Last post by Vladki on November 26, 2020, 12:04:09 AM »
Not sure to correctly understand the sense of your sentence.
I think that is related to your first request for way images that are half snow. This transition is not limited to slopes. It can be even on flat land if some tiles are in arctic climate (e.g. by using the public player), and thus the snow may be only in a corner of a tile, just like on the image you posted (on the corner of hill). I think this would need some sort of blending logic to blend the snow and non-snow images of ways.
98
I don't think nice is a good option here as the server already runs out of memory anyways.
I tried compiling simutrans-extended, at my home computer (linux), and memory is not the problem. "make -j3" required at most half GB extra. Usually just 200 MB. But if the server is already struggling with memory, then using "nice" and single thread compilation is the way to go. Single thread compilation was fine with just 100 MB of RAM
99
Forum / Re: Extended development board is chaos
« Last post by Isaac Eiland-Hall on November 25, 2020, 11:24:17 PM »
I have noticed that I appear to be an administrator.

Yay!

I wonder whether that means that I can make these changes myself?

Yes, indeed. Giving you that ability was part of the reason for the upgrade :) As the force behind a major part of the Simutrans community, it made sense to have you as an admin :)

If so, I am not entirely sure how to go about doing that.

I just got back into the forum today, sorry for the delay.

It's in the forum admin that you now have access to. If you've already looked at that, or you look at that after this reply and still aren't sure, please poke me and I'll be glad to handle it, no worries. :)
100
Pak256.Ex / Re: Players' screenshot
« Last post by Isaac Eiland-Hall on November 25, 2020, 11:20:49 PM »
Yes, that would be implied by the board this topic is in.
Pages: 1 ... 7 8 9 [10]