TS future

[NorthernWarrior]

Good point actually Griphos. I've already got the Jersey route (I think) but the prospect of another 4Gb of routes of which at least two I'm not bothered about and I'll probably play a handful of times just to get access to the beta, begs the availability of another option. IIRC Dirt Rally offered an early access option on Steam (non-refundable which is fair enough) which increased in price the more finished the end product became. Obviously a gamble as the final product might never appear for some reason, but in some ways a sort of advanced Kickstarter. Obviously the route sales (at 75% off) are designed to generate revenue but rather than pay £25 for a bunch of content I don't really want, I'd rather just pay £25 up front for early access and the full game included on release.

[Chacal]

TSW looks awesome. Good job gentlemen.
I appreciate that there is a roadmap to the future. I'll stick to TS2017 for now, as I have a huge investment in it and more routes, scenarios and assets than I have time to play them. I have yet to try a European route!
I'll let early adopters pay for getting the beta, and I'll let them go through the new game's childhood pains. In a few years, when it's stable and has enough content, and I have more money, I might start trying it.

my running time is often just a short time and I don't have time for all that foo foo.

+1. Presumably we'll be able to just jump in and bypass this kind of thing. Like when VRC came out with the GP40 with its advanced starting procedure, and I said why not let us bypass all this with the 'Z' key?

Since this is going to be a 64 bit ystem, will it be programmed to split child processes like textures and weather off to seperate cpu cores while using the main gpu to handle the main animation and engine display functions??

I think the game engine is supposed to take care of that kind of things. See if Unreal 4 does that.

[PamBrooker]

TSW looks awesome. Good job gentlemen.
I appreciate that there is a roadmap to the future. I'll stick to TS2017 for now, as I have a huge investment in it and more routes, scenarios and assets than I have time to play them. I have yet to try a European route!
I'll let early adopters pay for getting the beta, and I'll let them go through the new game's childhood pains. In a few years, when it's stable and has enough content, and I have more money, I might start trying it.

my running time is often just a short time and I don't have time for all that foo foo.

+1. Presumably we'll be able to just jump in and bypass this kind of thing. Like when VRC came out with the GP40 with its advanced starting procedure, and I said why not let us bypass all this with the 'Z' key?

Since this is going to be a 64 bit ystem, will it be programmed to split child processes like textures and weather off to seperate cpu cores while using the main gpu to handle the main animation and engine display functions??

I think the game engine is supposed to take care of that kind of things. See if Unreal 4 does that.

They have to program it to tell the engine how they want it done. Unreal is good, but its not plug n play.
The over all benefit to us is that it allows them to create a much more immersive game without any noticeable hits on performance. Currently, our 32 bit TS-2016 only uses one core, regardless of how many cores you tell it to use. Opening up multi core usage will allow them to do much much more by simply distributing the loads between cores, and we wont notice any difference in performance.

[harryadkins]

Does anyone have experience working with graphics in the Unreal engine? If so, could you give us an overview of the process and what types of files are involved. Graphics creation is one of my favorite aspects of the game.

[g_nash]

Does anyone have experience working with graphics in the Unreal engine? If so, could you give us an overview of the process and what types of files are involved. Graphics creation is one of my favorite aspects of the game.

Not much point in anything until you find out if/what editing/BP capabilities for the import of models and repainting of texture sets will be exposed for third party DLC.

If you're interested in where the UE world in general is heading here's 2 tube channels with an assortment of EU4 specific vids dealing with current PBR workflows for UE4, though not necessarily fitting for DTGs TSW, they will give you a basic introduction.

Quixel Suite, the new MegaScans is of particular interest for environments.

https://www.youtube.com/user/quixelteddy/videos

Allegorithmic Substance Painter and Designer

https://www.youtube.com/user/Allegorithmic/videos

I use both.

Nice vid from DTG, the future looks wild.

seeya

[peterhayes]

Pam
Sorry but

Currently, our 32 bit TS-2016 only uses one core, regardless of how many cores you tell it to use. Opening up multi core usage will allow them to do much much more by simply distributing the loads between cores, and we wont notice any difference in performance.

However, TS 2016 is multicore capable - has been since TS 2012, plus the way Windows works it can also allocate cores for any app to use and not just limit the app to a single core. TS is not true multicore, never has been, but then there is no guarantee that TSW 64-bit will be true multicore or that true multicore apps are any more efficient or better than current "serial" ones.

You can set TS to use a single core via task manager, just go in and set it (SET Affinity) to ONLY use Core 0 (the "OS core" and sit back and watch the slide show).

I use an app called Process lasso and often instruct it to only use Cores 1, 2, 1nd 3 leaving core 0 to the OS, this has some benefits wrt tile boundary stuttering, but not as much as I would like. I use a device called a Pertelian (or any Logitec keyboard with LCD display) and that shows in real time TS2016 will use 4 cores in a quad machine and that you can restrict TS to use just 3 cores too.

