The International Simutrans Forum

Community => Simutrans Gaming Discussion => Topic started by: jamespetts on July 28, 2015, 10:05:55 PM

Title: Windows 10 and Visual Studio 2015
Post by: jamespetts on July 28, 2015, 10:05:55 PM
May I ask whether there are any particular issues that have been identified in relation to using and/or developing Simutrans on the next version of the Windows operating system, due to be released to-morrow? For anyone who does upgrade to Windows 10, it would be useful to know their experiences with using/developing Simutrans using that operating system.

On the development side, will we have to upgrade to Visual Studio Community 2015 (which was released last week) to develop in Windows 10, or will the 2012/2013 editions still work? Is it worthwhile upgrading to 2015 even if older versions do continue to work? Is there anyone here who has experience of the Windows 10 beta and has any idea of what to expect for developers?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on July 29, 2015, 04:57:09 AM
The mostly belongs on the programmer board, not the gaming board.

Though I intended to, I haven't tried running Simutrans on the Windows 10 previews, as Windows 10 and VirtualBox haven't been the best of friends.

There is no need to upgrade to a newer Visual Studio unless you want to use new features in Windows 10. In fact, there is no need to use Visual Studio at all. Windows 10 shall still be able to run programs compiled on and for Windows 95. (As far as I know, even Windows 3.1 programs should work, though only on 32-bit Windows 10.) There might be bugs in this backwards compatibility, though, and some applications that should not have worked in the first place, might suddenly fail like they should have from the start.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on July 29, 2015, 01:57:42 PM
QuoteIs it worthwhile upgrading to 2015 even if older versions do continue to work?
Based on the release notes it is a good idea. Even a re-build using 2015 could (no promises) result in potentially faster code. Like with 2013, the community edition is available for free which is the full 2015 package usable by private people to create commercial programs.

Simutrans should still work on Windows 10. There is no reason it should not seeing how Microsoft generally does a good job with compatibility.

If you want to build programs specifically targeting Windows 10 (eg using Direct3D 12) then 2013 will probably need some patch to add the Windows 10 SDK. 2015 should come bundled with the Windows 10 SDK although that was disabled until today as part of Microsofts Windows 10 release plan.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Isaac Eiland-Hall on July 29, 2015, 02:30:54 PM
I've been running the Windows 10 Previews on my desktop and laptop for a couple of months, and have played Simutrans with no difficulties at all, though I haven't played very much.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on July 29, 2015, 02:45:58 PM
Quote from: DrSuperGood on July 29, 2015, 01:57:42 PM
2015 should come bundled with the Windows 10 SDK although that was disabled until today as part of Microsofts Windows 10 release plan.

That's a bit odd. Why don't they want third-party "launch titles"? I've also read that the separation between Visual Studio and Windows SDK has been changed now, so that the SDK no longer is a stand-alone product.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on July 29, 2015, 08:07:00 PM
QuoteThat's a bit odd. Why don't they want third-party "launch titles"? I've also read that the separation between Visual Studio and Windows SDK has been changed now, so that the SDK no longer is a stand-alone product.
Windows 10 SDK worked fine in the 2015 developer preview which is what was used to develop launch titles for Windows 10. Microsoft even recommended you hold off migrating from developer preview to release if you are in the middle of a Windows 10 project until Windows 10 is released. Not that any of this matters anymore as the SDK should now be enabled.

The SDK is offered stand alone, however it is much bigger than it used to be several years ago and is included with MSVC during installation. In the old days you needed to manually install the SDK after installing MSVC and also there were several SDKs to choose from such as DirectX SDK (now part of Windows SDK).
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on July 29, 2015, 09:51:48 PM
I did give some thought to which was the correct board for this, and did consider Programmers' Corner, but that seems to be for specific projects, and is limited in who may post, so I though that a general board might be more appropriate. Forgive me if I made the wrong decision in that connexion.

Thank you for your various thoughts. One very small thing: am I correct in understanding that Windows 8 and 10 have larger icons for programs than Windows 7 and earlier? If this is so, what version of Visual Studio is necessary to produce these larger icons, and how would one go about setting that up? It would be unfortunate if our icon were to look too pixellated, making the game look out of date.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on July 30, 2015, 02:15:09 AM
QuoteThank you for your various thoughts. One very small thing: am I correct in understanding that Windows 8 and 10 have larger icons for programs than Windows 7 and earlier? If this is so, what version of Visual Studio is necessary to produce these larger icons, and how would one go about setting that up? It would be unfortunate if our icon were to look too pixellated, making the game look out of date.
I do not think people care much. If you really have to know you can probably find out reading 2015's documentation about how to make an app as it will likely explain icon specifics in there somewhere. From what I have read it is likely the same as it always has been. For high resolution icons you simply added higher resolution icon resources. The OS should then select the most appropriate one for your DPI and intended size or scale the closest available icon.

