Friday Facts #230 - Engine modernisation

Regular reports on Factorio development.

Re: Friday Facts #230 - Engine modernisation

Postby Keks » Sat Feb 17, 2018 8:12 pm

posila wrote:
admo wrote:but no DX10 support means no Vista support too.

XP support went together with 32bit support. As far as I know DX11 is available also for Vista. But I wouldn't mind dropping Vista altogether :)


and then someone will come to the forum telling all of us how he/she dropped Vista because Factorio wasn't compatible anymore an you'll have yet another thing to be proud of.
Keks
Burner Inserter
Burner Inserter
 
Posts: 17
Joined: Sun Sep 27, 2015 12:55 pm

Re: Friday Facts #230 - Engine modernisation

Postby PunPun » Sat Feb 17, 2018 10:53 pm

Keks wrote:
posila wrote:
admo wrote:but no DX10 support means no Vista support too.

XP support went together with 32bit support. As far as I know DX11 is available also for Vista. But I wouldn't mind dropping Vista altogether :)


and then someone will come to the forum telling all of us how he/she dropped Vista because Factorio wasn't compatible anymore an you'll have yet another thing to be proud of.

Except opengl3.2 is supported in vista and even xp so factorio would work just fine.
PunPun
Burner Inserter
Burner Inserter
 
Posts: 10
Joined: Sun Mar 27, 2016 7:08 pm

Re: Friday Facts #230 - Engine modernisation

Postby Tekky » Sun Feb 18, 2018 11:36 am

I am happy to hear that Factorio will no longer be using Allegro, because it was causing a serious v-sync bug with me that the devs were unable to fix (except by getting rid of Allegro).
Tekky
Filter Inserter
Filter Inserter
 
Posts: 731
Joined: Sun Jul 31, 2016 10:53 am

Re: Friday Facts #230 - Engine modernisation

Postby bman212121 » Sun Feb 18, 2018 5:15 pm

posila wrote:
bobingabout wrote:Point of interest. no DX9 means no Windows XP support.... no big deal there really, since there's already no 32bit support.

but no DX10 support means no Vista support too.

XP support went together with 32bit support. As far as I know DX11 is available also for Vista. But I wouldn't mind dropping Vista altogether :)


I don't really see too many people falling into the Vista trap anyway. The real limitation that Factorio faces is memory bandwidth, so you're probably not playing it on a system that shipped with Vista, because that means it also had DDR2. I tried launching a late game map I had on a Q6600 system with 8GB of DDR2, and it wasn't possible for that computer to ever catch up. (The catching up bar actually goes backwards, and will slowly but surely lose the battle) The same map is completely playable on a low end dual core i7 in a laptop with 8GB of DDR3. The single threaded performance of the laptop is definitely lower, but it has higher memory bandwidth.

So if you just happen to have say a Q8400 that shipped with Vista 64 bit, I do see they could install an update to enable DX11. It's linked in a Microsoft thread here:
https://answers.microsoft.com/en-us/win ... 337?auth=1

But I question anyone having an older system than that which is capable of running Factorio without being modified. If you had a Q6600 or E6600 it probably only shipped with 2GB of memory, and Vista 32 bit, so you've already had to modify it to even get it to run the game. Not to mention that a Vista system would not have shipped with a DX11 compatible graphics card. If you can find the memory and graphics card to make the game run, it shouldn't be too hard to find a cheap copy of Windows 7 64 bit either. (You don't have to, but it's probably not a bad idea either way) If you have no money to spend though, you should still be able to even just download the Linux version in Windows, then fire up a live CD / USB with a Linux Distro. Most of them these days should allow you to read / write from a windows partition, so you can store your Linux game folder and saves on your hard drive, but still play the game as best as you can.

To support DX11 you need either an AMD HD5xxx series or higher, or an Nvidia GTX 4xx series or higher. So realistically I'd say the lowest specs for Factorio would end up being something like this:

Windows 7 64 bit
Intel Core 2 Duo P8400 or equivalent
4GB DDR3
AMD HD5450 or Nvidia GT 420
2GB of free space


I don't even see that playing well, but it's probably tolerable. That would be a realistic OEM system you might have been able to cobble together around 2010 or so. If you wanted to try something older you certainly can, but there is no doubt you'd have to cut the UPS in half to stand a chance.
bman212121
Long Handed Inserter
Long Handed Inserter
 
Posts: 76
Joined: Mon Apr 18, 2016 8:08 pm

Re: Friday Facts #230 - Engine modernisation

