Quoting: TheRiddickWondering if the GL Threading patch that's being worked on could help this title since its CPU bounded pretty hard?

As I said in my previous comment, multi-threaded OpenGL is not really the problem here. Sure, multi-threaded rendering would help, but not that much. A 3D engine is just a part of the whole engine, multi-threading it is good, but it's not the silver bullet you would expect.

It's the whole engine that has to be multi-threaded and take the most of the CPU cores. And if OpenGL is a problem, you keep it synchronized on one core. Yes, it's going to be a bottleneck, but at least everything else in your frame has been multi-threaded and that is here that you will win the most.

Actually, I would really be interested in CPU consumption on Windows. If it's the same as on Linux, it means that Aspyr simply did their best, but if it has multi-threading, it means that Aspyr could really do better with their ports.

View this comment - View article - View full comments

Quoting: liamdawe

Quoting: M@GOid

Quoting: liamdawe

Quoting: M@GOidMultithread is bad in OpenGL? Well, call me skeptical on that.

Anyway, 4A and Feral did it, so technically OpenGL is not blocking a multicore CPU utilization in Civilization VI.

Seriously? Go do some real research you're rather wrong.

Calm down man, I didn't mean to be disrespectful. If I was wrong you could explained why in a more relaxed tone, like M@yeulC did.

I'm perfectly calm :). Just don't see the need to repeat details that are basically common knowledge. I did already say to watch the video of Dave from Red Hat talking. Both Aspyr and Feral have previously explained limitations of OpenGL as have many others. Khronos themselves said about when giving the benefits of Vulkan. It goes on and on.

I think something was miscommunicated at some point.

OpenGL does have a problem with multi-threading, but it doesn't mean that you absolutely can't do anything on the other threads. Multi-threading is a problem with OpenGL when CPU-GPU communications are involved. But CPU-CPU communications are completely allowed. For instance the animations are very often just CPU-only, and for this, it's possible to send jobs on other threads that will compute the animations and get the result before the render pass. And depending on the engine, you can multi-thread quite a bunch of things. In an engine, the 3D part is just a small, important part of the whole, but not everything revolve around this 3D part.

I'll try to find some documentation to prove my point.

Edit:
This codeproject article is a good example that OpenGL and multi-threading are possible:
https://www.codeproject.com/articles/15344/a-multithreaded-opengl-enabled-application

And this too:
http://gamedev.stackexchange.com/questions/90762/taking-advantage-of-multithreading-between-game-loop-and-opengl

Edit 2:
All that to say that I'm pretty disappointed by the CPU usage of the Civ VI port. I would really like to hear from the Asypr devs about why they couldn't multi-thread a little bit more. Normally, when you optimize your engine, you try to max out your CPU cores. In a game engine, a core that does nothing is a wasted resource.

View this comment - View article - View full comments

They made me a Linux build for me to test, it did work on my machine! So they probably won't encounter much problem to do the port. But they are only two, that's why right now they're focusing on the stability and the features of the game.

On their latest version (on itch.io) they have quite a few more features that isn't shown in the trailer video, including boost pads, track curvature (tubes and tunnels), different track widths, etc..

View this comment - View article - View full comments

Quoting: GuestYou have no idea what you are talking about and just want to troll… That’s sad.

As a matter of fact I do have a very good idea of what I'm talking about. Maybe what you wanted to say was that we have different opinions.

@Schmerl I completely agree with you, making a game editor is an educational process and it might even become a brilliant open source project in the end. Hell, I even started to do one myself. It's just that I wouldn't advise that to a brand new game studio. I would advise to first get the games you want to make, get the money, and then, when you're financially stable, code your own game engine if you like it. Because making your first game often means that you won't receive any money for a long period of time. I'm not saying that it should not be done at all, especially since I think that competition is good, so let's go and create competitors to these other game editors. I'm just saying that it's a risk to do it along with your first game, that's all.

@ShabbyX I hope one day I'll see the light ;)

View this comment - View article - View full comments

Quoting: GuestMaking your own engine has many benefits, and using a pre-made engine isn’t free either.