We need to understand that a 64-bit program may not perform any better than a 32-bit one, yes, it will be much less prone (if at all) to VAS errors and that will be a major advance, particularly wrt TS editor. Is ETS2 32-bit any better than ETS2 64-bit?

The UE4 engine will be good, but to me one of the biggest advances will be to move from DirectX9.0c to Direct X 10, 11, 12. Just look at the difference between p3D (DirectX 11) and MS FSX (DirectX9.0c) to see what I mean.
Exciting times!
Regards
pH

[PamBrooker]

Pam
Sorry but

Currently, our 32 bit TS-2016 only uses one core, regardless of how many cores you tell it to use. Opening up multi core usage will allow them to do much much more by simply distributing the loads between cores, and we wont notice any difference in performance.

However, TS 2016 is multicore capable - has been since TS 2012, plus the way Windows works it can also allocate cores for any app to use and not just limit the app to a single core. TS is not true multicore, never has been, but then there is no guarantee that TSW 64-bit will be true multicore or that true multicore apps are any more efficient or better than current "serial" ones.

You can set TS to use a single core via task manager, just go in and set it (SET Affinity) to ONLY use Core 0 (the "OS core" and sit back and watch the slide show).

I use an app called Process lasso and often instruct it to only use Cores 1, 2, 1nd 3 leaving core 0 to the OS, this has some benefits wrt tile boundary stuttering, but not as much as I would like. I use a device called a Pertelian (or any Logitec keyboard with LCD display) and that shows in real time TS2016 will use 4 cores in a quad machine and that you can restrict TS to use just 3 cores too.

We need to understand that a 64-bit program may not perform any better than a 32-bit one, yes, it will be much less prone (if at all) to VAS errors and that will be a major advance, particularly wrt TS editor. Is ETS2 32-bit any better than ETS2 64-bit?

The UE4 engine will be good, but to me one of the biggest advances will be to move from DirectX9.0c to Direct X 10, 11, 12. Just look at the difference between p3D (DirectX 11) and MS FSX (DirectX9.0c) to see what I mean.
Exciting times!
Regards
pH

Peronally, I use 64 bit X-Plane, but thats what caused me to ask the question. To my understanding, lashing two or more cores together does little more than combine them into a single processing unit, rather than creating a distributed processing ystem. X-Plane, used a distributed system where one core handles textures, another precache and another shaders, etc.. It reduces load across the system and decreases lag by a large percentage, allowing for multiple animations and other operations to be performed at the ame time, with no noticeable hit on performance.
With your forgiveness, an example of the possibilities of this system can be seen prominently in the video below..
https://www.youtube.com/watch?v=XViCj0uqeco

[peterhayes]

Pam
Good points but splitting discrete "duties" across the cores may not necessarily increase performance. X-plane may well do that as you say, but so does TS 2016 in a certain way in that it utilises any core available and "splits" the load that way. If X-plane is doing as you say then there will need to be some real computer oomph to process and recombine those code elements that it has "split" up, so that it can be processed and displayed by the graphics card. Now again, I do not se any performance gain between the 32 or 64 -bit versions of XPlane wrt, frame dwell times, cpu usage, RAM usage, VRAM usage and so on.

Anyway with X-Plane 64-bit I'm not sure if it has Large address aware flag set (I could never find out from anyone at X-Plane) - if not, it can use all the cores that it wants to but with no or little increase in VAS, it is always going to be limited in terms of performance.

A true multicore app (I don't think that X-Plane is - I can't even think of any sim that is?) requires the code to written precisely and correctly, ie so called parallel computing, and there is no evidence at our level, ie games, simulation, it is any better than what we use today. I'm not even sure that Windows is optimised for parallel computing and that could cause issues when it is running a true multicore app??

As I say the biggest advance for me will come form a 64-bit app than can use up to 8 TERABYTES of VAS, and the use of the later versions of DirectX, on a stable gaming platform. At the end of the day TS2016/7 is still multicore capable, and it runs much more smoothly when more than one core is available to it.

Maybe you were thinking of multi-threading?

Regards
pH

[PamBrooker]

Pam
Good points but splitting discrete "duties" across the cores may not necessarily increase performance. X-plane may well do that as you say, but so does TS 2016 in a certain way in that it utilises any core available and "splits" the load that way. If X-plane is doing as you say then there will need to be some real computer oomph to process and recombine those code elements that it has "split" up, so that it can be processed and displayed by the graphics card. Now again, I do not se any performance gain between the 32 or 64 -bit versions of XPlane wrt, frame dwell times, cpu usage, RAM usage, VRAM usage and so on.

Anyway with X-Plane 64-bit I'm not sure if it has Large address aware flag set (I could never find out from anyone at X-Plane) - if not, it can use all the cores that it wants to but with no or little increase in VAS, it is always going to be limited in terms of performance.

