News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Insane delay OSX 10.9

Started by transporter, December 08, 2013, 02:46:07 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

transporter

I'm not sure if this would be the place to put it, but I (finally) got 112.3 to work on OSX 10.9. This is odd considering my old machine could run at 25+ fps while this one, which by all means should be blazing fast, seems locked at 11 fps. Simloops are between 2.5 and 3.5 depending on any activity on screen, and fast forward is very jumpy. The world seems to run at the right speed, but moving the map, clicking, and building are all delayed by 5-10 seconds each interaction. World generation time seems accurate, so I'm not sure why the map itself would slow down.


Other specs (brand new Macbook Pro)
Intel i7 Quadcore
16 GB RAM
500GB SSD
NVidia GeForce 750M

Ters

Increased screen resolution, such as Retina, would slow down Simutrans as it has to draw more (in the case of Retina, much more). How many pixels is tall and wide is your Simutrans window?

transporter

That makes sense, but would the more powerful machine balance that out? Yes it's the Retina and I've been maximizing the window. Not quite fullscreen, but close.


EDIT: Under some testing, I think you're right. But why such a huge performance hit? How is it that it isn't at least similar to my older machine?

Ters

During the last decade, computers haven't gotten much better at doing graphics the way Simutrans does it. At least not compared to how much they've improved in other areas. Simutrans is very much a game from the 1990ies, and isn't able to utilize the power of modern graphics cards. All attempts to make Simutrans take advantage of moderns graphics cards have so far failed, as they way Simutrans works is very at odds with how hardware acceleration works.

There have been some attempts at making use of the multiple CPU cores to speed up rendering, which apparently does help, but there is still the main bottleneck of getting all the data from the CPU, through RAM and to the screen. I'm not sure if this was ready or enabled in the last stable. Someone was also looking into, or thinking about looking into, having Simtrans run internally in non-retina resolutions, and using hardware to scale the image up to the same physical size as it would be on a non-retina display (obviously without the retina level of detail).

Markohs

I have similar problems on my computer, a Windows 7 machine that shows similar problems on my new monitor, at 2560x1600. I'm trying to fix it, making it more responsive. If I'm successful, it will be useful in your computer too, I'll keep you up to date.

Ters

Quote from: Markohs on December 08, 2013, 05:10:03 PM
I have similar problems on my computer, a Windows 7 machine that shows similar problems on my new monitor, at 2560x1600. I'm trying to fix it, making it more responsive. If I'm successful, it will be useful in your computer too, I'll keep you up to date.

This will only solve the problem with
Quote from: transporter on December 08, 2013, 02:46:07 AM
The world seems to run at the right speed, but moving the map, clicking, and building are all delayed by 5-10 seconds each interaction.
or?

transporter

I
Quote from: Ters on December 08, 2013, 04:45:22 PM
Someone was also looking into, or thinking about looking into, having Simtrans run internally in non-retina resolutions, and using hardware to scale the image up to the same physical size as it would be on a non-retina display (obviously without the retina level of detail).

This I would go for. Simutrans isn't meant for HD graphics and detail, but a simulation and in that it does great. A resolution hit back to how it looked on the bigger pixel screen wouldn't take anything away really.

I also just checked OpenTTD to see if there's any performance change and there's not. I realize there isn't too much similar between the two, but would there possibly be enough of a coding similarity to try to find the solution there?

Markohs

Yes ters, only the interactivity issue

Ters

Quote from: transporter on December 08, 2013, 06:08:57 PM
I also just checked OpenTTD to see if there's any performance change and there's not. I realize there isn't too much similar between the two, but would there possibly be enough of a coding similarity to try to find the solution there?

I haven't looked at OpenTTD, but have some ideas of my own. Unfortunately, the problem is so fundamental that half of Simutrans likely has to be written again from scratch.

whoami

For the pixel numbers: using full-screen mode with a specified resolution (use fractions of the actual pixel counts for each dimension) should put the entire scaling effort into the graphics hardware. (I have no idea whether this works on MacOS).
in simuconf.tab
fullscreen = 1
# also see readme.txt, -screensize option
display_width = ...
display_height = ...

If the program behaves odd and jumpy, it often helps to activate pause and release again after a little time.

If the water is animated, turning this off (water_animation_ms = 0) will improve performance.
If there is a huge number of trees to be displayer, it may slow down, too; maps can be set to have no trees.
Also, omit any transparancy in the display options.

transporter

Tried with no trees. Fps improved from 11 to 12. no water animations

prissi

OpenTTD uses 8 Bit mode, which needs much less data to be moved. Simutrans should run also faster, if you zoom in, i.e. make the tile larger. Not as fast as Hardware rendering, but it should help. The other thing you can do is running simutrans under a virtual machine in WIndows mode, since the MAC SDL release is not really great adapted to the MAC (none of the developer has a MAC).

YOu could also try the SDL2 build, if you can comiple programs yourself.

transporter

