Recent Posts

Pages: [1] 2 3 4 ... 10
Other paksets / Re: pak64 - Scale
« Last post by IgorEliezer on Today at 09:16:52 AM »
Bug Reports / Re: Remove Way - No preview when dragging
« Last post by Dwachs on Today at 07:40:38 AM »
@userfriendly: Solution should be simple: first copy data the old way (before your patch), then call the method of your patch
Code: [Select]
*addtool = *(general_tool[toolnr]); // this line was removed by the commit, bringing it back could help?
set_defaults_general_tool(addtool, param_str);
Found no time to test whether this would work.
Extension Requests / Re: Tall bridges, issues
« Last post by Leartin on Today at 06:11:28 AM »
As for two-tiled ramps, one would have to figure out how to select the height to build. If you just want to go over a bit of backwater from land at the same height, going up two levels would be a bit overkill. On the other hand, going up two levels should be default, or new players would get very confused as to how to build a bridge over another road. Perhaps some modifier to build the lower bridge, unless length is less than 5. Isn't there already some modifier for choosing whether to go up one or two levels if the bridge supports both height of ramps?
Currently, all bridges are low by default, but high when buildt over another way or when CTRL is pressed while building. (at least with half-height paksets)

Can we assume no bridge will support going up one and two levels in one tile and two levels in two tiles?
No, we cannot. I mean, I'm sure it could be programmed to only accept one or the other, but if not artificially enforced, both could exist in parallel, and someone will provide both in one bridge.

And what should be the default when building a bridge from one one level slope? If crossing a river, you might want to go up one level to let boats through, but it would be an unnecessary bump in the road otherwise.

For Two-Tile ramps, the logic would probably be:
If CTRL is not pressed, build a low bridge, if that fails, build a two-tile ramp, if that fails, build a one-tile-two-level ramp, if that fails, throw error.
Similarly, on slopes the bridge would first try to be straight (unless CTRL), then one level up, than two level up.
"failing" here means that the type of ramp does not exist in that particular bridge, that there is not enough space (for two-tile ramps), that there is something in the way, or that the bridge can't end.
Bug Reports / Re: "Game Info" ('n' key) -- mouse detaches, game hangs
« Last post by Ters on Today at 05:58:33 AM »
Triggering blocking remote calls to an unreliable server on some "random" normal key doesn't sound like a good idea to me. I find it annoying as it is that any unmapped key brings up the help window, which freezes up Simutrans for a second or two the first time.
Patches & Projects / Re: SDL2 performance regression
« Last post by Ters on Today at 05:53:43 AM »
I have used the GDI backend for years now, I think mostly to avoid having to set up SDL as a dependency, and Simutrans runs just fine. Never had any need for any of this threaded rendering stuff either. My computer is getting rather old, but I run Windows 10. But then I never zoom in or out (intentionally).

The lack of hardware acceleration in GDI might mean nothing for Simutrans, as Simutrans only uses a single GDI function every frame: StretchDIBits. That one may or may not still map pretty straight through to hardware, at least when no special effects are applied. The same is through for all other backends. Simutrans doesn't use them for drawing stuff, just the final upload of pixels to screen. However, since copying these pixels to screen may involve switching to kernel mode, doing a lot of small dr_textur may be less efficient these days, since switching to kernel mode has become more expensive with the patches for Meltdown.

It is possible that GDI is slow, or slower than the others, when DPI scaling is enabled. I have never tried out that, as I only have a HD monitor.
Can confirm that pak128.Sweden-Ex now appears to download perfectly.

I would say the tool is mature enough for a more wide scale deployment.
Pak192.Comic / Re: Indonesian P192C add-ons
« Last post by Suneo Wahyu Hidayat Hartanto on Today at 05:46:05 AM »
some addons from us ;D ;D ;D, we are currently using version 0.4.1 because 0.5.0 still has a lot of bugs. from the image can be seen a McDonals, Parking lot, Indomaret (minimarket Indonesia) and Office of a Company. :laugh: :laugh: :laugh:

simscr32" border="0
testing this thoroughly is not straightforward when that pakset seems to have no commercial or industrial city buildings, and the supplied sample buildings are all residential (what I wanted to test was how this interacts with the passenger generation system; this should not be a problem, as  I think that I already did code for this, but I do want to be sure).