Postby Inverness » Sun Feb 18, 2018 6:44 pm

You can use the DirectX 11 API to target DirectX 10 hardware AFAIK.
User avatar
Inverness
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Mon Jan 15, 2018 12:17 am

Re: Friday Facts #230 - Engine modernisation

Postby Oktokolo » Sun Feb 18, 2018 9:26 pm

bman212121 wrote:I tried launching a late game map I had on a Q6600 system with 8GB of DDR2, and it wasn't possible for that computer to ever catch up.

My gaming rig (wich i currently use for every game except Factorio) is a Core2Quad with 8 GiB of DDR2 too. It can't handle multiplayer because of the UPS drops. But i used it to start my first rocket.
With lowered expectations and when not planning to build a mega base, Factorio singleplayer is still feasible on such ole boxes - even more so when playing the experimental branch containing the latest UPS optimizations.


Rewriting the Visualization part of the engine has potential for all sorts of FPS boosts and surely reduces the lines of code used for getting the game on the screen. Less lines almost always lead to less bugs.
I like more FPS and less bugs. :)
But make sure to keep support for Windows 7 - so there is a fallback for players wich did not switch to Linux yet...
Oktokolo
Fast Inserter
Fast Inserter
 
Posts: 216
Joined: Wed Jul 12, 2017 5:45 pm

Re: Friday Facts #230 - Engine modernisation

Postby PurpleGreen » Sun Feb 18, 2018 10:06 pm

Keks wrote:
posila wrote:
admo wrote:but no DX10 support means no Vista support too.

XP support went together with 32bit support. As far as I know DX11 is available also for Vista. But I wouldn't mind dropping Vista altogether :)


and then someone will come to the forum telling all of us how he/she dropped Vista because Factorio wasn't compatible anymore an you'll have yet another thing to be proud of.


haha ... you made my day xD xD
PurpleGreen
Inserter
Inserter
 
Posts: 29
Joined: Thu Jun 15, 2017 4:32 pm

Re: Friday Facts #230 - Engine modernisation

Postby foodfactorio » Mon Feb 19, 2018 5:38 am

Oktokolo wrote:
bman212121 wrote:But make sure to keep support for Windows 7 - so there is a fallback for players wich did not switch to Linux yet...


yeah please keep support for win 7 and all my friends use it too,
directx 9 has always worked really well (for me at least) and other games like civilisation and xcom (the new ones) using later direct x always seem to crash, and theres even a huge hundredsof pages or thousands of posts from people on the steam forums about crashing before the 1st 5minutes.
(also me from the mod portal - im not dustine lol) = https://mods.factorio.com/mods/Dustine/ ... ssion/9108
my 1st Mod Idea :) viewtopic.php?f=33&t=50256
foodfactorio
Filter Inserter
Filter Inserter
 
Posts: 319
Joined: Tue Jun 20, 2017 1:56 am

Re: Friday Facts #230 - Engine modernisation

Postby bobingabout » Mon Feb 19, 2018 9:36 am

They front 3 letters of the upside down logo say tyc, which makes me think Tycoon. Are we playing Factory Tycoon anyone?
No matter what you do, you can't please everyone.
User avatar
bobingabout
Smart Inserter
Smart Inserter
 
Posts: 5697
Joined: Fri May 09, 2014 1:01 pm
Location: England

Re: Friday Facts #230 - Engine modernisation

Postby ratchetfreak » Mon Feb 19, 2018 10:03 am

Inglonias wrote:I can't even bring myself to tear apart a factory to fix it, much less tear apart the rendering engine to a game that's been in the works for as long as this one. I would have shrieked in horror and ran away from your office screaming if you asked me to do that. Bravo, Factorio devs, for being made of sterner stuff than I.

And whenever anyone talks about computer graphics code, I have to bring up one of my favorite pieces of computer code that I've ever laid eyes on and failed to understand: the Fast Inverse Square Root function.


tl;dr there is that the floating point representation is a approximation of the logarithm of the number with a fixed point representation, you can use that to get close to the sqrt and then do a few Newton-Raphson iterations to close in on the result.

ili wrote:I don't know anything about game coding.
Just wanted to ask what is the difference between coding for OpenGL 3.2 VS Vulkan?
Is Vulkan harder to do?


opengl is at its core very much an immediate mode API with synchronous roots, this means that the user code can act like a squirrel and just hop from one place to another and the driver has to play catch-up