I don't have nearly the knowledge to do either of those. But zooming in doesn't help either. It seems to be only relevant on the window size

Ters

Sounds like its bandwidth limited then. The bandwidth required for sending 2560x1600 of 16-bit pixels 25 times per second isn't too far from what the bandwidth on a modern MacBook Pro is (according to Wikipedia). Then there is all the other stuff beyond Simutrans' graphics that needs to move around on the system. If SDL does conversion from 16-bit to 32-bit in software, it gets worse.

ArthurDenture

The SDL2 build will be the only way to solve the performance problem. There are simply too many pixels to push without hardware acceleration.

Maybe it would be possible to switch the Mac nightly builds to use SDL2?

Ters

How does SDL2 help? By not running in Retina resolutions? Does it do that on it's own, or must Simutrans be set up a special way?

ArthurDenture

Quote from: Ters on December 10, 2013, 05:38:53 AM
How does SDL2 help?

SDL2 uses hardware acceleration for its 2D rendering, whereas SDL1.2 doesn't. (It creates a 2D OpenGL context under the hood and gives you a hardware surface to draw on.)

Ters

But Simutrans doesn't use SDL for rendering. It does the rendering itself, and only use the backends for transferring the end result to the screen. Simutrans still has to transfer 8 MB from RAM to CPU to RAM to VRAM every frame (first and third step is likely less than 8 MB, but not necessarily by much for the third step). That's almost 200 Mbit per frame, and almost 5 Gbit/s for 25 FPS. A worst case scenario, but that's only for the graphics, not the simulation (or sound).

ArthurDenture

Quote from: Ters on December 10, 2013, 06:26:25 AM
But Simutrans doesn't use SDL for rendering. It does the rendering itself, and only use the backends for transferring the end result to the screen. Simutrans still has to transfer 8 MB from RAM to CPU to RAM to VRAM every frame (first and third step is likely less than 8 MB, but not necessarily by much for the third step). That's almost 200 Mbit per frame, and almost 5 Gbit/s for 25 FPS. A worst case scenario, but that's only for the graphics, not the simulation (or sound).

Thing is, that doesn't end up being the slow part. It takes non-zero time, but I still get a solid 25-30 fps when playing maximized at 1920x1200 (and it does help that we attempt to only redraw dirty rectangles on each frame). But with software acceleration, after drawing each frame, the call to SDL_Flip or SDL_UpdateRects would then take more than 100ms to ship the pixel buffer off to the screen, making Simutrans unplayable on a Mac. So that's the problematic bottleneck that disappeared with SDL2. http://wiki.libsdl.org/MigrationGuide#Video describes this a bit.

Markohs

I had a quick look to the SDL2 port and it should be as fast as the OpenGL port, because if I understood it correctly you just create a texture of the size of the screen and just update it each frame and show it on screen, no? What about non power of two dimensions, you just choose the more similar sizes the hardware offers as similar? Texture is scaled after?


Ters

SDL2 just works around some odd thing with SDL1 and Mac. SDL1 can do 1920x1080 fine on a my laptop, even when I do other things on the other screen. But as we move to super-HD resolutions, SDL2 can't get around the fact that Simutrans is moving lots of pixels through the system bus every frame. SDL2 might be just enough to get 2560x1600 working, though. I don't know what resolution transporter's old machine had.

TurfIt

There's been enough reports of OSX and SDL1 disagreeing that IMHO it's time to abandon it. SDL1 does still provide the fastest screen updates on Win7, so is still useful there. For Macs, the releases and nightlies really should be moved to SDL2...

Ters

Yes, SDL1 and Mac is a known poor combination it's not worth clinging to. I was just pointing out that the switch SDL2 might only give us a short reprieve. It may not even help transporter, but it's worth a shot. Is it possible to make an SDL2 build of the latest stable, or do we have to wait until the next stable some time next year?

prissi

Weren't there still issues with SDL2 with Unicode? Could one rather use the OpeGL backend directly?

TurfIt

I don't remember seeing any bug reports about the unicode. The SDL2 backend is just taking whatever text is sent to it by the SDL2 text input routine. Likely there are still some lurking issues, but until the backend hits the nightlies, I doubt we'll see any more progress; Likely all those able/inclined to compile it on their own have done so by now...

Last I checked, the OpenGL backend comes with quite a performance hit, ~30% on Win7 IIRC. I've no idea how it does on OSX.

Markohs

Quote from: TurfIt on December 10, 2013, 11:27:35 PM
I've no idea how it does on OSX.

My wild guess is that the OpenGL + SDL1 backend will have the same performance than the SDL2, but it's pure speculation.

Ters

Quote from: Markohs on December 10, 2013, 11:41:51 PM
My wild guess is that the OpenGL + SDL1 backend will have the same performance than the SDL2, but it's pure speculation.

It should be able to at least.

wernieman

The Cross-Compiler for the MAC-nightly was not easy .... I could canche the generation to OpebGL or SDL2 ... but please Test it, before I must do it! It is not ... easy

I hope you understand my English