A true multicore app (I don't think that X-Plane is - I can't even think of any sim that is?) requires the code to written precisely and correctly, ie so called parallel computing, and there is no evidence at our level, ie games, simulation, it is any better than what we use today. I'm not even sure that Windows is optimised for parallel computing and that could cause issues when it is running a true multicore app??

As I say the biggest advance for me will come form a 64-bit app than can use up to 8 TERABYTES of VAS, and the use of the later versions of DirectX, on a stable gaming platform. At the end of the day TS2016/7 is still multicore capable, and it runs much more smoothly when more than one core is available to it.

Maybe you were thinking of multi-threading?

Regards
pH

Nooo, I dont think i mean multithreading.. Truth told though, to me, multithreading is new technology. I dont really understand it.. Multitasking and distributed processing i have a somewhat better idea of.. On the other hand, I worked for both Memorex when they made computers and Tandem computer for many years as a network admin and systems admin, so some of it rubbed off on me..
But no. Winows is not optimized for parallel processing. Its not optimized at all. At its heart is still the bastard step child of UNIX and CP/M that Bill Gated bought off a guy for sixty five bucks. However,Your graphics card is not only capable of it, but designed for it. here's a little video for NVidia cards that explains it far better than i could ever hope too. Its also rather fascinating.. https://www.youtube.com/watch?v=el69jiGqP2o .
A small glimpse of this possibility can be seen in the TSW demo clip, when the person walks down the ramp, opens the door, and enters the cab. There's no cut scenes. Thhe game is also multi-player, which implies that possibly you can have a friend in the cab with you. Normally, you would walk up to the door, click on it and the screen would go black or you would have a cut scene. Thats because the inside of the cab/house/building etc. and the outside, are two completely different environments. The one has to exist inside the other one and both have to be working at the exact same time. Star Citizen played hell working that out for their pace ships and multi player crews, but the effect is incredible.. It's worlds within worlds within worlds, and from the looks of it, theres a possibility that TSW is going to be similar. And thats what makes me very very curious.. Watch the vid ( boring as it may seem at first ) and you'll see what i mean..

[JerryC]

The direction this is taken might be better spun off to a new topic in Geek Speak. Some of the things you are talking about in the last fews posts are a bit beyond simple speculation about TS Future, which is the topic of this thread.

Now that i've been in it a few weeks, the Unreal Engine is very reminiscent of making levels for Duke Nukem' in the old Quake engine. The big difference is whereas there your game would take place inside a building, town, or city, the environment for TSW is 150 miles long. Although we will need "finishing hooks" provided by DTG, a great deal of the world and content creation information is already readily available online. If folks will read that stuff as enthusiastically as they do various Manuals that have been included in the present version of TrainSim, we should have at least one or two objects ready to port into the new game by 2019.

[buzz456]

I needed that this morning.

[NS349]

Question here: So If I am understanding it correctly as of right now, TS2017 will be a new yet separate from the other updates? In other words, say all the dlc and freeware routes/repaints/sounds etc... Those will stay with TS2016 but not move on with TS2017 as it did with TS2012 to present correct? That TS2017 will be a completely different game engine?

[ZekTheKid]

Question here: So If I am understanding it correctly as of right now, TS2017 will be a new yet separate from the other updates? In other words, say all the dlc and freeware routes/repaints/sounds etc... Those will stay with TS2016 but not move on with TS2017 as it did with TS2012 to present correct? That TS2017 will be a completely different game engine?

TS 2017 is just another DLC vamp for the exiting sim. But if you're talking about the new sim, TSW, then yes it is a new game engine; unreal 4.

[NS349]

Question here: So If I am understanding it correctly as of right now, TS2017 will be a new yet separate from the other updates? In other words, say all the dlc and freeware routes/repaints/sounds etc... Those will stay with TS2016 but not move on with TS2017 as it did with TS2012 to present correct? That TS2017 will be a completely different game engine?

TS 2017 is just another DLC vamp for the exiting sim. But if you're talking about the new sim, TSW, then RS it is a new game engine; unreal 4.

So will you still be able to access the content in TS2016 and not lose any of the addons etc?

[ZekTheKid]

Question here: So If I am understanding it correctly as of right now, TS2017 will be a new yet separate from the other updates? In other words, say all the dlc and freeware routes/repaints/sounds etc... Those will stay with TS2016 but not move on with TS2017 as it did with TS2012 to present correct? That TS2017 will be a completely different game engine?

TS 2017 is just another DLC vamp for the exiting sim. But if you're talking about the new sim, TSW, then RS it is a new game engine; unreal 4.

So will you still be able to access the content in TS2016 and not lose any of the addons etc?

Yes. But in TSW there is no backward compatibility, so no TS addons in TSW.