Many benefits and many disadvantages. The first of all being that you don't work on you game, but on your engine, although the game is your end product. The other one being that you're the one in charge of debugging and upgrading your engine (say to convert it to Vulkan or to port it to a new platform like Linux, PS4, Xbox One, ...).

The list of cons is very very long, and ownership and money is the only two main pros. It's a decision that need to be well thought and, in most case, it is only taken based on the ego (a.k.a. "I made this!", a.k.a. NIH syndrome) and hidden behind "commercial game editors cost a lot". But the bottom line is very simple: take your hour salary and multiply it by the amount of hours you've worked on the engine and not your game. Is it really worth it?

Modern days are so complex nowadays (and I'm talking about AIs, gameplay, story, graphics, sounds, etc... not even about the engine) that developing your own game engine for your game is a bit like developing your own browser for your website. I'm sure there are a few pros as well, but I doubt they will ever overcome the cons.

Edit: reformulations and typos

View this comment - View article - View full comments

Quoting: edoIts very cool than the game use its own engine.

IMO, I don't think a young game studio should make its own engine. It's very hard to compete with the man-years (man-decades!) invested in engines like Unreal and Unity. There is a particularly strong NIH syndrome among the game developers. Maybe because they are less involved with open source software...

So unless you can't do your game on one of these engines, I don't really see the point, except for the sake of learning how to make a game engine, but that is risky bet to take if you want to sell games at some point.

Quoting: natewardawgif the message is communicated clearly from the developer, they may not read it, or may misread it

It seems like a waste of time at first, but coding a messaging system directly in the game should improve drastically this kind of problem. Having a popup saying "Here's new since version x.y.z".

View this comment - View article - View full comments

Quoting: ShmerlIt's a matter of preference. Between pcregrep and nvim itself, it's pretty doable, and doing it with "one click" sounds rather risky, unless IDE really knows what to do. Things can get really messed up if it doesn't.

Can't say anything about VisuallAssist though. I didn't touch VisualStudio like forever.

One click, and Ctrl+Z if something bad happened ;)
And anyway, never trust your software blindly and always verify and test your changes before committing ;)

View this comment - View article - View full comments

Quoting: Phitherek_I'd suggest looking into JetBrains IDEs. I use IntelliJ IDEA on the daily basis on Linux and it's great. As I suppose the dev's programming language is C++, I would suggest CLion.

True. It's expensive, but I think it's worth it.

I'll be very happy when an open source IDE will match that quality though ;)

View this comment - View article - View full comments

Thanks for this interview, it's really cool and maybe it will encourage my friends to port their game to Linux a bit sooner ;)

About the IDEs, I really like Vim and I did try to use it as my main editor/IDE, and it took me some time to realize that Vim is not, and will never be, an IDE. It's an extremely powerful text editor, but you shouldn't try to make it more than that. To anyone saying the contrary or saying that Vim is just enough for coding, I invite them to use Visual Studio + Visual Assist. The most important missing feature in Vim is the refactoring capacity: finding all the reference to a variable/member/method/function and rename them in a click. This is really a deal breaker compared to vim+terminal+gdb.

And then there's the debugging part. gdb is plainly useless to me. I need a visual debugger. When debugging a several million lines project, remembering all the symbols is simply impossible.

To me, the best of both worlds are IDE with vim emulation for text edition. CLion is the only IDE I discovered recently that did things better than VS. Since I like GNOME, I'm also following GNOME Builder which seems very interesting.

View this comment - View article - View full comments

Quoting: MajGuanoBy this standard, yeah, it's a mediocre port. It's not bad. It runs. But it's not great, either. "Mediocre" doesn't mean "bad". It means "of ordinary or moderate quality". In this case, it might be slightly generous to call it "mediocre", since it's significantly worse than all other versions of A:I, as well as many other Feral products.

I admit that in French "mediocre" means worst than bad, that's why I thought you were pretty harsh on Feral.

I also love surround sound in my home cinema. Maybe Feral didn't update A:I, maybe A:I are using such technology that makes it difficult to have 5.1 in Linux (but I admit, that the former is more plausible, I'm afraid).

View this comment - View article - View full comments