vulkan requires that user code is much more deliberate with how you setup you rendering architecture. It also has a few obvious code smells that point to bad design. For example If you have a vkCreateGraphicsPipeline call in your render loop you are doing it wrong. Instead you are supposed to create those pipeline objects in advance (you can do that on a separate thread to avoid burdening the render thread) and then bind them as needed. It also forces you to do your own double buffering of render data or eat a gpu->cpu sync bubble every frame.
ratchetfreak
Filter Inserter
Filter Inserter
 
Posts: 890
Joined: Sat May 23, 2015 12:10 pm

Re: Friday Facts #230 - Engine modernisation

Postby PunPun » Mon Feb 19, 2018 6:07 pm

ratchetfreak wrote:opengl is at its core very much an immediate mode API with synchronous roots, this means that the user code can act like a squirrel and just hop from one place to another and the driver has to play catch-up

Not true. Since opengl3.0 "immideate mode" is no longer part of the core profile and is only present in compatibility profile. The main differences between opengl and vulkan is that in vulkan you need to handle all the cpu side memory yourself and decide yourself when to transfer what bits to vram etc when opengl handles this at the driver level. In opengl all you need to do is tell the driver that this bit of memory might be needed sometime in the future and it will try to predict when is the best time to put it in vram.

Opengl also always makes sure that before you actually draw something the assosiated buffers are present on vram. In vulkan you have to do that yourself. For example you if you want a textured triangle in opengl you call a function to give the driver the vertex buffers containing the data for the triangle and texture coordinates and another function to give it the texture data and another to specify what shaders to use and so on and when you call draw the driver makes sure everything is on vram before it is needed and if its not it delays execution until it is. In vulkan there is no handholding and you have to manage everything yourself.

And this is the reason vulkan can get more performance out of a gpu with less cpu overhead. The driver does not have to do any guesswork on what when or why so less cpu power is needed. And since the human coding the program knows exactly when something is needed and when something can be thrown away there are less gpu stalls because of misprediction of what data is needed on the vram next.

So in conclusion with vulkan you can squeeze a little more performance out of the hardware at the cost of a lot of workhours and with a game like factorio there is really no need for that. The performance boost you get from switching from gl1.2 to gl3.2 is more than enough for factorio to be cpu and memorybound for a very long time.
PunPun
Burner Inserter
Burner Inserter
 
Posts: 10
Joined: Sun Mar 27, 2016 7:08 pm

Re: Friday Facts #230 - Engine modernisation

Postby leoch » Mon Feb 19, 2018 6:40 pm

Maybe you should consider jumping technology at some point: http://arewegameyet.com/
GFX looks quite promising and there are a couple of windowing libraries.

I'm hoping Factorio 2 will use 3D rendering from the start :D
leoch
Fast Inserter
Fast Inserter
 
Posts: 120
Joined: Fri Dec 16, 2016 9:37 pm

Re: Friday Facts #230 - Engine modernisation

Postby kellerkindt » Mon Feb 26, 2018 8:14 pm

Well, this just dropped: https://www.khronos.org/news/press/vulk ... -platforms

One Vulkan Renderer is now sufficient for all three platforms..

SDL also added support for Vulkan on MacOS: https://twitter.com/sdl_commits/status/ ... 1947165696
kellerkindt
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Fri Feb 16, 2018 5:49 pm

Re: Friday Facts #230 - Engine modernisation

Postby Jürgen Erhard » Mon Mar 05, 2018 1:41 am

So, release in 2019?

Changing engine is always a recipe for disaster delays. Time and time again. Let's hope this (as pretty much everything Factorio, so there's that bit of hope) runs a lot smoother than should be expected.
Jürgen Erhard
Fast Inserter
Fast Inserter
 
Posts: 231
Joined: Sun Jun 12, 2016 11:29 pm

Re: Friday Facts #230 - Engine modernisation

Postby Oktokolo » Mon Mar 05, 2018 10:34 am

Jürgen Erhard wrote:So, release in 2019?

The new engine will be included in 0.17. And that is expected to hit experimental at fall (or xmas because timing matters) - this year!

The common AAA game company could even go bankrupt over an engine change.
But Wube is not a regular franchise-milking game company. They are a real game forge.
Oktokolo
Fast Inserter
Fast Inserter
 
Posts: 216
Joined: Wed Jul 12, 2017 5:45 pm

Re: Friday Facts #230 - Engine modernisation

Postby SuicideJunkie » Tue Mar 06, 2018 12:04 am

Gergely wrote:Wow. They are very good at this.

From what I can see on the screenshots, the first one was definitely unintentional, the second as well but the third...