Thank you for having a deep interest on this patch. I added commercial and industrial city buildings in the test addon set. With that, the patch seems to work fine.
I also implemented the cluster rule for multi-tile buildings, but I'm not sure it is working fine because the number of buildings is still not enough to confirm that. (commit:

One issue that my testing has demonstrated, however, which might need some further refinement of this model, is that multi-tile city buildings never seem to be renovated/redeveloped when a city expands.

I conducted a experiment and it showed that multi-tile city buildings are also renovated. However, the frequency of that is quite low. This is not so strange because there are many low level single-tile buildings in a city and these tend to be selected for renovation more frequently.
During the test, I found a problem in the calculation of population, and it is now fixed. All changes were committed on the git repository.
Patches & Projects / Re: SDL2 performance regression
« Last post by DrSuperGood on Today at 04:26:22 AM »
All modern OS run most of GDI (except a few select features) with software emulation as it is incompatible with newer more efficient display models. GDI used to be a lot faster as it would write directly to output buffers and have many of its draw options hardware accelerated.

Starting with Windows Vista most GDI hardware acceleration support was dropped as it conflicted with the new window management system. Instead GDI draw calls are applied to an internal window buffer using software routines. When it comes time to display the results the windows management system pushes this buffer out as a texture to the graphic sub system to be displayed. This was required because modern window management systems are hardware accelerated and responsible for drawing all windows unlike the GDI approach where each application was responsible for drawing its window when requested. The cost of this was a massive GDI performance regression as it was no longer possible to hardware accelerate GDI calls.

GDI was replaced by Direct2D in Windows Vista and newer OSes, which is pretty much fully hardware accelerated.
Patches & Projects / Re: SDL2 performance regression
« Last post by TurfIt on Today at 03:57:12 AM »
I rather doubt the meltdown/spectre patches are involved - the computer in question is an older win7 unit that hasn't been updated since these came out.

I've now tried on two other systems. Neither shows the large slowdown of the first, but one has SDL2 performing bad period, and all 3 have GDI terrible.
1) I7-3700k, AMD 7970, Win7. SDL2 ok in directx mode, not opengl unless dirty tiles turned off (-use_hw). SDL1 ok - slightly faster, GDI bad.
2) I7-6700k, Nvidia 980ti, Win10. SDL2 ok (directx 10% faster than gl, but gl still ok). SDL1 same times as SDL2. GDI completely unusable zoomed out - > 100ms frame time!.
3) i5-3210M based laptop, Intel graphics, Win10. SDL2 slow across the board, but same directx and opengl. SDL1 ok (50-100% faster zoomed in, but same when zoomed out). GDI 20% slower than SDL2, but remains usable.

Too many variables. WAG - bad ATI driver update... and Intel drivers are always bad for performance.

Disabling the forced opengl mode 'fixes' the issue on system 1. I'd planned to commit that anyways since Dwach's SDL2 crash fixes seemed to fix the directx crashes too, but was/am waiting for after the release so it can have some wider testing...

GDI as a backend choice should just be removed. It's terrible, and just getting worse. >100ms frame times when zooming all the way out now - lol. SDL1 is doing 17ms displaying the exact same.

Use_HW has never really been a good idea with SDL, and the documentation even says so.
Note: the SDL1 -use_hw switch was hijacked by the SDL2 backend to do something very different for testing reasons, and never was removed. In SDL2 it disables the dirty tile calls to SDL_UpdateTexture() and just calls it once updating the entire screen. On system 1, opengl, any more then ~80 update calls it is faster to have one call doing the whole screen.

On Linux 3.16, amd64, with SDL2 2.0.2, SDL Driver: x11:
Thanks for trying, but I'm confused... SDL Driver:x11 is a printout from the SDL1 backend... SDL2 doesn't show such??
Also SDL2 2.0.2 is quite old. Perhaps try with 2.0.7 current version if possible?
And, unless you're printing out the raw frame timing, you won't see the actual times. The gui displayed times include waiting time.

One way to test without a custom executable is to simply zoom out (and running a high enough resolution) enough to overload your computer so it can't keep up with the selected fps. That's how I noticed it in the first place - zoomed out on a computer than could previously easily handle 30 fps and ended up at 20 instead...
Pages: [1] 2 3 4 ... 10