Here (https://msdn.microsoft.com/en-us/library/vstudio/hh409293.aspx) is what 2015 brings for C++ development (relevant).
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on July 30, 2015, 05:03:47 AM
Quote from: DrSuperGood on July 29, 2015, 08:07:00 PM
In the old days you needed to manually install the SDK after installing MSVC and also there were several SDKs to choose from such as DirectX SDK (now part of Windows SDK).

I was thinking the other way around. Before, one could just install the SDK and develop Windows application. That's not possible anymore from what I understand, one must now install Visual Studio in order to develop applications. The SDK is nothing on its own (except very dry reading material).

Quote from: jamespetts on July 29, 2015, 09:51:48 PM
One very small thing: am I correct in understanding that Windows 8 and 10 have larger icons for programs than Windows 7 and earlier? If this is so, what version of Visual Studio is necessary to produce these larger icons, and how would one go about setting that up? It would be unfortunate if our icon were to look too pixellated, making the game look out of date.

Microsoft's icon guideline (https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx) doesn't mention any changes to icons since Windows Vista introduced 256x256 pixel icons. Such high-res icons might be more commonly used in a tile environment than on the desktop, though. Unless there is some new concept hidden somewhere else that I can't find, MSVC must lag seriously behind in icon support if you need to upgrade to 2015.
Title: Re: Windows 10 and Visual Studio 2015
Post by: prissi on July 30, 2015, 08:14:21 PM
At least the icons in the taskbar have become smaller, and look dead ugly in the today release. (Actually, the visual appearance gets again closer to the 16 color Windoiws 3.11 look.)
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on July 30, 2015, 09:01:15 PM
The default black and white theme, plus the snapping that makes it easy to tile windows, made me think of Windows 1.0, which was monochrome and didn't support overlapping windows.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on July 30, 2015, 10:25:49 PM
They've just removed the dot.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on July 30, 2015, 10:55:06 PM
Waiting to see if Windows 10 ever does download lol. I know I could force it with some command hackery but I want to see if it eventually downloads or not.

Reasons to use Windows 10 are more technical than practical. Specifically DirectX 12 which will be used and required by pretty much all games in the coming years (as it mirrors the console APIs largely).

I wonder if Direct3D 12 could be used to make Simutrans graphics faster. It is a different approach to graphics which may or may not be more compatible with simutrans than previous OpenGL/Direct3D versions.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on July 30, 2015, 11:00:18 PM
I think that the rollout for people who had pre-subscribed for a free upgrade will be measured in weeks rather than hours.

As to Direct3D 12, are the differences likely to make it easier to convert Simutrans? This will not be very cross-platform compatible, though, I imagine; or would the idea be to accelerate graphics in Windows and leave them as they are on other platforms? Is graphics speed really a problem now that they run in their own thread?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on July 31, 2015, 05:59:09 AM
Quote from: DrSuperGood on July 30, 2015, 10:55:06 PM
I wonder if Direct3D 12 could be used to make Simutrans graphics faster. It is a different approach to graphics which may or may not be more compatible with simutrans than previous OpenGL/Direct3D versions.

As long as there is a 3D in it, I doubt it. Direct2D might be more suited, but Mingw doesn't do anything higher than DirectX 7 (perhaps a little bit of 8).

Quote from: jamespetts on July 30, 2015, 11:00:18 PM
I think that the rollout for people who had pre-subscribed for a free upgrade will be measured in weeks rather than hours.

I've heard that someone had read that Windows 10 is rolled out to Insider members first, and then to other users once enough other users with a similar set-up to them had run Windows 10 successfully for a while. I haven't even installed the updates that will perform the installation. To have an escape route, I'll make a complete backup of my c: partition first. That is time consuming, and leaves me without a usable computer while it's happening, so I'm waiting for summer to come, when I can just daze in the sun. (However, it looks like summer may not come until next year.)
Title: Re: Windows 10 and Visual Studio 2015
Post by: prissi on July 31, 2015, 11:01:54 AM
The computer I got window 8 first was a computer sitting in a lap with an extremely bad WiFi connection (one bar, dropping after 5 minutes). Still Yesterday it had WIndows 10 ready to install (I reserved it there a month ago though).
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on July 31, 2015, 04:02:29 PM
According to co-workers more eager for Windows 10 than me, the download started well ahead of the offical launch date.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Isaac Eiland-Hall on July 31, 2015, 07:42:59 PM
I read articles saying that the download would happen before the release date.

In my case, it's not prompted me to upgrade on either computer; I have the "reservation" on both. :shrug:

I'm actually good with that - I bought a Windows key for 8.1 that I realize now was someone reselling Technet keys - because they said "single activation only".... so... I'll probably have to get new keys for 10. :|
Title: Re: Windows 10 and Visual Studio 2015
Post by: An_dz on July 31, 2015, 10:08:48 PM
I'm not upgrading yet as the OneDrive app is not that good as in Win8.1 and I could not find yet a way to stop all updates from downloading, just some.

Quote from: jamespetts on July 30, 2015, 11:00:18 PM
As to Direct3D 12, are the differences likely to make it easier to convert Simutrans? This will not be very cross-platform compatible, though, I imagine; or would the idea be to accelerate graphics in Windows and leave them as they are on other platforms?
Convert for the Windows Store? If so I believe it will since Windows Phone and Xbox have DirectX integrated. It would be, anyway, not cross-platform since DirectX is Windows only, on other systems SDL would stay. Right now we already have GDI that's also Windows only so a DirectX version could replace the GDI.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on July 31, 2015, 11:14:42 PM
Quote from: An_dz on July 31, 2015, 10:08:48 PM
I could not find yet a way to stop all updates from downloading, just some.

Buy the Enterprise edition. Home editions can not be configured. Users not patching their Windows is too big a problem for the Internet I guess, so Microsoft won't give them a choice anymore. This is my biggest concern about upgrading. How well will Windows install updates when I unplug the computer before leaving for work?

Quote from: An_dz on July 31, 2015, 10:08:48 PM
Convert for the Windows Store? If so I believe it will since Windows Phone and Xbox have DirectX integrated. It would be, anyway, not cross-platform since DirectX is Windows only, on other systems SDL would stay. Right now we already have GDI that's also Windows only so a DirectX version could replace the GDI.

I have made a DirectSound8 backend to replace the Windows Multimedia API backend. Music is a different matter, as I'm not sure there is any replacement API for MIDI. Xbox and Windows Phone probably doesn't do MIDI at all.

As for the new graphics APIs, they seems to be massive beasts, requiring a lot of code to set up.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 01, 2015, 12:24:30 AM
QuoteAs long as there is a 3D in it, I doubt it. Direct2D might be more suited, but Mingw doesn't do anything higher than DirectX 7 (perhaps a little bit of 8).
Direct2D is nothing more than a legacy wrapper for Direct3D which exists for convenience. In the old days it was aimed at 2D hardware acceleration but since most GPUs sold now support 3D acceleration it acts as a wrapper for Direct 3D with some pre-configured and standardized sharders. Direct3D represents an API to access GPU resources for the production of visual graphics. DirectCompute represents an API to access GPU resources for the purpose of GPU offloading non-graphic calculations which need similar computations to graphics.

The only reason I mention Direct3D 12 is that people have made previous attempts at hardware acceleration of graphics. These attempts were deemed too inefficient due to the APIs available to the point that single threaded graphics was still faster. Direct3D 12 offers new APIs that are lower level and faster so might be more compatible with how Simutrans does graphics.

Do note that OpenGL is also meant to be getting a revision that does something similar to Direct3D 12 by trying to make the API lower level. Unlike Direct3D 12 this should be available on both Linux and Mac systems. Chances are it still will need Windows 10 for windows users however.
Title: Re: Windows 10 and Visual Studio 2015
Post by: An_dz on August 01, 2015, 12:38:24 AM
Quote from: Ters on July 31, 2015, 11:14:42 PMBuy the Enterprise edition. Home editions can not be configured.
I have the Pro version and I can stop most updates but I've read security updates still download and I don't want them downloading when I'm using my phone internet.

Quote from: Ters on July 31, 2015, 11:14:42 PM
As for the new graphics APIs, they seems to be massive beasts, requiring a lot of code to set up.
I think DirectX has a compatibility layer for GDI+. I have no idea if this makes anything easier.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 01, 2015, 08:34:30 AM
Quote from: DrSuperGood on August 01, 2015, 12:24:30 AM
Direct2D is nothing more than a legacy wrapper for Direct3D which exists for convenience.

It's not a legacy wrapper. It's almost brand new.

Quote from: DrSuperGood on August 01, 2015, 12:24:30 AM
The only reason I mention Direct3D 12 is that people have made previous attempts at hardware acceleration of graphics. These attempts were deemed too inefficient due to the APIs available to the point that single threaded graphics was still faster. Direct3D 12 offers new APIs that are lower level and faster so might be more compatible with how Simutrans does graphics.

The key isssue is whether the API allows you to do simple blitting directly. If one has to send verticies with world coordinates and texture coordinates, sending that is more data to send across the bus than just doing it software like Simutrans does now. It is also problematic if changing source image is expensive, because Simutrans hardly ever draws the same image twice. Looking at the preliminary Direct3D 12 documentation, it looks insanely cryptic.

Quote from: An_dz on August 01, 2015, 12:38:24 AM
I think DirectX has a compatibility layer for GDI+. I have no idea if this makes anything easier.

That's likely the other way around. You first set up Direct3D, then you can do something that let's you use GDI+ to draw to it's textures.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 01, 2015, 05:17:44 PM
QuoteIt's not a legacy wrapper. It's almost brand new.
Although dated here is my reference.
QuoteDirect2D is a user-mode library that is built using the Direct3D 10.1 API. This means that Direct2D applications benefit from hardware-accelerated rendering on modern mainstream GPUs. Hardware acceleration is also achieved on earlier Direct3D 9 hardware by using Direct3D 10-level-9 rendering. This combination provides excellent performance on graphics hardware on existing Windows PCs.
It is nothing more than a wrapper of Direct3D. Although I do admit I was confusing it with DirectDraw (I am sorry but one forgets) so you are right that it is pretty new.

Direct3D 12 allows the use of a resource table (among many other features). This is meant to allow more resources to be cached and efficiently used than the previous API (greatly reducing I/O and driver overhead). For example current generations of video games can see astounding performance enhancements (as much as 40% some developers have reported) from the same hardware. However if this would help Simutrans at all is entirely another question as from what I can tell Simutran's graphics were designed for software rendering (graphic code mixed with state code). I would imagine the lighter weight drivers and faster resource API would speed up the sort of graphics Simutrans uses.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 01, 2015, 06:31:10 PM
Quote from: DrSuperGood on August 01, 2015, 05:17:44 PM
It is nothing more than a wrapper of Direct3D.

I think it's a little bit more than just a wrapper, but definately higher level than Direct3D, maybe with some backdoors down to the driver or maybe not.

Quote from: DrSuperGood on August 01, 2015, 05:17:44 PM
However if this would help Simutrans at all is entirely another question as from what I can tell Simutran's graphics were designed for software rendering (graphic code mixed with state code). I would imagine the lighter weight drivers and faster resource API would speed up the sort of graphics Simutrans uses.

The intermingling of state and presentation is at the core of what makes porting Simutrans to Direct3D and OpenGL difficult. In order to make use of GPUs, Simutrans needs to maintain most of the instuctions for drawing the world in VRAM from frame to frame, and only update it with visible deltas between frames. Simutrans lacks a way for getting notified that the world has changed, it happens from all over the place more or less directly into the low level data. The renderer just loops over everything, figuring what to draw from scratch every frame. Only which part of the resulting image has changed is tracked, and used to send only the parts of the screen that has changed from RAM to VRAM.

If a Direct3D/OpenGL based renderer is to simply send instructions to the GPU equalling the function calls in Simutrans renderer interface, that becomes pretty much the same amount of data to send over the bus (even more when zooming out, less when zooming in), than with the current software renderer. The other problem is that the way Simutrans draws the world, means that one has to constantly switch which image to draw. Pre-Direct3D 12 at least, such switching requires flushing the instruction stream, setting the new texture out-of-band, and then sending new instructions. This is exactly what one wants to do to get poor performance. If Direct3D 12 can do texture switches in the middle of an instruction stream, that might be a benefit, unless this still causes GPU stalls. Gathering individual images in mega-textures could reduce texture switches, but you have to find a way to make sure images drawn after each other is in the same mega-texture, which might not even be possible. As long as the 64k image limit was in place, pak64 had a hope of fitting in a single mega-texture on modern hardware. With that limit gone, the hope of avoiding texture switches was busted. At this point, it became too much for me.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 01, 2015, 06:34:51 PM
Is Simutrans' graphics engine really so slow to be worth any non-trivial amount of work in making it faster? It seems responsive enough to me.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 01, 2015, 07:18:34 PM
Quote from: jamespetts on August 01, 2015, 06:34:51 PM
Is Simutrans' graphics engine really so slow to be worth any non-trivial amount of work in making it faster? It seems responsive enough to me.

High-DPI displays may prove a problem. If one still want pak128 to be pak128 and not the new pak64 (or even pak32), a possible solution might be to just scale the image up in hardware after having rendered it in software.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 01, 2015, 07:20:48 PM
Or maybe just have more zoom levels?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 01, 2015, 08:22:17 PM
Quote from: jamespetts on August 01, 2015, 07:20:48 PM
Or maybe just have more zoom levels?

What do you mean that's good for? The problem is that it might be impossible to draw 8847360 (this is independent of zoom) in software and copy it from RAM for VRAM fast enough for the human eye to perceive it as motion. Currently, Simutrans is know to do 2073600 pixels fast enough, at least on some computers.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 01, 2015, 08:26:30 PM
Ahh, I think that I had misunderstood - you mean that the problems are likely to be when the player zooms out, not in? More levels of zooming in will help with things looking too small (they can look larger in a lower resolution), but not with having to do too much work zoomed out.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 01, 2015, 09:53:42 PM
Quote from: jamespetts on August 01, 2015, 08:26:30 PM
Ahh, I think that I had misunderstood - you mean that the problems are likely to be when the player zooms out, not in? More levels of zooming in will help with things looking too small (they can look larger in a lower resolution), but not with having to do too much work zoomed out.

That depends on what you were replying to. For Direct3D/OpenGL, zooming out makes thing worse (more things to draw), and zooming in makes it somewhat better (less things to draw). For High-DPI, the suspected performance problem with Simutrans' current renderer will be unrelated to zoom (for the most part at least).
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 11, 2015, 11:06:35 AM
Having taken a look at Visual Studio 2015, it looks like Microsoft have settled on a very deviant form of C++, and it seems that this is required for Windows Store apps. I guess this is what used to be called C++/CLI, based on the keywords and operators in the example code, but they are apparently no longer bother to state whether it is CLI or not. When also considering how the program entry point is in Windows Runtime is even more different from Win32 than Win32 is from POSIX, making Simutrans Windows Store compatible is no small feat. Other possible points of conflict with the Windows Store Policies are the user interface and the way users are pretty much expected to tinker with stuff inside the installation and/or user directory. (I'm actually surprised that the latter hasn't been much of an issue on Macs.)
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 11, 2015, 12:23:41 PM
Does any of this represent a problem for developing Simutrans on VS 2015 as a Win32 application?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 11, 2015, 01:10:22 PM
Not that I'm aware of, yet. Except that it might be difficult to keep C++ and C++ apart. However, I couldn't see any pressing reason to upgrade either. Most of the effort seems to be target towards mobile development, with VS2015 even boasting that it can develop iOS and Android apps as well. (Surprising amount of 3rd part stuff bundled or supported.)

Edit: Just noticed that the debugger has gotten some graphs since 2010.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Combuijs on August 11, 2015, 01:27:13 PM
Quote from: Ters on August 11, 2015, 01:10:22 PM
Except that it might be difficult to keep C++ and C++ apart.

It is indeed hard to see the difference  ;D ...
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 12, 2015, 07:17:05 PM
QuoteDoes any of this represent a problem for developing Simutrans on VS 2015 as a Win32 application?
No, it should still run like all Win32 applications do. If anything it becomes easier since you can raise the C++ standard closer to this decade (if desired). They also claim possible performance improvements just from a re-compile (since the compiler can optimize some code better) however if this will actually be the case is another question.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 12, 2015, 08:48:44 PM
Quote from: DrSuperGood on August 12, 2015, 07:17:05 PM
If anything it becomes easier since you can raise the C++ standard closer to this decade (if desired).

Unless you switch it to either another C++ or another "standard". The former is unlikely within Simutrans development as long as it is possible to import the existing project, and the latter has been an issue since forever (with GCC no better in that regard).

Another thing to look out for when upgrading the compiler is what the target platform ends up as afterwards. Just in case you don't want to lose players that have an older processor than the new compiler finds "fashionable", like our old night build server did some time ago. (Can't find any such detailed settings in VS2015, though. But then again, I have no experience doing C++ in Visual Studio, just some basic C# proof-of-concepts. Maybe such settings are the domain of the professional editions.)
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 12, 2015, 09:01:32 PM
One relevant issue is whether VS2015 supports Windows XP - I remember that VS 2012 needed a special extra download and configuration to do
so.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 13, 2015, 01:23:13 AM
QuoteUnless you switch it to either another C++ or another "standard". The former is unlikely within Simutrans development as long as it is possible to import the existing project, and the latter has been an issue since forever (with GCC no better in that regard).
That is entirely up to the director. James is developing Simutrans Experimental some what in parallel to standard and as such is free to raise the C++ specification for parts unique to experimental if desired. On the other hand for convenience it might be good to keep compiler compatible with standard. All comes down to choices really.

The biggest change with MSVC 2015 C++ is that the compiler now supports C++11 pretty much fully (as well as older standards with some newer features as well). C++11 should also be fully supported by newer versions of GCC (might need some compiler flags to link in some of the features) which should be available on general Linux systems. I think the reason standard still uses an older C++ standard is for some legacy and obscure system support (which do not have recent GCC builds or poorly maintained C++ compilers).

QuoteOne relevant issue is whether VS2015 supports Windows XP - I remember that VS 2012 needed a special extra download and configuration to do
so.
I think this (https://msdn.microsoft.com/en-us/library/jj851139.aspx) might answer the question. Looks pretty good from what that page shows.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 13, 2015, 10:04:19 AM
Thank you for that link: that is helpful. I think that it might be better to maintain compiler compatibility with Standard if possible, although I do not place the same emphasis on targeting non-standard platforms as does Standard: I am generally happy if Experimental can be compiled on Windows (XP and above), Mac OS X (for Intel) and Linux (32- and 64-bit). I wonder whether some of the more obscure platforms still need to be targeted by Standard or whether they are now so obscure that nobody is realistically likely to use them any longer? That might help to standardise and modernise development if that were so.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 13, 2015, 12:37:38 PM
Quote from: DrSuperGood on August 13, 2015, 01:23:13 AM
That is entirely up to the director. James is developing Simutrans Experimental some what in parallel to standard and as such is free to raise the C++ specification for parts unique to experimental if desired.

I wasn't writing about raising, I was writing about switching. Now it is of course up to him if I still wants to support other platforms or not, but it should be an intentional switch.

Quote from: DrSuperGood on August 13, 2015, 01:23:13 AM
C++11 should also be fully supported by newer versions of GCC (might need some compiler flags to link in some of the features) which should be available on general Linux systems.

But this is only one of the C++es, and not the one Microsoft is trying hard to push.

My other point is that while both may support the C++11 standard, they've both added something extra. This was a lament that even when writing algorithms with no ties to platform, those who use Microsoft's compiler and those who use GCC can end up writing code that doesn't work for the other. The fact that mingw decided to depend on an unsupported (from a developer standpoint) and outdated C runtime, makes it even worse. Although Microsoft's compiler and the Windows SDK is still free, it is now only available through Visual Studio, which isn't that great if you have a headless Linux box on which you want to test compile targetting multiple platforms to make sure you haven't written anything platform specific in the common code.
Title: Re: Windows 10 and Visual Studio 2015
Post by: prissi on August 13, 2015, 08:06:48 PM
If one targets more than one platform (especially Mac might be different from Linux and Windows) then using the latest compiler tricks is most likely not a good idea. Also raising the standard only in one tiny corner might be rather a concept for more confusion.

Certainly reliable multithreading on high level would be nice; but that is just something where compilers differ most.

Generally, throughout my life I wrote code for about ten different targets; and the more compiler specific extension one tends to use the more likely one stumble across a compiler feature which did not perform as expected (or just a bug). (Offtopic, my favorite was a TI DSP where sizeof(char)=sizeof(char[4])=sizeof(short)=sizeof(short[2]) with char actually ten bits which breaks most array code which assume otherwise.) But normally simple straight forward code tend to work always (and if it is quite straight forward, the optimiser should also be able to do a good job). So in the end, if there is not a very specific problem that can gain a lot I would keep thing simple and compatible as possible.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 13, 2015, 09:48:37 PM
After Haiku, I actually think the most unsure target to support is mingw. The original project is stuck somewhere near the turn of the millennium in terms of API support. (C and C++ standards support is more up to date, as far as a two decades old C runtime allows.) The new mingw64 is more up to date (except that they still use the same C runtime, I think), but there are concerns about it violating Microsoft's copyrights (though that would likely apply to Wine as well). And the project seems uncoordinated when it comes to delivering a complete, runnable environment for installation on Windows. (The development of the surrounding msys environment is probably fragmented even more, as a variant is also used by Git for Windows. Which, ironically, is used by Visual Studio's git support, from what I can understand. Furthermore, all of these are just forks of cygwin.)

But mingw is used for building nightlies. And also the official releases so far.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 14, 2015, 12:09:56 AM
I think Experimental is pretty much self built ATM. The versions for Windows I got for playing on the server appear to be MSVC built. If the Windows API problem can be solved then making from a Linux server should not be an issue either. Both MSVC and GCC are pretty good with the C++ standard up to about C++11.

Simutrans is a pretty complicated piece of software. Experimental is more so as it generally has higher system requirements. The sort of systems that Simutrans Experimental is aimed at generally have pretty standards compliant C++ compilers.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 14, 2015, 07:50:56 AM
Quote from: DrSuperGood on August 14, 2015, 12:09:56 AM
If the Windows API problem can be solved then making from a Linux server should not be an issue either. Both MSVC and GCC are pretty good with the C++ standard up to about C++11.

The key issue is that it looks like it won't, at least not in a way that everybody agrees is legal. And to what extent can newer C and C++ standards be implemented using a (possibly somewhat non-standard) C89 runtime?
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 14, 2015, 10:20:54 AM
Experimental is not built with MinGW at present, but Standard is. Can somebody give some sort of idea of what sort of code is legal in the C++ 11 standard that will not compile on MinGW? Will any of that stuff compile on VS 2015 but refuse to compile on VS 2012?
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 14, 2015, 04:26:38 PM
Here (http://forum.simutrans.com/index.php?topic=14351.0) I tried to post a C++11 patch.


// Array implementation. Compile time constant so should inline well.
static city_growth_factors_t const CITY_GROWTH_FACTORS[GROWTH_FACTOR_NUMBER] {
{ HIST_PAS_GENERATED, HIST_PAS_TRANSPORTED, &settings_t::get_passenger_multiplier },
{ HIST_MAIL_GENERATED, HIST_MAIL_TRANSPORTED, &settings_t::get_mail_multiplier },
{ HIST_GOODS_NEEDED, HIST_GOODS_RECIEVED, &settings_t::get_goods_multiplier } };

And it was producing this for some...
QuoteVisual Studio 6.0 
'identifier' : illegal symbol in context
Quotesimcity.cc:86:76: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default]

QuoteWill any of that stuff compile on VS 2015 but refuse to compile on VS 2012?
The above did compile in VS 2012. Although it had poor c++11 support it had enough for that feature.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 14, 2015, 05:00:24 PM
Quote from: jamespetts on August 14, 2015, 10:20:54 AM
Can somebody give some sort of idea of what sort of code is legal in the C++ 11 standard that will not compile on MinGW?

This isn't in C++11, it's from C11, but Visual Studio has supported this for some time as an extension to the standard. (Maybe it even was them that lobbied it into the C11 standard.)

char buf[BUF_SIZE];
strcpy_s(buf, "Hello", BUF_SIZE);


strcpy_s is the safer version of strcpy, and most functions in string.h has gotten such _s versions. Microsoft advocates that developers stop using the old functions, and rightly so, since these are probably the number one cause of all buffer overflow remote code execution exploits. (Although there are a few cases where just adding _s won't make your code any safer, because you still have to provide the correct inputs.)

It actually looks like even GCC on my Linux box doesn't support this.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 21, 2015, 05:07:42 AM
There are some minor compatibility problems with the pthread.h implementation and Windows SDK. I am trying to understand the specifics but it seems that Windows now does have "struct timespec" in "time.h". Since it is declared in the pthread.h header one can guess what happens.

Also I am getting this error...
Quotesized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function.
from lines like...

bild_besch_t* besch = new(4 * sizeof(PIXVAL)) bild_besch_t();

I am not sure what the line is meant to mean currently, I will need to look into it.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 21, 2015, 10:01:46 AM
Is there not a pthread.h version that supports Windows 10?
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 21, 2015, 02:51:29 PM
QuoteIs there not a pthread.h version that supports Windows 10?
Does not appear to be with the windows sdk. And the version of PThread used has not been updated for years.

I cannot test if it works or not until the other issue is resolved.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 21, 2015, 03:19:17 PM
Quote from: DrSuperGood on August 21, 2015, 05:07:42 AM
I am not sure what the line is meant to mean currently, I will need to look into it.

It is use of an overloaded new operator (provided in the Simutrans code somewhere) to allocate a chunk of memory larger than normal. This is an old C trick extended into C++. It lets bild_besch_t contain an array of arbitrary size, not point to one, which likely has been shown to be a performance issue in this case.

Although I don't really understand the quoted error. The wording doesn't even sound like an error.

Update:
Maybe it's trying to complain that there are no corresponding overloads for delete, although Simutrans never deletes besch instances anyway. Even if it did/does, the normal delete is just fine, so it should be a warning, not an error.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 21, 2015, 07:36:51 PM
The solution does not appear that simple. What is happening I think is that it is saying that the allocation signature is not acceptable as it conflicts with the placement deallocation function. I am unsure if this is a bug (as the error has been shown in bug reports) or that the hackery being used is no longer supported.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 21, 2015, 08:57:58 PM
Whether the exact trick is supported or not, new(...something...) (...possibly something...) is still part of the standard from what I could see in the documentation at cplusplus.com. Simutrans is not the only project depending on that feature. Maybe you found the answer to the original question: No it is quite the opposite of worthwhile to upgrade to Visual Studio 2015. At least until the possible bug is fixed.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 21, 2015, 11:17:42 PM
We do need to know in the long-term whether there is a way of working with VS2015 or later. Simutrans has been around for 16 years, and I hope that it will be around for at least another 16.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 21, 2015, 11:58:39 PM
This has nothing to do with MSVC 2015. It is a C++14 compatibility issue.

QuoteA declaration of a placement deallocation function matches the declaration of a placement allocation function if it has the same number of parameters and, after parameter transformations (8.3.5), all parameter types except the first are identical. Any non-placement deallocation function matches a non-placement allocation function. If the lookup finds a single matching deallocation function, that function will be called; otherwise, no deallocation function will be called. If the lookup finds the two-parameter form of a usual deallocation function (3.7.4.2) and that function, considered as a placement deallocation function, would have been selected as a match for the allocation function, the program is ill-formed. For a non-placement allocation function, the normal deallocation function lookup is used to find the matching deallocation function (5.3.5) [Example:
struct S {
  // Placement allocation function:
  static void* operator new(std::size_t, std::size_t);
  // Usual (non-placement) deallocation function:
  static void operator delete(void*, std::size_t);
};

S* p = new (0) S; // ill-formed: non-placement deallocation function matches
                  // placement allocation function


—end example]
The above is exactly what is happening at the moment. The "Usual (non-placement) deallocation function" for sized de-allocation is being inherited and matching the "placement allocation function".

Microsoft clearly explains it here (https://msdn.microsoft.com/en-us/library/bb531344.aspx)...

Currently looking into solution.

Temporary solution...
Quote
If you don't want to update your code immediately, you can revert to the old behavior by using the compiler option /Zc:sizedDealloc-. If you use this option, the two-argument delete functions don't exist and won't cause a conflict with your placement delete operator.

Now just need to rebuild all the dependent libraries...
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 22, 2015, 07:19:14 AM
That description was not easy to get my head around. If I understand it right, C++14 introduced new signatures for operator delete that has the same signature as the corresponding old-style operator delete would for obj_besch_t's overloaded operator new. I would say this is a standard quite explicitly breaking backwards compatibility. They could have avoided that by adding new parameters at the beginning, not at the end where developers were given permission to do as they please.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 22, 2015, 10:39:23 AM
Quote from: DrSuperGood on August 21, 2015, 11:58:39 PM
This has nothing to do with MSVC 2015. It is a C++14 compatibility issue.
...
Temporary solution...
Now just need to rebuild all the dependent libraries...

Does this mean (1) that it is necessary to use a special compiler switch when using MSVS 2015; (2) that some or all libraries (some of which do not normally need to be built specially as binaries are available) for Simutrans will have to be rebuilt to use MSVS 2015; and/or (3) that MSVS 2015 can only be used with the potentially problematic C++ 14 standard?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 22, 2015, 12:53:03 PM
Quote from: jamespetts on August 22, 2015, 10:39:23 AM
(2) that some or all libraries (some of which do not normally need to be built specially as binaries are available) for Simutrans will have to be rebuilt to use MSVS 2015

When using dynamically linked libraries (dlls), these must be compiled against the same C and C++ runtimes if these APIs are not fully abstracted away (and all libraries must agree on static or dynamic linking of common dependencies). Otherwise, all kinds of thing might happen when one C runtime is given something created by another C runtime. (Implosion of the universe is unlikely, but not ruled out by the standard.) Simutrans normally uses static linking only, except for the C/C++ runtime itself and whatever API the backend is based upon (GDI, SDL, etc.). This means that the nightlies (and others adhering to this rule) only need to provide the exe file, but makes it impossible for users to do a minor upgrade of zlib or bzip without building a new exe file themselves.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 22, 2015, 04:12:31 PM
QuoteThat description was not easy to get my head around. If I understand it right, C++14 introduced new signatures for operator delete that has the same signature as the corresponding old-style operator delete would for obj_besch_t's overloaded operator new. I would say this is a standard quite explicitly breaking backwards compatibility. They could have avoided that by adding new parameters at the beginning, not at the end where developers were given permission to do as they please.
They introduced it for optimization purposes. The placement allocator/decallocator was kind of obsolete outside of some very specific purposes (microcontrollers) and the only people generally using it were for the hack used in Simutrans.

One should be able to remove the sized destructor from the class somehow (so It defaults to the unsized one, since they are meant to be functionally equivalent when called by the compiler) however I am unsure of how to do that currently.

The other solution is to take advantage of different parameter type constructor/destructors. Simply wrapping the extra memory size in a enum or class (as described by Microsoft in the above link) and using that type as the signature would work since it will not be using the placement constructor/destructor but instead will use an entirely different constructor/destructor. This solution may need C++14 as I am unsure if different argument constructor/destructor was supported before then.

QuoteDoes this mean (1) that it is necessary to use a special compiler switch when using MSVS 2015;
Yes, currently you need to use that compiler switch until the code is made more c++14 compliant.

Quote(2) that some or all libraries (some of which do not normally need to be built specially as binaries are available) for Simutrans will have to be rebuilt to use MSVS 2015;
This is entirely dependent how you have it setup. Libraries generally need to be rebuilt to take advantage of compiler optimizations as well as changes in C++ standards. I built all of them in the past, I just need to get around to building them all again in MSVC2015. This is so link time optimization can be used (which allows optimizations like in-lining to be applied to library calls). The dll files I would not imagine needing to be rebuilt.

I am still in the process of doing this.

Quoteand/or (3) that MSVS 2015 can only be used with the potentially problematic C++ 14 standard?
I think it forces you to use parts of C++14. However the problems are not so much with the C++14 standard but the hacky old code Simutrans uses. Supporting C++14 building is always a good idea since it makes the code more future proof.

QuoteSimutrans normally uses static linking only, except for the C/C++ runtime itself and whatever API the backend is based upon (GDI, SDL, etc.). This means that the nightlies (and others adhering to this rule) only need to provide the exe file, but makes it impossible for users to do a minor upgrade of zlib or bzip without building a new exe file themselves.
It also uses a PThread dll. Currently I am trying to re-build compatible versions of the other libraries (zlib etc).
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 22, 2015, 04:31:13 PM
Perhaps when you have got it all running you could upload a step by step guide to building Simutrans on MSVS 2015? That would be extremely useful.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 22, 2015, 05:15:17 PM
Quote from: DrSuperGood on August 22, 2015, 04:12:31 PM
They introduced it for optimization purposes. The placement allocator/decallocator was kind of obsolete outside of some very specific purposes (microcontrollers) and the only people generally using it were for the hack used in Simutrans.
Most uses I have seen for it has been for tracing memory allocations in debug builds.

Quote from: DrSuperGood on August 22, 2015, 04:12:31 PM
One should be able to remove the sized destructor from the class somehow (so It defaults to the unsized one, since they are meant to be functionally equivalent when called by the compiler) however I am unsure of how to do that currently.
Sized destructor? You mean the delete operator taking a size_t parameter? That is part of the standard, and there is none in the class. It's the global default that is causing trouble I think. Removing this is probably what the compiler switch you mentioned does.

Quote from: DrSuperGood on August 22, 2015, 04:12:31 PM
The other solution is to take advantage of different parameter type constructor/destructors. Simply wrapping the extra memory size in a enum or class (as described by Microsoft in the above link) and using that type as the signature would work since it will not be using the placement constructor/destructor but instead will use an entirely different constructor/destructor. This solution may need C++14 as I am unsure if different argument constructor/destructor was supported before then.

I don't see what your solution will accomplish. Constructors have always taken arguments, destructors never have or will. But constructors are for initializing the class. The memory is allocated by operator new, so that what must be customized, but the new standard has suddenly (carelessly and needlessly in my opinion, they could have prepended the new parameter to avoid conflict) stolen a signature that earlier standards let the developers use as they wished.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 23, 2015, 01:26:27 AM
QuoteSized destructor? You mean the delete operator taking a size_t parameter?
Yes sorry, read my post with "allocator/deallocator" instead of "constructor/destructor".

QuoteThe memory is allocated by operator new, so that what must be customized, but the new standard has suddenly (carelessly and needlessly in my opinion, they could have prepended the new parameter to avoid conflict) stolen a signature that earlier standards let the developers use as they wished.
Looking at how the standards documentation was modified it looks like an oversight rather than purpose. Hence they extended placement constructors to support any argument type for the first argument other than "size_t".

QuotePerhaps when you have got it all running you could upload a step by step guide to building Simutrans on MSVS 2015? That would be extremely useful.
I have managed to get it running. Required me to rebuild both compression libraries but not pthread or FreeType.

I have attached a patch with fixes a typo in a previous patch of mine (could not test it at the time as I did not have Windows 8, I forgot a ';') as well as fixes the issue with PThread. This is the minimum changes required to build 32 bit with MSVC 2015 using the " /Zc:sizedDealloc-" compiler flag. A better work around for /Zc:sizedDealloc- is needed in the future (since the feature could potentially provide performance benefits). I have not tested 64 bit building yet.

Currently my Simutrans project configuration in MSVC 2015 is kind of a mess. I am working on tidying it up slowly. The problems I ran into was because I use self-compiled and optimized version of the compression libraries which it wanted updated, so I had to update them (again with rather messy project configurations, I am unsure of what the various compiler options do the libraries produced).
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 23, 2015, 10:04:27 AM
Thank you for that. I have applied the change to simthread.h, but I am a little confused about the changes to posix.cc, partly because this file is not, in fact, used in MSVS compilations, and partly because the state from which the patch was changing the file is very different to my version of that file. Has this been changed substantially in Standard lately? Mine looks like this:


/*
* Copyright (c) 1997 - 2001 Hansjörg Malthaner
*
* This file is part of the Simutrans project under the artistic license.
*/

#ifndef _MSC_VER
#include <unistd.h>
#include <sys/time.h>
#endif

#ifdef _WIN32
// windows.h defines min and max macros which we don't want
#define NOMINMAX 1
#include <windows.h>
#endif

#include "macros.h"
#include "simsys.h"


bool dr_os_init(const int*)
{
// prepare for next event
sys_event.type = SIM_NOEVENT;
sys_event.code = 0;
return true;
}

resolution dr_query_screen_resolution()
{
resolution const res = { 0, 0 };
return res;
}

// open the window
int dr_os_open(int, int, int)
{
return 1;
}


void dr_os_close()
{
}

// reiszes screen
int dr_textur_resize(unsigned short** const textur, int, int)
{
*textur = NULL;
return 1;
}


unsigned short *dr_textur_init()
{
return NULL;
}

unsigned int get_system_color(unsigned int, unsigned int, unsigned int)
{
return 1;
}

void dr_prepare_flush()
{
}

void dr_flush()
{
}

void dr_textur(int, int, int, int)
{
}

void move_pointer(int, int)
{
}

void set_pointer(int)
{
}

int dr_screenshot(const char *,int,int,int,int)
{
return -1;
}

static inline unsigned int ModifierKeys()
{
return 0;
}

void GetEvents()
{
}

void GetEventsNoWait()
{
}

void show_pointer(int)
{
}

void ex_ord_update_mx_my()
{
}

static timeval first;

unsigned long dr_time()
{
timeval second;
gettimeofday(&second,NULL);
if (first.tv_usec > second.tv_usec) {
// since those are often unsigned
second.tv_usec += 1000000;
second.tv_sec--;
}
return (unsigned long)(second.tv_sec - first.tv_sec)*1000ul + (unsigned long)(unsigned long)(second.tv_usec - first.tv_usec)/1000ul;
}

void dr_sleep(uint32 msec)
{
/*
// this would be 100% POSIX but is usually not very accurate ...
if(  msec>0  ) {
struct timeval tv;
tv.sec = 0;
tv.usec = msec*1000;
select(0, 0, 0, 0, &tv);
}
*/
#ifdef _WIN32
Sleep( msec );
#else
sleep( msec );
#endif
}


int main(int argc, char **argv)
{
gettimeofday(&first,NULL);
return sysmain(argc, argv);
}
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 23, 2015, 10:44:28 AM
Quote from: jamespetts on August 23, 2015, 10:04:27 AM
I am a little confused about the changes to posix.cc, partly because this file is not, in fact, used in MSVS compilations

Probably because whoever made it didn't use Visual Studio. Despite the name, posix.cc is for Windows as well.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 23, 2015, 11:44:07 AM
That's very odd: I don't include posix.cc in my MSVS compile, and it always works (for Experimental). What does this file do?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 23, 2015, 01:11:04 PM
Quote from: jamespetts on August 23, 2015, 11:44:07 AM
That's very odd: I don't include posix.cc in my MSVS compile, and it always works (for Experimental). What does this file do?

Well, it's simsys_posix.cc, and like the other simsys files, only one is necessary in a given build. It's basically the server "backend", so that Simutrans runs as a console/service process behaving like server processes traditionally do.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 23, 2015, 01:22:12 PM
Ahh, I see - but I am fairly sure that the no graphics server compiled for Windows also does not use simsys_posix.cc. Perhaps it ought to use it?
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 23, 2015, 03:43:16 PM
I wanted to try out JIT2 multiplayer properly so needed a no graphics server. I looked at the MAKE file for how it builds a no graphic server and applied that to MSVC (although in a rather hacky way, need to revise how I did that).

It was not building because of a variety of reasons. I supplied a patch which was incorporated to fix this. However recently I noticed that the Windows 8 and newer build of the file contains a syntax error (forgot ';') which is why that is tagged along because otherwise the POSIX server will fail to build targeting Windows 8 and newer.

QuoteAhh, I see - but I am fairly sure that the no graphics server compiled for Windows also does not use simsys_posix.cc.
I was not aware of any other way to get a no graphics server. In any case MSVC should be able to build a POSIX build for portability reasons.

Specifically this patch (https://github.com/aburch/simutrans/commit/dfad8ae44cb2112e260492760cfb7d8ed45bc79a) was the one I posted to fix POSIX build for MSVC.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 23, 2015, 05:44:18 PM
All that I had done before was to use simgraph0.cc rather than simgraph16.cc. I presume that that is the patch that I have yet to apply.

Are you aware of any way (apart from #ifdef directives in the files themselves) to tell MSVS which files to try to build separately for each build configuration?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 23, 2015, 06:07:12 PM
In MSVC2015 at least, you can exclude a file from the build for particular configurations and platforms. Does anybody know if this is the right way of doing it? It's sort of similar to how CodeBlocks does it, except that it has the inverse property (and also doesn't hold platform distinct from configuration).
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 23, 2015, 06:13:56 PM
Can this be done in MSVS 2012?
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 23, 2015, 08:37:49 PM
QuoteAre you aware of any way (apart from #ifdef directives in the files themselves) to tell MSVS which files to try to build separately for each build configuration?
You can exclude specific files from particular builds by right clicking them and modifying their properties.

I am not sure if this is the "right" way to do it. Looking at how zlib did it, you could make separate projects (whatever they are called) which specify the build configuration and then in those separate projects you have standard configurations like "debug", "Release", "Release (64)" etc.

Currently I have the messy approach of various builds like SDL2, SDL2 Debug, POSIX etc in one project. From a configuration point of view having separate projects (maybe they are sub-projects?) for things like GDI, POSIX, SDL, SDL2 etc each linking to different libraries and C++ files and then each of those has separate standard configurations (debug and release for 32 and 64).

The configurations with different C++ source files is supported in community 2013 and 2015. I am unsure of 2012. I would recommend upgrading to Community 2015 since it is completely free and suitable for even small scale commercial operations. However depending on what else you use it for (eg work) that might not be applicable.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on August 23, 2015, 09:29:02 PM
Thank you: that is very helpful. It does work in 2012. Would one then disable simsys_w for the command line server build?

Do you know whether your updated posix file is compatible with Experimental running on Linux? I know so little of the workings of the low level stuff that it will be very difficult for me to work out what the problem is if it is not (and a release is so far away that I may have forgotten this change by the time that I come to compile for Linux, making any problems very hard to track down).

Upgrading to the 2015 version may well be worthwhile if there are reasonable straightforward ways of fixing the issues, as you have outlined. I do not use MSVS for anything other than Simutrans: my work is entirely unconnected with programming (and I am entirely self taught, which is why I am hazy on the low level details in many cases).
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on August 23, 2015, 11:04:54 PM
QuoteThank you: that is very helpful. It does work in 2012. Would one then disable simsys_w for the command line server build?
You disable simsys_w and enable the posix one. I also think you need to change the graphic back end, I forget if that was for SDL2 or not.

QuoteDo you know whether your updated posix file is compatible with Experimental running on Linux?
Unless someone altered that file for experimental, or not all patches to it have been applied to experimental I see no reason for it to not work. The patches I made only alter the file behaviour when building targeting Windows, the file was not changed for Linux in any way.

QuoteUpgrading to the 2015 version may well be worthwhile if there are reasonable straightforward ways of fixing the issues, as you have outlined. I do not use MSVS for anything other than Simutrans: my work is entirely unconnected with programming (and I am entirely self taught, which is why I am hazy on the low level details in many cases).
I am slowly looking into constructing some form updated MSVC project file for standard. The problem is how to structure it in a nice, user friendly and maintainable way. Hopefully the same principles could be applied to experimental.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on August 24, 2015, 05:25:06 AM
Quote from: DrSuperGood on August 23, 2015, 11:04:54 PM
You disable simsys_w and enable the posix one. I also think you need to change the graphic back end, I forget if that was for SDL2 or not.

simsys_* is the graphics back end. simgraph, which is the middle layer, shouldn't care for SDL2 or otherwise.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on September 24, 2016, 12:46:46 AM
I should note that I am just in the process of upgrading to Visual Studio 2015 now so that I can undertake some profiling, and I note that Visual Studio 2015 compatible library files can be obtained from the Open TTD website here (https://www.openttd.org/en/download-openttd-useful/6.0).

Edit: However, I cannot find compatible versions of bzip anywhere - can anyone assist with that? I currently get linker errors (unresolved external symbol __iob_func referenced in function _bzopen_or_bzdopen)
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on September 24, 2016, 05:10:26 AM
Quote
and I note that Visual Studio 2015 compatible library files can be obtained from the Open TTD website here.
Or you could just build them yourself, which is what I did. All the dependent libraries for standard come with MSVC projects which just need some minor modifications for compatibility/optimization.

Quote
However, I cannot find compatible versions of bzip anywhere - can anyone assist with that?
I have self-built versions which I use to statically link with standard.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on September 24, 2016, 07:21:39 AM
Were you able to build them from the source tarball on the official bzip website? I had trouble opening that.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on September 24, 2016, 01:26:38 PM
QuoteWere you able to build them from the source tarball on the official bzip website? I had trouble opening that.
Yes I was. Start by extracting bzip2-1.0.6 folder using 7-zip. Since it is a tar.gz (nested compression) this means using 7-zip's file explorer to first open the gz file and then the tar file to reveal the required folder. Inside that folder open libbz2.dsp with MSVC2015 and one-way upgrade it to MSVC2015.

Since the project is very old one has to hack around at the build properties. For example change Configuration Type from .dll to .lib so that it can be statically linked (less messy, 1 fewer dll to distribute). Whole program optimization should be turned on to fast link time code generation (very important for optimization), multi-processor compilation and runtime library must be the same as Simutrans. After that build and it should be usable when placed on the library path. If you still get errors when trying to link it with Simutrans then maybe some of the settings are conflicting between the projects such as exception and calling conventions.
Title: Windows 10 and Visual Studio 2015
Post by: Ves on September 24, 2016, 04:12:37 PM
I think i remember using the version 3.1 of the openTTD files.
I use windows 10 and msvs2015
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on September 25, 2016, 09:26:26 PM
Excellent, that worked for me, thank you!
Title: Re: Windows 10 and Visual Studio 2015
Post by: Rollmaterial on September 28, 2016, 04:05:28 PM
I get this error when trying to compile bzlib:

Error D8016 '/ZI' and '/GL' command-line options are incompatible


Edit: I seem to have fixed that by compiling in release configuration. Now I'm having trouble with zlibstat from OpenTTD-useful-6.0.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ves on September 28, 2016, 04:42:16 PM
After james updated the experimental enviroment to mvsv2015 I get this error when trying to compile simutrans experimental:

Severity Code Description Project File Line Suppression State
Error C2011 'timespec': 'struct' type redefinition Simutrans-Experimental C:\Users\Victor\Documents\GitHub\OpenTTD\shared\include\pthread.h 320


His reply was that I should recompile the bzlib.
I have no problem compiling the bzlib uing the instructions in this thread, resulting in the file libbz2.lib, and I am replacing the existing one in the open TTD-files. I also modified the preferences to match the ones in experimtal and all the values DrSupergood suggested are matching.
However, experimental will still not compile, just throwing the same error again. Do any of you know what I might have been doing wrong?
Needless to say maybe, but I am running windows 10 msvs 2015


QuoteNow I'm having trouble with zlibstat from OpenTTD-useful-6.0.
I dont know if all this has changed now, but try the 3.1 one. It was the latest one I could get to work before.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Rollmaterial on September 28, 2016, 05:16:20 PM
Turns out I just forgot to add some directories. Now I'm getting something else:
Severity Code Description Project File Line Suppression State
Error C1047 The object or library file '.\intermediates\release\simdepot.obj' was created with an older compiler than other objects; rebuild old objects and libraries
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on September 28, 2016, 06:30:56 PM
Quote

Edit: I seem to have fixed that by compiling in release configuration. Now I'm having trouble with zlibstat from OpenTTD-useful-6.0.
Custom build all dependencies and make sure they are built with compatible settings. That error is the result of an incompatible library.

Quote
After james updated the experimental enviroment to mvsv2015 I get this error when trying to compile simutrans experimental:
The current MSVC version of pthread is incompatible with modern MSVC2015 due to it declaring its own timespec structure which already exists in MSVC2015 as it is part of standard C++. It was solved in Simutrans standard long ago (https://github.com/aburch/simutrans/blob/master/utils/simthread.h) but the patch must not have made its way to experimental.



#if defined _MSC_VER && _MSC_VER >= 1900
// MSVC 2015 with Windows 10 SDK has struct timespec
#define _TIMESPEC_DEFINED
#endif


Quote
Turns out I just forgot to add some directories. Now I'm getting something else:
You will manually need to build the dependencies as they were built with an incompatible or old version of MSVC.
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on September 28, 2016, 07:38:32 PM
Quote from: Rollmaterial on September 28, 2016, 05:16:20 PM
Turns out I just forgot to add some directories. Now I'm getting something else:
Severity Code Description Project File Line Suppression State
Error C1047 The object or library file '.\intermediates\release\simdepot.obj' was created with an older compiler than other objects; rebuild old objects and libraries


This looks as though you just need to clean the build before rebuilding, as the .obj files are temporary files created by the compiler whilst it is running.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on September 28, 2016, 08:34:20 PM
Quote
This looks as though you just need to clean the build before rebuilding, as the .obj files are temporary files created by the compiler whilst it is running.
Yeh you are probably write. I just read the error and did not look at the path (ops). The same error is given if a library is used that was built with an old version of MSVC and was set for link time optimization.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ves on October 02, 2016, 12:21:36 AM
Quote from: DrSuperGood on September 28, 2016, 06:30:56 PM
The current MSVC version of pthread is incompatible with modern MSVC2015 due to it declaring its own timespec structure which already exists in MSVC2015 as it is part of standard C++. It was solved in Simutrans standard long ago (https://github.com/aburch/simutrans/blob/master/utils/simthread.h) but the patch must not have made its way to experimental.

It appears as the experimental version was up to date, just with another set of comments, rearranging the lines. But that still unfortunately does not resolve the error.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on October 02, 2016, 01:23:32 AM
Quote
It appears as the experimental version was up to date, just with another set of comments, rearranging the lines. But that still unfortunately does not resolve the error.
I cannot even find simthread.h in the experimental GitHub. Please link?
Title: Re: Windows 10 and Visual Studio 2015
Post by: prissi on October 02, 2016, 07:12:45 AM
I am not sure but at a certain point this discussion went far away from MS 2015 issues. Maybe open a specific experimental thread that might help to find the pthread discussion again if needed?
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on October 02, 2016, 11:49:05 AM
To answer Dr. Supergood's question, pthread.h is not on the Github repository as it is found in ~\Simutrans\OpenTTD\shared\include (i.e., it is an included file rather than one that is treated as part of the core code).

Is this distinct from Standard? Ves - is this the same arrangement as you have?
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on October 02, 2016, 12:15:25 PM
Quote from: jamespetts on October 02, 2016, 11:49:05 AM
To answer Dr. Supergood's question, pthread.h is not on the Github repository as it is found in ~\Simutrans\OpenTTD\shared\include (i.e., it is an included file rather than one that is treated as part of the core code).

DrSuperGood didn't ask for pthread.h, which as far as I know is part of a (system) library. simthread.h on the other hand, is part of Simutrans and Simutrans specific.
Title: Re: Windows 10 and Visual Studio 2015
Post by: DrSuperGood on October 02, 2016, 03:59:12 PM
The fix for standard was to simthread.h (not pthread.h). All Simutrans thread functionality comes from that header, as opposed to directly importing pthread.h. Experimental does not appear to have a simthread.h file, which would be why there is no fix. Until the developers of pthread.h update their header file to be compatible with never versions of MSVC the only solution is to explicitly state, via definition, that the timespec struct already exists and the header is to not create it before one can import the header file. As simthread.h does this for standard that is where the fix was applied but apparently experimental does not have a simthread.h.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ves on October 02, 2016, 08:06:01 PM
Quote from: DrSuperGood on October 02, 2016, 01:23:32 AM
I cannot even find simthread.h in the experimental GitHub. Please link?
Simthread.h is located here: https://github.com/jamespetts/simutrans-experimental/blob/devel-new-2/utils/simthread.h (https://github.com/jamespetts/simutrans-experimental/blob/devel-new-2/utils/simthread.h)

QuoteI am not sure but at a certain point this discussion went far away from MS 2015 issues. Maybe open a specific experimental thread that might help to find the pthread discussion again if needed?
I am sorry if this is considered the wrong thread, I thought it is a windows 10/msvs2015 issue?

QuoteTo answer Dr. Supergood's question, pthread.h is not on the Github repository as it is found in ~\Simutrans\OpenTTD\shared\include (i.e., it is an included file rather than one that is treated as part of the core code).

Is this distinct from Standard? Ves - is this the same arrangement as you have?
Yes I have that file there.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ters on October 02, 2016, 08:46:53 PM
Quote from: Ves on October 02, 2016, 08:06:01 PM
I am sorry if this is considered the wrong thread, I thought it is a windows 10/msvs2015 issue?

I think the problem is that this thread was partially about experiences with Windows 10 mixed together with a MSVS2015 question. Now its just about MSVS2015, despite this being on a non-developer board. Anyone that might have come with Windows 10 feedback will likely be frightened by all the technical talk here. I suggest moving this discussion to one of the development boards. Then it can be a MSVS2015 discussion. What has been discussed lately has nothing to do with Windows 10.
Title: Re: Windows 10 and Visual Studio 2015
Post by: Ves on October 02, 2016, 09:10:32 PM
QuoteI think the problem is that this thread was partially about experiences with Windows 10 mixed together with a MSVS2015 question. Now its just about MSVS2015, despite this being on a non-developer board. Anyone that might have come with Windows 10 feedback will likely be frightened by all the technical talk here. I suggest moving this discussion to one of the development boards. Then it can be a MSVS2015 discussion. What has been discussed lately has nothing to do with Windows 10.

Ok, made a new thread here: http://forum.simutrans.com/index.php?topic=15783.0 (http://forum.simutrans.com/index.php?topic=15783.0)
Title: Re: Windows 10 and Visual Studio 2015
Post by: jamespetts on October 02, 2016, 09:21:01 PM
Apologies: I misread the original post. simthread.h should be there in the ~/utils directory, which I believe is the default location: I certainly have not moved it.