I do not think the third was unintentional.
It looks remarkably similar to the Factorio demo as it ran on my last PC, except that the player character is visible this time.
SuicideJunkie
Long Handed Inserter
Long Handed Inserter
 
Posts: 50
Joined: Wed Aug 23, 2017 10:17 pm

Re: Friday Facts #230 - Engine modernisation

Postby rkapl » Thu Apr 05, 2018 8:16 pm

I wish that the new SDL renderer will have a true fullscreen. It feels a bit snappier that way and it allows you to have lower resolution for the game.

But maybe the lower resolution will not matter anymore with the new gfx engine. :)
rkapl
Manual Inserter
Manual Inserter
 
Posts: 1
Joined: Thu Apr 05, 2018 8:13 pm

Re: Friday Facts #230 - Engine modernisation

Postby sthalik » Sun May 06, 2018 5:00 pm

kellerkindt wrote:Well, this just dropped: https://www.khronos.org/news/press/vulk ... -platforms

One Vulkan Renderer is now sufficient for all three platforms..


There's no real benefit over glMultiDraw* family of functions, for the Factorio use-case. It's enough to use a GL 4.3+ core context to do things right. It depends on what the developers find themselves more comfortable with.

As for the Vulkan API itself -- I've read the tutorial and some docs. I've no idea why it's considered harder than GL. It even allows for a customizable pipeline. Doesn't seem hard, and the C as well as C++ APIs are good. Gets rid of GL integer object identifiers.

leoch wrote:Maybe you should consider jumping technology at some point: http://arewegameyet.com/


Rust isn't halfway ready yet. The borrow checker still gets in the way when it shouldn't, even after the MIR change. I'd like to see some large codebase from typical C++ developers, and their comments on Rust. Are there migration experiences written already?

rkapl wrote:I wish that the new SDL renderer will have a true fullscreen. It feels a bit snappier that way and it allows you to have lower resolution for the game.

But maybe the lower resolution will not matter anymore with the new gfx engine. :)


See posila's response to my thread. It's very promising!
sthalik
Inserter
Inserter
 
Posts: 46
Joined: Tue May 01, 2018 9:32 am
Location: Poznan, Potato, Poland

Re: Friday Facts #230 - Engine modernisation

Postby ratchetfreak » Mon May 07, 2018 8:34 am

sthalik wrote:
kellerkindt wrote:Well, this just dropped: https://www.khronos.org/news/press/vulk ... -platforms

One Vulkan Renderer is now sufficient for all three platforms..


There's no real benefit over glMultiDraw* family of functions, for the Factorio use-case. It's enough to use a GL 4.3+ core context to do things right. It depends on what the developers find themselves more comfortable with.

As for the Vulkan API itself -- I've read the tutorial and some docs. I've no idea why it's considered harder than GL. It even allows for a customizable pipeline. Doesn't seem hard, and the C as well as C++ APIs are good. Gets rid of GL integer object identifiers.

The big reason is that the hello triangle program is easily around 1000 lines of code. The majority of which is filling in the structs and various bits of busywork.

The next reason is that the user has to keep synchronization straight. It is truly a async work api where you submit bits of work to be executed and then need to synchronize access to the data between each execution unit (between vkQueues and even subsequent commands)
ratchetfreak
Filter Inserter
Filter Inserter
 
Posts: 890
Joined: Sat May 23, 2015 12:10 pm

Re: Friday Facts #230 - Engine modernisation

Postby sthalik » Tue May 08, 2018 2:50 am

ratchetfreak wrote:
sthalik wrote:The big reason is that the hello triangle program is easily around 1000 lines of code. The majority of which is filling in the structs and various bits of busywork.

The next reason is that the user has to keep synchronization straight. It is truly a async work api where you submit bits of work to be executed and then need to synchronize access to the data between each execution unit (between vkQueues and even subsequent commands)


There are multiple C++11 wrappers that avoid the boilerplate code. Using the C API is pain though.

The synchronization primitives are straightforward I think. Put in a fence after a batch to see if it's done. Also, the need for a state machine is avoided with libraries like Boost's Coroutine2. Then it works like .NET's "await" keyword or asio itself.

I also saw slides on how to do memory management without immense pain in Vulkan. Apparently certain allocation flag combinations make it more usable to just load assets.
sthalik
Inserter
Inserter
 
Posts: 46
Joined: Tue May 01, 2018 9:32 am
Location: Poznan, Potato, Poland

PreviousNext

Return to News

Who is online

Users browsing this forum: No registered users and 7 guests